From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.groups.io with SMTP id smtpd.web11.2698.1571212483076454355 for ; Wed, 16 Oct 2019 00:54:43 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9ACEBA3CD88; Wed, 16 Oct 2019 07:54:42 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-232.ams2.redhat.com [10.36.116.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id 113E95C1B5; Wed, 16 Oct 2019 07:54:40 +0000 (UTC) Subject: Re: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses From: "Laszlo Ersek" To: "Wu, Jiaxin" , "devel@edk2.groups.io" Cc: Bret Barkelew , David Woodhouse , "Wang, Jian J" , Richard Levitte , Sivaraman Nainar Reply-To: devel@edk2.groups.io, lersek@redhat.com References: <20190927034441.3096-1-Jiaxin.wu@intel.com> <20191015230839.27708-1-lersek@redhat.com> <895558F6EA4E3B41AC93A00D163B727416F81251@SHSMSX107.ccr.corp.intel.com> <56d17f5f-8433-2ec5-924c-bade642ac5a7@redhat.com> Message-ID: <4284c06a-2dbc-ec0a-3402-59c2fe00ab9c@redhat.com> Date: Wed, 16 Oct 2019 09:54:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <56d17f5f-8433-2ec5-924c-bade642ac5a7@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.68]); Wed, 16 Oct 2019 07:54:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Here's an extra point: On 10/16/19 09:36, Laszlo Ersek wrote: > On 10/16/19 07:18, Wu, Jiaxin wrote: >> Fortunately, I get my wanted answer in RFC6125, SECTION 3.1 : >> >> If a subjectAltName extension of type dNSName is present, that MUST >> be used as the identity. Otherwise, the (most specific) Common >> Name field in the Subject field of the certificate MUST be used. >> Although the use of the Common Name is existing practice, it is >> deprecated and Certification Authorities are encouraged to use the >> dNSName instead. >> ... >> In some cases, the URI is specified as an IP address rather than a >> Hostname . In this case, the iPAddress subjectAltName must be >> present in the certificate and must exactly match the IP in the >> URI. > > Wow! > > This seems to prove David right, and it suggests that symptom (2) > encountered with my patch is actually *valid* behavior -- the > certificate I generated with "genkey" is *not* valid for a URI that > specifies an IP address! > > This is not good news: the "curl" utility also accepts such a > certificate as valid (IP address in URL, but the certificate only > contains a CN, matching the IP address in textual form). Is that a bug > in "curl" then? Check this out: https://wiki.openssl.org/index.php/Hostname_validation (The latest version of the article, which I'm looking at now, is .) This wiki article on the openssl website explains how to do hostname validation, and it also quotes "curl" code. Notice that it does not consider IP address validation specifically. The example code for OpenSSL 1.1.0 only calls SSL_set1_host(). And, the code quoted from "curl" seems to suffer from two issues: - matches_subject_alternative_name() ignores GEN_IP -- it only compares the host part of the URL against GEN_DNS entries - if matches_subject_alternative_name() fails, matches_common_name() can still accept the certificate, even if the URL specified a numeric IP address. How are we supposed to get this right if even the reference code in the wiki appears wrong (per RFC6125)? Anyway: once David's PR#9201 is merged into OpenSSL, the example code in the wiki page that calls SSL_set1_host() will become right. Thanks Laszlo