5 ms·

How HTTPS Works (2018)

174 points by gautamsomani 3y ago

gmac 3y ago
In a similar (but more binary) vein, there’s this: https://news.ycombinator.com/item?id=35884437 https://news.ycombinator.com/item?id=35884437
- hsdropout 3y ago
  I like this one https://tls12.xargs.org/ https://tls12.xargs.org/ & https://tls13.xargs.org/ https://tls13.xargs.org/
nirav72 3y ago
These are great. Loved reading their similarly created DNS explanation couple of years ago.
aniforprez 3y ago
>The green padlock on the URL bar of your browser tells you that there are no crabs watching over your shoulder The comic probably needs to be updated. At this point, all browsers have stopped showing the green lock for HTTPS in favour of just a grey nondescript lock and a red strike when it's HTTP. But this is definitely an excellent resource to make learning about HTTPS a little more accessible in a digestible format for new developers
- december456 3y ago
  I wonder what the new green lock will be. WEI?
- deleted 3y ago
  [deleted]
pizzafeelsright 3y ago
Does anyone else find the comic-style very distracting?
- justsomehnguy 3y ago
  The problem is not in the comic style. The problem is what this particular story is made to look like a comic for a 5 y/o, placed on LTR blocks like a proper text, with giant pictures yet with a small text and what nor the author nor the artist don't know shit about comics and web design or care about them. But hey! It has a fancy FQDN and TLD! Multiple translations! Emoticons everywhere! Grab your pumpkin smoothie latte and get ready for a fun! story! It's just an ad for the company behind the site. Somebody had spare money to throw in the PR dept.
- deleted 3y ago
  [deleted]
dclowd9901 3y ago
I feel stupid but I still don’t understand how a third party snooper is unable to use the public key themselves to decrypt the pre-master key.
- d-z-m 3y ago
  The pre-master key is encrypted to the server public key, and can only be decrypted with the server private key.
- ferfumarma 3y ago
  The public key is like a math answer that is easy to compute if you have the whole equation, but really hard if you only have the answer. Kind of like "what are the divisors of 93036637?" You can figure it out, but it requires testing lots of numbers (a brute force apporoach) to figure out that it's only 9391 and 9907. Say Adam sends the public key of 93036637 to Bob. (Note that the public key was chosen to be the product of two primes). Bob chooses a new prime number - say 8867 - and multiplies it in there, too, and the sends it back to Adam. Now we have 93036637 x 8867 => 824955860279 When Adam gets that public key back, he can divide out one of the original two prime numbers (824955860279 ÷ 9907 => 83,269,997) and then send it back to Bob. Bob KNOWS that his secret key was 8867, so he divides that back out to get the shared secret: 9391 (the other half of the original public key). Even though Eve listened to every single number being transmitted: Adam: "93,036,637" Bob: "copy. 824,955,860,279" Adam: "copy. 83,269,997" Only Adam and Bob can know the three prime factors of 8867, 9391, and 9907 without doing brute force division. Brute force division is easy for prime numbers less than 10k, but a sender can choose a prime number that's long enough to satisfy their privacy needs, based on their estimate of Eve's resources. So the bottom line is that the public key is easy to compute if you have the inputs, but incredibly time consuming (brute force) if you don't.
  - ta8645 3y ago
    If Eve is listening in to the data stream you've outlined, it's trivial for her to decode. Adam: (A)93,036,637 Bob: (B)824,955,860,279 Eve: (B)824955860279 / (A)93036637 = Bob's secret of (S3)8867 Adam: (C)83,269,997 Eve: (C)83269997 / (S3)8867 = (S1)9391 Eve: (A)93036637 / (S1)9391 = (S2)9907 Eve doesn't need anything but A, B, and C to easily calculate the rest.
