20

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
22

Yes.

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. – StackzOfZtuff 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. – immibis Oct 3 '15 at 0:47
15

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.

6

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 Hartley Oct 3 '15 at 11:20
0

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

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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