Mozilla Foundation just released it’s latest Firefox (Version 37.0). 
It’s been rolled out for Windows, Mac, Linux and Android operating systems. Those who don’t know, it was released on the week of March 31st. Well to be honest, as of writing this article, Version 37.0.1 was already out on April 3, 2015 that fixed 2 more issues since.
Firefox 37 disabled insecure TLS version fallback for site security by default and improved protection against site impersonation via OneCRL centralized certificate revocation. It removed support for DSA which improves certificate and TLS communication security. All in all, a massive overhaul was done in SSL and TLS security space.
Fixed in Firefox 37.0.1
- 2015-44 Certificate verification bypass through the HTTP/2 Alt-Svc header
- 2015-43 Loading privileged content through Reader mode
Firefox Notes for V 37.0
- Changed – Disabled insecure TLS version fallback for site security
- Changed – Improved performance of WebGL rendering on Windows
- Changed – Improved certificate and TLS communication security by removing support for DSA
- Changed – Extended SSL error reporting for reporting non-certificate errors
- Changed – TLS False Start optimization now requires a cipher suite using AEAD construction
A total of 13 security bugs were fixed. Amongst those, Cursor clickjacking with flash and images was used in malicious Advertisement to steal clicks. It was also used for Facebook and Twitter click-jacking. See list below for Firefox security advisories and fix details:
Fixed in Firefox 37
- 2015-42 Windows can retain access to privileged content on navigation to unprivileged pages
- 2015-41 PRNG weakness allows for DNS poisoning on Android
- 2015-40 Same-origin bypass through anchor navigation
- 2015-39 Use-after-free due to type confusion flaws
- 2015-38 Memory corruption crashes in Off Main Thread Compositing
- 2015-37 CORS requests should not follow 30x redirections after preflight
- 2015-36 Incorrect memory management for simple-type arrays in WebRTC
- 2015-35 Cursor clickjacking with flash and images
- 2015-34 Out of bounds read in QCMS library
- 2015-33 resource:// documents can load privileged pages
- 2015-32 Add-on lightweight theme installation approval bypassed through MITM attack
- 2015-31 Use-after-free when using the Fluendo MP3 GStreamer plugin
- 2015-30 Miscellaneous memory safety hazards (rv:37.0 / rv:31.6)
However the biggest new right now is the ability to browse web through opportunistic encryption of some https:// based resources. 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 https:// – 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 https:// 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 https://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.
You can control some details about how long the Alt-Svc mappings last and some other details. The Internet-Draft is helpful as a reference. As the technology matures we will be tracking it; the recent HTTP working group meeting in Dallas decided this was ready to proceed to last call status in the working group.