6

I have this silly question that is bothering me. When not using secure connection (HTTP for example) cookies can be intercepted and used to connect to the site as if we have the id and password. We can protect against this by using secure connection (https). This assures that the cookies sent to the server are encrypted.

My question is: why can't an attacker use the encrypted cookies? Could an attacker intercept these cookies and send them to the server?

nobody
  • 365
  • 1
  • 7
Hunsu
  • 175
  • 4

3 Answers3

10

Because you can't spot the cookies, and even if you could, you couldn't re-use them.

An actual HTTP request looks something like this, and the whole thing is encrypted:

GET /wiki/Main_Page HTTP/1.1
Host: en.wikipedia.org
Accept: text/html,application/xhtml+xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36 OPR/18.0.1284.49
Referer: http://en.wikipedia.org/wiki/Main_Page
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: centralnotice_bucket=0-4.2; uls-previous-languages=%5B%22en%22%5D
Connection: keep-alive

Note that the cookie is mixed in with a whole bunch of other stuff. You can't grab an encrypted cookie because you can't find it (it's surrounded by stuff that varies from browser to browser and even request to request). Even if you could find it, SSL includes measures to prevent an attacker from re-sending a request (a replay attack), and it includes a message authentication code (MAC) to prevent an attacker from slicing up a request and only using part of it.

Further, SSL uses a different encryption key for each connection. Even if you could grab the encrypted cookies and bypass the MAC, you'd find they were encrypted with the wrong key for you to use them.

Mark
  • 34,513
  • 9
  • 86
  • 135
  • 1
    and SSL doesn't use ECB block mode so even if you could find the cookie, it depends on the previous data what is actually sent, – ratchet freak May 19 '14 at 12:27
9

The reason why an attacker can't use the encrypted cookies is that HTTPS encrypts the entire HTTP conversation between client and server, not just the cookies. (Unless the attacker has managed to subvert the key exchange parts of the protocol, but that's a story for another question.)

For a fun exercise, use both Wireshark and your browser's debugger to watch the network traffic when you visit your favorite HTTPS site.

PlasmaSauna
  • 594
  • 3
  • 6
  • After I wrote my question this idea come to my mind thanks! – Hunsu May 19 '14 at 07:14
  • I was reading about TLS the other day and found myself wondering the same thing. TLS handshakes occur in the clear, but what I don't understand is how a MitM can't listen and then impersonate the client. – Scuba Steve Feb 01 '19 at 23:02
  • 1
    @ScubaSteve, the short of it is that the HTTP traffic is encrypted with a symmetric key; the client encrypts the symmetric key with the server's public key to keep the symmetric key from eavesdroppers. Without the symmetric key, a MitM can't produce messages that the server can decrypt or verify via MAC. Check out https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work at "You said the client sends a key, which is then used to setup symmetric encryption. What prevents an attacker from using it?" for more. – PlasmaSauna Feb 10 '19 at 05:32
0

If someone could manage to get the cookie, by, say, managing to get the data straight from your browser or HR (perhaps by sitting down at your computer when you stand up and walk away), then they could certainly reuse your cookie and it would work.

An attacker can't see the cookies because https encrypts the entire http packet, and the cookie is sent as part of the packet.

Incidentally, another method attackers can use is to try and trick your browser into sending the cookie to the server over http. (Google sslstrip if you're interested in more details on the attack). To prevent this servers can mark a cookie with the "secure" flag which tells the browser to only transmit the cookie over a secure SSL connection.

PopularIsn'tRight
  • 101
  • 2