From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web10.3645.1572514133720157725 for ; Thu, 31 Oct 2019 02:28:53 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=C9P00hAO; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572514132; 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=29yOJoVlvFh9EuB9+sgV7ztTApZAbyoWIhtK0A3esUw=; b=C9P00hAOBkPFM56HC7vQXs/erJmBGJovndjB2B7ElfGbqyMrw8biWHdyyorKFS5sh1ZCrK bPA5saE01/0ACz5+73OJVvIq4niL8xh0IO77AbXZcrHFwbDu0Nt9eFfEW4x+42SVavTIWH ILaZ9RWPTT5X/b4d/bhzUC+vQAvezZ4= 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-147-0AlQFUKBNSeMqb9j2KpMfQ-1; Thu, 31 Oct 2019 05:28:49 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8CDE62EDD; Thu, 31 Oct 2019 09:28:48 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-6.ams2.redhat.com [10.36.117.6]) by smtp.corp.redhat.com (Postfix) with ESMTP id 05EDD600CE; Thu, 31 Oct 2019 09:28:46 +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> Message-ID: <968b685f-2889-ca96-b77e-45e03ebcb905@redhat.com> Date: Thu, 31 Oct 2019 10:28:46 +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: <20191026053719.10453-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: 0AlQFUKBNSeMqb9j2KpMfQ-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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 > In v2, I have inserted 4 new patches in the middle, to satisfy two > additional requirements raised by Siva and David: >=20 > - 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. >=20 > - 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. >=20 > I've also fixed two commit message warts in Jiaxin's patches (see the > Notes sections on the patches). >=20 > I've tested the series painstakingly. [...] > And here's the test matrix: >=20 >> Server Certificate URL cURL edk2 unpa= tched edk2 patched >> --------------------- -------------------- ---------------- ---------= ------- ---------------- >> Common Subject hostname resolves status expected status e= xpected status expected >> Name Alt. Name to IPvX >> ------------------------------------------------------------------------= ------------------------- >> IP-literal - IP-literal IPv4 accept COMPAT/1 accept N= O/2 reject yes >> IP-literal - IP-literal IPv6 accept COMPAT/1 accept N= O/2 reject yes >> IP-literal - domainname IPv4 reject yes accept N= O/2 reject yes >> IP-literal - domainname IPv6 reject yes accept N= O/2 reject yes >> IP-literal IP IP-literal IPv4 accept yes accept y= es accept yes >> IP-literal IP IP-literal IPv6 accept yes accept y= es accept yes >> IP-literal IP domainname IPv4 reject yes accept N= O/2 reject yes >> IP-literal IP domainname IPv6 reject yes accept N= O/2 reject yes >> domainname - IP-literal IPv4 reject yes accept N= O/2 reject yes >> domainname - IP-literal IPv6 reject yes accept N= O/2 reject yes >> domainname - domainname IPv4 accept yes accept y= es accept yes >> domainname - domainname IPv6 accept yes accept y= es accept yes >> domainname IP IP-literal IPv4 accept yes accept y= es accept yes >> domainname IP IP-literal IPv6 accept yes accept y= es accept yes >> domainname IP domainname IPv4 accept yes accept y= es accept yes >> domainname IP domainname IPv6 accept yes accept y= es accept yes >> >> #1 -- should not be accepted: an IP literal in the URL must match the IP >> address in the SAN, regardless of the Common Name; but cURL accepts it >> for compatibility >> >> #2 -- this is (or exemplifies) CVE-2019-14553 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). Thanks! Laszlo