Hacker News Reader

Comment by flubert | Hacker News Reader

Where is a good site for getting an introduction on what HTTPS covers. Is the URL completely exposed? Does your ISP/third-parties know the domain, the subdomain, the path, and parameters in each URL?

View on HN

Think of it as occuring between TCP and HTTP. So you browser establishes a network connection to example.org, then negotiates to speak SSL/TLS, and then all the web things happen over the top of that (there are minor exceptions for vhost TLS configs).

So no web traffic should traverse in the clear - the URL, domains, GET data, POST data, headers, etc are protected.

however that does leave a surprising amount of info. Your IP address, the IP address you're connecting to, the host domain you're connecting to if your browser just did a DNS lookup (99% likely it did), how long you communicate with that site, the traffic shape, etc etc.

As a crude example: your ISP sees a DNS lookup to pornhub.com, followed by a connection to the IP address associated with that name, followed by 3 hours of fairly large packet sizes in regular repetitive patterns. It's highly likely they can extrapolate what's in your browser.

What I understand is that URL is encrypted, including path and parameters in URL and in POST requests. However, the IP address is public, and it's probably quite easy to link an IP address to a website.

There are several websites that offer this service: search an IP and get a list of all known websites that use that IP.

A link to an article from an authority in this field, that really explains this, would be really welcome!!!

This used to be correct, but modern SSL clients support SNI (Server Name Indication), which involves sending the exact hostname in the clear to allow vhosts to have different certificates. The path and everything else in the actual HTTP request is still private, though.

IP and port are required for routing, and as such aren't protected. The hostname is (usually) exposed through DNS, and is required for the server to know which certificate to send.

Also, usually (almost) everything is exposed on the first request, before the server has got the chance to redirect to the encrypted version. At that point, the ISP/interceptor could just replace the redirect...

> IP and port are required for routing, and as such aren't protected.

> The hostname is (usually) exposed through DNS, and is required for the server to know which certificate to send.

SNI solves this problem.

> Also, usually (almost) everything is exposed on the first request, before the server has got the chance to redirect to the encrypted version. At that point, the ISP/interceptor could just replace the redirect...

Admittedly, this is somewhat of a culture issue. I haven't read the DNSSEC spec, but it'd be cool to be able to specify redirects using DNS or smth. But at the end of the day, after that first connection (or preferably, it's already setup with HSTS preinitialized in your browser) you're never not going to be using HTTPS without scary warnings (assume the site admin has set up TLS properly).

Only the IP of the host server has to be known in HTTPS, the path and and other things are sent over an encrypted channel. However it's unlikely you're using Tor or DNSSEC, so the DNS lookup your browser does is also done over the clear, so the domain you're accessing is also probably compromised.

Reply on news.ycombinator.com