TLS 1.3 interoperability failure with servers that request (optional) client certs.

[vdukhovni]

If I enable TLS13, the handshake with the remote server fails with an "Internal Error" alert from the hs-tls client. OpenSSL's TLS 1.3 interoperates with the server. When I enable SSL state logging in OpenSSL I see:

posttls-finger: SSL_connect:before SSL initialization
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS read server hello
posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS read server hello
posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions
posttls-finger: SSL_connect:SSLv3/TLS read server certificate request
posttls-finger: SSL_connect:SSLv3/TLS read server certificate
posttls-finger: SSL_connect:TLSv1.3 read server certificate verify
posttls-finger: SSL_connect:SSLv3/TLS read finished
posttls-finger: SSL_connect:SSLv3/TLS write client certificate
posttls-finger: SSL_connect:SSLv3/TLS write finished
posttls-finger: Verified TLS connection established to <name[ip]:port>: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
posttls-finger: SSL_connect:SSL negotiation finished successfully
posttls-finger: SSL_connect:SSL negotiation finished successfully
posttls-finger: SSL_connect:SSLv3/TLS read server session ticket
posttls-finger: SSL_connect:SSL negotiation finished successfully
posttls-finger: SSL_connect:SSL negotiation finished successfully
posttls-finger: SSL_connect:SSLv3/TLS read server session ticket

The server solicits (but does not require) a client certificate, and "posttls-finger" sends an empty client certificate message (no client-side certificate is configured).

To make sure I'm on the right track, I've configured my own SMTP server to request certificates on port 587, but not port 25. With that done, the handshake from a client using hs-tls with TLS 1.3 enabled fails to port 587, but succeeds to port 25. Both succeed if I disable TLS 1.3.

So it looks like client certificate requests are not handled correctly with TLS 1.3, but work with earlier TLS versions.

[ocheron]

At this point client authentication is not implemented at all for TLS13.

[vdukhovni]

@ocheron At this point client authentication is not implemented at all for TLS13.

You may have missed my point. I don't expect to use client authentication. The server asks for optional client certificates, and my client has none so (TLS ≤ 1.2) it successfully continues without them by sending an empty client certificate list. This must continue to work with TLS 1.3. Many (SMTP at least) servers solicit client certificates, but don't require them, clients that have them may get relay access, or be exempt from some anti-spam filters, but authenticated clients are still accepted.

Enabling TLS 1.3 breaks unauthenticated connections to servers that solicit (optional) client certificates.

[ocheron]

Enabling TLS13 is not supported, the implementation is not finished.

[vdukhovni]

Yes, I understand that it is not finished, I am just testing it lightly, and highlighting places where it does not quite work right yet. I hope that's useful. If not, I can postpone all testing till later...

[kazu-yamamoto]

Three major issues for TLS 1.3 remain as described in #282.

• Key update is PRed.
• Downgrade protection is implemented and waiting for the PR above.
• I'm working on client authentication now.

[vdukhovni]

I also started work on client auth, how far along are you? Perhaps I should stop...

[vdukhovni]

I have it working for the case with no client certificate (server asks, client declines).

I have almost all the code for the case that the client has a certificate, but it does not handle the server's signatureAlgorithms extension correctly yet (just ignores it, and hardcodes a choice), and is not yet tested. It does however compile (type checks) and is quite close to complete.

[vdukhovni]

I am polishing up the code now, and adding more detailed comments.

[ocheron]

@vdukhovni Your help is welcome to review the implementation. I have same concern about preserving working functionality that's why I try to see how to expand test coverage.

Currently we have some corner cases due to delayed handshake termination as well as the ticket mechanism. I opened #296 to get better understanding and #297 to give an example of what is wrong.

[kazu-yamamoto]

@vdukhovni No problem. Please send us a PR for client authentication.

[vdukhovni]

Kazu, are you reachable by Skype or Google Hangouts? Please drop me an email with contact info if you are...

[kazu-yamamoto]

I sent you my gmail address.

[vdukhovni]

Opened #298 closing this issue.