Subject: Alt-Svc related Chromium bug report (proxy related)

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 31 Mar 2014 16:52:38 -0700

I think I mentioned this to Mark offhand before, but I'm emailing the wider
list to inform more people in case it deserves a design consideration in
Alt-Svc or some informative text. We encountered some issues with
Alternate-Protocol that were nasty.

https://code.google.com/p/chromium/issues/detail?id=288992

There are a few issues here:
* The origin server is advertising Alt-Svc where the port matches the port
it's delivering the response on. This is because it was added via the nginx
add_header directive without discriminating on the specific service (http
vs https). This is arguably benign since the origin server supports SPDY
(HTTP/2) anyway, so whatevs.
* But the proxy server (a CDN) doesn't support SPDY (HTTP/2) yet. But it
doesn't understand Alt-Svc, so it passes it onward. But a subsequent
attempt to use the alternate service fails since it advertises the
requirement for SPDY (HTTP/2), which the CDN doesn't support. This
currently translates to a user-visible error, with a fallback in the
browser to ignoring the Alt-Svc directive on subsequent loads. Arguably, we
should transparently do the fallback and only show an error if that
fallback fails too. Of course, requiring a fallback like this is a
downgrade attack if you want the extra security of a more secure protocol
on that alternate service, but that's already the case in many parts of the
Alt-Svc proposal, so no new "harm" there.
* But the Chromium code for ignoring the Alt-Svc directive only added an
in-memory decision to ignore it. So if you restart the browser, we read the
persistent (Alternate-Protocol has no cache directive like Alt-Svc does),
and hit the same error condition again. That's simply a bug that we need to
fix.

Anyway, for the folks pushing on Alt-Svc, it's something to keep in mind.
Cheers.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Mar 2014 17:16:29 -0700

Thanks for raising this Will.

Alt-Svc includes the following text, which is something I suspect that
Chromium will want to do:

   The client is not required to block requests; the origin's connection
   can be used until the alternative connection is established.
   However, if the security properties of the existing connection are
   weak (e.g. cleartext HTTP/1.1) then it might make sense to block
   until the new connection is fully available in order to avoid
   information leakage.

I think that we should make it clear that an intermediary could pass
on a bad value.

If it weren't for the fact that we've basically removed the Connection
header field in HTTP/2, I'd be suggesting that we add Alt-Svc there.
That would (should) have fixed the issue.

On 31 March 2014 16:52, William Chan (陈智昌) <[email-masked]> wrote:
> add_header directive without discriminating on the specific service (http vs
> https). This is arguably benign since the origin server supports SPDY
> doesn't understand Alt-Svc, so it passes it onward. But a subsequent attempt
> to use the alternate service fails since it advertises the requirement for
> SPDY (HTTP/2), which the CDN doesn't support. This currently translates to a
> user-visible error, with a fallback in the browser to ignoring the Alt-Svc
> directive on subsequent loads. Arguably, we should transparently do the
> fallback and only show an error if that fallback fails too. Of course,
> requiring a fallback like this is a downgrade attack if you want the extra
> security of a more secure protocol on that alternate service, but that's
> already the case in many parts of the Alt-Svc proposal, so no new "harm"
> there.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 31 Mar 2014 17:21:59 -0700

Oops, I wasn't clear about our implementation. It's a code confusion. When
I originally wrote the logic, I did not think of the possibility of someone
mis-advertising like this. We do indeed support fallback when they are
actually two separate HTTP transactions/connections. But when the Alt-Svc
basically says to come back to the same port, but effectively restricts the
protocol allowed for that connection, the fallback logic didn't work and we
showed a user visible error. Just a bug. Part of this is definitely an FYI
for other implementers. "Oh hey, some of those silly server people send
confused headers. Code defensively here." I didn't code for this edge case
in the original implementation.

On Mon, Mar 31, 2014 at 5:16 PM, Martin Thomson <[email-masked]>wrote:

> attempt

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 01 Apr 2014 16:08:26 +1300

On 2014-04-01 13:21, William Chan wrote:
> mis-advertising like this.

This is not "mis-advertising". The origin server producing the response 
eminently *does* support that service.

I then draw your attention to draft-ietf-httpbis-alt-svc-00 section 3...

  " Intermediaries MUST NOT change or append Alt-Svc values. "

There is no distinction regarding intermediary type(s), nor exemption 
clauses. CDN is an intermediary just as much as any other.

> We do indeed support fallback when they are

Regardless of the sillyness there is nothing wrong with that server, nor 
its header advertisement. The mechanism itself has been designed to do 
this as currently written.

There are parts of the HTTP/2 specification which contain(ed) similar 
gems inherited from SPDY.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Mar 2014 20:51:36 -0700

> clauses. CDN is an intermediary just as much as any other.

That would be fine, except for the fact that - in this case - it seems
likely that the CDN is acting as an origin server that serves a copy
of the content, not an intermediary.  The URI includes the domain name
of the CDN.  Will, amirite?

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 31 Mar 2014 21:58:57 -0700

> of the CDN.  Will, amirite?
Correct.