How HTTPS Works
howhttps.works
howhttps.works
Worth noting that "The Handshake" episode [0] covers the key exchange using RSA. This has the downside that it doesn't support forward secrecy, meaning if an attacker ever compromises the server's private key they can retroactively decrypt traffic they previously captured.
It's more common these days to use an ECDHE exchange in which the client and server exchange keys that are generated just for this session (or at least, they should be [1]) and use those to generate the "shared secret".
In fact, in TLS 1.3 ECDHE is the only key exchange mechanism. [2]
The server then uses its long term keypair corresponding to the certificate to sign all the handshake messages that were seen previously [3].
[0] https://howhttps.works/the-handshake/
[1] https://raccoon-attack.com/
This is not how HTTPS works, it's how HTTPS used to work long ago. What makes it even more frustrating is that they do mention that there are different versions and the very latest version is 1.3, but don't mention that what they just explained is a variant of TLS 1.2 that most people have deprecated long ago.
I agree with most of your post, but not this part. 1.2 is still out there on a large number of sites, but even worse 1.0 and 1.1 are there on many of the most popular sites. Google.com for example, despite all major browsers now having deprecated 1.0 and 1.1.
My guess is that we're a year or three, or one major related security incident from browsers either removing RSA kex or gating it behind default-off enterprise feature switches. We know it's a bad idea, but a bunch of organisations that lay people think of as "secure" (like banks) do it anyway, mostly for really stupid reasons. If an incident makes it necessary to pick between real security versus imagined, the browsers are going to pick real as they have before, even if that means First Bank of Springfield doesn't work in your browser. Normal churn means the banks are slowly adopting Forward secret capable upgrades anyway, so that's where my other timeline comes from. Three years from now products that once treated RSA kex as the bees knees will have aged out, capex justification to replace them is just "it's rusted" rather than explaining to somebody who control your budget that you picked a deliberately poor key exchange method because you're bad at your job and trusted a sales person.
For example, both client and server can send messages at the same time or asynchronously, and so they need separate keys for each direction. Let's call these two keys A and B, the client encrypts data with A, sends it, and the server decrypts with A, but the server encrypts data with B, sends that and the client decrypts with B. If they just use the same keys lots of things go wrong, including an adversary can now give the client back messages it just sent and it can decrypt them believing they are from the server.
What it does do is use a cartooning style that seems similar to the cartoons one might find at the dentist about why you should always floss your teeth or the cops hand out about why you must never talk to strangers. Thus it is somewhat ironical in the cartooning style it uses. I admit that someone could find this tedious but other people can admire it as a stylistic conceit (although admire is maybe too strong a word )
You have to pitch things appropriately. A six year old who has just noticed that some of her contemporaries have penises and some don't probably does not want a diatribe about Trans Exclusionary Radical Feminism and if she's wondering about TLS she probably doesn't need an excursion on ECC Safe Curves, but with care to stay relevant and not just blast her with jargon she doesn't understand there's no reason any topic needs to be off the menu.
Yes.
ps: I find it insulting that you find a random illustration insulting. Re-asses your thought process, I'll wager a guess you're better than this.
I honestly have no idea what kind of adult thought process is okay with being treated like a 6 year old, as this comic attempts to do. I honestly am better than that - but it sounds like maybe you're okay with it??
But I'm curious how you see it.
The comic uses the more common term privacy when the more appropriate term confidentiality is more appropriate. Privacy is more a legal term than a term of technical control. The distinction is not frequently appreciated because there is a massive ton of overlap, but the distinction is important in the authoring of policy guidance and legislation as the enforcement actions can greatly differ.
1) the fact that it doesn't spend much time explaining what happens after the client generates a pre-master key. Diffie Hellman seems to be pretty standard, but it's nowhere to be seen here. Also, how do the client and server agree on a shared key if the secure communication only goes one way at this point? How can the server securely answer to the client, if the client hasn't sent an actual public key? In other words, how could they do the DH step (not explained itself in the comic) if a MITM attack is possible at this stage? I always assumed the client generates a temporary public key for itself and sends it (encrypted with the server's public key) to the server, but I'm not sure at all.
2) I was glad to see a quiz, but sadly most questions are too easy, with 1 serious answer and 3 completely ludicrous ones. Doesn't really challenge your knowledge.
Excellent work however.
The server ends up with no assurance as to who the client is in typical day-to-day HTTPS. You could be anybody, which is why web servers use technologies like passwords. TLS can be used in a mutually authenticated mode where both sides present certificates, but that's not how HTTPS is ordinarily done.
So why is this any help? Well after DH neither side knows who the other is but whoever they both are they now have a secret in common. This is enough to send messages back and forth that nobody else can eavesdrop or tamper with. Now the server can use this secure channel to show a certificate for its identity and present a proof bound to this session, in the form of a signature over the transcript of the handshake so far. The client examines the certificate, the certificate should be satisfactory (e.g. for https://www.google.com/ the certificate with SAN dnsName www.google.com issued by a CA you trust seems satisfactory) and then the transcript signature can be verified with the public key listed in the certificate. So now the client is satisfied that this is, in fact, www.google.com it is talking to.
Also, just a great example of an innovative marketing strategy: provide legitimate value to people who are part of your target market.
Can we stop here and have a discussion about this? Every example I have ever seen of interception is either "coffee shop Wi-Fi" or government surveillance. Are those the main threats?
"Coffee shop Wi-Fi" seems like less of a threat each year. AFAIK WPA 3 means you get an ephemeral encryption key when you connect. Additionally, tethering seems to be more and more common these days. Both solve this problem, no?
Government surveillance is a different topic, but given how prevalent TLS termination is (any website using CloudFlare, for a start), I'm not so sure it helps - the NSA probably still have all your data.
Who is crab nowadays? Is he still a threat? Do we still need TLS even with WPA 3?
Maybe? Your threat model may vary. If you're very focused on happy news, most people's network use is not tampered with in a way that directly interferes with their enjoyment most of the time. If that's really all you wanted then you can reason TLS is unnecessary for you†
If the coffee shop uses WPA3 and not any older version (do you check?) and if you have your own secret password for the coffee shop WiFi not shared with anybody else (do you?) then WPA3 means crab probably cannot impersonate your coffee shop's WiFi router by hanging out in the coffee shop, although there are plenty of problems in practice with WPA3 implementations.
But what if crab runs the coffee shop WiFi anyway? Do you interview coffee shop owners about who provides their WiFi? It's just a cheap way to keep customers in the shop (if it's the sort of coffee shop that wants to do that) and who provides it and why isn't top of the owner's mind.
Maybe the family owned coffee shop just uses the stock ISP WiFi router and they're paying $50 per month like everybody else in the neighbourhood for Internet access. But, is that ISP the most scrupulous business? They can make money if they inject advertisements into your browsing, or if they can at least associate your address to specific browsing activity so that can be monetized. Perhaps even if the ISP itself is high-minded enough to turn these opportunities down an individual ISP employee is not, network engineers can certainly choose to eavesdrop easily enough.
† But you aren't using TLS just for you. We must all hang together or most assuredly we shall all hang separately. If only a relative minority of people use protocols which provide them with features like confidentiality, those people stand out more easily to be attacked. Don't Stand Out is an increasingly important property to protect us all by sheer numbers.
I would go beyond that and say that the reason most networks people use do not tamper with the traffic is because most people use TLS nowadays. Not too long ago, it was very common for networks to use a "transparent HTTP proxy", intercepting all TCP port 80 traffic and redirecting it to a separate box with a caching HTTP proxy like Squid, in an attempt to reduce the traffic. This sucked whenever the HTTP proxy misbehaved (which was not uncommon; many operators seemed to configure it to cache more than it should). Since nowadays most HTTP traffic is protected by TLS, transparent caching HTTP proxies no longer provide a relevant reduction in the bandwidth use, and so they became less common.
So, in that case, would TLS still be useful? It just seems like quite a lot of effort to ensure TLS everywhere because a small number of people use untrustworthy Wi-Fi networks
Then the mobile carrier/ISP is the threat. I personally do not really trust those DSLAM boxes scattered all around my city, often readily accessible by everybody with the right key/lock pick. E.g. I know the DSLAM box that is serving my house, and I can just walk up to it.
And every other hop between you and the destination is the threat as well, and every person having enough access to any such hop, from company employee to external attacker. Also, did China route half the internet through China again, by "accidental" buggy BGP routes.
And don't forget your own router, which is a threat (once hacked). Or that "smart" lightbulb or other IoT device in your LAN that may be able to listen to your all your Wifi communication at home depending on your setup.
TLS isn't "a lot of effort", it's a minor computational cost e.g. compared to the energy you use to display ads you don't want to see, and end-users do not have a hard time using it. It's a tiny bit of burden for server operators, tho letsencrypt/ACME made it a setup-once kinda thing for a lot of people.
Because again the scope of encryption offered by wireless operators is different from TLS. It is like asking if encrypting your disks makes TLS pointless.
TLS encrypts traffic between your computer, and some resource on the internet.
WPA3 encrypts communication between your computer and the wireless access point, no further. The wireless provider's encryption will similarly only encrypt data between your device and the wireless provider's equipment.
They are not designed to do the same thing. Technically WPA3 and and other wireless networking encryption is not needed if you are using TLS, because the scope of encryption of TLS covers the data going to your wireless provider or the wireless access point, but not everything is TLS - and even TLS still leaks DNS in many cases. And even if it was not leaking DNS there are still things that would be better for others to not know when you are using TLS.
With TLS encrypting web traffic we’re trying to secure the traffic as it makes that journey, in combination with WPA3 we’re making use of defence in depth - rendering your coffee shop attacker useless.
It’s not just bad actors at the coffee shop or at the government level intercepting traffic though:
Less scrupulous ISP’s will intercept plaintext traffic, doing dynamic ad insertion, dynamic image compression, or (theoretically) scraping content to build profiles on their customers - personally I object to those behaviours.
Is it not good practice that firms doing SSL Termination at a third party should be forwarding traffic onto their own equipment using their own or different certificates?
I don’t think anyone should trust any computer on the networks between their browser and the site they’re browsing, the internet is a much less trustworthy place than it was in the 90’s.
Encrypted to the router, which is managed by the "Coffee shop".
If you talk about encryption, it is important to consider the scope of it.
> Who is crab nowadays? Is he still a threat? Do we still need TLS even with WPA 3?
WPA 3 and TLS are not solving the same problem.
Yes. I take TLS and no Wlan crypto any day over the reverse.
It seems it's an authenticated encryption mode that does it, for example AES-GCM or a MAC as in ChaCha20 + Poly1305
I found this to make it SO MUCH MORE CONFUSING than just explaining how HTTPS works using words like Computer, Browser, Certificate.
My brain could not wrap around the concept of a ComPUGtor or whatever.
But I'm sure this works for some people - just think the site should have a "lose the comics" format.
I wrote a bit on it few days back- https://lafolle.ca/blog/broken-resolution/
The public key is represented by a blue key but… wouldn't it be more simple to say the public key is an open padlock the sender closes on the box after putting their message in it? Padlocks can only be open by one key, the private one.
All the same, informative and fun. I enjoyed it! :-)
FWIW, the site is hosted on Cloudfront using an Amazon issued certificate. Here's some debug output I show using curl which shows successful negotiation:
* Trying 13.227.219.41...
* TCP_NODELAY set
* Connected to howhttps.works (13.227.219.41) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=howhttps.works
* start date: Feb 14 00:00:00 2020 GMT
* expire date: Mar 14 12:00:00 2021 GMT
* subjectAltName: host "howhttps.works" matched cert's "howhttps.works"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.NH works, your site doesn't.
Easy to get those mixed up, as the comic doesn't specify.