- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 14 Nov 2013 07:45:15 +0100
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Cc: "William Chan (?????????)" <willchan@chromium.org>, Adrien de Croy <adrien@qbik.com>, Mike Belshe <mike@belshe.com>, Tao Effect <contact@taoeffect.com>, Tim Bray <tbray@textuality.com>, James M Snell <jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Nov 14, 2013 at 01:37:27AM +0000, Stephen Farrell wrote: > On 11/14/2013 01:09 AM, Willy Tarreau wrote: > > least detestable > > The second word of that phrase seems to me to be > almost perfectly appropriate for MITM attack product > features. But, importantly, I think your use of > the phrase does expose the reality of what we all > think of doing that, even, I suspect and hope, those > who do it for fun or profit. Thank you. I don't think anyone really disagrees with this. Amos and Adrien said they had to implement this because there is strong demand, not that they loved the concept. Nobody sane (technically speaking) loves the concept of trying to fool the user who believes there is some security when the tools are not designed to inform him about what's happening. > As to the supposed requirements that lead to those > detestable product features - if enforcing policy on > HTTP traffic is what is claimed to be required then > I would love to see this wg go figure out ways of doing > that using HTTP (rather than *ab*using TLS) so as to > not affect the many many other protocols that depend > on TLS not being as detestable as the implementations > you're talking about. But personally speaking I don't > know how you can do that without screwing up the many > other protocols that depend on https:// and in the > process making those also detestable. I think it's neither TLS nor HTTP's role to do to provide the solution to this, but at least it's certainly not HTTP's role to make efforts to ensure that this results in the worst situation for the end user when that's done anyway! In my opinion it's mostly a matter of user interface as long as the protocol does not needlessly complicate things. > Cheers, > S. > > PS: "Supposed" above is I think fair for most of the > "requirements" claimed in this space. There is some > validity to realtime inbound malware scanning but > the rest seems like nonsense. I do wonder why people > who pay for those products don't realise this;-) I would turn the question the other way around : you should wonder why you believe the rest is nonsense if people are paying a lot for this. You just don't have the same motivations as them, but for some, it's just being able to do so or run out of business. And just a reminder, we started this discussion about the fact that the ones who just MITM clear HTTP for caching will have a good reason for doing it with HTTPS if we enforce encryption where not needed. So you add the economics as a new motivation to do this. For most ISPs, the bandwidth costs are much higher than anything else, and margins are extremely low. So if the bandwidth requirements increase, they risk their business. Caching then becomes mandatory for some. With or without TLS, it's just an implementation detail when you're talking to someone who doesn't know if his company will survive past the end of the year. Willy
Received on Thursday, 14 November 2013 06:45:58 UTC