Subject: Re: [http-extensions] alt-svc vs the ability to convey the scheme inside the protocol (#92)

From: HTTP issue updates <[email-masked]>
Date: Sun, 15 Nov 2015 16:55:00 -0800

Straw-man proposal:

✂︎

Some server-side HTTP applications make assumptions about security based upon connection context; for example, equating being served upon port 443 with the use of a HTTPS URL (and the various security properties that implies).

This affects not only the security properties of the connection itself, but also the state of the client at the other end of it; for example, a Web browser treats HTTPS URLs differently than HTTP URLs in many ways, not just for purposes of protocol handling.

Since one of the uses of Alternative Services is to allow a connection to be migrated to a different protocol and port, these applications can become confused about the security properties of a given connection, sending information (e.g., cookies, content) that is intended for a secure context (e.g., a HTTPS URL) to a client that is not treating it as one.

This risk can be mitigated in servers by using the URL scheme explicitly carried by the protocol (e.g., ":scheme" in HTTP/2) as an indication of security context, instead of other connection properties. When the protocol does not explicitly carry the scheme (e.g., as is usually the case for HTTP/1.1 over TLS), servers can mitigate this risk by either assuming that all requests have an insecure context, or by refraining from advertising alternative services for insecure schemes (such as HTTP).

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/92#issuecomment-156880299

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 16 Nov 2015 01:09:47 -0800

Good enough for me. How exactly scheme needs to be visible and how connection details need to be hidden is beyond the scope of the spec anyway.

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/92#issuecomment-156961248

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 16 Nov 2015 04:17:27 -0800

Sounds good. @martinthomson does this work for you?

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/92#issuecomment-157011024

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 17 Nov 2015 00:32:16 -0800

9.5.  Confusion Regarding Request Scheme

   Some server-side HTTP applications make assumptions about security
   based upon connection context; for example, equating being served
   upon port 443 with the use of a HTTPS URL (and the various security
   properties that implies).

   This affects not only the security properties of the connection
   itself, but also the state of the client at the other end of it; for
   example, a Web browser treats HTTPS URLs differently than HTTP URLs
   in many ways, not just for purposes of protocol handling.

   Since one of the uses of Alternative Services is to allow a
   connection to be migrated to a different protocol and port, these
   applications can become confused about the security properties of a
   given connection, sending information (e.g., cookies, content) that
   is intended for a secure context (e.g., a HTTPS URL) to a client that
   is not treating it as one.

   This risk can be mitigated in servers by using the URL scheme
   explicitly carried by the protocol (e.g., ":scheme" in HTTP/2 or the
   "absolute form" of the request URI in HTTP/1.1) as an indication of
   security context, instead of other connection properties ([RFC7540],
   Section 8.1.2.3 and [RFC7230], Section 5.3.2).

   When the protocol does not explicitly carry the scheme (e.g., as is
   usually the case for HTTP/1.1 over TLS, servers can, mitigate this
   risk by either assuming that all requests have an insecure context,
   or by refraining from advertising alternative services for insecure
   schemes (such as HTTP).

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/92#issuecomment-157308154

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 19 Nov 2015 07:00:32 -0800

In the list of server mitigations we likely want to also include:

  "or return (421 Not Authoritative?) for insecure scheme requests
  received over TLS".

Neither of the other proposed mechanisms protect existing
secure applications/servers that assume that port-443/TLS
traffic is "secure".  Since the "advertising alternative services
for insecure schemes" would be done over an insecure channel,
simply refraining doesn't mitigate attacks if there is an application
vulnerability due to existing assumptions.

On Tue, Nov 17, 2015 at 3:32 AM, Julian Reschke <[email-masked]>
wrote:

> —
> Reply to this email directly or view it on GitHub
> <https://github.com/httpwg/http-extensions/issues/92#issuecomment-157308154>
> .
>

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/92#issuecomment-158082099