Re: On sanctioned MITMs

[mancha <mancha1 () zoho com>]

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

Attachment: _bin
Description: