The TLS protocol can perform the handshake in different modes. Either fresh handshake where new keys are generated, or using Pre Shared Keys (PSK) or what was know as Session Resumption in previous versions.

My question is: In practice, when do clients such as web browsers for example use TLS in PSK mode? Does the existence of a website in the browser History entails the use of PSK mode? Can you list the cases where clients will use PSK instead of exchanging fresh keys?


1 Answer 1


Pre-shared keys aren't used on the web. Using asymmetric cryptography and a public-key infrastructure has huge advantages: there's no need to exchange long-term secrets at any point, all the security relies on a few public values (the root CA public keys). Commonly-used web browsers do not support PSK ciphersuites.

Pre-shared keys are meant for embedded clients that have very limited computing power, that only talk to a very small number of servers. Symmetric cryptography is significantly cheaper than asymmetric cryptography, so it's the only way to have secure communication with devices that simply can't perform a signature or signature verification in a reasonable time, or where it would consume a too big fraction of the battery reserved, or where there isn't enough room for the extra code. If a device only communicates to a very small number of peers over its lifetime, it only needs to store those peers' keys, so PKI wouldn't be an advantage on that side. What is saved on the client side has a cost on the server side: the server needs to store all the clients' secret keys and not just one private key.

Pre-shared keys may also be used if some key exchange or key distribution takes place using a protocol other than TLS, and then the exchanged symmetric key is used for TLS. I don't think this is very common though.

Browsers do use session resumption as a performance optimization. Session resumption is effectively equivalent to having a pre-shared key, but this key was shared through a previous TLS session. On the web, the original session always used asymmetric cryptography. Session resumption means that one or both sides of the communication store some confidential data from which the next session's key can be derived. Generally the burden is on the client: the server sends the client a ticket, which is some encrypted and signed data, and the client stores both this ticket and the shared secret for the next session (premaster secret in TLS terminology). To resume a session, the client sends the ticket back to the server, and the server verifies the signature and decrypts the ticket to obtain a copy of the premaster secret.

Saving a session in this way keeps the advantages of the public-key infrastructure. As in any communication system based on hybrid cryptography, the payload is protected using symmetric keys which are ultimately obtained using key establishment methods based on asymmetric cryptography. The client does have the burden of storing the secret key securely between sessions, but this burden is made easier because the client can fail safe and erase the session data whenever it wants: erasing session data is only a small loss of performance, unlike the PSK-only scenario where it means losing the ability to communicate.

Session resumption was added to TLS 1.0 as an afterthought. In TLS 1.3, the key exchange protocol has been revamped, and session resumption is now merged with pre-shared keys. The same principles apply: a web browser would only ever use PSK as a way to resume a session that was started with asymmetric cryptography, whereas tiny embedded systems may support nothing but PSK.

  • $\begingroup$ Thanks. Bu a web browser would only ever use PSK as a way to resume a session that was started with asymmetric cryptography. When does browsers use this? by default when websites in the browsers History? When do browsers decide not to use this method and starts a fresh key? $\endgroup$ Apr 5, 2019 at 21:23
  • $\begingroup$ @user9371654 Browsers do this if they support the feature and the server also does (both sides send this information as part of the handshake). I think major browsers only store the session ticket in RAM, so they would use a fresh key when you restart the browser, or of course if the server signals that it doesn't like the ticket anymore. $\endgroup$ Apr 5, 2019 at 21:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.