Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm pretty new to security, so forgive my basic question, but does SSL encrypt POST requests but not GET requests?

For instance, if I have two requests

GET: www.mycoolsite.com/index?id=1&type=xyz

POST

site: www.mycoolsite.com/index { Params: id=1&type=xyz }

Is it safe to assume that someone is able to intercept the whole GET request (reading id and type), but if they intercept the POST they will be able to see the site path, but because it is going over SSL, they cannot see the params of id and type?

share|improve this question
2  
No, the full HTTP communication is encapsulated in SSL/TLS, if the protocol is HTTPS for both examples! Be aware that referenced resources (images, etc.) may be delivered insecure, depending on their uri. –  ordag Mar 8 '12 at 19:32
1  
Just wanted to point out that if you're using GETs to pass credentials (regardless if you're using SSL) that the passwords will be stored in plain text in the Web server logs. –  k1DBLITZ Jul 11 '13 at 13:55

6 Answers 6

up vote 24 down vote accepted

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&param=2hello

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

share|improve this answer
1  
All of the answers here were very good. In fact, it was hard to pic the "best" answer as each was complimentary of the other. The reason I choose this one is because it showed what a get and post looks like. However, I really like that Gilles went into other things to watch out for, and the same goes for Dr Jimbob's answer. In fact, Ordag's comment was something I didn't even consider before, so I'm thankful for that as well. If I could, i would aggregate all the answers and mark all of them as the accepted answer as each builds upon the last. –  TomJ Mar 9 '12 at 16:36
1  
To add a detail, the browser makes the destination host visible through the Server Name Indication (SNI) extension of TLS. –  Matthias Vallentin Mar 29 '12 at 16:54

Another point not mentioned is that if you use GET and have any embedded or linked third party content (site ads for example) then that third party site will get the full URL (with sensitive parameter data) in the Referer header.

That exposes the data to third parties who shouldn't have it.

share|improve this answer

Source: Answer on Stack Overflow

The GET method is meant for data retrieval only and should not have any side-effects. But POST is meant for that specific purpose: altering data on the server side.

GET requests can easily be foreged (see Cross-Site Request Forgery) by just placing an image on a page while forging POST requests is not that easy (this is also a reason why you should only allow authorized POST requests).

share|improve this answer

Just to add one more small detail, as to how this is accomplished over HTTP.
You're probably wondering (or you should be, if you know are familiar with the SSL handshake), how the SSL channel is created, without the GET request being sent unencrypted? What about if my request has to go through a proxy - how is that possible?

HTTP v1.1 introduced a CONNECT HTTP Method, which basically sends a simplified request to the server through a proxy, containing only the simplest host URL (without any additional parameters, headers, or body). Based on this request, a SSL tunnel is constructed, and then the original GET (or POST) request is sent over it.

share|improve this answer

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.

share|improve this answer
    
An excellent observation. +1 :) –  user2213 Mar 8 '12 at 20:23

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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