[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150501191522.GA18039@zoho.com>
Date: Fri, 1 May 2015 19:15:22 +0000
From: mancha <mancha1@...o.com>
To: oss-security@...ts.openwall.com
Subject: On sanctioned MITMs
In recent times, we've seen the growing popularity of CDNs such as
Akamai Prolexic, CloudFlare, and Incapsula that, among other services,
provide upstream DDoS mitigation to vulnerable servers.
In the context of SSL/TLS, the interposition between client and server
can take many forms. For example, CloudFlare offers products such as
"Flexible SSL", "Full SSL", and "Full SSL (strict)" [1]. In addition,
they've recently rolled out a new product they call "Keyless SSL".
Hushmail is a email provider that prominently advertises security and
built-in encryption [2]. In the past day or two, Hushmail webmail access
began getting handled by CloudFlare [3] & [4]. CloudFlare's server, in
effect a sanctioned man-in-the-middle, serves its own X.509 certificate
issued by "GlobalSign Organization Validation CA - G2" (attached). The
certificate has a *.hushmail.com DNS name in its SAN extension so
browsers with the GlobalSign certificate in their root store proceed
without incident when connecting to https://www.hushmail.com.
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.)?
--mancha
=====
[1] https://www.cloudflare.com/images/ssl/ssl.png
[2] https://www.hushmail.com
[3] dig www.hushmail.com
id 20483
opcode QUERY
rcode NOERROR
flags QR RD RA
;QUESTION
www.hushmail.com. IN A
;ANSWER
www.hushmail.com. 299 IN A 104.16.15.172
www.hushmail.com. 299 IN A 104.16.19.172
www.hushmail.com. 299 IN A 104.16.17.172
www.hushmail.com. 299 IN A 104.16.18.172
www.hushmail.com. 299 IN A 104.16.16.172
;AUTHORITY
;ADDITIONAL
[4] whois 104.16.15.172
NetRange: 104.16.0.0 - 104.31.255.255
CIDR: 104.16.0.0/12
NetName: CLOUDFLARENET
NetHandle: NET-104-16-0-0-1
Parent: NET104 (NET-104-0-0-0-0)
NetType: Direct Assignment
OriginAS: AS13335
Organization: CloudFlare, Inc. (CLOUD14)
RegDate: 2014-03-28
Updated: 2014-03-28
Comment: https://www.cloudflare.com
Ref: http://whois.arin.net/rest/net/NET-104-16-0-0-1
=====
View attachment "hushmail-cloudflare.pem" of type "text/plain" (1888 bytes)
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.
