I'm learning session management and I have two questions for which I could not find answers on the web.

Once the user is authenticated, the server creates the Session ID and sends it to the client (user) in the form of a cookie. This cookie is then subsequently used in requests the client sends to the server to identify himself among other users.

Now in a HTTPS session, the requests sent between the client and server are secured, as requests from the client are encrypted using the public key of the server, and it can only be decrypted using the private key which the server only has.

But initially when the server sends the cookie information to the client, it could be intercepted by anyone as even if this cookie which contains the session ID is encrypted using the private key. It could be decrypted by anyone having the public key. So, my question is:

  1. How does the server make sure that the session ID created by the server is securely sent to the client.

  2. I learnt that the client sends the cookie for each request it makes to the server. In a GET request, how does the client send the cookie information, as GET does not include the body?

2 Answers 2


The connection between the client and the server does not use public key encryption (that is only used for the initial key exchange). A different algorithm is used for encryption (usually a symmetric encryption), such as AES-256-CBC on a TLS 1.2 connection. So unless you intercepted it, no one but the intended browser and the original server can decrypt the message. So interception is not as easy as having the public key information from the server.

The cookie is not sent as a GET request. It is added to the headers as Cookie:[Token]; [Other cookies];. The underlying request type is irrelevant for this. (The default request type is GET, however.)

I would suggest that you look at the network traffic from your browser to a website to which you are logged in, and see what is being used where. (This is easy to do in Chrome.)


Answer 1: if the server uses SSL/HTTPS(verified by third party-not self-signed certificate), cookies and session IDs travel as cipher-text over the network, and if an attacker (Man in the Middle) uses a packet sniffer, they can not obtain any information. They can not decrypt data because the connection between client and server is secured by a verified third party.so HTTPS without verified certificate means server and user can not make sure that session ID is not sniffed.

it means that every data (i.e cookies) must be send and receive after establishing a secured HTTPS between user and server and can make sure that the session ID is securely sent to the user.

also asymmetric cipher just use for exchanging key of symmetric cipher(that is used for ciphering data between client and server).

enter image description here

for better image right click: open image in new window

Answer 2: Cookies are handled entirely by the request header in HTTP header fields, cookies in the client side are encoded in the 'Cookie' and 'Set-Cookie' response header and in the server side are encoded in the 'Cookie' request header - $Path variable.

Client request example:

GET /index.html HTTP/1.1
Host: www.example.com

Example answer from the server:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: foo=10
Set-Cookie: bar=20; Expires=Fri, 30 Sep 2011 11:48:00 GMT
... rest  of the response

Here, two cookies (foo=10 and bar=20) are stored on the browser. The second one will expire on 30 September. In each subsequent request the browser will send the cookies back to the server:

GET /spec.html HTTP/1.1
Host: www.example.com
Cookie: foo=10; bar=20
Accept: */*
  • 2
    They can not get the public key This is false. The public key is public. Anyone can get it. That's why it's called public.
    – Brandon
    Commented May 1, 2015 at 22:03
  • 2
    Public key encryption is typically used for authentication and negotiation of a symmetric key, and in SSL/TLS in particular is not used to encrypt any actual application data. It is just too slow and cumbersome. Lawri's answer should be the accepted answer.
    – Arc
    Commented May 1, 2015 at 23:02
  • 2
    "Foundation URL Loading"? Commented May 1, 2015 at 23:42
  • @Archimedix his answer is also true, I just talk about security of the line, by using third party, and asymetric encryption the secure connection stablish, symetric key exchange,and then they can talk in secure line, and MITM can not obtain any information
    – Ali
    Commented May 2, 2015 at 3:00
  • @Ali: Though the phrase about the public key had been removed from the answer, it still gives a wrong understanding of how SSL/TLS works. The link is not "verified third-party-secured". The third party, i.e. the certificate issuer only verifies the server's identity. Encryption is negotiated between client & server. "if the connection between server and client is based on OPENSSL, the story changes" is unexplained & suggests OpenSSL makes everything insecure. "Foundation URL loading system" isn't the term: Cookies are an HTTP extension.
    – Arc
    Commented May 2, 2015 at 5:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .