In addition to this, with SPDY around, these first milliseconds are becoming even more important. Since SPDY requires some sort of negotiation between server and client to agree they both support the protocol, this creates a problem for the first request: how do you know a server supports SPDY without having seen a response from said server? Note that the regular HTTP Accept negotiation is not enough since the browser should already pipeline multiple requests before having seen a response.
Since the designers of SPDY also figured security is important, they made use of TLS' protocol negotiation feature: they actually announce themselves as a TLS protocol in these first milliseconds of a HTTPS connection. Brilliant.
SPDY requires that you run it inside TLS. Within the already existing TLS handshake the client and server can advertise that they support SPDY instead of HTTP.
The way you describe it comes of as more complicated?!
Of the things to note is that nothing of SPDY describes encryption, which is why a lot of people have thought about using it without TLS via some other negotiation strategy (but nobody have really implemented this, since the value is only minor/non-existent outside internal networks).
Such a great article, true Hacker News material. Does not assume much knowledge about the field, yet still allows for a much deeper understanding of mechanics involved.
Agreed. Brilliant, and as someone who has been looking for accessible (for numerates) ways of learning about these such things I can't thank the poster enough.
I agree. I have meddled with wireshark time and again but never really got around to digging deep enough to understand what's exactly going on. I found this article to really fulfill my desire to understand the output of wireshark. It does a really good job of explaining what's going on. Much appreciated!
And now excuse me, i have to have a look at what happens when authenticating with my wlan router at the same level of depth :)
Please don't apologize! I don't know how many times I've googled for this type of thing, only to end up with a handful of stack overflow articles that don't even scratch the surface. This is one of the best reads I've seen on HN in a long time. Thank you!!
This reminds me of an old project. Explain all the bits that are communicated and computed across all APIs involved, when a user presses a key, and a set of pixels appear on the screen spelling "a".
About twenty years ago, I was able to do something pretty much like this for typing "cat file" - e.g. syscall interface, tty drivers, network protocols, filesystems, SCSI plus pervasive things like schedulers and memory managers. I can't do that any more, though, because I've become more of a storage specialist and some of the parts I haven't kept with have changed immensely. Also, some of the implementations of those parts in Linux are frankly insane and I no longer enjoy panning through a ton of dirt for a few flecks of gold.
Ditto. I'd still love to see whatever tidbits are available if only for historic reasons, which in itself is quite valuable. Might be also fun to see a before and after if someone else does an up to date version too.
Could someone point to a resource that would explain what happens when Im viewing a website on my phone driving down the highway?
What does my cellphone send to the nearest cell-phone tower?
What does the cell-phone tower send to the phone company servers? How do they tie back together packets coming back from https://news.ycombinator.com back to my phone?
Does this mean in SSL, the host name is not plain-text but in TLS it is?
To me, it seems better to use a possible-to-crack SSL with hidden hostname vs. hard/impossible to crack TLS where anyone can see I'm trying to go to https://anonymous-upload.wikileaks.org.
If the host name is encrypted the server needs to provide an SSL certificate identifying itself before it knows what host the user will request. This works if there's only one host on that IP, but if there's a 1-to-1 mapping between hosts and IPs then an attacker can figure out you're going to anonymous-upload.wikileaks.org from the fundamentally public information that you're going to 190.93.240.19. The way to fix this is to use tor, not to go back to old versions of SSL.
Note that certificates are always sent in plain. If it's a CA-signed certificate it will always have a common name or subject alt name field that specifies what host it is for (or a wildcard), readable in plain.
If it's a self-signed certificate scrubbed from anything identifiable then a server could still try to correlate what website you visited by the public key from the certificate.
They can see that anyway if they intercept the traffic anyway, since the IP will be in all packets. Even better, the TCP connection will end up creating routing tables on all hops along the way.
You can't have multiple secure domains on a single host which don't require the user to know a non-standard port without exposing the domain in plain text as part of SNI.
I don't get the comment how TCP creates routing tables but just having an IP address for HTTPS is not necessarily sufficient as you can have virtual hosts.
Since the designers of SPDY also figured security is important, they made use of TLS' protocol negotiation feature: they actually announce themselves as a TLS protocol in these first milliseconds of a HTTPS connection. Brilliant.
For more information, see: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...