public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>,
	"Wu, Jiaxin" <jiaxin.wu@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>,
	"Wang, Jian J" <jian.j.wang@intel.com>,
	Richard Levitte <levitte@openssl.org>,
	Sivaraman Nainar <sivaramann@amiindia.co.in>
Subject: Re: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses
Date: Wed, 16 Oct 2019 13:41:20 +0200	[thread overview]
Message-ID: <f89ddc3b-cbc8-01f7-f419-0984ad168dfb@redhat.com> (raw)
In-Reply-To: <139da0c5a4684b76809fa19acc007f4699e3eb28.camel@infradead.org>

On 10/16/19 11:19, David Woodhouse wrote:
> On Wed, 2019-10-16 at 09:36 +0200, Laszlo Ersek wrote:
>> On 10/16/19 07:18, Wu, Jiaxin wrote:
>>>    In some cases, the URI is specified as an IP address rather than
>>>    a Hostname .  In this case, the iPAddress subjectAltName must be
>>>    present in the certificate and must exactly match the IP in the
>>>    URI.
>>
>> Wow!
>>
>> This seems to prove David right, and it suggests that symptom (2)
>> encountered with my patch is actually *valid* behavior -- the
>> certificate I generated with "genkey" is *not* valid for a URI that
>> specifies an IP address!
>>
>> This is not good news: the "curl" utility also accepts such a
>> certificate as valid (IP address in URL, but the certificate only
>> contains a CN,  matching the IP address in textual form). Is that a
>> bug in "curl" then?
>
> Yes, I believe so.
> Please report it at https://github.com/curl/curl/issues

<https://github.com/curl/curl/issues/new> directs me to
<https://hackerone.com/curl>, for security-related issues, so I've now
registered on that site, and started writing up a report.

However. When I wanted to include a reference to RFC6125, I looked more
closely at the section that Jiaxin quoted. More specifically, the
surroundings of that section.

It turns out that the quoted section "3.1. Server Identity" is actually
part of Appendix B.2 ("HTTP (2000)"):

  https://tools.ietf.org/html/rfc6125#appendix-B.2

which is further part of Appendix B ("Prior Art"):

  https://tools.ietf.org/html/rfc6125#appendix-B

Appendix B starts with the statement

> (This section is non-normative.)

and Appendix B.2 starts with

>    In 2000, [HTTP-TLS] specified the following text regarding
>    application service identity verification in HTTP:

Thus, Appendix B of RFC6125 doesn't require us to do anything! (Other
specs may still require us, of course.)

Now, does RFC6125 say anything about IP addresses? Yes, it does, in
section 1.7.2, "Out of Scope":

https://tools.ietf.org/html/rfc6125#section-1.7.2

>    o  Identifiers other than fully qualified DNS domain names.
>
>       Some certification authorities issue server certificates based on
>       IP addresses, but preliminary evidence indicates that such
>       certificates are a very small percentage (less than 1%) of issued
>       certificates.  Furthermore, IP addresses are not necessarily
>       reliable identifiers for application services because of the
>       existence of private internets [PRIVATE], host mobility, multiple
>       interfaces on a given host, Network Address Translators (NATs)
>       resulting in different addresses for a host from different
>       locations on the network, the practice of grouping many hosts
>       together behind a single IP address, etc.  Most fundamentally,
>       most users find DNS domain names much easier to work with than IP
>       addresses, which is why the domain name system was designed in the
>       first place.  We prefer to define best practices for the much more
>       common use case and not to complicate the rules in this
>       specification.
>
>       Furthermore, we focus here on application service identities, not
>       specific resources located at such services.  Therefore this
>       document discusses Uniform Resource Identifiers [URI] only as a
>       way to communicate a DNS domain name (via the URI "host" component
>       or its equivalent), not as a way to communicate other aspects of a
>       service such as a specific resource (via the URI "path" component)
>       or parameters (via the URI "query" component).
>
>       We also do not discuss attributes unrelated to DNS domain names,
>       such as those defined in [X.520] and other such specifications
>       (e.g., organizational attributes, geographical attributes, company
>       logos, and the like).

So... I think we can (and should) proceed just the same, but we should
reference:

  https://tools.ietf.org/html/rfc2818#section-3.1

rather than RFC6125.

Accordingly, I've filed the curl report with reference to RFC-2818:

  https://hackerone.com/reports/715413

[...]

On 10/16/19 11:19, David Woodhouse wrote:
> So what did we say about false modesty, Laszlo?

It *was* hard; and in the first place, I truly hadn't expected myself to
send an edk2 RFC, at all... It was made possible by your code.

> In the end you did actually solve it all for yourself -- based on the
> pointer I'd given in bugzilla, and then ignoring my subsequent
> misdirection about callbacks and my overly complex attempt at doing it
> myself :)

You're too kind; I followed your code closely. I only updated the coding
style, added a bunch of comments, and supplied some error checks and
debug messages. In addition, Jiaxin suggested we should try to set the
smart verification params in TlsSetVerifyHost() at once.

