How is the session ID sent securely?

Question

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?

Answer 1

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 2

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

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: */*