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(&pattern, &pattern_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