Hi Viktor,
Great work on the API.
I have a few additional questions. My apologies if you are on the
beach enjoying yourself.
>> I guess what I am asking: what is the default behavior. Its not clear
>> from the basic description.
>
> For each flag bit, the opposite behaviour to that obtained by
> setting the bit is the default when the bit is zero.
Right, but what is the baseline behavior with (and without) wild cards
in a certificate's DNS name?
Does the entire RFC 6125 apply for hostname matching? If so, two points:
(1) X509_check_host(3)'s description only references tRFC 6125
for IDNs presentation, and not the entirety of hostname
matching.
(2) The certificates being issued for many sites and services use
CA/B Forums Baseline Requirement (and EV Guide); and *not*
the IETF's documents.
In my naiveness, it seems to beg for an API that allows one to load a
profile for matching (IETF vs CA/B). That is, if my client visits a
public website, then I'm probably dealing with a certificate from the
CA/Browser cartel and one set of policies would apply. if I am using a
VPN from an organization's internal PKI , then another set of policies
would apply.
I think its a mistake to match everything under the IETF's profile. A
standard written to encompass nearly all existing practices from the
era is bound to be a bit loose in some areas. A perfect example is the
matching of the gTLD "*.com". Its not prohibited by the IETF standards
even though we *know* no one entity controls every domain in *.COM.
(And the CA/B Forum's Baseline Docs does prohibit it).
>> For X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS:
>>
>> If set, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS suppresses support
>> for ``*'' as wildcard pattern in labels that have a prefix or
>> suffix, such as: ``www*''
>> or ``*www''; this only aplies to X509_check_host.
>>
>> Is that the "leftmost" rule? I.e., a wildcard must be at the leftmost label?
>>
>
> No, it is exactly what is described. When the bit is clear such partial
> wildcards are allowed.
So I'm clear (and forgive my ignorance): wildcards will be allowed in
places other than the leftmost label?
If so, it appears I have to use X509_check_host to tune the behavior.
Sorry to dive into the details. I need to understand these behaviors
when I write software and audit software using the features.
>> What is the purpose of allowing a leading dot for a hostname? I.e.,
>> why is ".example.com" allowed?
>
> It allows the verifier to specify a parent domain, rather than a
> particular host. Any host in that domain or sub-domain matches.
So I'm clear (and forgive my ignorance): is that like ** in some other
languages? I.e., *.example.com would match www.example.com,
mail.example.com, etc; while **.example.com would match
www.sub.example.com, www.sub1.sub2.example.com, mail.sub.example.com,
mail.sub1.sub2.example.com, etc.
Again, sorry to dive into the details.
>> Is there an intersection with EV OIDs? Or is it out of scope for host
>> name matching?
>
> EV is about whether the certificate is trusted by browsers. It
> has nothing to do with namechecks.
I thought Browser trust is conferred through its root certificate
store. (And I'm not going to try and define "trust", unlike the
conversation on the thread at SAAG).
EV indicates a CA applied a particular policy when issuing a
certificate. Since this is based on a well established policy, its
testable.
What EV accomplishes is a different story, and I think Dr. Gutmann
described it best with PKI-me-harder and his observations of restoring
profit levels.
>> According to the CA/B EV Guide, wildcards are not
>> allowed in EV certificates. So I would expect a wilcarded cert to be
>> rejected as malformed if its an EV certificate.
>
> Applications that process EV certs can disable wildcards in name checks
> via the appropriate flag.
OK, is that something that should be left to the application
developer? Does an application developer expect the functionality?
Or is it as simple as setting a flag for the routines (something like
X509_CHECK_FLAG_NO_EV_WILDCARDS or similar)?
>> Would it be possible to receive the reason for a failure? For example,
>> I would consider a DNS name in the CN as a soft failure that I could
>> recover from (both the RFC and CA/B Forums have deprecated the
>> practice, but its still frequently encountered). But a wildcard match
>> with trickery, such as a DNS name of "*.com", would be a hard failure
>> that I would not attempt to recover from.
>
> The specified reference identity either matches or not.
Well, I believe its much more than simple matching. If an application
naively approaches name matching, then the adversaries will thank
them.
>> As another example, Java will fail a cert for overlapping DNS names in
>> Subject Alt Names of a certificate, like having both "*.com" and
>> "www.*.com" or having both "*.com" and "example.com"
>
> Don't trust CAs that generate malformed certs. OpenSSL does not
> support "*.com", there must be at least two labels after the
> wildcard. OpenSSL does not support "www.*.com.au", the wildcard
> must be in the left-most label.
That's getting into murky waters because it only addresses gTLDs. It
sounds like ccTLDs, such as "*.co.uk", are vulnerable to attack. If
OpenSSL's API declares a match for "*.co.uk" and it turns out to be an
attack, then that could be a problem for both OpenSSL users and the
library.
If Dbound had any deliverables, then I would turn to them at this
point (https://www.ietf.org/mailman/listinfo/dbound). I don't think
the Public Suffix List (PSL) is applicable here since its context is
domain and cookie matching in browsers.
>> So maybe something like the following, where `reason` is an optional
>> bitmask that is valid *if* the function fails.
>>
>> int X509_check_host(X509 *, const unsigned char *name,
>> size_t namelen, unsigned int flags, int* reason);
>
> This is too complex an interface. You specify how matching is to
> be done, and then it either works or does not. Keep in mind that
> you should not explicitly use X509_check_host() if at all possible.
Then shouldn't it be a priavte interface named x509_check_host that's
only available internally and exported in test configurations for
testing?
> Instead use X509_VERIFY_PARAM_set1_host(), then name checks are
> performed as needed. The verify callback is called with an error status
> if the fail.
If a client application calls `SSL_set_tlsext_host_name`, does it also
need to call `X509_VERIFY_PARAM_set1_host()`? Or do we need to call
both? Is there a SSL_* function to set the X509 hostname verification
flags?
(Sorry about the last few questions. They percolated up last night,
but I did not want to send an additional email).
Jeff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
