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

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 (陈智昌) <willchan@chromium.org> wrote:
> 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.

Received on Tuesday, 1 April 2014 00:16:57 UTC