Mozilla Rolls Back Firefox 37's Opportunistic Encryption Over Security Issue 42
darthcamaro writes: Barely a week ago, Mozilla released Firefox 37, which had a key new feature called opportunistic encryption. The basic idea is that it will do some baseline encryption for data that would have otherwise been sent by a user via clear text. Unfortunately, Mozilla has already issued Firefox 37.0.1, which removes opportunistic encryption. A security vulnerability was reported in the underlying Alternative Services capability that helps to enable opportunistic encryption. "If an Alt-Svc header is specified in the HTTP/2 response, SSL certificate verification can be bypassed for the specified alternate server. As a result of this, warnings of invalid SSL certificates will not be displayed and an attacker could potentially impersonate another site through a man-in-the-middle, replacing the original certificate with their own." They plan to re-enable opportunistic encryption when this issue is investigated and fixed.
Opposite? (Score:5, Informative)
From what I understand how this is supposed to work, it's the opposite:
I think it's: you type a simple *http* address, the website behaves like a plain normal one. (so no https address, nothing misleading you into thinking you are using secure https website)
But when you submit data to it, the browser will automatically switch on-the-fly to an alternate, encrypted route, so the data is sent encrypted to a alternate destination handling encryption.
It's not a full blown https, but it's better than nothing.
Think of it as "https-lite" for sending data. Designed for server which can afford having a full blown https stack.
Except, that the thing is so much simplified that there aren't enough checks in this protocol. So a third party could use the feature to re-route data to their eavesdropping infrastructure, instead of re-routing it to an encryption feature on the original http server.
Re: (Score:2)
But when you submit data to it, the browser will automatically switch on-the-fly to an alternate, encrypted route, so the data is sent encrypted to a alternate destination handling encryption.
What benefit does that have over regular HTTPs? Why is this different from just having the submit URL be HTTPs? And wouldn't a security-aware user refuse to click submit when they saw the page wasn't encrypted?
Thanks for the explanation. I've been reading about this since I saw the Slashdot headline a few days ago and I'm just not getting it.
Re: Opposite? (Score:2)
It's good for nonfinancial/pii websites that can't afford SSL certs, but may have contact forms, website logins, etc. Where users may type in their (hopefully different from their banks) user name and passwords... Or email address, or plaintext commentary in a forum that they may not necessarily care if it's encrypted or not.
Is not intended for sites you really need or want security. I really see this as a benefit to helping protect people who use the same password for everything -- helping, in this case, j
Re: (Score:2)
How is this better than I'm unclear HTTPS with a self-signed cert? It seems like a convoluted way to suppress a certificate prompt.
Re: (Score:3)
Valid certificate not required. In particular this means you can use self-signed certs without a big massive warning.
Obviously a valid certificate via https:// is better, but if your choice is between a self-signed cert that throws a big warning and unsecured http://, you're going to choose the latter. Alt-Svc adds the option of delivering your http:// site over an encrypted connection.
(Nitpicker's corner: yes, the connection will be unauthenticated, which yes, means an active MITM can still read the conten
DANE... [skip] DANE... [skip] (Score:3)
I hate to sound like a broken record here, but this is a problem than can be easily solved with DANE (or certificate pinning or CT...). If you make a positive assertion about the legitimacy of your self-signed certificate in DNS, you can have the authentication of a CA-signed certificate without the associated expense.
With DANE, you (the domain owner) are acting as the authority who vouches for your certificate instead of (or in addition to) one of the many CAs.
(I know that this is supposed to be an opportu
Re: (Score:2)
But surely anyone able to perform an MITM attack on the key can also perform a MITM attack on DNS, since it's not authenticated? I presume you'd at least need DNSSEC to prevent that?
Re: (Score:2)
DANE [wikipedia.org] depends on DNSSEC, so the response is authenticated.
Re: (Score:2)
So we created this mechanism just to hide the certificate prompt? It seems like it would be better just to put text on the form that says "Hey, I used a self-signed certificate so ignore the message you see when you click submit" then just submit the form to an HTTP URL as usual. Alternatively, we could standardize on an HTML meta-attribute or HTTP header attribute that tells the browser to ignore the cert. No special browser feature required.
Surely I am missing something here.
Re: (Score:2)
No, we created it to make it actually possible to do unauthenticated encryption with self-signed certificates on public websites. Currently, nobody uses self-signed certs because of the invalid cert warnings.
<meta> tags or HTTP headers are sent after the SSL negotiation, so neither of them can change the negotiation behavior. (Putting text on the page telling people to ignore the warning doesn't work either, because they'd need to ignore the warning just to see the text.) The only way a new header is
Re: (Score:2)
The only way a new header is going to work is if you use http:/// [http] for the first request, and then include a header that tells the browser it can pull the same pages over TLS, but without doing authenticity checks on the certificate.
That's what I meant. Someone further up the comment chain said that is how OE works. First it connects with HTTP, then when "data is submitted" (I took that to mean a forms submission) it uses the OE.
So, in trying to understand the intent here:
No, we created it to make it actually possible to do unauthenticated encryption with self-signed certificates on public websites.
We already have that capability, but as you say:
Currently, nobody uses self-signed certs because of the invalid cert warnings.
So that seems to confirm that yes, the purpose of this is to hide the cert warnings. Am I missing something?
Aside: I just learned about dh_anon, which actually does not even require a certificate. Interesting.
Re: (Score:2)
I'd say the main purpose is to encrypt more stuff, and "not throwing a wobbly when you see a self-signed cert" is just a part of that. (Since you can't just turn off cert warnings and be done with it; you need some way to enable encryption without enabling authentication.)
It's not just for forms, or whatever "submit" was supposed to mean. All HTTP requests to the site except for the first one (per session? I'm not sure how long these headers are cached for) will go over TLS.
Re: (Score:3)
If you're at the point where you can insert arbitrary HTTP headers into a connection, you don't really need to insert a header that causes the client to make requests from one of your own servers in order to sniff the data in the connection. Just sniff the connection.
Sniffing doesn't work with OE (Score:3)
With OE, sniffing data doesn't work.
OE will encrypt the tiny bit that interests you, in the middle of an otherwise plain text connection.
So by simply passively listening to packets, you won't be able to gain access to the juicy parts, they will be the (only) encrypted part.
OE can prevent incident like google car which recorded sensitive information while logging data packets from non secure Wifi. Or attacks like FireSheep passively listening to clear text cookies in a internet café
But currently OE appa
Re: (Score:2)
Considering the short time it was up I don't see a major problem.
The main problem I see is that encrypted links are certified as being more secure than unencrypted when it comes to privileges in browsers because they aren't.
The basic idea as I see it with the Firefox browser doing opportunistic encryption is sound. The problem comes with all permutations of how it can be applied in a way that's transparent for the user.
We also have the problem with the chain of trust - not all CAs are trustworthy.
MSIE is dead (Score:2)
Except MSIE is dead [msdn.com]. And "Project Spartan" still doesn't have an official name.
Re: (Score:1)
Firefox died when they switched to version 4. It is now a buggy chrome-clone, but with even more tracking.
Re: (Score:1)
They can't bump to 38 until the built-in BitTorrent client is finished. 38.0.1 should have a couple of security fixes for that, plus a version of Gimp developed in PDFjs. I believe version 39 is slated to natively run Google Chrome.
hmmm...Man in the Middle attack... (Score:2)
Re: (Score:2)
hmmm.... ... it's means it is....
"It depends on what the meaning of the word 'is' is." -Clinton
How about fixing https printing first (Score:2)
Re: (Score:2)
If mozilla is looking for money, how about allowing us to pay, say, 40$ for one year where we get the privileges that the bugs we report are actually WORKED on?
Given their record, there's no way in hell I'd pay them for any bugs they haven't already fixed.
I would make a simple donation, but that won't happen until they start listening to the users, and take firefox in a sane direction again, so I don't anticipate it happening any time soon. Regardless, I'm not rewarding bad behavior. Right now they seem to be spending most of their time shitting up Firefox, I'm not paying for that.
It's not for a lack of money (Score:1)
For several years, Mozilla was getting about $700,000. a DAY from Google. They were rolling in money, and all they did was screw up the browser more and more.
Source: computerworld.com [computerworld.com]
Re: (Score:2)