I doubt the web will ever be fully encrypted. There will always be tons of people who don't care enough. I've come across dozens of high information static websites that were set up like 10+ years ago where the author will probably never be back to configure tls.
It's so strange that you have to ask someone's permission to use encryption[0]. Certificate authorities should've been (should be?) optional. SSH came out around the same time and its Trust-on-First-Use is a much better system.
The original impetus for SSL/TLS was to permit credit card transactions. For a long time only banking websites and retail checkout pages were encrypted. In that light it makes more sense why the industry focused so heavily on certificate authorities. People were told never to enter their credit card number unless the "secure" icon was displayed; if it did, then they could trust the site much like they would trust any brick & mortar store.
Back in the early days you couldn't get a certificate without faxing in a copy of your business registration. A certificate authority's digital imprimatur implied something substantial about the credibility of a site, however imperfect the process. But as the certificate authority market diversified there was a race to the bottom in terms of credible certificate authorities. We've been at that bottom for so long that it does seem ridiculous that we didn't have Let's Encrypt earlier.
> Back in the early days you couldn't get a certificate without faxing in a copy of your business registration.
Well well, guess who could easily spoof that one.
> A certificate authority's digital imprimatur implied something substantial about the credibility of a site, however imperfect the process.
Not just the process. SSL downplay attacks and lack of certificate pinning already existed back in those days.
As long as those attacks are unknown you may still be reasonably secure against a MITM from a banana state government or a random ISP.
Also, lets not forget that running your entire website on HTTPS was expensive on resources before the 10s.
So the argument "because we can" makes sense. That doesn't mean all that information has to be encrypted. However, if you want to harm a surveillance state, then one act is causing significant noise. Uninteresting, encrypted data is noise and potentially yields plausible deniability.
The other argument is "because we have to". Different attacks have been demonstrated on that one: hostile networks such as ISPs injecting ads, hijacking DNS, open WiFi, impersonating fraudulent websites are just a few examples.
> Well well, guess who could easily spoof [faxing in a copy of your business registration].
I worked for an ISP in 2000 and we had to both send and receive faxes on "company headed notepaper" as a means of authenticating a request. All you needed was a word doc with the company name in bold at the top of the page.
When we hit this particular bureaucratic speed bump (mostly dealing with domain name registrars), and having no "company headed notepaper" ourselves (we were 20 people) we just fabricated it. It always worked.
Anecdotal evidence, but for Japan that seems to be changing. Popular Japanese art site Pixiv rolled out TLS to the entire site in the past year or so, before that it was only used during login.
As far as Korea goes, they've got a whole different bag of worms going on, at least for a couple more years. Look up "South Korea Internet Explorer" for some astounding stuff if you've not heard of this before.
> I doubt the web will ever be fully encrypted. There will always be tons of people who don't care enough.
I don't think the Web will become fully encrypted by virtue of everyone caring enough to move to HTTPS.
The knockout punch for unencrypted sites will come when browsers make the decision to not load plain HTTP sites by default in order to protect their users. At that point, for the vast majority of people, the Web will be 100% HTTPS because they'll never see a site that isn't HTTPS.
We just have to get the encryption percentage high enough to allow browsers to finish the job.
What about the other part, the vast quantities of information that will never be encrypted because the sites remain but the people have moved on or are gone? Why does that deserve a knockout punch?
Not trying to defend the idea, but the domain will expire at whatever point the registrant doesn't fund renewal anyway. Is that potentially arbitrary sunset date "better" by virtue of being more distant? If the authors care to let the sites exist yet prefer to abandon stewardship now, they should transfer ownership now and to someone who cares enough to encrypt as needed.
Some of these sites may be on shared hosting where the hosting provider doesn't provide SSL for custom domains, or provides it for a fee which is unjustifiable to the website author[s], so it may not even be that they don't care enough, but that they don't want to shell out personal money for say a static, hobbyist website.
Well, there's always services like CloudFlare which would offer free certificates - thus even allowing for pages hosted on GitHub Pages to be served through HTTPS.
They don't deserve a knockout punch any more than FTP or Gopher deserved it, but unfortunately commercialisation of the web and the merging of static pages into dynamic apps (feature creep) and one gargantuan application (the browser) to interface with all of it and one gargantuan entity to discover it (Google), means that minnows are going to have to go with the overall flow.
I understood it to mean that FTP has mostly been replaced by HTTP, through no fault of FTP itself, but rather because that's what serves the interests of the people who implement things. That is, FTP still works, and works as well as ever, but its usage is dropping.
The browser providers have clearly made that decision for the vast majority of users: default safety trumps information access.
We've yet to see if users will either (A) follow the on-screen, flashing red prompts, or (B) be trained to click through the warning screens due to their sheer prevalence.
Even in case B, it's a non-negligible probability that browser vendors respond by disallowing click-through. Just another step towards (re-)making the web into a nice, safe walled garden.
those sites aren't really under any threat from an interstitial like you currently get on an expired certificate (which i assume is what the parent means by "refuses to load by default"). It would be a knockout punch for any site trying to build an audience, but it doesn't actually block the site. I don't think anybody is suggesting that insecure archived sites be deleted from the internet.
Oh I can't wait for that day. Then I can sell an Internet enabled appliance with a certificate that lasts just as long as the warranty! Recurring revenue here I come!
What prevents you from already selling an appliance that stops working, certificate or not, after the warranty expires? Sounds more like a lawsuit than recurring revenue to me.
> What prevents you from already selling an appliance that stops working, certificate or not, after the warranty expires?
That sounds malicious -- whereas having it no longer work after the certificate expires sounds like security, and everyone likes security. With enough PR, you can string together something that sounds like a legitimate concern, like "with privacy being a major concern, encryption has progressed leaps and bounds past what we had two years ago -- so even if we were to renew the certificates, we simply do not think our customers' data would be safe when handled by these old devices."
The most chilling part is the casual way that data is discussed, because the consumer of the future will be okay with their refrigerator gathering data to drive advertising profit.
It seems that if something stops working for a "legitimate" technical reason (like, your camera stops working because of no server access, even though you only ever used the camera on you lan anyway) the customer can't win the lawsuit.
> The knockout punch for unencrypted sites will come when browsers make the decision to not load plain HTTP sites by default in order to protect their users.
That would be a terrible idea: it would break every "http:" link in existence, requiring people to edit billions of documents. And if "modern" browsers started pretending that "http:" meant "https:", it would break every other browser and lots of bots.
Sadly because of SNI browsers send the domain name in clear text, so I do not feel there is much to gain in going all encrypted. HTTPS/HTTP2 is broken by default in this regard and there is no way you can fix it other than using a VPN. At least with DNS you can do something about it your self.
It looks like TLS 1.3 still puts server_name into ClientHello and that isn't encrypted.
I can't see how you could encrypt SNI without pushing TLS out to at least two round trips, which would suck for the Web although it might be tolerable in other applications.
One option that does occur to me would be to shove say, a 32-bit SHAKE(FQDN) instead of an FQDN in as the identifier. This way we don't show eavesdroppers the actual FQDN we wanted, although they can try to guess and discover if their guess was right at their leisure. So it doesn't prevent a sophisticated attacker verifying that we connected to vpn.example.com not www.example.com on the same IP address + port, but it does make it essentially impossible for them to find out that our server has a site named xy4298-beejee-hopskotch-914z.example.com by inspecting the traffic.
The server knows all the hosts it serves for, and can work out 32-bit SHAKE(name) for them and pick the right one or reject it without revealing anything extra. The birthday paradox means this is likely to have conflicts above a few tens of thousands of vhosts per server, but that's already getting into deeply bulk hosting territory where you don't care too much about security anyway. Ordinary people aren't doing much more than hundreds of distinct sites per IP address so conflicts for them would be extremely rare.
I can passively sniff all traffic and know where my users are going that is a big deal. Having a ip -> DNS mapping is a lot of work AFAIK, sure it can be done, but executing a get_hosts_by_ip() on every https packet is hard. In contranst this is enough to get all hostnames from SNI:
I do agree that there is more things to consider about privacy, but the call for al websites to be encrypted is so naive. If that is what you want it would be enough to extend chunked http with an adler32 on the end of each response/chunk, and it would be a lot easier to work with than TLS.
1. TOFU won't scale - if I have a single SSH host, I can easily verify the server key out of band, and then never change it (though that's quite an insecure proposition if you ask me). How would you do this to _every single website you visit?_ And if you don't verify out-of-band (like calling up the host), how do you know that you're not being massively MITMed? And then when you leave your house and go to an airport and get a "your certificate changed", all it means is that _now_ you're connecting to the real page, and not MITM page.
And even if you verified the original cert and now get a "site certificate has changed". It could mean that the owner rotated his private key. What do you do? 99% will just say "false alarm, ignore, move on".
2. WoT - It's a false sense of security. You're trusting that random people on the internet will 1. Bother doing _any_ verification before signing someone's key and 2. People will keep their private keys safe from botnets. And the network has perverse incentive - the less verification a group does, the more cross-signing they'll do, the more "trusted" it is.
Of course, airports will DNS poison you to serve up the stupid Wi-Fi ToS. google.com never loads due to a HTTPS error, so at airports I usually use aoeu.com or some other non-encryted site to agree to the ToS-by-poisoning.
Exactly, a stolen key and no verification and you're back to traffic in the clear. Just because you do some encryption doesn't mean you're somehow protected.
I think SSH and HTTPS have very different use cases, which is why their cert structure is different. Most people ssh to servers they either own or have a working relationship with. Https, on the other hand, is very often used to connect to sites that you have no relationship with, but you still want to know that you are connecting to who you think you are.
SSH works on the premise that you should know, or have a way to check, the key for the server you are connecting to. That really doesn't happen with HTTPS.
How are you sure it's only your grocery list? You trust the networks and states that the content is transferred through to not inject anything potentially malicious or otherwise undesirable into the content? The only way you can be relatively confident that's not happening if the content is delivered via HTTPS, surely.
Right now it's just your grocery list. In the future when it's sucked up into the algorithms used by the underwriters of your health insurance and life insurance, and you can't quite figure out why you aren't getting the healthy-eating-disguised-with-some-ambiguous-name discount, maybe your grocery selection is to blame.
> I assume you are hinting at app operator will sell user’s data? Or do you mean parent’s network provider does?
Yes and yes. ISPs are racing as we speak to develop the technology to data mine their users and inject their own ads. Hopefully we will get the web encrypted fast enough to make it less economically attractive.
They want to know which sites you visit, what you search for, which movies you watch and what you shop for, and package it and sell it to anyone who will pay.
Individual developers could do the same, and we should find ways to prevent that, but they have less negotiating and lobbying power and users have more choice in what apps to use.
Honestly question, is there any reason why a static website should have SSL? Unless you have encrypted DNS, whoever is stealing the data will know the server you're connecting to, and therefore will have all the exact data anyways. So HTTPS is quite literally a waste, no?
Sorry for the ignorance, it's a legitimate question.
Even if the site is supposed to be static, an active attacker can still inject dynamic code into it.
In one somewhat recent example, a non-HTTPS page was modified in transit by an attacker to inject Javascript code which did a denial-of-service attack against github. Had the page used HTTPS, the attacker would not be able to inject that Javascript.
Then perhaps browsers should not execute any code from a non-HTTPS source. That would nicely cover the old static page case. Any modifications to the html would be visible to the user.
If the malicious JS is served over https, it could still be inserted into a static page served over http without the user knowing. The static page needs to be served over https to avoid tampering from MITM attacks.
The browser would obviously have to be smart enough to mark code that came from any sort of http source, even those embedded in https pages or https loaded by http pages, as non-executable. That would probably be the easiest way to do it anyway. Once we hit http, the level of trust drops and stays dropped.
Having thought about this a bit more, that would be an browser option that we could use today without any general convention. Turning on the "No script execution without https" option would break very little and would prevent more than just MITM attacks.
Among other things, they can tell you're reading wikipedia but not that you're reading about <controversial subject of the day>, and they can tell that you're browsing youtube but not able to sell data that you watch PewDiePie every day. They're also prevented from messing with the data - providing incorrect information, blocking individual pages, and inserting advertisements.
A number of web pages from better writers than me will argue why you need HTTPS. E.g. it provides integrity (so the coffee shop WiFi can't insert ads in your site), and browsers only enable some features on HTTPS sites.
It's a great question. One is protection from ISPs. Over http, they can see everything you're browsing -- the exact page and data -- whereas with https I believe they only see the top-level domain (e.g. they know you're on hacker news, but not which thread). Worse, the ISP can potentially modify pages, inject code and advertisements, etc. In the US, we know that ISPs have done these things and now sell browsing info to advertisers.
This was enough to convince me to add https to my static blog.
See it not only as encryption, but a sealed envelope that verifies the integrity of the website which could otherwise be compromised by a man in the middle, unfortunately often an ISP to insert billing reminders, ads and promotions. Perhaps more nefariously by a hacker to replace your bitcoin wallets and Paypal links with his own...
It's so strange that you have to ask someone's permission to use encryption[0]. Certificate authorities should've been (should be?) optional. SSH came out around the same time and its Trust-on-First-Use is a much better system.
[0] https://www.tedunangst.com/flak/post/moving-to-https
https://en.wikipedia.org/wiki/Trust_on_first_use