which makes it clear that the point is to be able to say "I trust this proxy sufficiently that I'm ok with it acting as an intermediary, but I still don't want my stuff in the clear between me and the proxy or between the proxy and the far end server."
So it's about enabling the user to trust -only- the proxy, whereas currently in order to get utility out of a proxy you need to send the traffic as plain HTTP which then trusts both the proxy and the networks over which the data will travel.
That seems to me to absolutely meet the requirements for "strictly better".
If your definition of "better" is simply "faster", then yes, it is better. If you care about security of your data, end-to-end, this is worse (as others have pointed out because of your ISP being a MitM). In addition, now we are introducing another vector of attack for bad guys to exploit - how enticing does it sound that every ISP becomes a root certificate authority, essentially?
Your ISP could be MitM-ing your plaintext HTTP already, and it's the use cases that we currently use plaintext HTTP for that this is addressing.
If you care about security of your data, end-to-end, then you should probably only use this feature, if at all, with the proxy running on a machine you control - but presumably in that case you currently aren't using plaintext HTTP for anything anyway, so I don't see how it relates.
indeed - but I think its even worse than that, because even "faster" is rather contextual.
proxies can inject dog leg routes, single points of failure, computational and i/o bottlenecks and they make lovely centralized dos and data theft targets. They also often downgrade you out of performance enhancements that the client and server would have negotiated if they had been speaking directly (e.g. some actually block compression negotiation so they can observe the content of more flows with less cpu).
Sometimes they do make things faster though - its just not clear to me why we want to continue to centralize that approach rather than distributing it across the network given all the baggage proxying carries.
Comments
I think the crucial thing to understanding this is this diagram -
which makes it clear that the point is to be able to say "I trust this proxy sufficiently that I'm ok with it acting as an intermediary, but I still don't want my stuff in the clear between me and the proxy or between the proxy and the far end server."So it's about enabling the user to trust -only- the proxy, whereas currently in order to get utility out of a proxy you need to send the traffic as plain HTTP which then trusts both the proxy and the networks over which the data will travel.
That seems to me to absolutely meet the requirements for "strictly better".
If your definition of "better" is simply "faster", then yes, it is better. If you care about security of your data, end-to-end, this is worse (as others have pointed out because of your ISP being a MitM). In addition, now we are introducing another vector of attack for bad guys to exploit - how enticing does it sound that every ISP becomes a root certificate authority, essentially?
Your ISP could be MitM-ing your plaintext HTTP already, and it's the use cases that we currently use plaintext HTTP for that this is addressing.
If you care about security of your data, end-to-end, then you should probably only use this feature, if at all, with the proxy running on a machine you control - but presumably in that case you currently aren't using plaintext HTTP for anything anyway, so I don't see how it relates.
indeed - but I think its even worse than that, because even "faster" is rather contextual.
proxies can inject dog leg routes, single points of failure, computational and i/o bottlenecks and they make lovely centralized dos and data theft targets. They also often downgrade you out of performance enhancements that the client and server would have negotiated if they had been speaking directly (e.g. some actually block compression negotiation so they can observe the content of more flows with less cpu).
Sometimes they do make things faster though - its just not clear to me why we want to continue to centralize that approach rather than distributing it across the network given all the baggage proxying carries.