On 03/06/2013 10:53, "Nicholas Weaver" <[email protected]> wrote:
>At the same time, without at least #2, you are in huge trouble if there
>exists some supposedly "smart" middlebox....
>
>There are NATs that inject responses into HTTP traffic, as well as ISPs.
>There are transcoding proxies that convert 64 kB images into 4 kB blobs
>that would display poorly on a commodore 64. There are web proxies that
>contain 3 year old! vulnerabilities. If its possible for an HTTP
>middlebox to screw up traffic in some way, there probably is a deployed
>middlebox that does it already.
>
>ALTO is something new, and if you really want it to work reliably, in as
>many contexts as possible, ESPECIALLY over port 80, you must account for
>the middleboxes.
>
>And the way to account for the middleboxes is to require support for TLS
>on port 443, so that the middleboxes are forced to go "hands off".
Clearly you've been burned by middleboxes! I have as well, although not
since the 1997.
But don't most of those problems come from middleboxes trying to "improve"
html -- simplify it, remove ads, reformat it, etc? Or compress images? And
don't those middleboxes base their transformations on the content type?
Since ALTO messages are new mime type, it's unlikely those boxes would
change them.
Also, I believe one of the reasons for switching to a more REST-ful
structure (around draft 8) was to make it easier for proxies to cache full
network and cost maps.
And although I haven't personally been burned by this, I've been told some
middleboxes block port 443. Eg, to prevent employees from shopping when
they should be working.
>And once you mandate support for TLS, what reason is there to not always
>use it?
Here's the reason. Suppose the protocol spec states that an ALTO server
*cannot* use unencrypted http. That's telling a potential ALTO service
provider, "You're too stupid to make the right choice. We know best."
Yes, that is a very nasty way to put it. But that is the message that
requirement would send.
I prefer to assume that providers are smart enough to pick the appropriate
level of security for their environment, their client base, and the
sensitivity of their network data. That means you, as a potential ALTO
service provider, are perfectly free to have your ALTO server accept https
only. And as a potential client, you're free to refuse to use ALTO servers
that don't provide https. But other people can make other choices.
- Wendy Roome
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
