As a crypto ignoramus - Why is the random data from each side necessary? Why can’t things just be encrypted with the PreMasterSecret directly ?
Every Byte of a TLS Connection Explained and Reproduced
81–90 of 104 posts
Re: Every Byte of a TLS Connection Explained and Reproduced
#82http://www.networksorcery.com/enp/Protocol.htm has a bunch of network diagrams for various protocols.
This website lays things out really nicely, would love to have more protocols :)
Re: Every Byte of a TLS Connection Explained and Reproduced
#83As a crypto ignoramus - Why is the random data from each side necessary? Why can’t things just be encrypted with the PreMasterSecret directly ?
It's about the nonce / initialization vector. Basically it is used inside the cryptos primitives to add some entropy to the encryption itself and prevent a various ranges of attacks. A good introduction to crypto is "Introduction to modern cryptography" imho
Re: Every Byte of a TLS Connection Explained and Reproduced
#84Author here - I was going to publish this today but it leaked out ahead of time. Enjoy! EDIT: I'm putting a CDN in place.
I did a presentation at our local software meetup on this topic a month ago, and wow, I could have really used this. It's way clearer and more organized than my muddled slides.. :-)
Very nice work !
Re: Every Byte of a TLS Connection Explained and Reproduced
#85As a crypto ignoramus - Why is the random data from each side necessary? Why can’t things just be encrypted with the PreMasterSecret directly ?
Involving random data gives everybody who gets to pick the random data (so in TLS that's both client and server) a freshness guarantee.
Because the other party needed to know you'd picked this particular random data to make the keys, the messages from them encrypted with those keys couldn't possibly have been pre-recorded / replayed.
In the ephemeral Diffie Hellman modes both parties contribute to the key anyway so this isn't as important, but with old school RSA the random values are the only thing preventing Replay attacks.
TLS 1.3 capable servers also scribble "DOWNGRD" in part of the random field if a client message says it can't do TLS 1.3. If a TLS 1.3 client sees that unusual "random" choice it knows bad guys tampered with the connection (attempted a downgrade attack). If bad guys just change the values, they won't match between client and server and the connection aborts. Older clients think nothing of the unusual random value and carry on as before.
Re: Every Byte of a TLS Connection Explained and Reproduced
#86I remember implementing ssl in java when I worked for Netscape back in the day. Nostalgia rush looking at this. Great stuff
Re: Every Byte of a TLS Connection Explained and Reproduced
#87This is wonderful! I may make a version where the bytes used for lengths are highlighted, since it feels like so many bytes are lengths; look at the SNI extension, which has three 16-bit lengths, I know why they're there, but SNI probably shouldn't be a list, and even if it was a list, an extension that consists solely of a list has a list of the length of the extension, you shouldn't need two bytes for that, and if…
Moreover, from a security perspective since we're talking about TLS, "overspecified" and/or "redundant" lengths are just begging to be made inconsistent and a source of vulnerabilities.
Re: Every Byte of a TLS Connection Explained and Reproduced
#88As a crypto ignoramus - Why is the random data from each side necessary? Why can’t things just be encrypted with the PreMasterSecret directly ?
Involving random data gives everybody who gets to pick the random data (so in TLS that's both client and server) a freshness guarantee. Because the other party needed to know you'd picked this particular random data to make the keys, the messages from them encrypted with those keys couldn't possibly have been pre-recorded / replayed. In the ephemeral Diffie Hellman modes both parties contribute to the key anyway so t…
TLS 1.3 capable servers also scribble "DOWNGRD" in part of the random field if a client message says it can't do TLS 1.3. If a TLS 1.3 client sees that unusual "random" choice it knows bad guys tampered with the connection (attempted a downgrade attack). If bad guys just change the values, they won't match between client and server and the connection aborts. Older clients think nothing of the unusual random value and carry on as before.
I haven't looked at the spec in detail, but does this mean that random generation has to specifically exclude that "sentinel value", lest it accidentally occur?
Re: Every Byte of a TLS Connection Explained and Reproduced
#89The parties had agreed on a cipher suite using ECDHE, meaning the keypairs will be based on a selected Elliptic Curve, Diffie-Hellman will be used, and the keypairs will be Ephemeral rather than using the public/private key from the certificate.
I think it's important to mention that even with ephemeral cipher suites, the server's ephemeral public key is signed using the server's certificate private key and verified by the client, since otherwise one would be able to MITM the key exchange.
Re: Every Byte of a TLS Connection Explained and Reproduced
#90Earlier quoted context omitted.
Involving random data gives everybody who gets to pick the random data (so in TLS that's both client and server) a freshness guarantee. Because the other party needed to know you'd picked this particular random data to make the keys, the messages from them encrypted with those keys couldn't possibly have been pre-recorded / replayed. In the ephemeral Diffie Hellman modes both parties contribute to the key anyway so t…
TLS 1.3 capable servers also scribble "DOWNGRD" in part of the random field if a client message says it can't do TLS 1.3. If a TLS 1.3 client sees that unusual "random" choice it knows bad guys tampered with the connection (attempted a downgrade attack). If bad guys just change the values, they won't match between client and server and the connection aborts. Older clients think nothing of the unusual random value and…
The probability of a particular seven bytes occurring by chance is less than one in a billion billion billion billion.