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.

Trueblacker
  • 393
  • 2
  • 6
  • 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 02 '15 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. – Trueblacker Sep 02 '15 at 13:17

1 Answers1

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

Community
  • 1
gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • Thanks! Have just found this looking through openssl sources. – Trueblacker Sep 02 '15 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 – Trueblacker Sep 02 '15 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? – Trueblacker Sep 02 '15 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 02 '15 at 13:46
  • Surely, I know that I need more than just session ID value to resume session. Anyway, thanks, you were really helpfull. – Trueblacker Sep 02 '15 at 13:50
  • on second thought this is not that simple. What prevents a client to send fatal alert just upon receiving server hello with the same session id as it was in client hello? As far as I can see, such this must force the server to purge the session information. If so, isn't there a vulnerability which allows a malicious third party instantly purge any clientAuth sessions to make the client full re-handshake on any reconnect? – Trueblacker Sep 02 '15 at 17:36
  • 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 02 '15 at 17:39
  • some APIs don't allow to bind the session to the IP address (e.g. MS SSPI). The consideration about encrypted alert sounds reasonable, thanks. Need to check what RFC says about that – Trueblacker Sep 02 '15 at 17:43
  • @Trueblacker RFC 5246 states "Like other messages, alert messages are encrypted and compressed, as specified by the current connection state." That implies that an unencrypted alert is not appropriate when encryption is in place, and the only way an alert could reset the session ID validity is if that session ID is in active use, e.g., encryption is in place. THAT SAID, this is the sort of area where testing of real-world implementations usually finds misbehavior. – gowenfawr Sep 02 '15 at 18:15
  • I think this implies null cipher as a valid connection state. But I am not sure – Trueblacker Sep 02 '15 at 18:34
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/27694/discussion-between-gowenfawr-and-trueblacker). – gowenfawr Sep 02 '15 at 19:29