This is very nice. I think the green on green and blue on blue highlight are a little hard to see.
Agreed - the color choice is one of the things I never really felt happy with (I'm not a frontend guy).
Every Byte of a TLS Connection Explained and Reproduced
21–30 of 104 posts
Re: Every Byte of a TLS Connection Explained and Reproduced
#22This 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 we recast sni into just a type and a string, the string is clearly going to take the rest of the extension length, so it doesn't need a two byte length either.
Re: Every Byte of a TLS Connection Explained and Reproduced
#23So does this happen for every single request? or is this based on a single session.
The two "application data" records at the bottom are what would wrap around a request/response for an established connection - you can see how much is added to make the strings "ping" and "pong" (though some of that is padding to expand it to a multiple of 16 bytes).
And much of the rest of the records might go away completely if the session were resumed from the client's memory (this wasn't demonstrated here).
Re: Every Byte of a TLS Connection Explained and Reproduced
#24There's a lot of practicality I learned from reading the Go source and implementing my own (e.g. always an array of a single value of 0 for compression method). Now do a version with DTLS (one more message type, couple more fields on existing types, and logic concerning retries). Also, now do a TLS 1.3 one.
Yep, reading the Go source is what inspired me to do this, it's still very compact and readable. I originally used an AEAD cipher but found it was impossible to demonstrate on the command line (openssl enc refuses to do AEAD because it can't confirm the authentication in a streaming context). A friend asked me to demonstrate ALPN in this but as I looked into it I found it was distracting, as there's already so much g…
> As for 1.3 my next project was going to be implementing it rather than documenting it. Just a throwaway implementation, nothing you'd want to use.
Since you read the Go source, you might like [0]. I will say I personally think Go could have done better. I think it's too compact, too hidden, too disorganized, too underdocumented, and too inflexible/non-extensible. I began to pick some of it apart for a DTLS impl I started at [1], but have put on temporary hold yesterday due to other work obligations.
0 - https://github.com/cloudflare/tls-tris 1 - https://github.com/cretz/go-dtls
Re: Every Byte of a TLS Connection Explained and Reproduced
#25Beautiful. I recently had to implement two way auth over 1.2 and this would have saved much hair pulling. (and who does TWO way auth over an MPLS connection. Turns out, us).
I feel your pain. Two-way TLS is a funny thing, it's supported by the standards and even most implementations but its actual use is minuscule compared to "normal" one-way TLS, so much so that it's hard to find documentation even acknowledging two-way TLS exists, let alone how to use it.
And don't get me started about the hassles of obtaining signed certificates that are actually usable for client auth...
Re: Every Byte of a TLS Connection Explained and Reproduced
#26Earlier quoted context omitted.
Yep, reading the Go source is what inspired me to do this, it's still very compact and readable. I originally used an AEAD cipher but found it was impossible to demonstrate on the command line (openssl enc refuses to do AEAD because it can't confirm the authentication in a streaming context). A friend asked me to demonstrate ALPN in this but as I looked into it I found it was distracting, as there's already so much g…
> As for 1.3 my next project was going to be implementing it rather than documenting it. Just a throwaway implementation, nothing you'd want to use. Since you read the Go source, you might like [0]. I will say I personally think Go could have done better. I think it's too compact, too hidden, too disorganized, too underdocumented, and too inflexible/non-extensible. I began to pick some of it apart for a DTLS impl I s…
I've also had https://github.com/h2o/picotls suggested.
Re: Every Byte of a TLS Connection Explained and Reproduced
#27Site's timing out and google cache is giving me a 404...
Re: Every Byte of a TLS Connection Explained and Reproduced
#28HN hug of death ? Page is timeouting
Re: Every Byte of a TLS Connection Explained and Reproduced
#29The irony is: I get "Your connection is not secure" when trying to open the link.
Re: Every Byte of a TLS Connection Explained and Reproduced
#30So does this happen for every single request? or is this based on a single session.
This is what happens under the hood of every ping request.
A ping is very much different. A ping is (typically) simply an ICMP Echo Request, (not TCP, thus no TLS, etc). The receiving device, if accepting echo requests and configured to reply with echo replies, then responds with an ICMP Echo Reply - or some device in the middle (or the device itself could respond with an ICMP unreachable, or some other response - or quite simply drop the ICMP Echo Request entirely and silently).
*Edited an incorrect UDP reference out based on the below comment.