What is the difference between GET and POST encryption?

Question

What is the difference when encrypting GET and POST data?

To be more specific: when https-SSL encrypts both of this methods, what is the difference in the way the browser does this; Which parts are encrypted and which are not?

I read somewhere that the destination url is not encrypted in POST, is that true? If it is true and same in GET, where are all the parameters?

When both methods are encrypted with same data, do they look the same when sniffed? What parts are encrypted and which are not?

Solution 1

GET data is appended to the URL as a query string:

https://example.com/index.html?user=admin&password=whoops

Because the data is appended to the URL, there is a hard limit to the amount of data you can transfer. Different browsers have different limits, but you'll start to have problems around the 1KB-2KB mark.

POST data is included in the body of the HTTP request and isn't visible in the URL. As such, there's no limit to the amount of data you can transfer over POST.

If the HTTP connection is using SSL/TLS, then GET parameters are also encrypted but can show up in other places such as the web server logs and will be accessible to browser plugins and possibly other applications as well. POST data is encrypted and does not leak in any other way.

From a Google Discussion:

The data contained in the URL query on an HTTPS connection is encrypted. However it is very poor practice to include such sensitive data as a password in the a 'GET' request. While it cannot be intercepted, the data would be logged in plaintext serverlogs on the receiving HTTPS server, and quite possibly also in browser history. It is probably also available to browser plugins and possibly even other applications on the client computer.

Always use POST over HTTPS if you want to securely transfer information.

If you're using an encryption library to encrypt the data then you can use GET or POST, but this will be an added pain and you might not setup the encryption correctly, so I'd still recommend using POST over HTTPS, rather than rolling your own encryption setup. This problem has been solved already, don't re-invent the wheel.

Another option you might want to consider is using a secure cookie. A cookie that has the secure flag set is only sent over a secure channel, such as HTTPS, and isn't sniffable. This is a good way to persist information securely, such as a session ID.

Solution 2

The difference is that an encrypted parameter that is sent with GET verb will be visible in the address bar while the one sent with the POST verb will not (of course this doesn't mean that the user cannot see the encrypted value). Another difference is in the allowed maximum length: GET requests are limited as urls are limited in browsers. Third difference: GET requests are logged in intermediary web servers they transit (web, proxy, ...) so if you use GET over the internet your encrypted parameter will definitely be logged on many machines before it arrives to your web server.

Solution 3

When an HTTPS GET request is made, the query string parameters ARE ENCRYPTED! The only thing that is not encrypted in an HTTPS request is the server name or IP address and port of the request. Those are the only two pieces of information necessary to route the request from your browser to the web server, which then performs the decryption.

Use Fiddler (with the SSL decryption turned off) and look at your traffic with a secure site. You'll see that you cannot view unencrypted query string data or even path information.