True, the query string (https://myserver?query=string&is=here) is encrypted when making an HTTPS call. The issue is that some people pose a very similar question with the opposite answer: Is the query string secured when making a GET request over HTTPS? Here's how I proved to myself that data in the query string is encrypted but doesn't really belong there.
I used Safari to make web requests to the same URL, once over http and another time over https. Then I used a program called
Eavesdrop to capture the TCP packets, mostly because its application icon is a giant ear. Actually, I normally use
Wireshark but the screen capture in XWindows kinda sucks on OSX (and the giant ear made me laugh).
http://blogstamp.org/blogstamp/validate?matt=cansee
Notice how you can see the whole GET request (GET /blogstamp/validate?matt=cansee HTTP/1.1)
https://blogstamp.org/blogstamp/validate?matt=cansee
Notice how you can't decipher anything except the host name (blogstamp.org).
Analysis
Of course this all makes perfect sense since TLS/SSL is encryption in the transport layer. A handshake happens between the endpoints before the application layer even sends its data. So in our case, the secure connection is established prior to the GET (URI + Query parameters) data request.
Sensitive Data Transmission in the Query String
One of the main concerns with sensitive data is privacy-- you really don't want sensitive data (e.g. password) sitting around somewhere in cleartext. Here's a few places where the query string is exposed as cleartext:
- Server side logs
- History caches in browsers
- Bookmarks
- Bugs in the application/browser (e.g. HTTP referrer leakage)
The best you can do today is to POST sensitive data to a server over HTTPS.
