From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web09.6053.1572693841870207686 for ; Sat, 02 Nov 2019 04:24:02 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GUdnUtt3; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572693841; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p5egUFxRkpElei2pPeHSHfEYTefD2Qp4TTC07sHf31U=; b=GUdnUtt3vbG/2fGPz+0BCi6ZGR9pKgb+4ZGGknGpx08Y8Gf1JDbvUP/od2rQkEVuarz/VW yf+kQbJVP2ilzzBM7Yw/Xi5Vw0tg7ykilqGXeW8/ZvCBV2NM49te7AuvLTmWsynOmBKOJE s9taZ1xBq8Tyxbz7wEGLvwfwgCa2alY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-290-05cxBEBsOoynKEETm2KcjQ-1; Sat, 02 Nov 2019 07:23:51 -0400 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id E54DF800A1E; Sat, 2 Nov 2019 11:23:49 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-108.ams2.redhat.com [10.36.116.108]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8C4935C1D4; Sat, 2 Nov 2019 11:23:47 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2 0/8] support server identity validation in HTTPS Boot (CVE-2019-14553) From: "Laszlo Ersek" To: edk2-devel-groups-io Cc: David Woodhouse , Jian J Wang , Jiaxin Wu , Sivaraman Nainar , Xiaoyu Lu Reply-To: devel@edk2.groups.io, lersek@redhat.com References: <20191026053719.10453-1-lersek@redhat.com> <968b685f-2889-ca96-b77e-45e03ebcb905@redhat.com> Message-ID: Date: Sat, 2 Nov 2019 12:23:45 +0100 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: <968b685f-2889-ca96-b77e-45e03ebcb905@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-MC-Unique: 05cxBEBsOoynKEETm2KcjQ-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable On 10/31/19 10:28, Laszlo Ersek wrote: > On 10/26/19 07:37, Laszlo Ersek wrote: >> Repo: https://github.com/lersek/edk2.git >> Branch: bz960_with_inet_pton_v2 >> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D960 >=20 >> In v2, I have inserted 4 new patches in the middle, to satisfy two >> additional requirements raised by Siva and David: >> >> - If the Subject Alternative Name in the server certificate contains an >> IP address in binary representation, and the URL specifies an IP >> address in literal form for "hostname", then both of those things >> should be compared against each other, after converting the literal >> from the URL to binary representation. In other words, a server >> certificate with an IP address SAN should be recognized. >> >> - If the URL specifies an IP address literal, then, according to >> RFC-2818, "the iPAddress subjectAltName must be present in the >> certificate and must exactly match the IP in the URI". In other words, >> if a certificate matches the IP address literal from the URL via >> Common Name only, then the certificate must be rejected. >> >> I've also fixed two commit message warts in Jiaxin's patches (see the >> Notes sections on the patches). >> >> I've tested the series painstakingly. [...] >=20 >> And here's the test matrix: >> >>> Server Certificate URL cURL edk2 unp= atched edk2 patched >>> --------------------- -------------------- ---------------- --------= -------- ---------------- >>> Common Subject hostname resolves status expected status = expected status expected >>> Name Alt. Name to IPvX >>> -----------------------------------------------------------------------= -------------------------- >>> IP-literal - IP-literal IPv4 accept COMPAT/1 accept = NO/2 reject yes >>> IP-literal - IP-literal IPv6 accept COMPAT/1 accept = NO/2 reject yes >>> IP-literal - domainname IPv4 reject yes accept = NO/2 reject yes >>> IP-literal - domainname IPv6 reject yes accept = NO/2 reject yes >>> IP-literal IP IP-literal IPv4 accept yes accept = yes accept yes >>> IP-literal IP IP-literal IPv6 accept yes accept = yes accept yes >>> IP-literal IP domainname IPv4 reject yes accept = NO/2 reject yes >>> IP-literal IP domainname IPv6 reject yes accept = NO/2 reject yes >>> domainname - IP-literal IPv4 reject yes accept = NO/2 reject yes >>> domainname - IP-literal IPv6 reject yes accept = NO/2 reject yes >>> domainname - domainname IPv4 accept yes accept = yes accept yes >>> domainname - domainname IPv6 accept yes accept = yes accept yes >>> domainname IP IP-literal IPv4 accept yes accept = yes accept yes >>> domainname IP IP-literal IPv6 accept yes accept = yes accept yes >>> domainname IP domainname IPv4 accept yes accept = yes accept yes >>> domainname IP domainname IPv6 accept yes accept = yes accept yes >>> >>> #1 -- should not be accepted: an IP literal in the URL must match the I= P >>> address in the SAN, regardless of the Common Name; but cURL accepts it >>> for compatibility >>> >>> #2 -- this is (or exemplifies) CVE-2019-14553 >=20 > Based on the feedback thus far, I'm planning to push this set on > Saturday (that is, after 1 week of list-time), or perhaps next Monday > (depends on how my Saturday will look). Pushed as commit range b15646484eaf..e2fc50812895. Thanks, Laszlo