Anyway: we still have the issue that X509_VERIFY_PARAM_set_ip_asc()
appears to reject IPv4 address literals. Could you check that please?

(Using a hosted (Linux userspace) program like "sconnect", it must be
easier to debug. I tried connecting gdb to QEMU, running OVMF, but it
crashed gdb. :)

I also looked at the OpenSSL code parsing the IPv4 literal, and nothing
struck me as obviously wrong. (Well, sscanf() is generally improper for
parsing untrusted data, but that's beside the point, for my test case
with a valid IPv4 literal.))

Thanks!
Laszlo

  reply	other threads:[~2019-10-16 11:41 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-27  3:44 [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553) Wu, Jiaxin
2019-09-27  3:44 ` [PATCH v1 1/4] MdePkg/Include/Protocol/Tls.h: Add the data type of EfiTlsVerifyHost(CVE-2019-14553) Wu, Jiaxin
2019-09-27  3:44 ` [PATCH v1 2/4] CryptoPkg/TlsLib: Add the new API "TlsSetVerifyHost"(CVE-2019-14553) Wu, Jiaxin
2019-09-27  3:44 ` [PATCH v1 3/4] NetworkPkg/TlsDxe: Add the support of host validation to TlsDxe driver(CVE-2019-14553) Wu, Jiaxin
2019-09-27  3:44 ` [PATCH v1 4/4] NetworkPkg/HttpDxe: Set the HostName for the verification(CVE-2019-14553) Wu, Jiaxin
2019-09-29  6:09 ` [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553) Wang, Jian J
2019-09-30 23:21   ` Laszlo Ersek
2019-10-01  9:02     ` David Woodhouse
2019-10-08  6:19       ` Wu, Jiaxin
2019-10-09  7:53         ` David Woodhouse
2019-10-09 20:24           ` Laszlo Ersek
2019-10-09 20:34             ` David Woodhouse
2019-10-10  3:11               ` Wu, Jiaxin
2019-10-10  8:00               ` Laszlo Ersek
2019-10-10 15:45                 ` David Woodhouse
2019-10-10 18:03                   ` Laszlo Ersek
2019-10-11  2:24                     ` Wu, Jiaxin
2019-10-11  6:58                       ` David Woodhouse
2019-10-11  8:04                         ` Wu, Jiaxin
2019-10-11 10:55                       ` Laszlo Ersek
2019-10-11 11:16                         ` David Woodhouse
2019-10-11 15:36                           ` Laszlo Ersek
2019-10-11 16:01                             ` David Woodhouse
2019-10-14 16:15                               ` Laszlo Ersek
2019-10-14 16:20                                 ` Laszlo Ersek
2019-10-14 16:53                                 ` David Woodhouse
2019-10-15 11:03                                 ` David Woodhouse
2019-10-15 11:06                                   ` David Woodhouse
2019-10-15 13:54                                   ` Laszlo Ersek
2019-10-15 15:29                                     ` David Woodhouse
2019-10-15 16:56                                     ` Laszlo Ersek
2019-10-15 17:34                                       ` Laszlo Ersek
2019-10-16  9:40                                         ` David Woodhouse
2019-10-16 10:27                                           ` Laszlo Ersek
2019-10-15 15:57                     ` David Woodhouse
2019-10-15 17:28                       ` Laszlo Ersek
2019-10-10  2:45           ` Wu, Jiaxin
2019-10-09 15:54     ` Laszlo Ersek
2019-10-10  2:46       ` Wu, Jiaxin
2019-10-15 23:08 ` [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses Laszlo Ersek
2019-10-16  5:18   ` [edk2-devel] " Wu, Jiaxin
2019-10-16  7:36     ` Laszlo Ersek
2019-10-16  7:54       ` Laszlo Ersek
2019-10-16  7:56         ` David Woodhouse
2019-10-16  8:08       ` Laszlo Ersek
2019-10-16  9:19       ` David Woodhouse
2019-10-16 11:41         ` Laszlo Ersek [this message]
2019-10-16 13:35           ` David Woodhouse
2019-10-16 14:43             ` Laszlo Ersek
2019-10-16 15:25               ` David Woodhouse
2019-10-17 15:35                 ` Laszlo Ersek
2019-10-17 15:49                   ` David Woodhouse
2019-10-18 13:25                     ` Laszlo Ersek
2019-10-25  2:12                       ` Wu, Jiaxin
2019-10-25  8:14                         ` Laszlo Ersek
2019-10-24 19:47                     ` Laszlo Ersek
2019-10-25  2:13                       ` Wu, Jiaxin
2019-10-25  2:12               ` Wu, Jiaxin
2019-10-25  2:12           ` Wu, Jiaxin
2019-10-16  8:45     ` David Woodhouse
2019-10-16 11:01   ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f89ddc3b-cbc8-01f7-f419-0984ad168dfb@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox