Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Just wondering, if you use SSL/TLS at the application layer would this make anybody trying to sniff between my client and the router unable to see which websites I am requesting to see?

Same with a VPN i presume?

I would like to prevent anybody sniffing between the client and the router from seeing which websites I am making http requests to.

share|improve this question

A normal SSL/TLS session in a browser (ie using https) generally makes a connection from the client to the webserver in question.

So while the traffic cannot be sniffed as it is encrypted, it is possible to see at least the destination IP address, and from there you can infer the website in question.

If on the other hand you are referring to using SSL as a VPN transport to a VPN server, and the outgoing connection is made from that to the webserver, then sniffing the local traffic would only show encrypted traffic between you and the VPN server, and so individual http requests would be hidden.

The other aspect to consider is where the DNS requests are going. If you use an unencrypted path to DNS servers to resolve before sending the http request to that site over the VPN, then sniffing DNS will show where you are visiting.

share|improve this answer
+1 for considering DNS leaks. – grawity Jan 10 '12 at 12:02
@Paul, I was thinking of using a SSL VPN. How is this different to connecting to a website using https? Also, could I hide my DNS requests in this VPN? – Trevor Jan 10 '12 at 19:38
@Trevor SSL VPN means that all of your conversation are with a single destination - the VPN server. All of the traffic between you is encrypted and cannot be evesdropped. Yes, you can put DNS requests and any other form of traffic across an SSL VPN, you just need to make sure that you are doing so - how you do this is somewhat dependent on implementation. – Paul Jan 10 '12 at 22:17

They would be able to see which IP address the requests are being made to. They would not be able to read the Host header in the request. Therefore, they can not pin it down to the exact web site you're looking at, only which server it's on (more or less).

share|improve this answer
The host name will also be visible in the certificate. – Bruno Jan 11 '12 at 12:43

They would be able to see which IP address you're requesting (this wouldn't necessarily resolve back to the host name you've requested) as well as the server certificate sent by the server during the handshake process. The server certificate is visible in clear during the handshake (it's a step required to established the encrypted channel, that happens just before the encryption is effective).

The server certificate will contain the host name, so it will be visible. In some cases, the certificate may contain multiple Subject Alternative Name (SAN) entries (or wildcard entries (e.g. *, which means it will be valid for multiple host names: this can be a bit ambiguous for the eavesdropper, but this gives a fairly strong clue.

(As @Paul said, the DNS could would also give a clue. If you know in advance which sites you want to visit, you might be able to prevent request by pinning the DNS entries in your hosts file.)

Modern clients that support Server Name Indication will also reveal the host name they're after in the server_name extension in the TLS ClientHello message.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.