Re: implement subject alternative names support for SSL connections

On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
>
> On 08/28/2014 07:28 PM, Alexey Klyukin wrote:
>>
>> On Mon, Aug 25, 2014 at 12:02 PM, Heikki Linnakangas <
>> hlinnakangas(at)vmware(dot)com> wrote:
>>
>>> On 08/24/2014 03:11 PM, Alexey Klyukin wrote:
>>>
>>>> On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas <
>>>> hlinnakangas(at)vmware(dot)com> wrote:
>>>>
>>>>> The patch doesn't seem to support wildcards in alternative names. Is
>>>
>>> that on purpose?
>>
>>
>> Not really, we just did not have any use case for them, but it seems that
>> RFC 5280 does not disallow them:
>>
>> " Finally, the semantics of subject alternative names that include
>> wildcard characters (e.g., as a placeholder for a set of names) are
>> not addressed by this specification. Applications with specific
>> requirements MAY use such names, but they must define the semantics."
>>
>> I've added support for them in the next iteration of the patch attached to
>> this email.
>
>
> Hmm. So wildcards MAY be supported, but should we? I think we should follow the example of common browsers here, or OpenSSL or other SSL libraries; what do they do?

Yes, they seem to be supported. The function you've mentioned above
(X509_check_host) specifically mentions wildcards in SANs at
https://www.openssl.org/docs/crypto/X509_check_host.html:

'X509_check_host() checks if the certificate Subject Alternative Name
(SAN) or Subject CommonName (CN) matches the specified host name,
which must be encoded in the preferred name syntax described in
section 3.5 of RFC 1034. By default, wildcards are supported and they
match only in the left-most label; but they may match part of that
label with an explicit prefix or suffix. For example, by default, the
host name ``www.example.com'' would match a certificate with a SAN or
CN value of ``*.example.com'', ``w*.example.com'' or
``*w.example.com''.'

>
> RFC 6125 section 6.4.4 Checking of Common Names says:
>
>> As noted, a client MUST NOT seek a match for a reference identifier
>> of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
>> URI-ID, or any application-specific identifier types supported by the
>> client.
>
>
> So, to conform to that we shouldn't check the Common Name at all, if an alternative subject field is present.

While the RFC indeed says so, the OpenSSL implementation includes
X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT flag (which, as far as I can see,
is set to 1 by default), which makes it check for the CN even if DNS
names in SAN are present. I'm not sure what is the reason behind
section 6.4.4, and I think it makes sense to check CN as well, since
it does not lead to the case of false matches.

>
>
> Yeah, I think a certificate without CN should be supported. See also RFC 6125, section 4.1. "Rules" [for issuers of certificates]:
>
>> 5. Even though many deployed clients still check for the CN-ID
>> within the certificate subject field, certification authorities
>> are encouraged to migrate away from issuing certificates that
>> represent the server's fully qualified DNS domain name in a
>> CN-ID. Therefore, the certificate SHOULD NOT include a CN-ID
>> unless the certification authority issues the certificate in
>> accordance with a specification that reuses this one and that
>> explicitly encourages continued support for the CN-ID identifier
>> type in the context of a given application technology.
>
>
> Certificates without a CN-ID are probably rare today, but they might start to appear in the future.

Ok, I will change a patch to add support for this clause.

>
>
> BTW, should we also support alternative subject names in the server, in client certificates? And if there are multiple names, which one takes effect? Perhaps better to leave that for a separate patch.

Good question. The RFC 5280 section 4.2.1.6 does not restrict the
certificates to be used only server-side, so the same rules should be
applicable to the client certs. I'm wondering if there is an
equivalent of RFC 6125 for the clients?

PostgreSQL, however, checks different things on the backends and the
clients, the formers are checked against the DNS name, while on the
clients only the user name is checked. For this, I think, a SAN
section
with some custom identity type should be issued (the 4.2.1.6 does not
list user names as a pre-defined identify type). Note that PostgreSQL
can already support clients with multiple names via the user maps, so
support for SAN is not that urgent there.

On the other hand, should we, in addition to verification of client
user names, verify the client names supplied during connections
against the DNS entries in their certificates? Are there use cases for
this?

I do agree this should be the subject of a separate patch.

Regards,
Alexey