HTTPS and encrypted cookie for session

Question

Currently I am developing an SSO system with CAS. CAS uses an ticket granting ticket (TGT) that can be seen as the SSO-session. CAS by default will encrypt the TGT. And by default you also have HTTPS among the nodes.

Since HTTPS already deals with encryption I don't get why I need to encrypt the value of the cookie (TGT). Yes, you can still read the value from the cookie and use it I guess. But when you already hijack the session, you can also do it with the encrypted TGT since the client just send an encrypted TGT to the server and doesn't decrypt it before.

So my question is: What are the reasons for an encrypted cookie value if you already have HTTPS among all nodes? Can you mention possible attack scenarios?

Answer 1

Its correct that usually in accessing ssl encrypted website you don't need encrypt cookies normally , But its about even if someone somehow hijacked your ssl connection , the TGT should be unusable to that person.

As in the SSO scenarios things changes a lot .

Authentication Process / Request Flow

During Authentication process after your identity is verifies at KDC ( key distribution center ), Authentication Server sends two messages you.

One message is the TGT that contains:
    your name/ID,
    the TGS name/ID,
    timestamp,
    your network address 
    lifetime of the TGT 
    TGS Session Key,
    and is encrypted with the TGS Secret Key . 

The other message contains:
    the TGS name/ID,
    timestamp,
    lifetime (same as above), and
    TGS Session Key
    and is encrypted with your Client Secret Key.

TGS Session Key is the shared key that will be used between you and the TGS. in next step

Your Client Secret Key is determined by prompting you for your password, appending a salt and hashing the whole thing. you can use it for decrypting the second message in order to obtain the TGS Session Key.
You can not, however, decrypt the TGT since you do not know the TGS Secret Key. The encrypted TGT is stored within your credential cache.

Now you have the TGS session key, you can request the final token to access the required service from TGS

The TGT ( encrypted with TGS secret key ) and for Example HTTP service request ( encrypted with TGS session key ) is send to the TGS

TGS now decrypts the TGT and fetches TGS session key , with this key it decrypts http authenctication request

The Ticket Granting Server then randomly generates the HTTP Service Session Key, and prepares the HTTP Service ticket for you that contains:

your name/ID,
HTTP Service name/ID,
your network address 
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
and encrypts it with the HTTP Service Secret Key.

Then the TGS sends you two messages. One is the encrypted HTTP Service Ticket; the other contains:

HTTP Service name/ID,
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
that is encrypted with the TGS Session Key.

upto receiving the message client decrypts the second message and get http session key

Now User have access To HTTP service

What if TGT was not encrypted

If TGT was not encrypted anyone having that can alter the HTTP service request to either by forging anyone's identity in the request and get HTTP service session key

Even a user can exploit the authentication process anyhow jst by altering the TGT

so to avoid misuse of TGT encryption is done

Answer 2

Cookies stay in the browser. And if they have some sensitive information stored, they should be encrypted. Though I will argue that any sensitive information should not be stored in the cookies.
And encrypting session ID(which is already a random value) doesn't make sense at all. And if you are using some user information as session ID, then this practice is itself bad and instead of encrypting, you should think of redefining how a session is managed. Check OWASP for this.

Answer 3

If your cookie is just a session ID that allows the server to identify you then encryption is, as you correctly comment, pointless in addition to TLS encryption. However, there might be applications which really need to store information in a cookie that they want to keep confidential, even confidential from users inspecting their own cookies with dev tools in the browser. An example might be a session info for a distributed environment where the servers don't share a single database and the cookie contains e.g. a confidential identifier of the issuing server you don't want the user to see because she could want to fake that (of course this is pure speculation).

I would always try to avoid such a design and go for some open standard like SAML but I'm pretty sure there are applications that do it like this.