This concern is also why many implementations of client certificates in TLS 1.2
and earlier would perform a handshake without requesting a client certificate,
then immediately begin renegotiation to exchange the client certificate under
encryption. TLS 1.3 removes the need to do this.
-----Original Message-----
From: TLS <tls-boun...@ietf.org> On Behalf Of Viktor Dukhovni
Sent: Monday, March 27, 2023 8:08 AM
To: tls@ietf.org
Subject: Re: [TLS] potential security concern regarding the exchange of client
certificates during the TLS handshake process
On Sun, Mar 26, 2023 at 02:18:58AM +0000, Yannick LaRue wrote:
> [...] This means that information such as the client's name, email
> address, and other identifying details are transmitted in cleartext,
> potentially allowing for interception and exploitation by malicious
> actors.
This is true for TLS versions 1.0–1.2, but not TLS 1.3.
> I propose that a solution to this issue would be to separate the
> exchange of client certificates from the initial handshake process,
> and instead require the client to present their certificate only after
> the secure channel has been established. This would allow for mutual
> authentication without exposing sensitive information to potential
> interception.
In TLS 1.3, the client certificate is in the encrypted part of the handshake.
TLS 1.3 also supports post-handshake-authentication.
> I urge you to consider this proposal and take action to address this
> potential security vulnerability. Thank you for your attention to this
> matter.
It seems you've rediscovered one of the concerns addressed in TLS 1.3.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
