client authentication status

[Matt Caswell]

On 01/09/2021 16:36, Zeke Evans wrote:
> Is there any way to check the status of client authentication sent in a 
> TLS 1.3 handshake after SSL_connect returns?  With TLS 1.2 SSL_connect 
> seems to always capture the status and return an error code if it failed 
> but not TLS 1.3.  I haven’t been able to find a good way to do this 
> after SSL_connect returns.  I have to handle blocking and non-blocking 
> sockets so calling SSL_read or SSL_peek isn’t an option since those 
> could block.  If client authentication happened to fail then calling 
> those methods would work because they will return an error but if it 
> didn’t fail then they could block.

At a protocol level the handshake looks like this:

        Client                                           Server

Key  ^ ClientHello
Exch | + key_share*
      | + signature_algorithms*
      | + psk_key_exchange_modes*
      v + pre_shared_key*       -------->
                                                   ServerHello  ^ Key
                                                  + key_share*  | Exch
                                             + pre_shared_key*  v
                                         {EncryptedExtensions}  ^  Server
                                         {CertificateRequest*}  v  Params
                                                {Certificate*}  ^
                                          {CertificateVerify*}  | Auth
                                                    {Finished}  v
                                <--------  [Application Data*]
      ^ {Certificate*}
Auth | {CertificateVerify*}
      v {Finished}              -------->
        [Application Data]      <------->  [Application Data]


The handshake has completed from the perspective of one of the endpoints 
once it has both sent and received a "Finished" message.

 From the above you can see that the client receives the server's 
"Finished" message before it sends its "Certificate"/"CertificateVerify" 
and "Finished" messages back to the server. At this point "SSL_connect" 
returns and the client is ready to start receiving application data.

 From the server's perspective it is still handshaking when it receives 
the client's certificate (because it didn't receive the client's 
"Finished" message yet). So the server when send an alert at this point 
if the certificate is not acceptable and SSL_accept() will return with a 
failure.

The client does not know what it will receive back from the server. It 
could either be application data (in the case of an accepted 
certificate) or an alert (in the case of a reject certificate). The only 
way it can find out is to attempt to read data from the connection and 
see what it gets back. The API to do this is SSL_read()/SSL_peek().

So, to answer your question, there is no way to check the status of 
client authentication without calling SSL_read()/SSL_peek(). It 
necessarily requires an attempt to read data from the socket in order to 
find that status out due to the way the protocol is designed.


On 01/09/2021 16:51, Benjamin Kaduk via openssl-users wrote:
 > Note that the server is allowed to ignore a client cert that it 
doesn't like, proceeding with the connection as if the client was 
unauthenticated.  If you need a specific signal that the server believes 
the client successfully authenticated, that has to be at the application 
layer.

This is true, but ultimately the client still needs to attempt to read 
data from the socket to figure out what the server did.

 > Did you try a zero-length SSL_read()?  My recollection is that that 
gets far enough into the library to see if there are pending alert 
messages to process.

Again, there will only be alerts to process (related to a client 
certificate failure) if the client has attempted to read application data.

Matt