Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session

>> The server doesn't recognize that session and replies 
>> with
>> a Server Hello containing his highest protocol version, 
>> plus
>> plus server certificate message plus client cert request 
>> plus
>> server hello done.  The popular Web Browser closes the 
>> network
>> connection without sending any kind of SSL alert and 
>> shows
>> "Page cannot be displayed" to the user.
>>
>>
>> I firmly believe that this is a conceptual flaw on the 
>> client
>> side, making a flawed assumption about when a cached SSL 
>> session
>> can be expected to be resumable.
>
> ISTM that there are two issues here:
>
> 1. Whether the client should have offered asession ID.
> 2. Whether it should have choked when the server refused.
>
> Without taking a position on the first, which I think is 
> tricky,
> the client should definitely not have choked. Servers can 
> always
> refuse to accept a resumption.
>
> -Ekr

I reasoned differently, because this is an https context - 
there is thus a URL resolver involved. The validity of a 
secure URL is not the same as the validity of an SSL-named 
layer 4 TCP port (or SSL-named PPP tunnel connection,....)

At the SSL layer, the client sought a session resumption 
from a named layer 4 port. Session resumption means that the 
URL resolver at the https layer, however, is based on the 
client's connection state , not the host/port parsing. This 
includes the binding of URLs used in session creation, and 
the URL used in connection establishment (which are allowed 
to differ)

IN the cited case, a server responding from a given layer 4 
port of the second URL refused to resume a session (for some 
reason, like it didn't share session state records with 
another implementation). It then correctly engaged in a full 
handshake (with unusual custom pipelining of full handshake 
messages).

The client is entitled to reject the handshake, as in any 
full/partial rehandshake case. The client uses the 
conforming option to close the TLS Transport (TCP) rather 
than perform a close. This is reasonable, given the URL 
resource showed no knowledge of the sessionid/keying 
material.

---

I exploit the SSL architecture myself, sending server 
HelloRequests to my clients which respond with a clientHello 
(with special data in the time/nonce), a server Hello is 
similarly sent with similar custom time/nonce, which causes 
the client to finally issue a "sorry no"... alert, 
non-fatal. My special data happens to be time-synced OTPs 
(with CR capability, beyond STD 61), generated by a USB 
smartcard device. Given the flow is occurring over the 
current connection state (which is running mac'ed in my 
cipher suite, and each fragment gets DOA semantics from the 
confidentiality service) I'm adding timing signals to the 
SSL record_layer essentially.

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls