Hacker News new | past | comments | ask | show | jobs | submit login
How HTTPS Works (howhttps.works)
466 points by kirillzubovsky 14 days ago | hide | past | favorite | 64 comments

I love seeing comics like this that aim to show concepts in simple ways. Kudos!

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/

[2] https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/

[3] https://tools.ietf.org/html/rfc8446#section-4.4.3

Yeah, it's a bit of a pet peeve of mine to complain that so many people who start "easy crypto explanations" basically explain things that are outdated or sometimes simply wrong.

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.

> 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.

It's true that most sites support TLS 1.2, but between clients and servers the no-FS RSA kex is rarely negotiated. Any vaguely modern browser can do better given the opportunity and only a very small fraction of sites that do TLS 1.2 (and so would actually talk to a modern browser out of the box) don't prefer ECDHE.

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.

This is really great. I was flapping around trying to explain this to my curious, yet-not-technical wife just the other day. This'll do nicely as a follow up, thank you!

Well it does have a separate "generate shared secret" step. Perhaps it is an amalgamation of both methods...

This is a simplification of a subsequent step. The Pre Master Secret is actually used to derive several keys (exactly how many varies depending on other choices in the handshake) which are all shared between the client and server.

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.

probably ed25519 would be better if you don't need to support old servers: https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e...

Unsolicited constructive criticism is that I think the comic could do with a bit more spacing between the panels, it gets easier to read feels less dense that way - that's what I think.

I have some different constructive criticism. I felt like the cartoons made it seem like they were treating me like a 5 year old. Is this for adults or children? I had to click away, it was a little bit insulting honestly.

While I don't like to be overly harsh to submissions, I'm afraid I agree. For contrast, check out the original comic that announced the Chrome browser [1]. I was amazed by it's effectiveness in telling a detailed story, but I never felt talked down to. I felt this comic lived in a different kind of uncanny valley, where the verbiage felt Barney/Sesame Street-esque but the topic was clearly geared toward adults.

[1] https://www.google.com/googlebooks/chrome/

Same here, it omits some of the basic principles of comics. Outlines, contrast, spacing, context. It overly introduces some characters (certificat, compugter, browserbird), but then suddenly there is a regular crab. If you'd look at the Oatmeal[1], even though his style is absolutely chaotic it's still a lot easier on my eyes/mind to focus. I also don't want to be harsh and I love the initiative and the effort, but if it would be a bit easier to read I'd bookmark it and show it to every new trainee.

[1] https://theoatmeal.com/comics/mantis_shrimp

If it was made for children, would you still find insult?

Do you think SSL encryption is really a subject for children? I'm talking about ~6 year olds, the cartoons seem geared towards 6 year olds. Infantilism isn't really attractive, this "guide" is practically the same as an adult persistently talking in a baby voice. Sorry if the truth hurts.

In my experience with 6 year olds if you use words like eavesdrop you then have to explain what it means, so I don't think linguistically the comic is geared towards 6 year olds.

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 )

A six year old is both inquisitive about the world and capable of learning about it so I don't see any less reason you should be prepared to talk to them about TLS than any other topic they might express curiosity about.

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.

Please, someone show this to a 6 year old and let me know long they stay focused on the topic and how much they actually understand about TLS after reading this. It would be hilarious if this were a youtube video, too. Sorry but I just don't believe any 6 year old is going to be interested in TLS or really learn much except how to mispronouce "computer" as "Compugter".

>Do you think SSL encryption is really a subject for children?


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.

leptons 13 days ago [flagged]

Do you like it when people treat you like a 6 year old? No? Or maybe you do? You're probably better than that.

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??

Good introspection. You're almost there.

On the other hand, adults are buying colouring books and superhero toys now. Infantilism is some kind of new strange/creepy marketing vector? I dunno.

Maybe the content isn't for you, or made with you in mind. I don't understand why you wouldn't just change the channel on something as benign as this, rather than find the time to be insulted. Different strokes, I guess.

I did "change the channel". I hit the back-arrow after reading "Compugter" and "Certificat" and wrote an honest comment about how bad an idea this infantile comic is, and questioning what audience it serves. In my opinion, it's a confused mess. I really hope this won't be a trend in tech, because it's honestly pretty awful.

But I'm curious how you see it.

Yeah, I agree. It's easier to read if you zoom out the page a bit, but perhaps more spacing and slightly visible edges around each box would make it easier to consume.

A pointlessly unnecessary nitpick that doesn't invalidate anything:

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.


