- From: Adrien W. de Croy <adrien@qbik.com>
- Date: Mon, 02 Apr 2012 22:34:45 +0000
- To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
- Cc: "Mike Belshe" <mike@belshe.com>, "Peter Lepeska" <bizzbyster@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
------ Original Message ------ From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie> > > >On 04/02/2012 10:43 PM, Adrien W. de Croy wrote: >> >> >> >>------ Original Message ------ >>From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie> >>To: "Mike Belshe" <mike@belshe.com> >>Cc: "Peter Lepeska" <bizzbyster@gmail.com>;"ietf-http-wg@w3.org" >><ietf-http-wg@w3.org> >>Sent: 3/04/2012 9:36:32 a.m. >>Subject: breaking TLS (Was: Re: multiplexing -- don't do it) >>> >>> >>>On 04/02/2012 10:20 PM, Mike Belshe wrote: >>>>I was trying to describe https to the proxy, which breaks the SSL, >>>>and then initiates a new SSL connection to FB. >>>>I call this a "trusted proxy". The browser in this case must have >>>>explicitly specified the proxy to use and also that it is okay to >>>>let >>>>it break SSL. >>> >>>TLS MITM has been proposed before and rejected. >>I don't think that's what Mike was proposing when he said break. >> >>the proposal is that TLS would terminate on the proxy, then the >>client >>would additionally / optionally be able to specify that the proxy >>make >>an SSL connection to the server. >> >>It's all explicit, no MITM, no underhandedness. > >Previous proposals were also explicit and open yet didn't achieve >IETF consensus. If this "feature" is to be designed-in, I predict >it'll be quite controversial. You can argue that the IETF hasn't >been good with this and with NAT (i.e. middleboxen in general) but >that's probably because there are real arguments against such >things, as well as for them. I don't disagree. > > >>>Even for FB, but definitely for banking, I don't want that middlebox >>>getting my re-usable credentials and I don't see how to avoid that >>>problem. >> >>You're right, the proxy would still get this, which is why it would >>need >>to be trusted. There's no other way. > >Just saying "trusted" not sufficient - trusted for what? > >If you were to describe this as "trusting your employer with your >bank account credentials" then it might be more accurate, and, yes, >less acceptable. It's difficult to quantify. In the end, it's trust in the vendor of the software not to put something nasty in. We already do that with pretty much all software we run. And then it's trust in whoever may get access to confidential information not to do anything untoward with it, whatever that is. We already do that all the time as well. With your bank, your government etc. > > >>This issue won't be going away. Unless you think you can convince >>every >>boss/parent on the planet that their employees/kids should be able to >>do >>whatever they like. > >I agree there's an issue there. OTOH, is there good evidence of the >effectiveness of such outbound proxies in terms of their claimed >benefits? you're asking if there's any evidence that implementing acceptable use policies has any merit? that's a political issue. > > >I also don't buy that most users will know enough to say "ah, >www-proxy.example.com:8080 is ok" esp. when the browser discovered >the proxy who know's how. Definitely. There's a real issue there. Hence my comment about doing any discovery in a secure (holistically) manner. Adrien > > >Stephen. > > >>> >>> >>>I do understand that there are percieved-real requirements here for >>>enterprise middleboxes to snoop but we've not gotten IETF consensus >>>to >>>support that kind of feature in our protocols. >> >>sure we do. 2616 already contemplates and supports proxies - just not >>with https. >>> >>> >>>Stephen. >>>PS: I'm not angling for better http auth here. Even if we get that >>>there will be many passwords and other re-usable credentials in use >>>for pretty much ever and the argument against breaking TLS will >>>remain. >> >>Auth in fact may be the answer to the issue of trust for a server to >>place in a proxy (re the client cert issue). >> >>There may not be a good answer for client certs, and it may be the >>only >>way to support them is to continue to tunnel. >> >>At least they are not that prevalent so that in cases where they are >>required, tunneling can be allowed. >> >>Adrien >>> >>> >>> >>>> >>>>Mike >>>> >>>> >>>> >>>>> >>>>>The proxy can still not see the facebook traffic in the clear so >>>>>the >>>>>admin will still either need to block facebook entirely or do a >>>>>MITM. >>>>>Peter >>>>>On Mon, Apr 2, 2012 at 5:11 PM, Mike Belshe<mike@belshe.com> >>>>>wrote: >>>>>> >>>>>> >>>>>>On Mon, Apr 2, 2012 at 2:08 PM, Adrien W. de >>>>>>Croy<adrien@qbik.com>wrote: >>>>>>> >>>>>>>------ Original Message ------ From: "Mike >>>>>>>Belshe"<mike@belshe.com> To: "Adrien W. de >>>>>>>Croy"<adrien@qbik.com> >>>>>>>Cc: "Amos Jeffries"<squid3@treenet.co.nz>;"ietf-http-wg@w3.org"< >>>>>>>ietf-http-wg@w3.org> Sent: 3/04/2012 8:52:22 a.m. Subject: Re: >>>>>>>multiplexing -- don't do it >>>>>>> >>>>>>> >>>>>>>On Mon, Apr 2, 2012 at 1:43 PM, Adrien W. de Croy< >>>>>>><adrien@qbik.com> adrien@qbik.com> wrote: >>>>>>>> >>>>>>>>------ Original Message ------ From: "Mike >>>>>>>>Belshe"<mike@belshe.com>mike@belshe.com >>>>>>>> >>>>>>>> >>>>>>>>On Mon, Apr 2, 2012 at 6:57 AM, Amos Jeffries< >>>>>>>><squid3@treenet.co.nz><squid3@treenet.co.nz> >>>>>>>>squid3@treenet.co.nz> wrote: >>>>>>>>>On 1/04/2012 5:17 a.m., Adam Barth wrote: >>>>>>>>>On Sat, Mar 31, 2012 at 4:54 AM, Mark Nottingham wrote: >>>>>>>>>> >>>>>>>>>>>On 31/03/2012, at 1:11 PM, Mike Belshe wrote: >>>>>>>>>>>For the record - nobody wants to avoid using port 80 for new >>>>>>>>>>>>protocols. I'd love to! There is no religious reason that >>>>>>>>>>>>we >>>>>>>>>>>>don't - its just that we know, for a fact, that we can't do >>>>>>>>>>>>it without subjecting a non-trivial number of users to >>>>>>>>>>>>hangs, >>>>>>>>>>>>data corruption, and other errors. You might think its ok >>>>>>>>>>>>for >>>>>>>>>>>>someone else's browser to throw reliability out the window, >>>>>>>>>>>>but nobody at Microsoft, Google, or Mozilla has been >>>>>>>>>>>>willing >>>>>>>>>>>>to do that… >>>>>>>>>>>Mike - >>>>>>>>>>>I don't disagree on any specific point (as I think you >>>>>>>>>>>know), >>>>>>>>>>>but I would observe that the errors you're talking about can >>>>>>>>>>>themselves be viewed as transient. I.e., just because they >>>>>>>>>>>occur in experiments now, doesn't necessarily mean that they >>>>>>>>>>>won't be fixed in the infrastructure in the future -- >>>>>>>>>>>especially if they generate a lot of support calls, because >>>>>>>>>>>they break a lot MORE things than they do now. >>>>>>>>>>>Yes, there will be a period of pain, but I just wanted to >>>>>>>>>>>highlight one of the potential differences between deploying >>>>>>>>>>>a >>>>>>>>>>>standard and a single-vendor effort. It's true that we can't >>>>>>>>>>>go too far here; if we specify a protocol that breaks >>>>>>>>>>>horribly >>>>>>>>>>>50% of the time, it won't get traction. However, if we have >>>>>>>>>>>a >>>>>>>>>>>good base population and perhaps a good fallback story, we >>>>>>>>>>>*can* change things. >>>>>>>>>>That's not our experience as browser vendors. If browsers >>>>>>>>>>offer >>>>>>>>>>an HTTP/2.0 that has a bad user experience for 10% of users, >>>>>>>>>>then major sites (e.g., Twitter) won't adopt it. They don't >>>>>>>>>>want to punish their users any more than we do. >>>>>>>>>>Worse, if they do adopt the new protocol, users who have >>>>>>>>>>trouble will try another browser (e.g., one that doesn't >>>>>>>>>>support HTTP/2.0 such as IE 9), observe that it works, and >>>>>>>>>>blame the first browser for being buggy. The net result is >>>>>>>>>>that >>>>>>>>>>we lose a user and no pressure is exerted on the >>>>>>>>>>intermediaries >>>>>>>>>>who are causing the problem in the first place. >>>>>>>>>>These are powerful market force that can't really be ignored. >>>>>>>>> >>>>>>>>>So the takeway there is pay attention to the intermediary >>>>>>>>>people >>>>>>>>>when they say something cant be implemented (or won't scale >>>>>>>>>reasonably). >>>>>>>> >>>>>>>>I agree we should pay attention to scalability - and we have. >>>>>>>>Please don't disregard that Google servers switched to SPDY >>>>>>>>with >>>>>>>>zero additional hardware (the google servers are fully >>>>>>>>conformant >>>>>>>>http/1.1 proxies with a lot more DoS logic than the average >>>>>>>>site). I know, some people think Google is some magical place >>>>>>>>where scalability defies physics and is not relevant, but this >>>>>>>>isn't true. Google is just like every other site, except much >>>>>>>>much bigger. If we had a 10% increase in server load with SPDY, >>>>>>>>Google never could have shipped it. Seriously, who would roll >>>>>>>>out >>>>>>>>thousands of new machines for an experimental protocol? Nobody. >>>>>>>>How would we have convinced the executive team "this will be >>>>>>>>faster", if they were faced with some huge cap-ex bill? Doesn't >>>>>>>>sound very convincing, does it? In my mind, we have already >>>>>>>>proven clearly that SPDY scales just fine. >>>>>>>>But I'm open to other data. So if you have a SPDY >>>>>>>>implementation >>>>>>>>and want to comment on the effects on your server, lets hear >>>>>>>>it! >>>>>>>>And I'm not saying SPDY is free. But, when you weigh costs >>>>>>>>(like >>>>>>>>compression and framing) against benefits (like 6x fewer >>>>>>>>connections), there is no problem. And could we make >>>>>>>>improvements >>>>>>>>still? Of course. But don't pretend that these are the critical >>>>>>>>parts of SPDY. These are the mice nuts. >>>>>>>> >>>>>>>>For a forward proxy, there are several main reasons to even >>>>>>>>exist: >>>>>>>>a) implement and enforce access control policy b) audit usage >>>>>>>>c) >>>>>>>>cache >>>>>>>>you block any of these by bypassing everything with TLS, you >>>>>>>>have >>>>>>>>a non-starter for corporate environments. Even if currently >>>>>>>>admins kinda turn a blind eye (because they have to) and allow >>>>>>>>port 443 through, as more and more traffic moves over to 443, >>>>>>>>more pressure will come down from management to control it. >>>>>>>>Best we don't get left with the only option being MITM. >>>>>>> >>>>>>>In my talk at the IETF, I proposed a solution to this. >>>>>>>Browsers need to implement SSL to trusted proxies, which can do >>>>>>>all of the a/b/c that you suggested above. This solution is >>>>>>>better >>>>>>>because the proxy becomes explicit rather than implicit. This >>>>>>>means that the user knows of it, and it IT guys knows of it. If >>>>>>>there are problems, it can be configured out of the system. >>>>>>>Implicit proxies are only known the the IT guy (maybe), and >>>>>>>can't >>>>>>>be configured out from a client. The browser can be made to >>>>>>>honor >>>>>>>HSTS so that end-to-end encryption is always enforced >>>>>>>appropriately. >>>>>>>Further, proxies today already need this solution, even without >>>>>>>SPDY. Traffic is moving to SSL already, albeit slowly, and >>>>>>>corporate firewalls can't see it today. Corporate firewall >>>>>>>admins >>>>>>>are forced to do things like block facebook entirely to prevent >>>>>>>data leakage. But, with this solution, they could allow facebook >>>>>>>access and still protect their IP. (Or they could block it if >>>>>>>they >>>>>>>wanted to, of course). >>>>>>>Anyway, I do agree with you that we need better solutions so >>>>>>>that >>>>>>>we don't incur more SSL MITM. Many corporations are already >>>>>>>looking for expensive SSL MITM solutions (very complex to >>>>>>>rollout >>>>>>>due to key management) because of the reasons I mention above, >>>>>>>and >>>>>>>its a technically inferior solution. >>>>>>>So lets do it! >>>>>>> >>>>>>>I basically agree with all the above, however there is the ISP >>>>>>>intercepting proxy to think about. >>>>>>>Many ISPs here in NZ have them, it's just a fact of life when >>>>>>>you're 150ms from the US and restricted bandwidth. Pretty much >>>>>>>all >>>>>>>the big ISPs have intercepting caching proxies. >>>>>>>There's just no way to make these work... period... >>>>>>>unless the ISP is to >>>>>>>a) try and support all their customers to use an explicit proxy, >>>>>>>or b) get all their customers to install a root cert so they can >>>>>>>do MITM. >>>>>> >>>>>> >>>>>>>Maybe we need a better way to force a client to use a proxy, and >>>>>>>take the pain out of it for administration. And do it securely >>>>>>>(just remembering why 305 was deprecated). >>>>>> >>>>>>Do proxy pacs or dhcp work for this? >>>>>>Note that we also need the browsers to honor HSTS end-to-end, >>>>>>even >>>>>>if we turn on "GET https://". Mike >>>>>> >>>>>> >>>>>> >>>>>>>Adrien >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>Adrien >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>Mike >>>>>>>> >>>>>>>> >>>>>>>>>With plenty of bias, I agree. >>>>>>>>>AYJ >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >>
Received on Monday, 2 April 2012 22:35:20 UTC