Slashdot Mirror
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.
So thank s to OE I can see https in the url and no certificate warnings but it's actually not that safe at all? oh good that won't mislead users
Maybe the whole Mozilla organization should care a little less about *everything else* and go back writing, debugging and fixing what should have been a browser (and now is almost an half-assed Chrome clone).
You know, that kind of things developers used to do before shipping to users, not after.
Roll out a vulnerable "security" feature just long enough to get exploited?
Mission Complete!
Let us know how the NSA debriefing goes.
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Except MSIE is dead. And "Project Spartan" still doesn't have an official name.
Nobody uses it, yet it alredy causes vulnerabilities.
Have they forgotten that higher version numbers equals better software?
At this rate, we won't even be at version 50 by Christmas.
were have I read about that recently? Oh yeah, Hillary Clinton's "disappeared" email server with it's self-signed cert. Running Exchange 2010 MitM might not be very easy, but when you've got an entire country funding you (China, NK, Russia, etc) nothing like that is actually impossible.
Before integrating all the newest protocols, how about fixing decades old bugs to basic functions, like printing...? Since forever, when you print https pages, firefox will print the first, and last one, and nothing in between.(it's not on all https pages, but it's on enough that it's a major anyoance) Other browsers have no problems with the same pages, so it's a FF problem. Bugs related to this have been opened since 2004, 11 years ago! And again, you get answer to the bug to the likes of "we got too much on our plate right now to take a look at this" 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?
hmmm.... ... it's means it is....
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
hmmm.... ... it's means it is....
"It depends on what the meaning of the word 'is' is." -Clinton
But by disabling OE and falling back to completely unprotected plaintext, attackers lose the ability to MitM, thereby fixing the problem?
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.)
If you want a vision of the future, imagine a youtube comments section scrolling - forever.
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
decent idea, but seriously flawed implementation (and lack of thinking through sufficient non-sunny-day scenarios).