On 7/3/2014 1:22 PM, Viktor Dukhovni wrote:
On Thu, Jul 03, 2014 at 12:35:23AM -0400, Jeffrey Walton wrote:
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.
*****
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 without the bit, a certificate can specify that it applies to
"*www.example.com" and match servers "onewww.example.com",
"twowww.example.com" etc. but not "onepay.example.com", while with
the bit, the only acceptable certificates are those issued to
exactly "*.example.com" or each of "onewww.example.com" and
"twowww.example.com"
Did I get that right?
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.
A leading dot does not appear to be a valid hostname nor a well formed
FQDN. I don't recall reading about it in the RFCs or the CA/B Forums
(RFCs 5280, 6125 or CA/B Baseline Requirements). I would expect a
certificate with it to be rejected as malformed.
This name is NOT in the certificate. It is a fuzzy reference identity.
So you mean if ".example.com" is passed as the "hostname to match"
argument to X509_VERIFY_PARAM_set1_host() or X509_check_host(), then
it will accept any certificate issued to www.example.com,
mail.example.com, internal.mail.example.com, *.example.com or
*.mail.example.com, as just a few examples?
By the way does ".example.com" also match the bare "example.com"?
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.
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.
The common case is that an application accepts both EV and non-EV certs
during the TLS (etc.) handshake, then informs the user (via a color or
icon) if the negotiated cert is EV or not.
Thus to be a meaningful audited replacement for each application coding
its own certificate verification logic, the API introduced in OpenSSL
needs to handle that scenario, since it is the most common case.
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.
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.
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.
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.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
