On Tue, Nov 7, 2023 at 3:43 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Mon, Oct 23, 2023 at 01:37:55PM -0400, Viktor Dukhovni wrote: > > > > - Some Java TLS libraries (used to?) fail the handshake when the > > client has no configured certs, or the list of issuer CA DN hints > > does include any of its available (typically just zero or one) > > certificates. > > > > They could just proceed without a certificate, or return a default > > one, but they don't. > > A colleague discovered a case where sending CertificateRequest to Chrome > causes it to fail, instead of just proceeding without a certificate > (which would have worked). > I don't know the details of that case, but this would not surprise me. If we are in a context where we are unable to prompt the user (e.g. in a background context where we cannot show UI), that is the only viable option. TLS client certificate decisions in a browser, and generally in an HTTPS stack, have to be remembered context-wide. Otherwise we cannot do socket reuse or session resumption, and have to prompt the user on every HTTP request. But even continuing without a certificate is a decision. That means, if we automatically proceed without a certificate in unpromptable contexts, we poison the context and prevent the user from making an actual decision later. Moreover, this can even apply when there are zero matching certificates. On some platforms (e.g. Android), where the platform's security model (quite reasonably) prevents applications from directly enumerating the client certificate store, querying and prompting is a single combined operation. But this means we cannot even check for zero or non-zero certificates without triggering a prompt in the non-zero case, which again means we cannot trigger this code from background contexts. Moreover, on such platforms, the application is entirely at the mercy of the platform as to what kind of filtering or prompt suppressions are applied. On older Androids, this single combined operation does not automatically suppress empty prompts, and does not filter based on the CA list. Newer ones are capable, but it further makes optional CertificateRequests incoherent. Ultimately, TLS client certificates, and how they're used in practice, are just not suitable for user-facing HTTPS applications. But there is such a long history of existing usage, that the ship has not only sailed but also circumnavigated the globe a couple times. It's too late to simply say "oh this was a mistake, let's not do that anymore". :-( David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
