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: 5, Insightful) by Marand on Wednesday April 15 2015, @07:24AM
Reading the news or some static page about gardening or the news hardly warrants the effort.
In fact, I see very little content on the web that SHOULD be encrypted, but which isn't.
Secrecy is one reason to encrypt, but not the only one. Encryption also discourages certain bad behaviour like ISPS and other parties inserting advertisements into pages [google.com], for a common example. You also can't trust public access points not to mangle your traffic for personal gain; why not inject a few adverts and make a buck or two off of it? Plus there's always the possibility of a malicious third party getting access and injecting malicious code, such as the recent attack on github [arstechnica.com].
Really, encryption by default is a great idea and should be embraced. The problem is that it's currently a pain in the ass to deal with when all you want to do is get a page up and running. Getting encryption going is already enough effort that it's unattractive to use, but then you have everobody demonizing self-signed certificates and pushing you to use properly signed ones, which means even more effort and expense.
That's bullshit because for most uses, self-signed certs are good enough and would limit abuse, but browsers throw up giant warnings and panic buttons that say things like "Get me out of here!" if you try, making it look like insecure http traffic is safer. It's doubly bullshit because it's essentially telling you that, if you want encryption, you must either shell out or have your site be shunned. It's easier to the visitor if you just don't bother.
Other protocols have made similar moves, with encryption either being bolted on (such as telnet-ssl, ftps) or new alternatives appearing to do the same job with encryption (ssh, scp, sftp). The difference is they're usually less of a headache to set up and don't all harass you for using self-signed certificates. Maybe you get a one-time "are you sure?" that gets saved afterward, without all the sky-is-falling melodrama every page visit.
TL;DR: Deprecate unencrypted http? Great idea! Just fix the fucked up SSL certificates situation first, jackasses.
(Score: 3, Informative) by DNied on Wednesday April 15 2015, @07:48AM
Encryption can't fix that. The browser at an access point might still insert anything into the page source, post-decryption.
Maybe, but we're not talking about encryption by default (à la HTTPS-Everywhere). Rather, we're talking about deprecating plain HTTP, which IMO is not a good idea. Lose the human readability of a data stream and you'll lose not just the ability to tamper with the stream, but the ability to check what's going in and out of your LAN too.
(Score: 4, Informative) by Marand on Wednesday April 15 2015, @08:21AM
Encryption can't fix that. The browser at an access point might still insert anything into the page source, post-decryption.
I don't think you're talking about the same thing I am. A "public access point" generally means an open wireless AP, such as what you find in places like stores, restaurants, and coffee shops. You connect with your tablet, phone, or laptop and browse using your hardware on their network. HTTPS does limit the abuse potential in those cases. You seem to be thinking of a public computer, like what you find in a library.
Maybe, but we're not talking about encryption by default (à la HTTPS-Everywhere). Rather, we're talking about deprecating plain HTTP, which IMO is not a good idea. Lose the human readability of a data stream and you'll lose not just the ability to tamper with the stream, but the ability to check what's going in and out of your LAN too.
Telnet and FTP are deprecated in favour of secure counterparts, why not HTTP as well? You lose the ability to tamper with streams you don't initiate, but that doesn't mean you'll suddenly lose the ability to interact with HTTP outside of browsers. You can use other tools [superuser.com] to initiate and interact with SSL connections the same way you can telnet to port 80 and manually interact with HTTP.
As for the LAN diagnostic argument, the benefits of non-encryption don't outweigh the disadvantages, in my opinion. Even with universal encryption, you can still see what host and port is responsible for suspicious or excess traffic and, if needed, use physical access to the hardware to determine what's going on. Netstat to find what process is responsible, maybe poke around memory to find out what the program is doing.
You don't need deep packet inspection, nor does anybody else; it's just privacy invasion for the sake of convenience. Attitudes like that are why we need universal encryption at all.