New Firefox version says “might as well” to encrypting all Web traffic | Ars Technica
Developers of the Firefox browser have moved one step closer to an Internet that encrypts all the world's traffic with a new feature that can cryptographically protect connections even when servers don't support the HTTPS protocol.
Further Reading
Opportunistic encryption, as the feature is known, acts as a bridge between plaintext HTTP connections and fully compliant HTTPS connections based on transport layer security or its predecessor, protocol secure sockets layer. These traditional Web-based encryption measures require site operators to obtain a digital credential issued by a browser-recognized certificate authority and to implement TLS protection through OpenSSL or a similar code library. Even then, many sites are unable to fully encrypt their pages because they embed ads and other third-party content that's still transmitted in plaintext. As a result, large numbers of sites (including this one) continue to publish some or all of their content in HTTP, which can be readily manipulated by people with the ability to monitor the connection.OE, as opportunistic encryption is often abbreviated, was turned on by default in Firefox 37, which was released this week. The move comes 17 months after an Internet Engineering Task Force working group proposed OE become an official part of the HTTP 2.0 specification. The move garnered critics and supporters alike, with the former arguing it may delay some sites from using the more secure HTTPS protections and the latter saying, in effect, some protection is better than none. The chief shortcoming of OE is its lack of authentication for cryptographically validating that a connected server is operated by the organization claiming ownership.
In a recent blog post, Mozilla developer Patrick McManus laid out some of the thinking and technical details behind the move to support HTTP 2 in Firefox:
OE provides unauthenticated encryption over TLS for data that would otherwise be carried via clear text. This creates some confidentiality in the face of passive eavesdropping and also provides you much better integrity protection for your data than raw TCP does when dealing with random network noise. The server setup for it is trivial.
These are indeed nice bonuses for http:// - but it still isn't as nice as https://. If you can run https you should - full stop. Don't make me repeat it :) Only https protects you from active man in the middle attackers.
But if you have long tail of legacy content that you cannot yet get migrated to https, commonly due to mixed-content rules and interactions with third parties, OE provides a mechanism for an encrypted transport of http:// data. That's a strict improvement over the cleartext alternative.
Two simple steps to configure a server for OE
- Install a TLS based h2 or spdy server on a separate port. 443 is a good choice :). You can use a self-signed certificate if you like because OE is not authenticated.
- Add a response header Alt-Svc: h2=":443" or spdy/3.1 if you are using a spdy enabled server like nginx.
When the browser consumes that response header it will start to verify the fact that there is a HTTP/2 service on port 443. When a session with that port is established it will start routing the requests it would normally send in cleartext to port 80 onto port 443 with encryption instead. There will be no delay in responsiveness because the new connection is fully established in the background before being used. If the alternative service (port 443) becomes unavailable or cannot be verified Firefox will automatically return to using cleartext on port 80. Clients that don't speak the right protocols just ignore the header and continue to use port 80.
This mapping is saved and used in the future. It is important to understand that while the transaction is being routed to a different port the origin of the resource hasn't changed (i.e. if the cleartext origin was http://www.example.com:80 then the origin, including the http scheme and the port 80, are unchanged even if it routed to port 443 over TLS). OE is not available with HTTP/1 servers because that protocol does not carry the scheme as part of each transaction which is a necessary ingredient for the Alt-Svc approach.
McManus may be overstating the ease many site operators will have in supporting OE. At the moment, implementing HTTP 2 is anything but trivial, mainly because popular Web servers such as Apache and nginx don't yet ship with HTTP 2 support. Still, Mozilla's overture is a start. In February, McManus said nine percent of all Firefox release channel HTTP transactions were already happening over HTTP 2, as users with Firefox 35 or 36 beta connected to sites, such as Google and Twitter, that had implemented the updated protocol. Now that Mozilla offers fuller support in version 37, OE could gain wider use.