oss-sec mailing list archives

Re: On sanctioned MITMs


From: Kurt Seifried <kseifried () redhat com>
Date: Fri, 01 May 2015 14:10:29 -0600

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.

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.

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.

--mancha


-- 
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Attachment: signature.asc
Description: OpenPGP digital signature


Current thread: