[gnutls-devel] Mandatory to honor DN in server certificate requests?

[Nikos Mavrogiannopoulos]

On Wed, Apr 27, 2016 at 10:41 AM, Martin Storsjö <martin at martin.st> wrote:
> Hi,
> I'm looking into an issue in using gnutls to do a DTLS handshake with
> browsers (for use with WebRTC).
> If the server side of the handshake is firefox, with manually installed
> custom CAs in the browser (unrelated to the WebRTC setup at hand), the
> Certificate Request record from the server contains a nonzero list of CAs,
> listing the manually installed custom CAs.
> The client side of the handshake only has got a self-signed certificate
> (completely unrelated to whatever extra CAs might be installed in the
> browser). Now since the client certificates don't match the DNs listed in
> the certificate request, gnutls doesn't pick any certificate to send at all,
> and sends an empty certificate record back.
> (For comparison, if the client side is handled by openssl, it ignores the
> DNs here and just sends whatever client certificate that has been provided,
> regardless if this matches the certificate request.)
> I guess this is a pretty uncommon scenario, since most users don't have
> manually installed CAs though.

Well, if the server is asking a certificate from the user to
authenticate it specifies the exact CAs it trusts so that the client
will use a certificate from that CA to authenticate. In the tangible
world it is like entering a company A and the guard at front expects
you to authenticate using your company A ID.

> I'm not completely sure which party is at fault here; I don't see RFC 5246
> clearly saying that if the list of CAs in the certificate request is
> non-empty, the response MUST match it, I only read this:
>    certificate_authorities
>       A list of the distinguished names [X501] of acceptable
>       certificate_authorities, represented in DER-encoded format.  These
>       distinguished names may specify a desired distinguished name for a
>       root CA or for a subordinate CA; thus, this message can be used to
>       describe known roots as well as a desired authorization space.  If
>       the certificate_authorities list is empty, then the client MAY
>       send any certificate of the appropriate ClientCertificateType,
>       unless there is some external arrangement to the contrary.

It is not the TLS protocol which will specify that behavior but rather
the application protocol. gnutls takes the conservative approach and
does not reveal the ID of the client if it doesn't match the expected
ID from the server. That way if you mistakenly specified your
certificate from site A your ID will not be revealed just because site
B asked of a certificate as well.

> Is firefox at fault here (sending unrelated CAs as part of this handshake -
> e.g. chrome doesn't send any such), or does gnutls need an option for
> intentionally ignoring the requested CAs and sending whatever certificate is
> provided, letting the server decide whether it is acceptable?

If the server would accept a certificate not signed by anyone in his
accepted list, why not send an empty list instead? If there is a
common use-case or scenario that the current behavior don't handle we
may want to provision for it somehow.

Said that, note that this behavior is only with the "automatic"
handling of client certificates. If you want to force the client
sending a certificate you can utilize the callbacks instead.

regards,
Nikos