Live data from Hacker News

Every Byte of a TLS Connection Explained and Reproduced

tls.ulfheim.net

51–60 of 104 posts

Re: Every Byte of a TLS Connection Explained and Reproduced

#51
post #38

Author here - I was going to publish this today but it leaked out ahead of time. Enjoy! EDIT: I'm putting a CDN in place.

Great illustration, I am going to share this with the rest of my team. One thing that I would find interesting is how x509 client certificates fit into the negotiation. I know this is optional so I don't know how it would fit into your flow easily though.

Yes, I thought about explaining client certs and others (the first request I got was to add ALPN to the connection), but there's already so much to talk about in even this simple connection that I thought it would detract from the document as a whole by making it even longer and denser.

I didn't even get a chance to explain the (normal, server-side) x509 certificate signing much because it just kept taking over the document. TLS is complex enough that just explaining the happy path is 400kb of HTML.

Re: Every Byte of a TLS Connection Explained and Reproduced

#52

Earlier quoted context omitted.

Per session.

Unrelated but: based on your understanding of establishing a TLS session with a server, and then traffic through that connection, do you think the new Gmail user interface for the web (desktop) is sufficiently speedy? The reason I ask in this thread is that this thread treats some of the low-level minimum traffic necessary between clients and servers.

What does TLS have to do with the Gmail redesign? It used TLS before the redesign, didn't it?

Re: Every Byte of a TLS Connection Explained and Reproduced

#53

Earlier quoted context omitted.

Per session.

Unrelated but: based on your understanding of establishing a TLS session with a server, and then traffic through that connection, do you think the new Gmail user interface for the web (desktop) is sufficiently speedy? The reason I ask in this thread is that this thread treats some of the low-level minimum traffic necessary between clients and servers.

Gmail was using TLS since day 1. If it's slow for you the first likely culprit is the sheer weight of Javascript and DOM work, followed by making more web requests than necessary.

Re: Every Byte of a TLS Connection Explained and Reproduced

#54

Earlier quoted context omitted.

Unrelated but: based on your understanding of establishing a TLS session with a server, and then traffic through that connection, do you think the new Gmail user interface for the web (desktop) is sufficiently speedy? The reason I ask in this thread is that this thread treats some of the low-level minimum traffic necessary between clients and servers.

What does TLS have to do with the Gmail redesign? It used TLS before the redesign, didn't it?

It gives a target or minimum for a fast and lightweight secure web application.

Re: Every Byte of a TLS Connection Explained and Reproduced

#55
post #46

Has anyone of you seen such beautiful explanation for other protocols (TCP, 4-way handshake)?

They're in text form, but I've always loved the clarity of W. Richard Stevens' (RIP) books on TCP/IP.

He did a great job of demonstrating every byte and jitter on the wire and how it related to the underlying BSD TCP/IP stack.

Re: Every Byte of a TLS Connection Explained and Reproduced

#56
post #48

Cool! Would you be able to add a ascii view beside it?

I was afraid that it wouldn't fit and might be overly complex for what was gained (there's not much text in there). However there's a PCAP at https://github.com/syncsynchalt/illustrated-tls/tree/master/... if you'd like to load it up in wireshark or tcpdump.

Re: Every Byte of a TLS Connection Explained and Reproduced

#57
post #48

Cool! Would you be able to add a ascii view beside it?

Not trying to come off trite, but the RFC [0] has a simple ASCII diagram of the message flow and the structures that follow are fairly easy to read. Granted you have to hop to a couple of other RFCs to understand extensions and maybe even real world impls to understand some changes (e.g. no time in the random block of client hello), but it's worth perusing if you're interested. 0 - https://tools.ietf.org/html/rfc5246…

I think they mean a side-by-side ASCII interpretation like that supplied by `hexdump -C` - where any alphanumeric character is printed as itself and every other character is printed as a "."

It gives a nice strings-like view of raw data.

Re: Every Byte of a TLS Connection Explained and Reproduced

#58
post #10

Nice, could have really used this a few years ago when I was making my own HTTP server implementation. Could someone make a PDF of this? Any C++ and C# examples of this?

I might post a PDF later (as the content becomes final), or make a printable view. In the meantime try this:

    # in your javascript console, paste this:
    [].forEach.call(document.querySelectorAll(".record, .calculation"), function(el){el.classList.add("selected")});
    [].forEach.call(document.querySelectorAll(".record, .calculation"), function(el){el.classList.add("annotate")});
    [].forEach.call(document.querySelectorAll("codesample"), function(el){el.classList.add("show")});
Then you can print the page to PDF.

Re: Every Byte of a TLS Connection Explained and Reproduced

#59
tls.ulfheim.net - "This site is blocked due to a security threat."

ulfheim.net - no problem

At least according to my megacorp threat filter. I have never actually seen something blocked before, and it's a shame because the page would be great to share with my team.

Re: Every Byte of a TLS Connection Explained and Reproduced

#60
post #59

tls.ulfheim.net - "This site is blocked due to a security threat." ulfheim.net - no problem At least according to my megacorp threat filter. I have never actually seen something blocked before, and it's a shame because the page would be great to share with my team.

This is one of the major problems with threat feeds.
Post reply on HN