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?

Answer 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.