- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 19 Oct 2010 11:21:44 +1100
- To: Eric J. Bowman <eric@bisonsystems.net>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Maciej Stachowiak <mjs@apple.com>, Adam Barth <w3c@adambarth.com>, "William Chan (ιζΊζ)" <willchan@chromium.org>, "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
The attack is also on intermediaries, which don't evolve as fast as browsers. By causing a hard error in the UAs, your'e reducing the effectiveness of the cache poisoning attack as well. Regards, On 18/10/2010, at 4:31 PM, Eric J. Bowman wrote: > OK, that's definitely a browser vulnerability if the first C-L is used. > But how is this *still* a vulnerability under the current wording? In > the presence of multiple C-L headers, if length is determined by reading > until connection close, then no splitting occurs. > > -Eric > > Mark Nottingham wrote: >> >> http://www.securiteam.com/securityreviews/5CP0L0AHPC.html >> >> Technique #2. >> >> >> On 18/10/2010, at 4:00 PM, Eric J. Bowman wrote: >> >>> Mark Nottingham wrote: >>>> >>>>> We can't simply break formerly-conforming implementations. >>>> >>>> We can if it's a security issue. >>>> >>> >>> The security issue in question is "HTTP request smuggling" which is >>> an attack vector which always takes the form of a malicious request >>> from a user-agent. All it is the other way around, is a broken >>> server putting itself at risk. There's no justification for a MUST >>> even if there is consensus for it. >>> >>> I thought the consensus the WG was after, was whether or not to >>> discard all but the first C-L or the last C-L. The current >>> proposed language says read to connection close, instead. This >>> makes loads of sense to me, instead of MUST fail hard based on what >>> concern, exactly? >>> >>> -Eric >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 19 October 2010 00:22:18 UTC