Re: Problems with cert authentication under Turkish locale

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux