Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

[[e-mail] (Martin Rex)]

David Benjamin wrote:
> 
> Post-handshake auth exists basically entirely to service HTTP/1.1 reactive
> client certificate which was previously hacked on via renegotiation. I
> think we should not make this feature any more complicated than absolutely
> necessary to support this mode, and we should not add more bells and
> whistles to it to encourage further use.
> 
> For the HTTP/1.1 use case, this is not necessary because it's reasonable
> for client/server to agree that the server will not send any more data for
> that request until it has processed the client's authentication messages.

Well, the funny thing here is how HTTP/1.1 POST works when the server
asks for a certificate through renegotiation.  The client-side data,
which may be a multi-megabyte upload, will be performed entirely before
the renegotiation, and any renegotiation requested by the server might
be sitting in the incoming network buffer and ignored by the
client.  Depending on how much data the server expects, and the bandwith
available to the client upstream, the server might not even want to start
the renegotiation handshake before the client has completed transmission,
because this might result in a connection termination (when the client
needs more than 2*MSL for the upload and doesn't perform any recv() / SSL_Read
on the socket while uploading.

-Martin