Re: [openssl-users] Problems with cert authentication under Turkish locale
On Tue, Nov 01, 2016 at 06:15:01PM +0100, Jakob Bohm wrote:
> >>The issue is triggered in libcurl but it seems to come out of libssl. It
> >>seems to be
>
> Note that the Turkish UNICODE locales have the unusual property
> that the uppercase/lowercase routines do not match ASCII "I" to
> ASCII "i", to cater to the distinguishing between "dotted" and
> "dotless" letter I in Turkish natural language. It is the only
> known locales to case map an ASCII character differently than the
> basic ASCII algorithm presumed by the standard for Internet host
> names.
Indeed, but the hostname comparison code in OpenSSL 1.0.2+ does
not uses none of the locale-sensitive tolower(), toupper(),
str[n]casecmp() to do name comparison:
/* Compare while ASCII ignoring case. */
static int equal_nocase(const unsigned char *pattern, size_t pattern_len,
const unsigned char *subject, size_t subject_len,
unsigned int flags)
{
skip_prefix(, _len, subject_len, flags);
if (pattern_len != subject_len)
return 0;
while (pattern_len) {
unsigned char l = *pattern;
unsigned char r = *subject;
/* The pattern must not contain NUL characters. */
if (l == 0)
return 0;
if (l != r) {
if ('A' <= l && l <= 'Z')
l = (l - 'A') + 'a';
if ('A' <= r && r <= 'Z')
r = (r - 'A') + 'a';
if (l != r)
return 0;
}
++pattern;
++subject;
--pattern_len;
}
return 1;
}
The only use of strncasecmp() is to compare the first four characters
of an A-label with with "xn--". No known locale breaks that, and
there's no "xn--" in "www.hotmail.com".
The inputs are required to be A-labels, so Unicode is out of scope:
https://www.openssl.org/docs/man1.1.0/crypto/X509_check_host.html
Per section 6.4.2 of RFC 6125, name values representing
international domain names must be given in A-label form. The
namelen argument must be the number of characters in the name
string or zero in which case the length is calculated with
strlen(name). When name 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).
Perhaps similar language should be added to:
https://www.openssl.org/docs/man1.1.0/ssl/SSL_set1_host.html
SSL_set1_host() sets the expected DNS hostname to name clearing
any previously specified host name or names. If name is NULL,
or the empty string the list of hostnames is cleared, and name
checks are not performed on the peer certificate. When a
non-empty name is specified, certificate verification automatically
checks the peer hostname via X509_check_host with flags as
specified via SSL_set_hostflags(). Clients that enable DANE
TLSA authentication via SSL_dane_enable should leave it to that
function to set the primary reference identifier of the peer,
and should not call SSL_set1_host().
Some users may not delve deeper and read the X509_check_host()
documentation. Documentation patches welcome.
> So something, in either OpenSSL or curl (or a combination) may
> (on the OPs system) be using a locale-sensitive function to
> compare e.g. "hotmail.com" and "HOTMAIL.COM", where some kind
> of locale-neutral function should be used to avoid the special
> handling that the Unicode standard specifies for the letter "I"
> in Turkish.
>
> >I see nothing in the OpenSSL X.509 stack that would be sensitive
> >to this locale. In particular, with OpenSSL >= 1.0.2 doing the
> >hostname check, both:
It is hard to see where OpenSSL could be going astray. It is true
that on Windows OpenSSL provides an OPENSSL_str[n]casecmp() that
compares by mapping to upper case. Perhaps libcurl is using
that?
The name constraint code might hypothetically not work right in
the Turkish locale, because it uses the locale-sensitive strcasecmp().
That should be fixed, but is not pertinent to the OP's report.
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Problems with cert authentication under Turkish locale
On 01/11/2016 17:42, Viktor Dukhovni wrote: On Tue, Nov 01, 2016 at 04:28:18PM +0100, Sebastian Kloska wrote: [ Redirecting to openssl-users. ] (I cannot see the original posts, as I am only subscribed to -users). We have problems authenticating a a CERT while LC_CTYPE is set to tr_TR.UTF-8 The issue is triggered in libcurl but it seems to come out of libssl. It seems to be Note that the Turkish UNICODE locales have the unusual property that the uppercase/lowercase routines do not match ASCII "I" to ASCII "i", to cater to the distinguishing between "dotted" and "dotless" letter I in Turkish natural language. It is the only known locales to case map an ASCII character differently than the basic ASCII algorithm presumed by the standard for Internet host names. So something, in either OpenSSL or curl (or a combination) may (on the OPs system) be using a locale-sensitive function to compare e.g. "hotmail.com" and "HOTMAIL.COM", where some kind of locale-neutral function should be used to avoid the special handling that the Unicode standard specifies for the letter "I" in Turkish. I see nothing in the OpenSSL X.509 stack that would be sensitive to this locale. In particular, with OpenSSL >= 1.0.2 doing the hostname check, both: LANG=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname www.hotmail.com and LC_CTYPE=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname www.hotmail.com return success. OpenSSL 1.0.1 and earlier do not do hostname checks, that's left to the application. With 1.0.1 the chain alone verifies just fine: $ LC_CTYPE=tr_TR.UTF-8 /.../OpenSSL_1_0_1/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem CONNECTED(0003) depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify return:1 depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 EV SSL CA - G3 verify return:1 depth=0 1.3.6.1.4.1.311.60.2.1.3 = US, 1.3.6.1.4.1.311.60.2.1.2 = Washington, businessCategory = Private Organization, serialNumber = 600413485, C = US, postalCode = 98052, ST = Washington, L = Redmond, street = 1 Microsoft Way, O = Microsoft Corporation, OU = Outlook Kahuna BAY-A Jun2015, CN = mail.live.com verify return:1 --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A Jun2015/CN=mail.live.com i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 --- Server certificate -BEGIN CERTIFICATE- ... -END CERTIFICATE- subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A Jun2015/CN=mail.live.com issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 --- No client certificate CA names sent --- SSL handshake has read 5342 bytes and written 511 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-SHA384 Session-ID: ... Session-ID-ctx: Master-Key: ... Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1478018209 Timeout : 300 (sec) Verify return code: 0 (ok) So it seems that any problem lies with libcurl. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, 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-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Problems with cert authentication under Turkish locale
On Tue, Nov 01, 2016 at 04:28:18PM +0100, Sebastian Kloska wrote: [ Redirecting to openssl-users. ] > We have problems authenticating a a CERT while LC_CTYPE is set to > tr_TR.UTF-8 > > The issue is triggered in libcurl but it seems to come out of libssl. It > seems to be I see nothing in the OpenSSL X.509 stack that would be sensitive to this locale. In particular, with OpenSSL >= 1.0.2 doing the hostname check, both: LANG=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname www.hotmail.com and LC_CTYPE=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname www.hotmail.com return success. OpenSSL 1.0.1 and earlier do not do hostname checks, that's left to the application. With 1.0.1 the chain alone verifies just fine: $ LC_CTYPE=tr_TR.UTF-8 /.../OpenSSL_1_0_1/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem CONNECTED(0003) depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify return:1 depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 EV SSL CA - G3 verify return:1 depth=0 1.3.6.1.4.1.311.60.2.1.3 = US, 1.3.6.1.4.1.311.60.2.1.2 = Washington, businessCategory = Private Organization, serialNumber = 600413485, C = US, postalCode = 98052, ST = Washington, L = Redmond, street = 1 Microsoft Way, O = Microsoft Corporation, OU = Outlook Kahuna BAY-A Jun2015, CN = mail.live.com verify return:1 --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A Jun2015/CN=mail.live.com i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 --- Server certificate -BEGIN CERTIFICATE- ... -END CERTIFICATE- subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A Jun2015/CN=mail.live.com issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 --- No client certificate CA names sent --- SSL handshake has read 5342 bytes and written 511 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-SHA384 Session-ID: ... Session-ID-ctx: Master-Key: ... Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1478018209 Timeout : 300 (sec) Verify return code: 0 (ok) So it seems that any problem lies with libcurl. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
