6

Is there a way for a TLS client to inform the server that it doesn't intend to resume its authenticated session(s) anymore?

Example:

A client established authenticated session with the server providing its certificate with clientAuth key usage, then performed all the application-level work, and now wishes to tell the server something like:

No need to keep my authenticated session any longer; next time you'll see this sessionID on a client hello - don't resume the session, because I have finished my work here

Is there a way to say that? As far as I see, close_notify alert doesn't mean this, it just informs that connection is going to be closed or unprotected data will be transfered through it.

2
  • I feel there is an interesting question here but I have to ask: what do you expect happen after such command is given ?
    – Stephane
    Sep 2, 2015 at 12:53
  • I expect that a hacker, who is analyzing the traffic to bruteforce masterkey can't use his result even if he would manage to get any success with it. Sep 2, 2015 at 13:17

1 Answer 1

3

Is there a way for a TLS client to inform the server that it doesn't intend to resume its authenticated session(s) anymore?

Yes, by sending an Alert with a Fatal severity.

From RFC 5077:

5.1. Invalidating Sessions

The TLS specification requires that TLS sessions be invalidated when errors occur.

This is an apparent reference* to the following text from RFC 5246 (emphasis mine):

7.2. Alert Protocol

One of the content types supported by the TLS record layer is the alert type. Alert messages convey the severity of the message (warning or fatal) and a description of the alert. Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections.

Practically speaking, choosing to terminate the SSL session with a fatal alert instead of with a warning close_notify alert probably won't cause anything worse than a log entry on the server. Because you're not closing until after your data exchange has concluded, it's unlikely the fatal alert will affect that. It's the moral equivalent of terminating a TCP connection with a RST instead of a FIN.

(I think you can actually just send a close_notify alert with Fatal severity instead of Warning severity, but I'd want to test that on the wire first).

Of course, if you have enough control over your client to impact how it closes the session, you have enough control to not send prior Session IDs on subsequent connections, which will achieve the same goal. The server will never try to resume a session unless the client has first proposed that Session ID. But if instead you're worried about third parties somehow gaining and re-using your Session ID, then triggering the server to purge it might be reasonable.


* When I say 5077 (January 2008) references 5246 (August 2008), it really was referencing an earlier version of the TLS spec; I'm just dragging out the most recent spec for you to look at. In fact the language for "7.2 Alert Protocol" is equivalent for TLS 1.1 (RFC 4346) and TLS 1.0 (RFC 2246).

11
  • Thanks! Have just found this looking through openssl sources. Sep 2, 2015 at 13:10
  • >> But if instead you're worried about third parties somehow gaining and re-using your Session ID, then triggering the server to purge it might be reasonable. yes, this is the case Sep 2, 2015 at 13:11
  • Any suggestions for HTTPS here? If we don't use KeepAlive connection, we need to re-establish TLS connection with this sessionID just for sending fatal alert. Am I right? Sep 2, 2015 at 13:13
  • @Trueblacker yes, you could open a new connection for the sole purpose of resuming and then wiping (via Fatal Alert) the session ID from the server, as opposed to modifying your main connection. But you'll need more than just the session ID, you also need to know the session parameters, so it's not like you can just open a new session with a different client.
    – gowenfawr
    Sep 2, 2015 at 13:46
  • 1
    @Trueblacker I haven't checked but I'm willing to bet that a) a server will only re-use a session ID with the same IP it previously sessed with and/or b) a server will only delete the session ID upon an encrypted fatal alert, which implies that the attacker needs not just the session ID but the crypto parameters as well. Either of those will prevent a malicious third party from forcing full re-handshake.
    – gowenfawr
    Sep 2, 2015 at 17:39

You must log in to answer this question.

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