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.web10.964.1570730631213694384 for ; Thu, 10 Oct 2019 11:03:51 -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 B229018CB8E5; Thu, 10 Oct 2019 18:03:50 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-48.rdu2.redhat.com [10.10.120.48]) by smtp.corp.redhat.com (Postfix) with ESMTP id 48457194B2; Thu, 10 Oct 2019 18:03:48 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553) To: David Woodhouse , "Wu, Jiaxin" , "devel@edk2.groups.io" , "Wang, Jian J" , Bret Barkelew Cc: Richard Levitte References: <20190927034441.3096-1-Jiaxin.wu@intel.com> <69774fe6-ea00-44b9-5468-c092dea6cd36@redhat.com> <8106467c9f4132c831d0aa604e897fe9d4dda12a.camel@infradead.org> <895558F6EA4E3B41AC93A00D163B727416F5D921@SHSMSX107.ccr.corp.intel.com> <777053db79600eb90a19945700293d14f4978344.camel@infradead.org> <6bb5d2f6-ec6f-1766-e19b-03fd45c1bc12@redhat.com> <9A4966EE-76CD-465C-A6CA-70DD9E38D834@infradead.org> <850a81a8-2cdc-0708-4ff7-db9825fdaedc@redhat.com> From: "Laszlo Ersek" Message-ID: <23699ae3-10c2-037c-b3f5-ac8f5bea1fb7@redhat.com> Date: Thu, 10 Oct 2019 20:03:48 +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.6.2 (mx1.redhat.com [10.5.110.63]); Thu, 10 Oct 2019 18:03:50 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/10/19 17:45, David Woodhouse wrote: > On Thu, 2019-10-10 at 10:00 +0200, Laszlo Ersek wrote: >>> Subject: C=HU, ST=Pest, L=Budapest, O=Laszlo Ersek Home Office, OU=IPv6 cert, CN=fd33:eb1b:9b36::2 > > Yeah, you're not actually testing the case I'm talking about. You want > a GEN_IP in the x509v3 Subject Alternative Name. > > Compare with... > > $ openssl s_client -connect vpn-i-ha01.intel.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 Alternative > X509v3 Subject Alternative Name: > DNS:vpn-int.intel.com, DNS:scsidcint01-a.intel.com, IP Address:134.191.232.101 > > $ curl https://134.191.232.101/ > OK, thank you. I can imagine two failure modes, with the patches applied. (1) Edk2 ignores the GEN_IP in the SAN, and rejects a matching server certificate. (2) Edk2 is confused by the GEN_IP in the SAN, and accepts an invalid (mismatched) server certificate. Can we tell which failure mode applies? (I can't test it easily myself, as I don't even know how to create a server certificate with a SAN -- any kind of SAN, let alone GEN_IP.) Case (2) is clearly bad, and it would be a sign that the patch series does not fully fix the issue. Case (1) would be tolerable, in my opinion. I assume a GEN_IP SAN is pretty rare in practice. Thus regressing it (perhaps temporarily) should be an acceptable trade-off for fixing the current gaping hole (= subject name not checked at all). Thanks Laszlo