Subject: http/1 opportunistic encryption

From: Stefan Eissing <[email-masked]>
Date: Tue, 16 Jun 2015 10:32:19 +0200

Reading (again) https://httpwg.github.io/http-extensions/encryption.html, some questions:

* If configuring a old-school http/1 only server for this, the Alt-Svc announcement would be:
  Alt-Svc: http/1.1=":81"
   ?

* Ch. 5.1
  "When it appears in a HTTP response from a strongly authenticated alternative service..." 
  This means the certificate is valid for the alt-svc host that can be different from the
  host in the http:// url originally requested, right?
  Example:
  GET http://test.example.org/opportunistic
  -> Alt-Svc: h2="h2.example.biz:81"
  -> GET http://test.example.org/opportunistic via TLS+h2 connection to h2.example.biz:81
  "strongly authenticated" meaning connection presents valid cert for h2.example.biz, has acceptable cipher, etc.

* Given that the example above is correct, what protocol does h2.example.biz:81 need to implement?
  Will it be something like RFC 7540, but ignoring the special security requirements for TLS? Which parts would still apply to a server implementing this?

I am asking out of interest to implement this and easing configuration, at least giving advice, for people who want to have this working on their httpd installation. 

As for testing, are there clients/canaries already implementing this?

Thanks for the help.

//Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: Patrick McManus <[email-masked]>
Date: Tue, 16 Jun 2015 08:16:04 -0400

>   host in the http:// url originally requested, right?

not in the way you mean. The point is that the alternate must authenticate
for the origin to prove itself authoritative to serve the origin's
resources. Now the actual certificate can be different (only one might be a
wildcard, for example) - but the alternate's cert must cover the origin.

>   "strongly authenticated" meaning connection presents valid cert for
> h2.example.biz, has acceptable cipher, etc.
>

it means that the cert presented by h2.example.biz:81 must be valid for
test.example.org

> h2.example.biz:81 need to implement?

h2..

>   Will it be something like RFC 7540, but ignoring the special security
> requirements for TLS? Which parts would still apply to a server
> implementing this?
>
>
all parts of 7540 section 9.2 should still apply.

hth

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 17 Jun 2015 13:15:33 +1000

> On 16 Jun 2015, at 6:32 pm, Stefan Eissing <[email-masked]> wrote:
> 

See <https://httpwg.github.io/http-extensions/encryption.html#confusion-regarding-request-scheme>; "HTTP/1.1 MUST NOT be used for opportunistically secured requests."

--
Mark Nottingham   https://www.mnot.net/

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 17 Jun 2015 10:20:31 +0200

> Am 17.06.2015 um 05:15 schrieb Mark Nottingham <[email-masked]>:
> 
>> 

Thanks for pointing me there. 

What is the scenario exactly that clients, knowledgeable of Alt-Svc, will confuse htttp: and https: URIs? With an Alt-Svc sitting at the endpoint of a TLS connection, no middle box confusion is involved. I would also assume that a server announcing such a service knows what it's doing (for example using a special port for this service). So, 6.4 does not explain to me (and maybe other readers) what the MUST NOT is about.

What did I miss?

<green/>bytes GmbH

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 17 Jun 2015 11:34:12 +0300

On Wed, Jun 17, 2015 at 10:20:31AM +0200, Stefan Eissing wrote:
> What is the scenario exactly that clients, knowledgeable of Alt-Svc,
> will confuse htttp: and https: URIs? With an Alt-Svc sitting at the
> endpoint of a TLS connection, no middle box confusion is involved.
> I would also assume that a server announcing such a service knows
> what it's doing (for example using a special port for this service).
> So, 6.4 does not explain to me (and maybe other readers) what the
> MUST NOT is about.

It is not about the clients being confused. It is about the eventual
server being confused.

Most servers perform http/https detection on HTTP/1.1 by transport,
so if one has TLS connection, those assume it is https://. And that
can't be overriden by using the authority form, even if it has
explicit protocol, so that can't be used.

-Ilari

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 17 Jun 2015 10:50:45 +0200

> Am 17.06.2015 um 10:34 schrieb Ilari Liusvaara <[email-masked]>:
> 

Well, it's the server that announces the Alt-Svc, so it has to know what it's doing - as with everything else. I agree that it seems unwise to place a service for opportunistic encryption onto port 443. I fail to see why it would be a problem to offer it at another, special port for this transport service. 

Instead, I see an opportunity for existing servers to support such a configuration without the need to support h2 first. Since for server software, main stream servers are reluctant to bring in h2 into their existing releases - understandably since it impacts their core processing engine. And even if, apart from some very skilled users, most people will have to wait for their OS maintainers to adopt it.

That is the reason why I ask: do we need to kill opportunistic encryption for HTTP/1.1 servers in general?

<green/>bytes GmbH

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Jun 2015 09:25:50 -0700

On 17 June 2015 at 01:50, Stefan Eissing <[email-masked]> wrote:
> Well, it's the server that announces the Alt-Svc, so it has to know what it's doing - as with everything else. I

The concern is that it might not be the server that provided the
announcement.  It could have been a rogue resource that set a header
field, or a MitM.  One attack of concern is where the server releases
a secure cookie into an insecure context.

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 18 Jun 2015 10:26:06 +0200

So, basically the trick would be to have a client call http: into a https: port, server sets cookie, client later reopens connection against http: and sends cookie in the clear. And with h2, the server can detect that http: was requested, and avoid setting the secure cookie.

Ok, thanks for the explanation.

I think, as a consequence, I need to disable the Alt-Svc support for http: in mod_h2, since scheme information is not available to others living inside Apache httpd and the described http/1.1 exploit will work exactly the same with h2 involved. I think some

Feedback to the spec itself, ch. 6.4:
The confusion about the request scheme in real life servers has seldom anything to do with the protocol being served. "h2" and "http/1.1" requests will be, from an application point of view, be indistinguishable, especially for all of the existing web. Servers will add "h2" support in the most compatible way and that means taking care that existing applications continue to run.

Saying that the scheme confusion has anything to do with h1 vs h2, is not giving the complete picture. Admins who advertise h2 as Alt-Svc for http: resources might feel safe when indeed they are not.

And the advice for server implementations would then be to make sure that the TLSiness of the connection gets hidden from any application that processes such requests, regardless of the http version used. And additionally, that using port 443 for such a transport is not a good idea, because apps might use that as an indicators of httpsiness as well.

> Am 17.06.2015 um 18:25 schrieb Martin Thomson <[email-masked]>:
> 

<green/>bytes GmbH

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 18 Jun 2015 10:58:48 +0200

> Am 18.06.2015 um 10:26 schrieb Stefan Eissing <[email-masked]>:
> 

Correction to my last paragraph: the transport port number needs to be hidden as well and, at least with h1, 443 should not be used.

<green/>bytes GmbH

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Jun 2015 10:06:47 -0700

On 18 June 2015 at 01:26, Stefan Eissing <[email-masked]> wrote:
> I think, as a consequence, I need to disable the Alt-Svc support for http: in mod_h2, since scheme information is not available to others living inside Apache httpd and the described http/1.1 exploit will work exactly the same with h2 involved.

It depends on how Apache reports things as being "https" or not.  If
you can avoid generating those signals or suppress them, then it
should be OK.

We can certainly improve the text.  Here's what I have:

Some HTTP/1.1 implementations use ambient signals to determine if a
request is for an `https`
resource.  For example, implementations might look for TLS on the
stack or a port number of 443.
An implementation that supports opportunistically secured requests
SHOULD suppress these signals if
there is any potential for confusion.