Hacker News new | comments | show | ask | jobs | submit login
The First Few Milliseconds of an HTTPS Connection (2009) (moserware.com)
549 points by dhotson on Aug 29, 2013 | hide | past | web | favorite | 37 comments



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.

For more information, see: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...


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).


How does what I describe differ from SPDY using a TLS handshake as advertising SPDY support? In any case, it was my intention to explain exactly that.


Why not use the HTTP protocol switch thing that WebSocket uses?


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 :)


Previous discussion (2009): https://news.ycombinator.com/item?id=650914


Yep, sorry for the repost.

I figured that enough time had passed since the last time since it's such an excellent article. ;-)


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!!


And right you are. It's great.


No apologies necessary, thanks for this!


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.


I wouldn't mind seeing that, even for a 20 year old system.


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.


There's a wonderful post similar to your old project. https://plus.google.com/112218872649456413744/posts/dfydM2Cn...


Did you ever get around to finish that? I'm curious.


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?


If it's you driving, you put down the phone and pay attention to the road. :)


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.

https://en.wikipedia.org/wiki/Server_Name_Indication


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.


Unless there are multiple secured domains hosted on that IP address, in which case knowing the domain would be extra information.


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.


You can if you have a certificate with multiple domain names in the SAN[0] field.

[0] http://en.wikipedia.org/wiki/SubjectAltName


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.


Anyone monitoring you will have seen your initial DNS query.


Why is this so complicated?


Because good security is hard.


Jeff Moser's blog is awesome.


"was". He hasn't posted since Nov 2011


Nice analysis. But why is this trending now? This is from 2009.


Discovered or rediscovered by someone, and seemingly new to some on here or still appreciated by enough others to upvote.

FWIW, it was the first time I'd seen it. Very comprehensive.


Great article.


excellent. thanks for posting.




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: