excellent. thanks for posting.
The First Few Milliseconds of an HTTPS Connection (2009)
11–20 of 39 posts
Re: The First Few Milliseconds of an HTTPS Connection (2009)
#12Why is this so complicated?
Re: The First Few Milliseconds of an HTTPS Connection (2009)
#13Such 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.
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 :)
Re: The First Few Milliseconds of an HTTPS Connection (2009)
#14This 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.
Re: The First Few Milliseconds of an HTTPS Connection (2009)
#15This 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".
There's a wonderful post similar to your old project.
https://plus.google.com/112218872649456413744/posts/dfydM2Cn...
Re: The First Few Milliseconds of an HTTPS Connection (2009)
#16Does 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.
Re: The First Few Milliseconds of an HTTPS Connection (2009)
#17Does 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 .
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.
Re: The First Few Milliseconds of an HTTPS Connection (2009)
#18Why is this so complicated?
Because good security is hard.
Re: The First Few Milliseconds of an HTTPS Connection (2009)
#19In 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...
Re: The First Few Milliseconds of an HTTPS Connection (2009)
#20Does 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 .
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.