Date: Fri, 1 May 2015 23:39:35 +0000 From: mancha <mancha1@...o.com> To: oss-security@...ts.openwall.com Subject: Re: On sanctioned MITMs On Fri, May 01, 2015 at 02:10:29PM -0600, Kurt Seifried wrote: > On 05/01/2015 01:15 PM, mancha wrote: > > Though Hushmail email credentials, for example, can't be sniffed in > > the segment connecting the client to CloudFlare, they are available > > to CloudFlare's infrastucture. Moreoever, there is no way for the > > client to verify that the segment connecting CloudFlare to the > > destination server is similarly encrypted (i.e. it might be in the > > clear as would be the case when using CloudFlare's "Flexible SSL" > > product). > > > > Hushmail's CloudFlare usage serves as an example that brings me to > > my general point. > > > > How should the security community view this growing use of > > sanctioned MITM in light of the ever-increasing amount of sensitive > > content sent over SSL/TLS encrypted channels (e.g. email, electronic > > banking, medical records, etc.)? > > This is me speaking personally: > > This is nothing new. Front end load balancers that handle SSL/TLS and > then do HTTP on the backend have been around for decades. This is > simply outsourcing it to a trusted (hopefully, because I use them!) > party rather than doing it in house. Using SSL/TLS in-house front ends is an entirely different animal than breaking up end-to-end TLS encryption into multi-segmented pathways via 3rd party interposition. > We have had outsourcing of far more sensitive things for literally > centuries, e.g. legal and accounting firms, my lawyer and accountant > both have literally all my personal info and could easily destroy me > financially if they wanted to. But they don't because we have > contracts, and more importantly contract enforcement in the form of a > civil legal system (as does most of the world). The same applies for > CloudFlare, Google (my email), and so on. I think your analogies are confusing the incentives and priorities of different actors (service consumer, service provider, 3rd party contractor). My own lawyer analogy crystalizes things a bit more clearly: Say you called your lawyer's cell phone but unbeknownst to you she's been getting flooded by telemarkers. To help with this she's contracted a call service that screens her incomings and transparently relays valid calls. Maybe this service is trustworthy or maybe it just irreparably deep-sixed your attorney-client privilege. The clincher is without doing IMEI/TMSI analysis, you're unable to detect the interposition is even there. Moreover, while your connection to the call center is A5/1 protected, the call center might be relaying to your lawyer in the clear. You have no way of knowing from your end. s/lawyer/doctor/g etc. > So in my opinion this is really nothing new, like any outsourced > activity pick your partners carefully. > > This is me speaking on behalf of the Cloud Security Alliance: > > Make your partners/vendors/etc. fill out at least the self attestation > level of STARS, which is free: > > https://cloudsecurityalliance.org/star/self-assessment/ > > If they refuse to do so that might be a good hint as to how secure > they really are. Those are good suggestions for service providers seeking to outsource part of their processes but not so relevant to grandma e-banking or checking her medical results from her chalet in the Swiss Alps. As grannie is finding out, more and more sensitive transactions are being conducted over HTTPS these days. So, she's happy when she sees a lock in the url bar and gets no alerts from Firefox. In recognition of this reality, browsers are assuming ever-increasing roles in safeguarding the security of their users. Traditional measures such as certificate validity checks and blocking weak primitives like small DH moduli and MD5 are constantly being augmented with innovations such as static pin lists, HKPK, etc. SSL/TLS libraries are similarly evolving. It is in within this evolving context that the increasing usage of sanctioned TLS MITMs should be examined. > -- Kurt Seifried --mancha Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