dang 3y ago
Related: How HTTPS Works - https://news.ycombinator.com/item?id=24476469 https://news.ycombinator.com/item?id=24476469 - Sept 2020 (64 comments) How HTTPS works - https://news.ycombinator.com/item?id=17932728 https://news.ycombinator.com/item?id=17932728 - Sept 2018 (72 comments)
csydas 3y ago
I do enjoy the comic and the breakdown of HTTPS/Certs, but I do take issue with the "HTTPS/Certs offer identification" in any meaningful way. This has been bugging me for awhile, but I don't think it's correct to associate identification with modern IT security, regardless of what it is. We don't have identity management, we have authorization management, and they're very different. Identity management would mean that the system knows that the authorization request and secret it just received is coming from someone who is authorized to receive that authorization, which is obviously not the case. Even with MFA solutions (Yubikeys, geo-based fencing, etc), it's not really identity management unless someone actually sees you making the request, and even then, we can't know if the authorization request is done under duress or not or with malicious intent. I'm not trying to suggest that this _must_ be a part of security, but I would say let's call it what it is; authorization management at scale. There is no identity, even with all the data that the companies vacuum up from users just trying to do their work, it's just deciding whether this user trying to access this resource has the correct secret to get access: or more succinctly, HTTPS and SSL Certs (and naturally any cert) doesn't validate identity, it just determines if the secret passed to the server should get authorized or not. Similarly, Certs, as useful as they are, are still a mess; it's too easy to break the cert process with other common security practices, cert creation is too costly from the suppliers, unless you already understand how certs work, it's very easy to ask for a cert that doesn't meet your requirements which often means paying for another cert; SSL/HTTPS certainly are quite great and I don't want them to change or leave, but the cert process would be benefitted from a UX improvement. But it is important to understand that certs don't necessarily guarantee identity either, even with the names. All you can tell is that the chain is valid to the CA, so at some point, the cert was given specifically to a company. But breaches are so common, it's a bit too nervous to trust them blindly, and certs compromising stories also happen a bit too much. Unlike with Identity Management, I do think certs can solve this with some minor improvements to the process, and LetsEncrypt was a great step in this direction; just still, I have concerns about the idea that certs prove identity in a meaningful way. Excuse the rant, but identity management has been on my mind a lot recently, and while the article was good, the 3rd panel mentions identification, which none of the items discussed in the comic truly addresses.
philistine 3y ago
I take umbrage at using national flags to identify language. It’s always difficult to figure out intent and then fish for the tricolor flag that is not the other tricolor flag. Language names are clear and precise, and much better. If you are pressed for space, language codes are fine too. Language speakers are used to fishing for their codes.
- deleted 3y ago
  [deleted]
- arrowsmith 3y ago
  There's a whole website dedicated to this complaint: https://www.flagsarenotlanguages.com/ https://www.flagsarenotlanguages.com/
bullen 3y ago
1. privacy: this does not solve the server problem. You have no privacy because the server has your data unencrypted. to protect passwords use this: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289 2. integrity: if you need integrity, like for a bank transaction HTTPS is great, but you don't need HTTPS for all sites. for simple tampering control hashing is way more efficient. 3. identity: "This SSL certificate is valid and has been issued by a legitimate Certificate Authority." Who is the authority. If they have the power to pre-install root certificates on all hardware on the planet does that mean they are to be trusted? None of these arguments make any sense if you know how cryptography works, HTTPS is a waste of time, electricity, "money" and freedom for 99% of uses. Everyday I go to URLs with expired certificates. Just use HTTP! From the folks at "DNS"imple, great another centralized protocol.
- lolinder 3y ago
  > privacy: this does not solve the server problem. You have no privacy because the server has your data unencrypted. You seem to be saying that because servers can still see data that I send to them, we should just let every ISP along the route snoop on it too. If I'm sending data to a server, it's because I have some reasonable level of trust in that server. I don't want to have to think about whether I trust every single network my packet will pass through on the way, and HTTPS frees me from having to think about that aspect of privacy. > integrity: if you need integrity, like for a bank transaction HTTPS is great, but you don't need HTTPS for all sites. for simple tampering control hashing is way more efficient. Given what I said above—I want HTTPS all the time in order to keep middlemen from inspecting every request—it doesn't matter if hashing is more efficient, because I'll already be using encryption. Integrity is a nice side effect of privacy. > identity: "This SSL certificate is valid and has been issued by a legitimate Certificate Authority." Who is the authority. If they have the power to pre-install root certificates on all hardware on the planet does that mean they are to be trusted? The CA system is a legitimate weakness in HTTPS that needs to be fixed, but rejecting HTTPS wholesale as "a waste of time, electricity..." on that weakness alone is throwing the baby out with bath water. Let's fix the CA system, not throw out encryption.
larsonnn 3y ago
Interesting read. Just to add, even HTTPS isn't completely safe from Man-in-the-Middle attacks, especially in corporate environments. A few points to consider: - Some apps bypass or poorly implement certificate pinning. - Companies using self-signed certs can be spoofed. - There's always the risk of compromised Certificate Authorities. - Corporate tools that inspect HTTPS traffic, while useful for security, can inadvertently become a vulnerability if misconfigured or hacked. Always good to remember: HTTPS is a protective layer, but not an unbreakable barrier.

174 points by gautamsomani 3y ago

gmac 3y ago

In a similar (but more binary) vein, there’s this: https://news.ycombinator.com/item?id=35884437 https://news.ycombinator.com/item?id=35884437

hsdropout 3y ago
I like this one https://tls12.xargs.org/ https://tls12.xargs.org/ & https://tls13.xargs.org/ https://tls13.xargs.org/

nirav72 3y ago

These are great. Loved reading their similarly created DNS explanation couple of years ago.

aniforprez 3y ago

>The green padlock on the URL bar of your browser tells you that there are no crabs watching over your shoulder The comic probably needs to be updated. At this point, all browsers have stopped showing the green lock for HTTPS in favour of just a grey nondescript lock and a red strike when it's HTTP. But this is definitely an excellent resource to make learning about HTTPS a little more accessible in a digestible format for new developers

december456 3y ago
I wonder what the new green lock will be. WEI?
deleted 3y ago
[deleted]

pizzafeelsright 3y ago

Does anyone else find the comic-style very distracting?

justsomehnguy 3y ago
The problem is not in the comic style. The problem is what this particular story is made to look like a comic for a 5 y/o, placed on LTR blocks like a proper text, with giant pictures yet with a small text and what nor the author nor the artist don't know shit about comics and web design or care about them. But hey! It has a fancy FQDN and TLD! Multiple translations! Emoticons everywhere! Grab your pumpkin smoothie latte and get ready for a fun! story! It's just an ad for the company behind the site. Somebody had spare money to throw in the PR dept.
deleted 3y ago
[deleted]

dclowd9901 3y ago

I feel stupid but I still don’t understand how a third party snooper is unable to use the public key themselves to decrypt the pre-master key.

d-z-m 3y ago
The pre-master key is encrypted to the server public key, and can only be decrypted with the server private key.
ferfumarma 3y ago
The public key is like a math answer that is easy to compute if you have the whole equation, but really hard if you only have the answer. Kind of like "what are the divisors of 93036637?" You can figure it out, but it requires testing lots of numbers (a brute force apporoach) to figure out that it's only 9391 and 9907. Say Adam sends the public key of 93036637 to Bob. (Note that the public key was chosen to be the product of two primes). Bob chooses a new prime number - say 8867 - and multiplies it in there, too, and the sends it back to Adam. Now we have 93036637 x 8867 => 824955860279 When Adam gets that public key back, he can divide out one of the original two prime numbers (824955860279 ÷ 9907 => 83,269,997) and then send it back to Bob. Bob KNOWS that his secret key was 8867, so he divides that back out to get the shared secret: 9391 (the other half of the original public key). Even though Eve listened to every single number being transmitted: Adam: "93,036,637" Bob: "copy. 824,955,860,279" Adam: "copy. 83,269,997" Only Adam and Bob can know the three prime factors of 8867, 9391, and 9907 without doing brute force division. Brute force division is easy for prime numbers less than 10k, but a sender can choose a prime number that's long enough to satisfy their privacy needs, based on their estimate of Eve's resources. So the bottom line is that the public key is easy to compute if you have the inputs, but incredibly time consuming (brute force) if you don't.
- ta8645 3y ago
  If Eve is listening in to the data stream you've outlined, it's trivial for her to decode. Adam: (A)93,036,637 Bob: (B)824,955,860,279 Eve: (B)824955860279 / (A)93036637 = Bob's secret of (S3)8867 Adam: (C)83,269,997 Eve: (C)83269997 / (S3)8867 = (S1)9391 Eve: (A)93036637 / (S1)9391 = (S2)9907 Eve doesn't need anything but A, B, and C to easily calculate the rest.

dang 3y ago

Related: How HTTPS Works - https://news.ycombinator.com/item?id=24476469 https://news.ycombinator.com/item?id=24476469 - Sept 2020 (64 comments) How HTTPS works - https://news.ycombinator.com/item?id=17932728 https://news.ycombinator.com/item?id=17932728 - Sept 2018 (72 comments)

csydas 3y ago

I do enjoy the comic and the breakdown of HTTPS/Certs, but I do take issue with the "HTTPS/Certs offer identification" in any meaningful way. This has been bugging me for awhile, but I don't think it's correct to associate identification with modern IT security, regardless of what it is. We don't have identity management, we have authorization management, and they're very different. Identity management would mean that the system knows that the authorization request and secret it just received is coming from someone who is authorized to receive that authorization, which is obviously not the case. Even with MFA solutions (Yubikeys, geo-based fencing, etc), it's not really identity management unless someone actually sees you making the request, and even then, we can't know if the authorization request is done under duress or not or with malicious intent. I'm not trying to suggest that this _must_ be a part of security, but I would say let's call it what it is; authorization management at scale. There is no identity, even with all the data that the companies vacuum up from users just trying to do their work, it's just deciding whether this user trying to access this resource has the correct secret to get access: or more succinctly, HTTPS and SSL Certs (and naturally any cert) doesn't validate identity, it just determines if the secret passed to the server should get authorized or not. Similarly, Certs, as useful as they are, are still a mess; it's too easy to break the cert process with other common security practices, cert creation is too costly from the suppliers, unless you already understand how certs work, it's very easy to ask for a cert that doesn't meet your requirements which often means paying for another cert; SSL/HTTPS certainly are quite great and I don't want them to change or leave, but the cert process would be benefitted from a UX improvement. But it is important to understand that certs don't necessarily guarantee identity either, even with the names. All you can tell is that the chain is valid to the CA, so at some point, the cert was given specifically to a company. But breaches are so common, it's a bit too nervous to trust them blindly, and certs compromising stories also happen a bit too much. Unlike with Identity Management, I do think certs can solve this with some minor improvements to the process, and LetsEncrypt was a great step in this direction; just still, I have concerns about the idea that certs prove identity in a meaningful way. Excuse the rant, but identity management has been on my mind a lot recently, and while the article was good, the 3rd panel mentions identification, which none of the items discussed in the comic truly addresses.

philistine 3y ago

I take umbrage at using national flags to identify language. It’s always difficult to figure out intent and then fish for the tricolor flag that is not the other tricolor flag. Language names are clear and precise, and much better. If you are pressed for space, language codes are fine too. Language speakers are used to fishing for their codes.

deleted 3y ago
[deleted]
arrowsmith 3y ago
There's a whole website dedicated to this complaint: https://www.flagsarenotlanguages.com/ https://www.flagsarenotlanguages.com/

bullen 3y ago

1. privacy: this does not solve the server problem. You have no privacy because the server has your data unencrypted. to protect passwords use this: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289 2. integrity: if you need integrity, like for a bank transaction HTTPS is great, but you don't need HTTPS for all sites. for simple tampering control hashing is way more efficient. 3. identity: "This SSL certificate is valid and has been issued by a legitimate Certificate Authority." Who is the authority. If they have the power to pre-install root certificates on all hardware on the planet does that mean they are to be trusted? None of these arguments make any sense if you know how cryptography works, HTTPS is a waste of time, electricity, "money" and freedom for 99% of uses. Everyday I go to URLs with expired certificates. Just use HTTP! From the folks at "DNS"imple, great another centralized protocol.

lolinder 3y ago
> privacy: this does not solve the server problem. You have no privacy because the server has your data unencrypted. You seem to be saying that because servers can still see data that I send to them, we should just let every ISP along the route snoop on it too. If I'm sending data to a server, it's because I have some reasonable level of trust in that server. I don't want to have to think about whether I trust every single network my packet will pass through on the way, and HTTPS frees me from having to think about that aspect of privacy. > integrity: if you need integrity, like for a bank transaction HTTPS is great, but you don't need HTTPS for all sites. for simple tampering control hashing is way more efficient. Given what I said above—I want HTTPS all the time in order to keep middlemen from inspecting every request—it doesn't matter if hashing is more efficient, because I'll already be using encryption. Integrity is a nice side effect of privacy. > identity: "This SSL certificate is valid and has been issued by a legitimate Certificate Authority." Who is the authority. If they have the power to pre-install root certificates on all hardware on the planet does that mean they are to be trusted? The CA system is a legitimate weakness in HTTPS that needs to be fixed, but rejecting HTTPS wholesale as "a waste of time, electricity..." on that weakness alone is throwing the baby out with bath water. Let's fix the CA system, not throw out encryption.

larsonnn 3y ago

Interesting read. Just to add, even HTTPS isn't completely safe from Man-in-the-Middle attacks, especially in corporate environments. A few points to consider: - Some apps bypass or poorly implement certificate pinning. - Companies using self-signed certs can be spoofed. - There's always the risk of compromised Certificate Authorities. - Corporate tools that inspect HTTPS traffic, while useful for security, can inadvertently become a vulnerability if misconfigured or hacked. Always good to remember: HTTPS is a protective layer, but not an unbreakable barrier.