Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 2 May 2015 22:25:46 +0000
From: mancha <mancha1@...o.com>
To: oss-security@...ts.openwall.com
Cc: lyndon@...hanc.ca
Subject: Re: On sanctioned MITMs

On Fri, May 01, 2015 at 07:40:51PM -0700, Lyndon Nerenberg 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.)?

> But also ask why they might use it.  E.g., in the presence of a DDOS
> attack, many companies rely on infrastructure such as what Cloudflare
> provides in order to keep their services running.  By their nature,
> those mitigation services have to bust the SSL pipe to do what they
> do.

I kicked off my post mentioning DDoS mitigation was one of the reasons
services contract with CDNs such as CloudFlare.

> What I am not hearing anywhere in this conversation is a proposal for
> how Cloudflare can provide the service they do, but in a manner that
> doesn't require busting the SSL pipe in the middle.  There are MANY
> people begging for an answer to that.  Do you have it?  If not, are
> you prepared to see the services you "need" go offline when someone
> decides to DDOS the provider?
> 
> That's not a rhetorical question.  For some people, the answer is
> 'yes'.  But for most, it is 'no'.

I agree achieving end-to-end (E2E) security with interposition is an
interesting security research area. In fact, it would be great if as a
result of this thread more members of the infosec and oss communities
were motivated to tackle that. 

> In the specific Hushmail example, would it alleviate peoples concerns
> if the Cloudflare MITM-busting behaviour took place entirely inside
> Canada?  If not, how do you propose an alternative?

Dean Pierce points out that outsourcing across national borders can have
legal implications but this is outside of my area of expertise.

> And what, exactly, is the attack vector you are trying to close down?
> Is it the only one?  How do they interact?
> 
> --lyndon

I've already alluded to the general security issues that arise in MITM
setups. More specifically, breaking E2E security with interposition adds
well-known complications/issues: rogue employees at the interposing
service, increased attack surfaces, more points of failure, inability to
verify path integrity, inability to verify content integrity,
misconstruing of communications as E2E-secure by non-experts, among many
others. 

As you said, lots of people are interested in ways of achieving E2E
security with intermediation - precisely because there is recognition
current TLS interposition models are not satisfactory. 

My specific interest is how OSS projects (e.g. browsers, TLS stacks,
etc.) can address security issues that arise from SSL/TLS interposition.
Also of interest is leveraging the intersection of infosec/oss/crypto to
develop related innovations (e.g. interposition that coexists with
uncompromised E2E security). 

--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.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.