Let's say I enter http://domain.com/... as a URL. The domain.com server performs a 301 redirect of all HTTP requests to the HTTPS version, so it shows me https://domain.com/....

Can my ISP see the whole URL (not just domain name) that I entered with HTTP when I made the request (if they are monitoring traffic)?

  • A malicious ISP can even see your HTTPS traffic if the are using a man-in-the-middle attack.
    – agtoever
    Oct 3 '15 at 5:29
  • 6
    @agtoever An ISP can't MITM HTTPS unless they have a certificate on your machine, or some vulnerability.
    – Buge
    Oct 3 '15 at 5:54
  • Most ISPs will have some certificate (for example for webmail). They can use that certificate as explained here to perform a not-too-easy-to-detect MitM attack...
    – agtoever
    Oct 4 '15 at 6:49


This is the reason that SslStrip works. (Okay, one of the reasons.)

HTTP is in the clear. So the 301 is in the clear as well. Anyone who's listening with e.g. Wireshark will be able to see this. (Try for yourself on the same host. It's easy.)

  • 1
    No. Not if the browser knows that the site uses HSTS,either through pre-registration or from a previous visit. In that case, it will change the scheme to 'https before sending any request.
    – symcbean
    Oct 2 '15 at 17:39
  • 3
    @symcbean: true, but OP did not mention HSTS. Oct 2 '15 at 18:04
  • 4
    @symcbean If you unplug your network cable and turn off your wireless, then even if you enter an HTTP URL, your ISP cannot see which URL you requested, because no HTTP request ever gets sent. I'm pretty sure you wouldn't consider that an interesting scenario. HSTS basically means that even though you enter an HTTP URL, no HTTP request is sent either, so to be honest I don't really see why it would be worth even bringing up.
    – hvd
    Oct 2 '15 at 19:09
  • 1
    @symcbean "Before a HTTP request is 301-redirected to HTTPS". In the case of HSTS, an HTTP request is not 301-redirected to HTTPS, so it's out-of-scope of the question.
    – user253751
    Oct 3 '15 at 0:47

Yes, the ISP can see the whole URL as the request before the redirect to HTTPS is plain HTTP.

HTTP Strict Transport Security (HSTS) is trying to fix that by having the server notify the browser to only connect via HTTPS. Of course, the very first request to a HSTS enabled site is still unencrypted, because the browser doesn't know about the HSTS policy of the site. Browser vendors are trying to fix that by maintaining lists of HSTS enabled sites .

If it's just for your own safety (and not in general), you can also use HTTPS Everywhere, a plugin for most browsers that has a list of sites that are known to support HTTPS properly and you can and should add sites that are not yet in the list but support HTTPS, as this project is community driven.


To add to @StackzOfZtuff's answer (I can't comment yet, or else I would), before HTTP and well before SSL/TLS get involved, your TCP handshake is visible referencing the actual host and the nature of the request. After that, your client HELO to the webserver is visible, though the URL itself is not presented. Your data, including the actual GET, is encrypted once SSL key exchange is done between you and the server. By then you are about 9 packets into the sequence already.

In situations where HTTP is redirecting to HTTPS, that 301 response from the server to send you to the relevant HTTPS URL doesn't happen until after your browser has sent 'GET /.txt' in the clear. Additionally, the 301 response with URL is completely visible, as it is also sent over unencrypted HTTP.

  • 1
    You know, this stands perfectly well as its own answer.
    – Nic
    Oct 3 '15 at 11:20

Yes your ISP can see the URL of your HTTP request because the URL is sent in the clear.

Moreover, your ISP may be able to see the hostname of the URL even after you make the jump to HTTPS if the website is using SNI (https://en.wikipedia.org/wiki/Server_Name_Indication) which is an increasingly likely scenario in the wild. For example (https://aws.amazon.com/about-aws/whats-new/2014/03/05/amazon-cloudront-announces-sni-custom-ssl/)

  • 2
    It's not up to the server to use SNI. A client that supports SNI will always send SNI, whether or not the server is going to process the SNI.
    – Lie Ryan
    Oct 3 '15 at 15:18

Your Answer

