
How HTTPS Works - kirillzubovsky
https://howhttps.works/
======
jwcrux
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/](https://howhttps.works/the-
handshake/)

[1] [https://raccoon-attack.com/](https://raccoon-attack.com/)

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

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

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

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

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

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

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

~~~
hn_throwaway_99
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/](https://www.google.com/googlebooks/chrome/)

~~~
yellowcabinet
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](https://theoatmeal.com/comics/mantis_shrimp)

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

[https://en.wikipedia.org/wiki/Privacy](https://en.wikipedia.org/wiki/Privacy)

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

------
dryd
If you enjoyed this, check out [https://howdns.works/](https://howdns.works/)
by the same authors.

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

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

~~~
aeden
Added.

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

~~~
tialaramex
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/](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.

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

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

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

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

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

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

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

------
LaFolle
Great demonstration!

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

------
greg0ire
In [https://howhttps.works/the-keys/](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.

------
Infiltrator
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! :-)

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

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

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

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

------
megraf
This is a really cute and informative page. Bravo

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

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

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

