SoylentNews is people
SoylentNews
from the it's-the-end-of-the-web-as-we-know-it-and-i-feel-fine dept.
Phoronix reports the Mozilla Security Engineering team is planning to make their browser useless for browsing much of the World Wide Web, by deprecating insecure HTTP.
Richard Barnes of Mozilla writes:
In order to encourage web developers to move from HTTP to HTTPS, I would like to propose establishing a deprecation plan for HTTP without security. Broadly speaking, this plan would entail limiting new features to secure contexts, followed by gradually removing legacy features from insecure contexts. Having an overall program for HTTP deprecation makes a clear statement to the web community that the time for plaintext is over -- it tells the world that the new web uses HTTPS, so if you want to use new things, you need to provide security.
See also this document outlining the initial plans.
(Score: 2, Insightful) by Anonymous Coward on Wednesday April 15 2015, @06:04AM
So line this schedule up with turning IPv4 off, since the limited IPv4 space cannot supply the unique address required to universally support HTTPS. And while you are at it, require DNSSEC and add UTF8 for domain names.
But one thing is for certain, the existing certificate authority system is broken. Just like you cannot move a locked domain to another registrar, any certificate authority should not be able to produce a valid certificate for any domain name. Certificate transparency is a step in the right direction, but a better solution is to require that the domain registrar sign the domain's certificate. The domain registrar could even provide a free, non-identification certificate (to be used for what we use plain HTTP for today).
Not every website needs or should have the level of identification validation provided by a certificate authority. For these websites, something like letsencrypt.org should provide the certificates until financial transactions or protected data is being transmitted. So let a free, automated, non-identification certificate authority such as letsencrypt.org or something else replace what we use HTTP for today, and reserve the secure lock shown on the web browser that we display for HTTPS today for certificates with identification verification and are signed by the domain registrar.
(Score: 0) by Anonymous Coward on Wednesday April 15 2015, @06:10AM
Except unique addresses aren't required anymore thanks to TLS and SNI. Only crippled crap-for-browsers like IE have trouble supporting that in older versions that, sadly, are still quite popular in the wild.
(Score: 0) by Anonymous Coward on Wednesday April 15 2015, @06:24AM
Do not forget mobile. Old phones have trouble with SNI.
SNI also requires server upgrades, user friendly domain admin tools gaining this functionality, and admins learning new things. It should not be hard to overcome. Servers should be running the latest stable releases anyway.
But people will still have to throw away their old smart-phones for IPv4 to be usable with SNI. These phones (that do not support SNI) usually support IPv6, so you would be supporting more devices by turning IPv4 off and force their web browsers to IPv6 without SNI. As IPv6 adoption is growing exponentially, by the time we phase out HTTP, IPv6 will be nearly everywhere.
(Score: 0) by Anonymous Coward on Wednesday April 15 2015, @07:02AM
And by smart phones, I also mean e-readers, iPod's, tablets, and other device specific OSs that manage the web browser for you. Really, these are out of date web browsers, vulnerable to attacks, and no longer supported, so maybe they should be thrown out. But that seems wasteful and not everyone is going to do that.
(Score: 2) by frojack on Wednesday April 15 2015, @07:00AM
So line this schedule up with turning IPv4 off, since the limited IPv4 space cannot supply the unique address required to universally support HTTPS.
Explain that last bit again?
Isn't https being handled virtually completely by IPV4 already?
No, you are mistaken. I've always had this sig.
(Score: 2, Informative) by Anonymous Coward on Wednesday April 15 2015, @07:21AM
With http, you can serve thousands of domains from one IP address. The Host: header in the http protocol tells the server which site you want.
With https, the encryption is started before the Host: header is transmitted, thus the correct certificate needs to be selected without knowing the Host: header. This limits you to to one domain per IP address, thus switching everything to https would require at least an order of magnitude more IP addresses.
There is a newer protocol that tries to solve this (SNI). But as long as anyone still uses Internet Explorer, it's not going to be of any use. Microsoft kinda tried to implement it, but somehow made it not a part of the update to Internet Explorer, so you'll only get it if you love Windows Tablet Edition (aka Windows 8).
(Score: 2) by gnuman on Wednesday April 15 2015, @04:05PM
There is a newer protocol that tries to solve this (SNI). But as long as anyone still uses Internet Explorer
IE supports SNI.
http://en.wikipedia.org/wiki/Server_Name_Indication#No_support [wikipedia.org]
So if you are not using IE 6 on XP, you are probably just fine.
(Score: 0) by Anonymous Coward on Wednesday April 15 2015, @07:34AM
Before we saw what the NSA was doing, before Google announced that it would penalize sites for not using HTTPS, and recently, China injecting DDoS code into HTTP traffic, websites only supported HTTPS if they needed to. One for those reasons is that without SNI, certificates are only good for a specific address and port number.
Because we like using standardized port numbers on the open Internet, and SNI support is poor for older web browsers and devices (smart phones, tablets, eReaders, etc.), you have to buy another IP address for each domain and subdomain. These cost anywhere from $1 to $5 per month for good reason. They are not plentiful. So the majority of domains share the IP address with dozens of other domains. Only 1 of that set can be configured for HTTPS (without SNI).
Consider how many domains there are on the Internet. Consider how few of them currently support HTTPS. Consider that this difference requires IPv4 addresses for each domain and subdomain to properly support older browsers and devices. Even for domains that support HTTPS, not all of their subdomains support HTTPS. There are not enough IPv4 addresses to put every domain name, including subdomains if you do not use expensive wildcard certificates, on its own IPv4 address.
Maybe Mozilla plans is to put this requirement far enough into the future where non-SNI devices do not exist or need to browse the web anymore. But at that time, IPv6 will be widely deployed, and you are more likely to have replaced your obsolete IPv4-only WiFi router with an IPv6 capable one for the 802.11ac, 802.11n, or whatever, and if you have not already done that, it might be preferable to do than throwing away older non-SNI devices, which may have locked DRM content still exclusively on them.