Re: [hybi] workability (or otherwise) of HTTP upgrade

On Sat, 4 Dec 2010 2:50 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:
> So in the POST experiment, the bytes are
>
>     POST /path/of/attackers/choice HTTP/1.1
>     Host: host-of-attackers-choice.com
>     Sec-WebSocket-Key: <connection-key>
>
>     GET /script.php/<random> HTTP/1.1
>     Host: target.com
>
> In 1376 cases the 2nd request was routed to target.com, presumably
> because some interceptors parsed it as an HTTP request, and routed it
> based on Host.
>
> In the Upgrade experiment, the bytes are
>
>     GET /path/of/attackers/choice HTTP/1.1
>     Host: host-of-attackers-choice.com
>     Connection: Upgrade
>     Sec-WebSocket-Key: <connection-key>
>     Upgrade: WebSocket
>
>     GET /script.php/<random> HTTP/1.1
>     Host: target.com
>
> In only 1 case the 2nd request was routed to target.com. This
> experiment is apparently done in the same ad display as the POST
> experiment, and the bytes passed over same intermediaries.
>
> Don't you find that odd? How do you explain the difference?

My interpretation is that most (but not all) of the proxies that route
requests by Host header decided not to parse the 2nd request as an
HTTP request, because they observed an HTTP Upgrade negotiation in the
first request.

On Sat, 4 Dec 2010 at 3:39 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:
> From paper: "47,741 (96:9%) reported that no intermediaries were
> confused when sending the spoofed HTTP request"
>
> What's the expected behavior here? The 2nd request is transmitted to
> host-of-attackers-choice.com verbatim, right?
>
> "There were 97 of 49;218 impressions (0:2%) where the spoofed request
> was routed by IP"
>
> The 2nd request is also transmitted to host-of-attackers-choice.com
> verbatim, right? How does this differ from the 1st case?

The 2nd request was received by the server on a separate network connection.

On Tue, Dec 7, 2010 at 2:38 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:
> On Tue, Dec 7, 2010 at 3:42 AM, Dave Cridland <dave@cridland.net> wrote:
> > On Mon Dec  6 23:27:02 2010, Maciej Stachowiak wrote:
> >>
> >> I'd like to see more detail on the data than is found in the paper, but it
> >> seems to show a real-world hazard with use of Upgrade, since many
> >> intermediaries do not understand it and at least a few are confused into
> >> treating subsequent traffic as additional HTTP requests and responses.
> >
> > That's a subtle misread of the paper.
> >
> > The paper shows that many intermediaries treat any traffic as HTTP requests
> > and responses until they find a CONNECT, after which they treat the traffic
> > as opaque except in a tiny minority of cases (what, 4 out of 54,000?).
>
> I do not think the paper corroborates that argument at all.
>
> Quoting the paper: "In our experiments, we observed two proxies which
> appear not to understand CONNECT but simply to treat the request as an
> ordinary request and then separately route subsequent requests, with
> all routing based on IP address."
>
> Sounds simple and clear, but let's dig a little deeper. The
> experiments sent bytes in the following form (as far as we know, from
> conversations on this mailing list)
>
>  CONNECT websocket.invalid:443 HTTP/1.1
>  Host: websocket.invalid:443
>  Sec-WebSocket-Key: <connection-key>
>  Sec-WebSocket-Metadata: <metadata>
>
>  GET /script.php/<random> HTTP/1.1
>  Host: target.com
>
> that is, two HTTP requests, well formed. An HTTP interceptor that
> understands CONNECT will treat the load(all bytes after the connect
> request) as opaque and forward them to the server verbatim.
>
> On the other hand, a "CONNECT-agnostic" HTTP interceptor, one that
> does not "understand CONNECT but simply to treat the request as an
> ordinary request and then separately route subsequent requests, with
> all routing based on IP address", will do ... pretty much the same
> thing! It could have parsed the load into a HTTP request, then sent
> the request to the server as is, effectively forwarding the load to
> the server verbatim. Neither the client nor the server could detect
> the fact that this interceptor parsed the load as HTTP requests.
>
> Some CONNECT-agnostic interceptors may have touched the 2nd request in
> some way, allowing the server to detect them. The two proxies
> described in the paper may have done something like that. It would
> nice if the authors tell us how exactly they are detected.

The 2nd request was transmitted on a separate network connection. That
is how we distinguished it from the normal case, which re-uses the
initial connection.

As discussed in Section V(C)(3) of the paper, we did not observe any
caching proxies that had this behavior in our experiment. If these
proxies are a concern, it is possible to prevent them from becoming
poisoned using encryption.

Collin Jackson

Received on Thursday, 9 December 2010 08:39:06 UTC