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.web12.3280.1571326505225592171 for ; Thu, 17 Oct 2019 08:35:05 -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-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2AF6B51F0B; Thu, 17 Oct 2019 15:35:04 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-208.ams2.redhat.com [10.36.117.208]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9D56119C70; Thu, 17 Oct 2019 15:35:01 +0000 (UTC) Subject: Re: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses To: devel@edk2.groups.io, dwmw2@infradead.org, "Wu, Jiaxin" Cc: Bret Barkelew , "Wang, Jian J" , Richard Levitte , Sivaraman Nainar 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> <139da0c5a4684b76809fa19acc007f4699e3eb28.camel@infradead.org> <81cf523b-1cc0-9df1-cbb3-c16a78e26a55@redhat.com> From: "Laszlo Ersek" Message-ID: <64366517-6a4e-41da-0ab5-6dea3580bf30@redhat.com> Date: Thu, 17 Oct 2019 17:35:00 +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: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 17 Oct 2019 15:35:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Jiaxin, On 10/16/19 17:25, David Woodhouse wrote: > On Wed, 2019-10-16 at 16:43 +0200, Laszlo Ersek wrote: >> Regarding the current edk2 patch set, I think we should do the following: >> >> - use X509_VERIFY_PARAM_set1_ip() rather than >> X509_VERIFY_PARAM_set1_ip_asc() >> >> - incorporate "StdLib/BsdSocketLib/inet_pton.c" from the edk2-libc >> project (which used to be part of edk2 itself) into TlsLib, and call >> inet_pton() for parsing the address as both IPv4 and IPv6. > > That makes sense. Please wait a little before starting work on this. I've been made aware, in , of the practices of various certificate authorities: [1] https://www.geocerts.com/support/ip-address-in-ssl-certificate [2] https://www.leaderssl.com/articles/381-issuing-ssl-certificate-for-an-ip-address [3] https://support.globalsign.com/customer/en/portal/articles/1216536-securing-a-public-ip-address---ssl-certificates What's most worrisome is [3], which writes: If you are targeting Windows 10 and later, you can populate the IP address in either field. If however, you are targeting Windows 8.1 and earlier, you should only specify the IP address as the common name. Keyword being "only". Assuming the above quote precisely reflects reality: if we made edk2 strictly insist on the IP address being in the SAN.iPAddress field, then edk2 could not HTTPS-boot from such web servers that intend to serve Windows clients up to 8.1. Reference [2] advises to put the IP address in both CN and SAN.iPAddress for best compatibility, and that would be fine, for X509_VERIFY_PARAM_set1_ip(). But the word "only" in [3] is really bad for X509_VERIFY_PARAM_set1_ip(). Thanks Laszlo