SSL with GET and POST

Now, the question is, do you know what a HTTP request looks like?

Well, assuming not, here's an example of one:

GET /test?param1=hello&param2=world HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

All of this information is enscapulated within the SSL transport - as the comment on your answer kindly says. This means:

  • Get parameters are encrypted.
  • HTTP Body (post parameters) are encrypted.

What's not necessarily secure:

  • The host you're asking for. Most web servers these days support Host: something parameters so multiple domains can be handled by one web server on one interface and IP address. Clearly, this header is encrypted, however, if you run non-https traffic to the site it should be clear which hosts you might connect to. Even if that's not the case, reverse DNS will certainly tell you what's hosted on that IP and you can probably make a reasonable guess from there.
  • Your browser/client information. Unfortunately each https client is different and its negotiation process might potentially give away what platform it runs on, or what browser it is. This is not the end of the world by any means, it's just a fact to understand.

POST requests look similar to get requests, except they contain a body. This may look like this:

POST /testpost HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

param1=hello&param2=hello

There are some more complicated variants, of course, but essentially it is all encrypted anyway.


I didn't see this mentioned in the other responses, but you generally should not put secret information (passwords) in GET requests even with SSL, but use POST instead. Why? The URL with the sensitive information will generally be logged at both ends; e.g., in your browsers history list (https://www.example.com?user=me&password=MyPassword) as well as the logs on the server. POST information (especially with passwords) is generally not written to webserver logs, though obviously can be configured to be logged--so its best not to reuse (or use similar) passwords at different sites.


SSL encrypts and ensures the authenticity of the whole connection, including the requested method and URL. A GET is just as well protected as a POST.

When SSL works as intended, an eavesdropper can only see what IP address is connecting to what IP address (and on what port, but it's usually 443), at what time, and how much. If there are multiple virtual hosts on the same machine, the attacker cannot know which one you are contacting (however, the eavesdropper may see your DNS requests just before the HTTPS request and take a plausible guess). All this information is also authenticated: an active attacker cannot play man-in-the-middle and modify the data in transit.

Things that can make SSL not work as intended:

  • Application misuse, where some data is accidentally sent over plain HTTP.
  • One of the rare vulnerabilities in the SSL protocol, such as the recent BEAST vulnerability.
  • Bad certificate manipulation, which allows the attacker to pass off as the server, either because the server's certificate has been leaked, a certification authority has improperly delivered a certificate to the attacker, or because the client does not check the server's certificate correctly.
    • On this note, remember that SSL, as it is used most of the time, authenticates the server but not the client. The server cannot assume anything about the client.
  • A side channel attack may reveal some information to the eavesdropper. For example, the exact timing at which the participants send data may reveal something about how the data is computed and thus about the nature of the data. The size of each packet is also known to the attacker. How revealing this can be depends on whether the participants take precaution and on the nature of the information. A real-time conversation is a lot more prone to such traffic analysis than the download of a file.

See also How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it? for some background.

Tags:

Rest

Tls

Recent Posts