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

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 <martin.thomson@gmail.com>wrote:

> 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.
>