On 15/07/2009, at 5:34 PM, Ian Hickson wrote:
On Wed, 15 Jul 2009, Mark Nottingham wrote:
Upgrade is hop-by-hop, so it's pretty limiting.
Do man-in-the-middle proxies count as a hop for the purposes of
HTTP? As
far as I can tell from the HTTP spec, the client is supposed to know
whether it is speaking to a proxy or not, so man-in-the-middle proxies
don't affect the hop-by-hop semantics... but it's not entirely clear.
Intercepting (often called "transparent", although that's confusing
because HTTP defines "semantically transparent" as something
completely different) do consider them to be separate hops (to be
clear, the "hops" are on the wire, not on the devices, although
sometimes there might be a virtual "hop" inside a device).
There are a few "L7" load balancers that don't act as a full
intermediary in the HTTP sense (or at least, what they do is muddy
enough that it's not clear), but do fiddle with headers (e.g., this is
why you see things like Coenection instead of Connection).
The important thing to remember is that interception *only* happens on
port 80, except in the most pathological of networks (and you won't be
able to do anything about them anyway).
Notice that I'm making a distinction between intercepting and
firewalling here; all bets are off when a firewall does stateful
inspection of your protocol, unless you can convince it to pass an
encrypted stream (the TLS-over-443 solution).
They're also allowed to change the formatting of the message; e.g.,
re-wrap headers, normalise whitespace.
Sure, but that's why we have the TLS-over-port-443 option. In the
cases
where there is uncooperative network infrastructure, the client can
just
switch to that, and then there's no way the connection can be
affected.
As long as you're using TLS, yes. That's going to limit scaling, of
course.
Specifying a bit-for bit handshake is incredibly fragile.
Not doing so is unacceptably insecure for this use case, IMHO. We
can't
run the risk of Web pages hitting SMTP servers and sending spam, or
poking
at intranet servers, or who knows what else.
Let me put that a slightly different way; specifying a bit-for-bit
handshake is fragile *when you expect it to pass through HTTP
infrastructure that has no reason to preserve those bits exactly as
they are*.
Can you remind me why you need the handshake to look like valid HTTP
again? I think that's the crux here.
Cheers,
--
Mark Nottingham [email protected]
