Client doesn't get certificate rejection promptly

[dpwiz]

We use client certificates and clients don't know about rejections until they try to read data.
Server threads do crash on handshake, but clients apparently go right through it.
Clients can even "send" data without knowing the session didn't even start.

We had to add a "lookahead" read to get the error before it corrupts downstream state.

cc @epoberezkin

[kazu-yamamoto]

Theoretically speaking:

• For TLS 1.2, handshake can receive an alert in the second server flight.
• For TLS 1.3, handshake cannot, recvData can receive an alert.

This is because that tls is based on a single thread model.
No sender nor receiver threads.
The main thread dominates send/receive.
Packets cannot be received while sending.

I will prepare error cases for client certificate to see if the theory works well.

[kazu-yamamoto]

Thinking the handshake diagram deeply, handshake for TLS 1.3 cannot receive alert by the protocol design.
One work around is to prepare a function which receives control messages including new session tickets and alerts with timeout.
If this function receives app data, it is saved in Context.
receiveData prefers this saved app data to coming app data from the network.

[kazu-yamamoto]

We can forget post-handshake authentication due to https://datatracker.ietf.org/doc/html/rfc8740.
This is nice.

[kazu-yamamoto]

One idea: if the client authentication is required by a server, the client sends key update request after Finished and waits for key update. This can receive an alert from the server.

[kazu-yamamoto]

@dpwiz What do you think?

[kazu-yamamoto]

TLS 1.2:

      Client                                               Server

handshake
  ^   ClientHello                  -------->
  |                                                  ServerHello
  |                                                  Certificate*
  |                                            ServerKeyExchange*
  |                                           CertificateRequest*
  |                               <--------      ServerHelloDone
  |  Certificate*
  |   ClientKeyExchange
  |   CertificateVerify*
  |   [ChangeCipherSpec]
  |   Finished                     -------->
  |                                            [ChangeCipherSpec] or Alert
  V                                <--------             Finished
      Application Data             <------->     Application Data

TLS 1.3 (not resuming):

       Client                                           Server

 handshake
     ^ ClientHello
     | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     | + pre_shared_key*       -------->
     |                                            ServerHello
     |                                            + key_share*
     |                                       + pre_shared_key*
     |                                  {EncryptedExtensions}
     |                                  {CertificateRequest*}
     |                                         {Certificate*}
     |                                   {CertificateVerify*}
     |                                             {Finished}
     |                         <--------  [Application Data*]
     | {Certificate*}
     | {CertificateVerify*}
     | {Finished}              -------->
     | [KeyUpdateReq]          -------->
     v                         <--------          [KeyUpdate] or Alert
       [Application Data]      <------->   [Application Data]

[kazu-yamamoto]

Or client handshake just waits for NewSessionTicket with timeout of an estimated RTT?

[kazu-yamamoto]

OK. Test cases for client authentication failure are now ready.
I will try to implement the last approach.

[kazu-yamamoto]

The last approach works well.
Let's close this.