Re: X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS
On Tue, Apr 19, 2022 at 10:07:15PM -0400, Viktor Dukhovni wrote:
> This is an apples/oranges dichotomy. "*" wildcards are "presented
> identifiers" in the certificate.
>
> If the documentation is not sufficiently clear (too subtle) on this
> point, would you like to suggest some text to clarify the documentation?
> A pull request?
Note that paragraph three of the DESCRIPTION reads:
When name [bold font] starts with a dot (e.g. ".example.com"),
it will be matched by a certificate valid for any sub-domain of name,
(see also X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS below).
where it should ideally be clear that we're talking about the peer name
specified by the application (reference identifier in terms of RFC 6125),
not a DNS-ID in the certificate (presented identifier).
--
Viktor.
Re: X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS
On Tue, Apr 19, 2022 at 03:25:03PM -0700, Hal Murray wrote: > man X509_check_host says: >If set, X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS restricts name values >which start with ".", that would otherwise match any sub-domain in the >peer certificate, to only match direct child sub-domains. Thus, for >instance, with this flag set a name of ".example.com" would match a >peer certificate with a DNS name of "www.example.com", but would not >match a peer certificate with a DNS name of "www.sub.example.com"; this >flag only applies to X509_check_host. > > I haven't see the idea of ".example.com" being special in any of the RFCs > I've > been looking at. Can somebody give me a lesson in this area? You perhaps did not notice that this describes syntax in "reference identifiers" (arguments to SSL_set1_host(3), ...), rather "presented identifiers" (contents of the peer certificate). As such these a local matter (API detail) that lies outside any RFC. A verifier than asks for a specific hostname is not affected by this feature. But a verifier that asks OpenSSL to verify ".example.com" against a certificate is specifying a "fuzzy" match. > Is there any way to turn it off totally while still allowing * type wildcards? This is an apples/oranges dichotomy. "*" wildcards are "presented identifiers" in the certificate. If the documentation is not sufficiently clear (too subtle) on this point, would you like to suggest some text to clarify the documentation? A pull request? -- Viktor.
Re: freefunc - name clash with Python.h
> On 21 Jun 2020, at 1:20 pm, Dan Kegel wrote: > > Openssl should probably stop using generic identifiers like freefunc > in its header files, out of sheer self-defense. I'd long held an apparently minority opinion among OpenSSL team members that prototypes in header files MUST NOT name any variables, and should only mention their types, precisely to avoid this sort of issue. Thus, e.g.: int foo(char *, int); rather than: int foo(char *buf, int len); Variable names in header files are no substitute for documentation, and are all too prone to precisely this sort of conflict. -- Viktor.
X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS
man X509_check_host says: If set, X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS restricts name values which start with ".", that would otherwise match any sub-domain in the peer certificate, to only match direct child sub-domains. Thus, for instance, with this flag set a name of ".example.com" would match a peer certificate with a DNS name of "www.example.com", but would not match a peer certificate with a DNS name of "www.sub.example.com"; this flag only applies to X509_check_host. I haven't see the idea of ".example.com" being special in any of the RFCs I've been looking at. Can somebody give me a lesson in this area? Is there any way to turn it off totally while still allowing * type wildcards? -- These are my opinions. I hate spam.
Forthcoming OpenSSL Releases
The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 3.0.3 and 1.1.1o. These releases will be made available on Tuesday 26th April 2022 between 1300-1700 UTC. These are security-fix releases. The highest severity issue fixed in these releases is MODERATE: https://www.openssl.org/policies/secpolicy.html#moderate Yours The OpenSSL Project Team OpenPGP_0xD9C4D26D0E604491.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
