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

On 2014-04-01 13:21, William Chan wrote:
> 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.

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

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

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

Received on Tuesday, 1 April 2014 03:08:56 UTC