From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from IMSVA.IN.MEGATRENDS.COM (IMSVA.IN.MEGATRENDS.COM [14.98.235.2]) by mx.groups.io with SMTP id smtpd.web12.7825.1583474825656787419 for ; Thu, 05 Mar 2020 22:07:06 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=SPF record not found (domain: amiindia.co.in, ip: 14.98.235.2, mailfrom: sivaramann@amiindia.co.in) Received: from IMSVA.IN.MEGATRENDS.COM (IMSVA.IN.MEGATRENDS.COM [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5E3C682047; Fri, 6 Mar 2020 11:44:51 +0530 (IST) Received: from IMSVA.IN.MEGATRENDS.COM (IMSVA.IN.MEGATRENDS.COM [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2A21682046; Fri, 6 Mar 2020 11:44:50 +0530 (IST) Received: from webmail.amiindia.co.in (venus2.in.megatrends.com [10.0.0.7]) by IMSVA.IN.MEGATRENDS.COM (Postfix) with ESMTPS; Fri, 6 Mar 2020 11:44:50 +0530 (IST) Received: from VENUS1.in.megatrends.com ([fe80::951:7975:6ecf:eae5]) by Venus2.in.megatrends.com ([fe80::2002:4a07:4f17:c09b%14]) with mapi id 14.03.0248.002; Fri, 6 Mar 2020 11:35:55 +0530 From: "Sivaraman Nainar" To: "To:" , "Wu, Jiaxin" , "Fu, Siyuan" CC: "Madhan B. Santharam" , "Arun Subramanian B" , Bhuvaneshwari M R , Ramesh R. , Srini Narayana Subject: reg: Host Name Validation with Wild Card Certificate Thread-Topic: reg: Host Name Validation with Wild Card Certificate Thread-Index: AdXze9fi9m5g3RwrTAW35AjbpsuUsQ== Date: Fri, 6 Mar 2020 06:07:07 +0000 Message-ID: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.226] MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.1817-8.5.0.1020-25272.005 X-TM-AS-Result: No--15.171-5.0-31-10 X-imss-scan-details: No--15.171-5.0-31-10 X-TMASE-Version: IMSVA-9.1.0.1817-8.5.1020-25272.005 X-TMASE-Result: 10--15.171100-10.000000 X-TMASE-MatchedRID: zndDlPK4YUpYukXu/bAZ07BZAi3nrnzb4oSd18bdmwJpsnGGIgWMmb67 LxTidyGBrjyUl8kKQtz2Jzq6yZuBqZC0Ht7h6sHdqg0gbtLVIa+jXi/7W48JB8AkyHiYDAQb1Is 5GvhmGbw2ZvhXd39zJnyC5eu2BgKmiJx4642cvJb9KXlxhBAZb5hwKdlCfPk8StFk/81wIJKQM2 zg4yhfEpqEb+LwlrVjt1gVV8hFpdLvOC1QV7aBzlnAtIGDGCFo+eBf9ovw8I0j0vSXSt1uP24GP EMJeKPOJFfll7wWwfAB/+giEOsxzFy8LiE9LxheIj0zFI5DoJLAtpDNMLs81qTsE8Z/jrr+IUEc OllE7cOlFYL0oNKxPHCVOA5OEjiE0b0gTJDrX6wOsNNBnlgRWn0tCKdnhB58r10pknZXGJrPPeN 6HN6d7FdeyAYu6Pty33fj+sMArfOEbaqKQSlAZQ1WvgFAFWqR1jx0Zy08DVbKfk3zP2qdB2aVdZ aSxZ65puaxAHVA3oc= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_B4DE137BDB63634BAC03BD9DE765F197029AE9C609VENUS1inmegat_" --_000_B4DE137BDB63634BAC03BD9DE765F197029AE9C609VENUS1inmegat_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all: Need a clarification on the Host Name support added in the HTTP Boot. When certificates are generated with the Wild Card in the SAN the host nam= e validation is getting failed with the below error codes. Ex: DNS Name=3D*.ami.internal-test.com TlsDoHandshake SSL_HANDSHAKE_ERROR State=3D0x4 SSL_ERROR_SSL TlsDoHandshake ERROR 0x1416F086=3DL14:F16F:R86 Http Request failed. Code=3DAborted If the Host verify flag is changed from HttpInstance->TlsConfigData.VerifyHost.Flags =3D EFI_TLS_VERIFY_FLAG_NO_= WILDCARDS; To HttpInstance->TlsConfigData.VerifyHost.Flags =3D EFI_TLS_VERIFY_FLAG_NO= NE; Then the Http request can pass. Is the host Name support strictly not allowing Wild card support? In this c= ase do we need to have multiple Certiricate to have each URL with exact Hos= t Name? Thanks Siva --_000_B4DE137BDB63634BAC03BD9DE765F197029AE9C609VENUS1inmegat_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all:

 

Need a clarification on the Host Name support added = in the HTTP Boot.

 

When certificates are generated with the Wild Card i= n the SAN  the host name validation is getting failed with the below e= rror codes.

Ex: DNS Name=3D*.ami.internal-test.com

 

TlsDoHandshake SSL_HANDSHAKE_ERROR State=3D0x4 SSL_ERROR_S= SL

TlsDoHandshake ERROR 0x1416F086=3DL14:F16F:R86<= /span>

Http Request failed. Code=3DAborted

 

If th= e Host verify flag is changed from

HttpInstance->TlsConfigData.VerifyHost.Flags    =3D&= nbsp;EFI_TLS_VERIFY_FLAG_NO_WILDCARDS;

To

HttpInstance->TlsConfigData.VerifyHost.Flags    =3D&= nbsp; EFI_TLS_VERIFY_FLAG_NONE;

=  

Then = the Http request can pass.

 

Is the host Name support strictly not allowing Wild = card support? In this case do we need to have multiple Certiricate to have = each URL with exact Host Name?

 

Thanks

Siva

--_000_B4DE137BDB63634BAC03BD9DE765F197029AE9C609VENUS1inmegat_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] reg: Host Name Validation with Wild Card Certificate To: Sivaraman Nainar ,devel@edk2.groups.io From: "Sean" X-Originating-Location: Redmond, Washington, US (50.35.74.15) X-Originating-Platform: Windows Chrome 82 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Sat, 07 Mar 2020 14:40:50 -0800 References: In-Reply-To: Message-ID: <10736.1583620850271595025@groups.io> Content-Type: multipart/alternative; boundary="8xW7iIUJvn2TTsIZsQBT" --8xW7iIUJvn2TTsIZsQBT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The name of this flag is terrible but if you read the 2.8 spec. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf page 1436. Says: EFI_TLS_VERIFY_FLAG_NONE means no additional flags set for hostname valida= tion. Wildcards are supported and they match only in the left-most label. In the HttpDxe driver we made a change to support wildcards as wildcards a= re pretty commonly used in web services. https://github.com/microsoft/mu_basecore/commit/931ff1a45ce13a6a8c3e296f89= c6de21f23a17ed#diff-45ead71899abef9932d2697dbd1d8867 There is a lot of noise on this thread but its the best i can find. https://bugzilla.tianocore.org/show_bug.cgi?id=3D960 We might need to open a new bugzilla as i think 960 is resolved but is too= strict for practical usage. Thanks Sean --8xW7iIUJvn2TTsIZsQBT Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable The name of this flag is terrible but if you read the 2.8 spec.  =
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_= 8_A_Feb14.pdf
page 1436.  
Says: 
EFI_TLS= _VERIFY_FLAG_NONE means no additional flags set for hostname validation. Wi= ldcards are supported and they match only in the left-most label.

In the HttpDxe driver we made a change to support wildcards as wildcards = are pretty commonly used in web services. 
https://github.com/microsoft/mu_b= asecore/commit/931ff1a45ce13a6a8c3e296f89c6de21f23a17ed#diff-45ead71899abef= 9932d2697dbd1d8867

There is a lot of noise on this thread bu= t its the best i can find. 
https://bugzilla.tianocore.org/show_bug.cgi?id= =3D960

We might need to open a new bugzilla as i think 960 = is resolved but is too strict for practical usage. 

Thanks<= br />Sean
--8xW7iIUJvn2TTsIZsQBT-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web11.30526.1583657709043367847 for ; Sun, 08 Mar 2020 00:55:09 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RXKhlYDL; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583657708; h=from:from: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=LoyXhSOMMCa+H9rDSmQt7WWKNyLSwqaaQgg0sesEafc=; b=RXKhlYDLwiUAZZ8DUd1/fbeqh480rpAlWH5G8L7Xgwy6Wd1PB7gGBFmcADJtt2zGNXFXY1 zjb+CiDSBm1uFK8ozDZNAkmhz5+HlZnIAhXjfIaHfT3lUkjXXXTj/9dibkMFOoURqbqj1l ZyST3npBdllNcjhVjHwycHINRmNP3aQ= 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-339-H8bMR4XWNYK5v7jlgVIbKQ-1; Sun, 08 Mar 2020 04:54:59 -0400 X-MC-Unique: H8bMR4XWNYK5v7jlgVIbKQ-1 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 B02651005509; Sun, 8 Mar 2020 08:54:57 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-62.ams2.redhat.com [10.36.116.62]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8E7375C545; Sun, 8 Mar 2020 08:54:56 +0000 (UTC) Subject: Re: [edk2-devel] reg: Host Name Validation with Wild Card Certificate To: sean.brogan@microsoft.com References: <10736.1583620850271595025@groups.io> Cc: devel@edk2.groups.io, Sivaraman Nainar , Jeremiah Cox From: "Laszlo Ersek" Message-ID: <1181cf99-0752-3114-1ea3-54dd462fd5be@redhat.com> Date: Sun, 8 Mar 2020 09:54:55 +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: <10736.1583620850271595025@groups.io> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/07/20 23:40, Sean via Groups.Io wrote: > The name of this flag is terrible but if you read the 2.8 spec. > https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf > page 1436. > Says: > EFI_TLS_VERIFY_FLAG_NONE means no additional flags set for hostname validation. Wildcards are supported and they match only in the left-most label. > > In the HttpDxe driver we made a change to support wildcards as wildcards are pretty commonly used in web services. > https://github.com/microsoft/mu_basecore/commit/931ff1a45ce13a6a8c3e296f89c6de21f23a17ed#diff-45ead71899abef9932d2697dbd1d8867 > > There is a lot of noise on this thread but its the best i can find. > https://bugzilla.tianocore.org/show_bug.cgi?id=960 > > We might need to open a new bugzilla as i think 960 is resolved but is too strict for practical usage. Yes, please open a new Bugzilla ticket for investigating EFI_TLS_VERIFY_FLAG_NO_WILDCARDS vs. EFI_TLS_VERIFY_FLAG_NONE. Thanks! Laszlo