29

While perusing the contents of pcap files I've noticed some URLs appear to be visible despite being HTTPS. These mainly occur inside payloads that contain cert URLs too, but I also see HTTPS URLs inside what appear to be HTTP payloads.

Can someone say conclusively whether HTTPS URLs are truly kept secret?

I'm concerned about this because I want to put some parameters in the URL and I don't want these to be easily uncovered.

Icann
  • 433
  • 1
  • 5
  • 11
  • 6
    It sounds like you are looking at plain HTTP traffic which happens to contain hyperlinks to HTTPS pages. The fact the hyperlink will lead to an HTTPS page if followed doesn't magically encrypt data on the page linking to it. – lzam Feb 06 '15 at 06:15
  • The answer is simple. Is the person running Wireshark an administrator of the computer that is running your program? IFF yes, then yes. – Aron Feb 06 '15 at 09:38
  • 1
    @Izam: sounds plausible. So a partial answer to "are HTTPS URLs truly kept secret?" is "not if you publish those URLs on the internet" ;-) – Steve Jessop Feb 06 '15 at 09:50
  • 2
    So to summarize all the answers: the request URL (other than hostname) is protected exactly as well as the rest of the data, except it might be stored in browser history. And traffic analysis could let attackers figure out what someone is doing on your site. Sensitive info in form parameters sent with GET requests is fine over the wire as long as SSL isn't defeated (with several answers going off on that useful tangent), but should maybe be avoided for use in ways that will go in a users' browser history. – Peter Cordes Feb 06 '15 at 20:22
  • @Icann although not related to your specific question, it's important to remember the other place that https URLs can end up is in log files server side (maybe even multiple logs e.g. stunnel>haproxy>nginx>appserver). That's probably a good enough reason in itself to keep "secret" stuff out of the url and url query string regardless whether HTTP or HTTPs – tardate Feb 09 '15 at 05:49

5 Answers5

49

With HTTPS the path and query string of the URL is encrypted, while the hostname is visible inside the SSL handshake as plain text if the client uses Server Name Indication (SNI). All modern clients use SNI because this is the only way to have different hosts with their own certificates behind the same IP address.

The rest of the URL (i.e. everything but the hostname) will only be used inside the encrypted connection. Thus in theory it is hidden from the attacker unless the encryption itself gets broken (compromising the private key, man-in-the-middle attacks etc). In practice an attacker might have indirect ways to get information about the remaining part of the URL:

  • Different pages on the same server serve different content with different sizes etc. If the attacker scans the site to find out all possible pages he might then be able to find out which pages you've accessed just by looking at the size of the transferred data.
  • Links to other sites contain Referer header. Usually the Referer is stripped when linking from https to http, but if the attacker controls one of the sites linked with https he might be able to find out where the link came from, that is the site you've accessed.

But in most cases you are pretty safe with HTTPS, at least much safer than with plain HTTP.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 3
    I assume another indirect method would be by viewing your browser history? – Silveri Feb 06 '15 at 12:15
  • 2
    That's not a bad point, actually. I mean, if an attacker can read your browser history, they can probably do a lot more stuff. But it might be a good idea to keep sensitive info out of URLs so they don't go in browser history, to limit the damage of someone losing having their browser history compromised. – Peter Cordes Feb 06 '15 at 20:19
12

Both HTTP headers (containing requested URL) and application data in HTTPS is encrypted.

You can see requested hostname, because browsers send it in Service Name Indication extension during handshake, so that server can choose matching SSL certificate.

zakjan
  • 356
  • 2
  • 8
11

Using wireshark, you will be able to find out the host name, as mentioned by some other answers, due to SNI. Also, you'll be able to see some parts of certificates. The https URLs you've seen were probably the URLs of CRLs or OCSPs.

If someone could get at your URLs by walking your site, and compare the size of the returned pages with the size of what's returned in your encrypted page, they could make assumptions about which page your program called. But, as you want to put some parameters into the URL and hide those, this isn't a big attack vector in your case. If your URL is https://my.server/api?user=scott&password=tiger&highscore=12345, and your api always returns pages between 1000 and 1010 bytes, seeing 1007 bytes returned won't help anyone determine user or password or how to enter a highscore.

HOWEVER

https is only secure if you prevent MITM attacks. Tools like fiddler, charles or mitmproxy redirect your traffic to themselves, present a faked certificate to the client, decrypt the traffic, log it, re-encrypt it, and send it to the original site.

If your client relies on the OS's truststore, then the attacker will be able to insert his own certificate into the truststore, and your client will not notice anything. The READMEs of the abovementioned tools have instructions how to do this.

So, if you go https to prevent decryption, you will need to check if the certificate returned by the server is correct before you actually send your URL. Check how certificate pinning works for your OS/programming language, and use the above tools to make sure your client will detect a fake certificate and not send the URL before you publish it.

Guntram Blohm
  • 1,529
  • 11
  • 13
  • Good answer about mentioning the possibility of the browser contacting the CRL publishing site for a cert. I've never understood why CAs don't publish these on https sites. They seem to be mostly on http sites, which doesn't make much sense. – Steve Sether Feb 06 '15 at 16:00
  • @SteveSether The CRL file is signed, and encrypting it isn't necessary, so insecure http is fine. Plus, using https would be tricky: How do you connect to `https://crl.example.com/` to validate `crl.example.com`'s own certificate? http sidesteps that issue. – Matt Nordhoff Feb 09 '15 at 06:33
  • @MattNordhoff Thank you! That answers the question. Though I believe the CRL is just supposed to be for revocation, so you're trusting the CA, and the CA's root cert. I'm assuming it's signed with the CA's root cert? – Steve Sether Feb 09 '15 at 12:09
  • @MattNordhoff - insecure http is *never* fine. – StampyCode Mar 14 '16 at 09:42
3

It is possible to perform traffic analysis by crawling the website and comparing packet sizes, etc. Depending on how much dynamic content is present or images referenced from the URL it is possible to get a very accurate understanding of which URLs where visited.

The presentation SSL Traffic Analysis Attacks - Vincent Berg (YouTube) explains it and has some functional demonstrations.

Peter Mortensen
  • 877
  • 5
  • 10
wireghoul
  • 5,745
  • 2
  • 17
  • 26
  • 2
    While interesting, this clearly doesn't answer the question as wireshark isn't doing that. I don't like being a pedant, but the answer only tangentially connects to the question. This seems more appropriate as a comment somewhere than an answer. – Steve Sether Feb 06 '15 at 16:03
  • I answered the security specific concern. I don't think security decisions should be made on the basis of perceived limits of tools. Since wireshark supports plugins the capability can be added. – wireghoul Feb 07 '15 at 02:00
1

It is possible if the attacker has access to the client, for an overview see: https://wiki.wireshark.org/SSL#Using_the_.28Pre.29-Master-Secret

For example on Java-Clients an agent like jSSLKeylog can be attached to intercept and log the supposed encrypted content/URL. If the PreMaster-Secret of an communication can be obtained through any means in the process, captured encrypted communication can be decoded afterwards.

Alim Özdemir
  • 111
  • 3