Mozilla Rolls Back Firefox 37's Opportunistic Encryption Over Security Issue

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.

Comments

Opposite?

[DrYak]

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:Opposite?

[Dagger2]

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.

Re:Opposite?

[Dagger2]

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 contents. An active MITM is harder to pull off than passive sniffing, is obviously more evil, and is detectable, which makes this better than unsecured HTTP even if you don't get 100% perfect protection with it.)

DANE... [skip] DANE... [skip]

[chihowa]

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 opportunistic approach, but reliance on the CAs is what is making proper HTTPS, even if just for forms, underutilized.)

Sniffing doesn't work with OE

[DrYak]

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 apparently lack any authentication scheme. so it's trivial to throw a MITM attack.

OE isn't competing as being an alternative to HTTPS. (Https is the real deal if you want security).
OE is trying to be a tiny bit better than plain text over HTTP, and currently is a little bit better at preventing accidental eavesdrop.