4 ms·

The path and query string are only transmitted over TLS, so it should be fine so long as you never use HTTP without TLS.

tialaramex 6y ago
Indeed, let's break it down: The scheme (https) is implied but isn't transmitted anywhere. An adversary can infer you used HTTPS because it was port 443 and looks like TLS traffic. The hostname (www.duckduckgo.com) is somewhat implied by the destination IP address on the connection, and is also transmitted in the clear as part of TLS Server Name Indication so that the receiving server knows which service you wanted. In TLS 1.2 and earlier the site's certificate is also transmitted in the clear (but this is fixed in TLS 1.3). Encrypting SNI is a work-in-progress. The path and query string are encrypted. An adversary can't discover what they are, nor can they tamper with them successfully. The total overall amount of data sent is not hidden, but clients can (though most do not) add padding to hide exactly how much of this was "real". The fragment identifier (#foo) is not transmitted anywhere it remains only on the client (web browser). Headers, body and so on of both request and response are encrypted, and the same caveat about an adversary knowing how much data was transmitted and when applies.
- kortex 6y ago
  This is a really good summary! A few months back I was hunting for an answer as to whether url/query parameters were encrypted with HTTPS. The answer space was strangely sparse for something so critical.
  - tialaramex 6y ago
    The answer is obvious† to somebody who knows how it works, so it's probably in a category of questions where there's not a lot of overlap between people who might ask and people who might be in a position to answer. I remember when I answered a Stack Overflow question about how Domain Validation for certificates in the Web PKI work thinking that just a year or two earlier the answer would be hazy and probably get marked unsatisfactory even though it was true - because it was so vague and few people would be in a position to confirm it. As it happened they'd asked after the Ten Blessed Methods were formally required and so those are the answer, written down in black and white in a document I could offer as a reference for anyone to look at. † The hostname part is less obvious than the rest it's fair to say because HTTP's Host header is just a header and thus encrypted, and you need extra insight to realise SNI needs to exist.
- kyuudou 6y ago
  None of it really matters though if the certificate authorities are compromised.
  - tialaramex 6y ago
    How so? If a CA is compromised (which was very rare, even under historically more lax oversight than today) the bad guys would need to issue themselves a cert from this compromised CA, get it logged, and then from an on-path position use the certificate to MITM you and capture your URL which presumably they wanted very badly as this seems like a really expensive approach. The CA does not have the ability to decrypt eavesdropped HTTPS traffic for example.

tialaramex 6y ago

Indeed, let's break it down: The scheme (https) is implied but isn't transmitted anywhere. An adversary can infer you used HTTPS because it was port 443 and looks like TLS traffic. The hostname (www.duckduckgo.com) is somewhat implied by the destination IP address on the connection, and is also transmitted in the clear as part of TLS Server Name Indication so that the receiving server knows which service you wanted. In TLS 1.2 and earlier the site's certificate is also transmitted in the clear (but this is fixed in TLS 1.3). Encrypting SNI is a work-in-progress. The path and query string are encrypted. An adversary can't discover what they are, nor can they tamper with them successfully. The total overall amount of data sent is not hidden, but clients can (though most do not) add padding to hide exactly how much of this was "real". The fragment identifier (#foo) is not transmitted anywhere it remains only on the client (web browser). Headers, body and so on of both request and response are encrypted, and the same caveat about an adversary knowing how much data was transmitted and when applies.

kortex 6y ago
This is a really good summary! A few months back I was hunting for an answer as to whether url/query parameters were encrypted with HTTPS. The answer space was strangely sparse for something so critical.
- tialaramex 6y ago
  The answer is obvious† to somebody who knows how it works, so it's probably in a category of questions where there's not a lot of overlap between people who might ask and people who might be in a position to answer. I remember when I answered a Stack Overflow question about how Domain Validation for certificates in the Web PKI work thinking that just a year or two earlier the answer would be hazy and probably get marked unsatisfactory even though it was true - because it was so vague and few people would be in a position to confirm it. As it happened they'd asked after the Ten Blessed Methods were formally required and so those are the answer, written down in black and white in a document I could offer as a reference for anyone to look at. † The hostname part is less obvious than the rest it's fair to say because HTTP's Host header is just a header and thus encrypted, and you need extra insight to realise SNI needs to exist.
kyuudou 6y ago
None of it really matters though if the certificate authorities are compromised.
- tialaramex 6y ago
  How so? If a CA is compromised (which was very rare, even under historically more lax oversight than today) the bad guys would need to issue themselves a cert from this compromised CA, get it logged, and then from an on-path position use the certificate to MITM you and capture your URL which presumably they wanted very badly as this seems like a really expensive approach. The CA does not have the ability to decrypt eavesdropped HTTPS traffic for example.