RE: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
I don't think it makes sense to have a separate flag. What's the harm in looking at the CN if you don't find a match in the SAN? /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
On Wed, Apr 02, 2014 at 07:24:21AM -0400, Salz, Rich wrote: I don't think it makes sense to have a separate flag. What's the harm in looking at the CN if you don't find a match in the SAN? Well, in fact if any DNS SANs exist, per RFC 6125 and other prior art, one in fact must not look at the CN. The question here is whether wildcards allowed in SANs by LDAP specs should consequently also be allowed in the CN (when no SANs are present) despite said LDAP specs. If so we don't need confusing additional flags to separately control processing of wildcards in CN vs. SAN. My plan is to support only one wildcard flag which enables/disables wildcard processing in both CN and SANs. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
A quick check of some of our customers shows that out of 4200 SSL certs, 820 have a wildcard CN. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
On Wed, Apr 02, 2014 at 11:45:05AM -0400, Salz, Rich wrote: A quick check of some of our customers shows that out of 4200 SSL certs, 820 have a wildcard CN. Right, I think this makes particular sense for Akamai customers, for whom you likely host multiple related web sites and coordinating the deployment of multiple certs is likely often too complex. I doubt that Akamai is hosting very many public-facing customer LDAP servers though. In any case, wildcard CNs are a fact of life that even OpenLDAP has accepted, so the plan is what makes sense rather than literal 6125 LDAP adherence. Thanks. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
Right, I think this makes particular sense for Akamai customers, for whom you likely host multiple related web sites and coordinating the deployment of multiple certs is likely often too complex. No, these are individual per-site certs for our customers. And just because you gave me the chance to brag, we handle the deployment of nearly 10,000 SSL certs just fine :) /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
On 03/30/2014 03:39 PM, Viktor Dukhovni wrote: On Sun, Mar 30, 2014 at 11:20:51AM +0200, Steffen Ullrich via RT wrote: - probably useful: while no RFC currently forbids something like *.com you have a check to disallow wildcards in the two rightmost suffixes. I think it makes sense to have that, although it is not sufficient (e.g. *.co.uk should also not be allowed). But doing this 100% correct will be tricky, because there is currently no definition of correct behavior in this area: While chrome disallows *.co.uk firefox allows it. Such a policy would be too complex for OpenSSL, and will be even more complex to get right once all the new TLDs ICANN is blessing us with come online. I think the current best approach to this is the public suffix list, http://publicsuffix.org/ it's a horrible kludge (a fully-enumerated list of all zones that are known to allow registration of sub-zones to the public), but it's better than just counting labels. there are a few C libraries that could be used to make this abstraction available to OpenSSL (if building against external libraries is OK) without requiring much extra work in OpenSSL itself. --dkg signature.asc Description: OpenPGP digital signature
RE: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
I, for one, would not want OpenSSL to employ such a complex and fragile mechanism. Yeah, it's kinda gross and clunky. On the other hand, it's really all we have right now, and rejecting a cert with a SAN name of *.com is a good security thing to do. Perhaps a configure option, or a callback that could implement it? /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
Viktor Dukhovni openssl-users at dukhovni.org writes: On Tue, Apr 01, 2014 at 12:36:18PM -0400, Daniel Kahn Gillmor wrote: I think the current best approach to this is the public suffix list, http://publicsuffix.org/ it's a horrible kludge (a fully-enumerated list of all zones that are known to allow registration of sub-zones to the public), but it's better than just counting labels. there are a few C libraries that could be used to make this abstraction available to OpenSSL (if building against external libraries is OK) without requiring much extra work in OpenSSL itself. I, for one, would not want OpenSSL to employ such a complex and fragile mechanism. I, too, favor a KISS approach. A simple and self-contained algorithm to ensure RFC 6125 compliance can be the near-term goal. However, RFC 6125 makes a point of saying it only recommends client-side wildcard cert handling to accomodate existing infrastructure (i.e. backwards compat). So, a medium-term higher-order discussion can be on the sanity of continuing to support wildcards given the security implications, ambiguities in specifications, variability in client implementations, etc. Maybe that's a topic best suited for the uta wg. --mancha __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
On Tue, Apr 01, 2014 at 05:03:32PM -0400, Salz, Rich wrote: I, for one, would not want OpenSSL to employ such a complex and fragile mechanism. Yeah, it's kinda gross and clunky. On the other hand, it's really all we have right now, and rejecting a cert with a SAN name of *.com is a good security thing to do. Perhaps a configure option, or a callback that could implement it? Note that the implementation in master (some day 1.1.0) already rejects *.com, what it fails to reject is *.co.uk (that's why we're still mulling over this thread). An optional callback perhaps to validate the suffix of a wildcard cert, but complexity has costs, and I think the onus is on the trusted CA ( that wants to remain trusted) to not issue such certificates. I am far from sure the callback is worth the trouble. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
Note that the implementation in master (some day 1.1.0) already rejects *.com, what it fails to reject is *.co.uk Yes, I understand; my example was wrong, sorry. I think the onus is on the trusted CA ( that wants to remain trusted) to not issue such certificates. And mistake-free? I am far from sure the callback is worth the trouble. It's all about trade-offs. I could imagine a callback being generally useful. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
On Tue, Apr 01, 2014, Viktor Dukhovni wrote: On Tue, Apr 01, 2014 at 05:03:32PM -0400, Salz, Rich wrote: I, for one, would not want OpenSSL to employ such a complex and fragile mechanism. Yeah, it's kinda gross and clunky. On the other hand, it's really all we have right now, and rejecting a cert with a SAN name of *.com is a good security thing to do. Perhaps a configure option, or a callback that could implement it? Note that the implementation in master (some day 1.1.0) already rejects *.com, what it fails to reject is *.co.uk (that's why we're still mulling over this thread). It's also in 1.0.2-beta. An optional callback perhaps to validate the suffix of a wildcard cert, but complexity has costs, and I think the onus is on the trusted CA ( that wants to remain trusted) to not issue such certificates. I am far from sure the callback is worth the trouble. The initial aim of X509_check_host was to support minimal host name matching which until then wasn't in OpenSSL at all. It wasn't intended to cover every case but to be a lot better than nothing. The wildcard matching was contributed as an addition. If it's felt it is terminally broken it can be either disabled by default or reverted altogether. Or fixed if someone can come up with a patch... Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
On Wed, Apr 02, 2014 at 12:57:28AM +0200, Dr. Stephen Henson wrote: I am far from sure the callback is worth the trouble. The initial aim of X509_check_host was to support minimal host name matching which until then wasn't in OpenSSL at all. It wasn't intended to cover every case but to be a lot better than nothing. The wildcard matching was contributed as an addition. If it's felt it is terminally broken it can be either disabled by default or reverted altogether. Or fixed if someone can come up with a patch... I can contribute a patch, that addresses many of the issues. Things that I'm not immediately planning to address are: - Separate flag for wildcards in CN vs. wildcards in SAN dnsName. (LDAP case in RFC 6125). - Adding the just discussed callback if it is not obvious how to extend X509_VERIFY_PARAM_ID_st. - Matching multiple reference identities if it is not obvious how to extend X509_VERIFY_PARAM_ID_st to hold additional host names. What were your plans for X509_VERIFY_PARAM_ID_st for DANE? That's where the TLSA records were going to be right? If you post a note about the approach you want to take with extending X509_VERIFY_PARAM_ID_st I can provide a more complete patch. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
On Tue, Apr 01, 2014, Viktor Dukhovni wrote: What were your plans for X509_VERIFY_PARAM_ID_st for DANE? That's where the TLSA records were going to be right? If you post a note about the approach you want to take with extending X509_VERIFY_PARAM_ID_st I can provide a more complete patch. At this stage it doesn't matter too much how X509_VERIFY_PARAM_ID is extended as long as it stays as an opaque structure in a private header file. By doing that it can be reorganised later to handle new features without breaking binary compatibility. That would be much trickier if new fields had been added to the X509_VERIFY_PARAM which is defined in a public header file. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
Viktor Dukhovni wrote: I can contribute a patch, that addresses many of the issues. Things that I'm not immediately planning to address are: - Separate flag for wildcards in CN vs. wildcards in SAN dnsName. (LDAP case in RFC 6125). Just to add context - the LDAP RFCs always specified wildcards in SAN only, not in the CN. But most commercial CAs seem to have made a practice of issuing wildcard certs using * in the CN, not in a dnsName SAN. For a long time we rejected wildcard CN certs in OpenLDAP but finally started accepting them after multiple users' requests. It's a slippery slope, don't expect to get it right. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
On Tue, Apr 01, 2014 at 07:07:10PM -0700, Howard Chu wrote: Viktor Dukhovni wrote: I can contribute a patch, that addresses many of the issues. Things that I'm not immediately planning to address are: - Separate flag for wildcards in CN vs. wildcards in SAN dnsName. (LDAP case in RFC 6125). Just to add context - the LDAP RFCs always specified wildcards in SAN only, not in the CN. But most commercial CAs seem to have made a practice of issuing wildcard certs using * in the CN, not in a dnsName SAN. For a long time we rejected wildcard CN certs in OpenLDAP but finally started accepting them after multiple users' requests. It's a slippery slope, don't expect to get it right. Thanks, good to know. So is there in your view a real need for separate wildcard flags in SAN vs. CN? It never made much sense to me, and if LDAP implementations are now giving in to CA practice, I am inclined to do what makes more sense, more than I am inclined to support an oddity of the LDAP wildcard matching specifications. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
Viktor Dukhovni wrote: On Tue, Apr 01, 2014 at 07:07:10PM -0700, Howard Chu wrote: Viktor Dukhovni wrote: I can contribute a patch, that addresses many of the issues. Things that I'm not immediately planning to address are: - Separate flag for wildcards in CN vs. wildcards in SAN dnsName. (LDAP case in RFC 6125). Just to add context - the LDAP RFCs always specified wildcards in SAN only, not in the CN. But most commercial CAs seem to have made a practice of issuing wildcard certs using * in the CN, not in a dnsName SAN. For a long time we rejected wildcard CN certs in OpenLDAP but finally started accepting them after multiple users' requests. It's a slippery slope, don't expect to get it right. Thanks, good to know. So is there in your view a real need for separate wildcard flags in SAN vs. CN? It never made much sense to me, and if LDAP implementations are now giving in to CA practice, I am inclined to do what makes more sense, more than I am inclined to support an oddity of the LDAP wildcard matching specifications. By all means, do what makes sense. I'm not sure how relevant it is for LDAP, since OpenLDAP's libldap is pretty much the only LDAP client library around now, and we already have our own cert validation function which behaves identically for OpenSSL, MozillaNSS, and GnuTLS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
On Sun, Mar 30, 2014 at 11:20:51AM +0200, Steffen Ullrich via RT wrote: - wrong: according to RFC 6125 section 7.2 only the leftmost label should be checked for wildcards, but you support also something like www.*.example.com (there is even a test for it). Well, wrong is perhaps too strong a claim, it is however not RFC6125 conformant, and applications should be able to (perhaps by default) get RFC6125 conformant behaviour. Therefore, there should probably be a flag to disable (if on by default) or enable (if not) the RFC6125 restriction on * lying in the left-most label of the wildcard pattern. Separately, there should be a flag to relax the RFC6125 restriction that disallows that left-most wildcard to match more than one leading label, say with X509_CHECK_FLAG_MULTI_LABEL_WILDCARD: foo.bar.example.com ~ *.example.com Also the current code insists that * match at least one character, but RFC6125 (based on all too brief text in RFC2818) is silent on the question of whether: foo.example.com ~ foo*.example.com Lacking normative text, what is current practice? How do browsers handle this? - wrong: you match wildcards within IDNA labels (there is also a test for it), which is not allowed. While according to http://rt.openssl.org/Ticket/Display.html?id=2909#txn-35213 the IDNA handling could not be found in any standard, RFC6125 section 7.2 is actually quite clear about it. Indeed this should be fixed. If the pattern label containing the wildcard matches (case insensitive) one of: /^xn--.*\*/ /^\*.*xn--/ then the wildcard is definitely taboo. There are subtler cases: /^x*--/ here the pattern is not obviously an A-label, but matches some A-labels. The solution is I think to enhance the pattern validity checks to more fully check the required LDH structure: # No trailing '.' # No consecutive '.' characters # No consecutive '-' characters, except when part of xn-- at the start of a pattern label # No '-' characters at the beginning or end of a label - insufficient: you have a flag X509_CHECK_FLAG_NO_WILDCARDS to disable wildcard checking and a flag X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT to check the CN even if subject alternative names are present. That's not sufficient to describe the hostname checking which needs to be done for the various protocols: Indeed there is as yet no flag that enables/disables the use of foo* and *foo in which * matches only part of a label. Such a flag should be added. - in theory X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT should be false too, but its behavior does not match whats required from the RFC: the current implementation does check CN if there are no subject alternative names, but it should check CN if the are no DNS subject alternative names. So if SAN sections contains only IP it should check CN too. Indeed the TLS support code contributed by Lutz Jaenicke for Postfix over a decade ago suppresses CN checks only when no DNS altnames are found, rather than when no altnames are found at all. So this is easy to fix without interface changes, just change the implementation to only skip the Subject CN when DNS altnames are present. - ldap only allows in subject alternative names something like *.foo.com, but not x*.foo.com like it is allowed with http and done with the current wildcards check - it also should check the CN always, but does not allow wildcards in the CN This LDAP behaviour is bizarre, and reflects the absurd mess of PKIX name checks prior to RFC6125, which RFC6125 is unfortunately forced to accept and document. It makes little sense to allow wildcards in altnames but disallow them in the subject CN. So I don't think that a separate flag for wildcard support in CN vs. DNS altname is warranted. - smtp, imap, pop3, nntp ... (RFC2595, RC4642, RFC5539...) - these protocols don't allow x*.foo.com too, e.g only *.foo.com There is no specification for name checks in MTA to MTA SMTP, name checks, if any, are local policy. There is a partial specification for submission. There is a new draft under development in the Using TLS for Applications (UTA) working group to specify name checks for MTA to MTA SMTP and the situation is rather different when DANE TLSA authentication is used (in this draft * again matches only the complete label). With Postfix, the administrator can specify *multiple* valid reference identities, which can match the server certificate. And indeed this will be required by DANE TLSA for SMTP and with SRV records. The Postfix local policy is rather flexible. The * wildcard must be a complete label in the server certificate, but by default can match more than one label in the reference identity. The administrator can specify multiple reference identities. When a reference identity takes the form .example.com (starts with a leading .), it matches server names that
