Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The First Few Milliseconds of an HTTPS Connection (2009)

moserware.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: The First Few Milliseconds of an HTTPS Connection (2009)

#21

Post by mrud »

lucian1900 wrote: post #17
chime wrote: post #16

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 .

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.

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.

Re: The First Few Milliseconds of an HTTPS Connection (2009)

#22

Post by cbr »

chime wrote: post #16

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

Re: The First Few Milliseconds of an HTTPS Connection (2009)

#23

Post by richardwhiuk »

masomenos wrote: post #20
lucian1900 wrote: post #17

Earlier quoted context omitted.

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.

Re: The First Few Milliseconds of an HTTPS Connection (2009)

#24

Post by hyperpape »

notacoward wrote: post #14
gatestone wrote: post #4

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 thos…

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

Re: The First Few Milliseconds of an HTTPS Connection (2009)

#25

Post by xnyhps »

chime wrote: post #16

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 .

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.

Re: The First Few Milliseconds of an HTTPS Connection (2009)

#26

Post by [deleted] »

notacoward wrote: post #14
gatestone wrote: post #4

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 thos…

[deleted]

Re: The First Few Milliseconds of an HTTPS Connection (2009)

#27

Post by RKearney »

richardwhiuk wrote: post #23
masomenos wrote: post #20

Earlier quoted context omitted.

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

Re: The First Few Milliseconds of an HTTPS Connection (2009)

#29

Post by billpg »

chime wrote: post #16

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 .

Anyone monitoring you will have seen your initial DNS query.

Re: The First Few Milliseconds of an HTTPS Connection (2009)

#30

Post by dencold »

dhotson wrote: post #5
stalled wrote: post #3

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!!
Post reply on HN