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.
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.
For my experience, this still holds in Japan, and I've heard in Korea.
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.
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.
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.
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.
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.
Would you clarify what you mean here?
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."
Dystopia.
Or encryption will just get backported to http eventually. I never understood why they didn't just do that in the first place.
There was some talk about SNI encryption in the TLS working group. Not sure where that went, though.
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.
tshark -T fields -e ssl.handshake.extensions_server_name
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.
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.
Use example.com. It's the domain that's required to be always available for this and other purposes.
Dvorak user?
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.
I'm one of those people. The grocery list app I use doesn't use SSL and I don't really care because it's just my grocery list lol.
I guess in latter case SSL would help, but what’s more likely, though, operator selling out or app developer?
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.
Sorry for the ignorance, it's a legitimate question.
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.
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.
This was enough to convince me to add https to my static blog.
n-gate.com will make sure of that http://n-gate.com/software/