Privacy is a social norm; it happens to have some not-exactly-matching instantiations in law. Mistaking the two is dangerous.

If you enjoyed this, check out https://howdns.works/ by the same authors.

It's well done, helpful especially for non-technical folks or beginners. But I'm annoyed with using the dnssimple.com as example site along with name servers at ns1.dnssimple.com . So, a newbie may wrongfully assume that example.com may have name servers like ns1.example.com which is not the case. May sound silly, but any one totally new to the DNS could easily misunderstand it. They could have used example.com to avoid any ambiguity.

Entertaining irony; I couldn’t resolve the A record for that domain from my pi-hole and nearly wrote an embarrassing comment here before I checked another resolver. All sorted now though

their site footer only links the howdns.works not howhttps.work ?

Thanks for pointing that out, we'll put a link to howhttps.works in the footer on dnsimple today.


I found this comic very good and useful, but I'm a bit disappointed by two things:

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.

Actually ordinarily today we do DH first and there is no step where the Pre Master Secret is actually sent at all - unlike this comic. Magic! DH allows them to agree a random secret and since we wanted a random secret anyway that's fine.

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.

Thanks for sharing, I found it really cool and informative.

Also, just a great example of an innovative marketing strategy: provide legitimate value to people who are part of your target market.

>Crab is listening on the communication capturing the message.

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?

> Are those the main threats?

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.

> 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

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.

The coffee shop router is the thread. Whether it's the coffee shop owner, an employee, somebody who hacked the router or just somebody who tricked you into going into their WiFi which is not actually the coffee shop's.

I don't have data on this, but I suspect usage of public Wi-Fi is going to keep declining in favor of cellular data as it becomes cheaper and data caps rise/go away

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

I still regularly use Wifi, e.g. on trains in rural areas, because mobile data is a lot more unstable there compared to the train wifi, especially at speed in rural areas. (Trains here usually have better antenna and often uplinks to multiple carriers)

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.

> So, in that case, would TLS still be useful?

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.

Just out of curiosity, I wonder how many layers of encryption one can reach in a day-to-day usage scenario.

TLS keeps the traffic secret between the client and the server. Encryption on part of the transport - like the cellular net - only covers part of the journey, and is out of your control. It's the difference between sending a box locked or not - the box is routed between different operators and terminals.

You’re correct about the coffee shop wifi being less of a problem year on year. Though WPA3 only gets you as far as the access point you’re connecting to - you still have the rest of the networks your traffic will grace between that access point and your destination.

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.

> "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.

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.

>Who is crab nowadays? Is he still a threat? Do we still need TLS even with WPA 3?

Yes. I take TLS and no Wlan crypto any day over the reverse.

I'm wondering how the integrity part of HTTPS works.

It seems it's an authenticated encryption mode that does it, for example AES-GCM or a MAC as in ChaCha20 + Poly1305

Yes, but note TLS records were explicitly authenticated with HMAC before the adoption of AEAD modes.


I see a lot of love for this, but there always has to be the other side.

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.

Great demonstration!

I wrote a bit on it few days back- https://lafolle.ca/blog/broken-resolution/

In https://howhttps.works/the-keys/

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.

I really enjoyed reading this, but I felt like the characters used throughout the comic weren't particularly representative of the things they're trying to represent (mainly attacking Browserbird here). This made it slightly harder for me to digest.

All the same, informative and fun. I enjoyed it! :-)

Funny. But confusing - to me at least - is the naming of browserbird and compugter. Half of the time (I think?) browserbird is not a browser but a person; same with compugter. Alice and Bob would make things clearer.

Plain awesomeness! had a good laugh and learnt a good deal about https. Thanks OP.

I commend you for taking the time to translate the material to different languages. We really lack good learning material in languages like Portuguese. This helps a lot.

From what I heard the translations actually came from customers who read the comic in English and then wanted it to be available in their language.

This is a really cute and informative page. Bravo

I'm getting an SSL negotiation error. I don't think it works. They might want to have their SSL checked out.

Could you provide some details so we can look into this. Specifically what browser and OS you are using, and any customizations you've made in your browser.

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
  * Connected to howhttps.works ( 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.

Check your SSL score. If you've got an A or A+ or such, it means many people can't connect to your site. Not every browser has TLSv1.2. The maximum score is something like A- nowadays.

NH works, your site doesn't.

The "left clap" is the server's left, and the "right clap" is the server's right.

Easy to get those mixed up, as the comic doesn't specify.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact