4 ms·

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 th

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 6y ago
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.

tialaramex 6y ago

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.