Break open Dropbox SSL traffic with Squid Proxy
The Problem
Some threats creep up on you over time, they evolve to a point where they pose a risk to all organisations at around the same time. Data Loss Prevention (DLP) is a relatively recent solution area that organisations are seeing as a ‘must have’. The mix of personal rather than corporate identity, cloud, encryption and synchronisation ensure that corporate data is leaking all the time. Sure this is nothing new in some respects, you could have emailed that sensitive document out or used a USB key.
Whether organisations like it or not they are going to have to start inspecting encrypted traffic. This is going to cause friction with employees (the talent) but it’s a conversation that has to begin soon before organisations feel the sting of data loss. In this blog post I examine the visibility a normal security team would have regarding Dropbox traffic and how Squid Proxy could be used in a whitelist or blacklist configuration to decrypt and inspect SSL traffic.
Standard SSL Proxy Requests
All HTTP proxies will use the HTTP ‘CONNECT’ method to enable encrypted communications. When you look at the Squid Proxy access log you will see a series of CONNECT requests and the destination domain name and IP address. However you can’t see what the user is doing. Are they uploading? Are they downloading? With Dropbox you get an ‘idea’ of what is going on because of the separate DNS domains (dl-web and photos-1).
In the example below I logged into Dropbox, downloaded a picture, deleted a picture and uploaded a picture and then viewed the picture in the gallery.
1306911721.016 100708 ::1 TCP_MISS/200 58002 CONNECT www.dropbox.com:443 - DIRECT/208.43.202.50 - 1306911721.674 98606 ::1 TCP_MISS/200 7693 CONNECT www.dropbox.com:443 - DIRECT/208.43.202.50 - 1306911721.936 98871 ::1 TCP_MISS/200 121798 CONNECT www.dropbox.com:443 - DIRECT/208.43.202.50 - 1306911722.025 98963 ::1 TCP_MISS/200 16674 CONNECT www.dropbox.com:443 - DIRECT/208.43.202.50 - 1306911724.024 100945 ::1 TCP_MISS/200 80967 CONNECT www.dropbox.com:443 - DIRECT/208.43.202.50 - 1306911724.729 101649 ::1 TCP_MISS/200 118764 CONNECT www.dropbox.com:443 - DIRECT/208.43.202.50 - 1306911897.287 67655 ::1 TCP_MISS/200 87629 CONNECT dl-web.dropbox.com:443 - DIRECT/184.73.202.71 - 1306912018.476 63442 ::1 TCP_MISS/200 2420 CONNECT dl-web.dropbox.com:443 - DIRECT/50.17.180.175 - 1306912084.914 61758 ::1 TCP_MISS/200 3204 CONNECT photos-1.dropbox.com:443 - DIRECT/50.19.119.250 - 1306912085.113 61956 ::1 TCP_MISS/200 5636 CONNECT photos-1.dropbox.com:443 - DIRECT/50.19.119.250 - 1306912098.433 154744 ::1 TCP_MISS/200 55489 CONNECT www.dropbox.com:443 - DIRECT/208.43.202.50 -
Squid Proxy with ssl-bump
Squid proxy through the ssl-bump feature allows you to Man in the Middle (Squid in the Middle) the SSL traffic. Traffic from the user to Dropbox is intercepted by Squid and a private certificate is used to terminate the SSL traffic. The private certificate in this case was one I knocked up using openssl but in reality it would be a certificate from an organisation’s CA of which the Trusted Root Certificate is installed on user’s desktops.
When I navigate to Dropbox and enter my credentials you are prompted to accept the Firefox Security Exception as the Trusted Root certificate of the CA I am using is not installed. Creating a signed certificate within your organisation and rolling out the Trusted Root Certificate across all desktops is a relatively simple task.
Once I accept the security exception the site operates as normal but you can tell that we are now using a Black Foundry certificate rather than Dropbox’s certificate.
It is immediately evident the difference it makes with regards to visibility. You can see every single GET and POST and the URI of the request (as if it was http).
Again for this test I navigated to Dropbox, logged in, downloaded a photo, uploaded a photo etc. Note: I have deleted a number of lines related to page assets (images and css) to make it clearer.
1306912992.524 1390 ::1 TCP_MISS/200 22151 GET http://www.dropbox.com/ - DIRECT/208.43.202.53 text/html 1306912994.201 2439 ::1 TCP_MISS/200 174273 GET http://www.dropbox.com/static/16862/javascript/lib-mini.js - DIRECT/208.43.202.53 application/x-javascript 1306912995.021 1340 ::1 TCP_MISS/200 280096 GET http://www.dropbox.com/static/16862/javascript/dropbox-mini.js - DIRECT/208.43.202.53 application/x-javascript 1306912997.503 2417 ::1 TCP_MISS/200 105081 GET http://www.dropbox.com/static/1306962360/images/sprites/sprites.png - DIRECT/208.43.202.53 image/png 1306913044.641 3097 ::1 TCP_MISS/302 1892 POST https://www.dropbox.com/login - DIRECT/208.43.202.53 text/html 1306913048.109 3465 ::1 TCP_MISS/200 48696 GET https://www.dropbox.com/home - DIRECT/208.43.202.53 text/html 1306913193.031 3378 ::1 TCP_MISS/200 43060 GET https://dl-web.dropbox.com/get/Photos/jamie-eason_2.jpg? - DIRECT/50.17.242.125 image/jpeg 1306913213.153 1401 ::1 TCP_MISS/200 235 POST https://www.dropbox.com/cmd/delete? - DIRECT/208.43.202.53 text/html 1306913213.953 1202 ::1 TCP_MISS/200 225 POST https://www.dropbox.com/job_status/1306913211747239568 - DIRECT/208.43.202.53 text/plain 1306913214.574 1404 ::1 TCP_MISS/200 5235 POST https://www.dropbox.com/browse2/Photos? - DIRECT/208.43.202.53 text/html 1306913218.900 3165 ::1 TCP_MISS/200 13152 GET https://www.dropbox.com/static/swf/swfupload.swf? - DIRECT/208.43.202.53 application/x-shockwave-flash 1306913230.098 6934 ::1 TCP_MISS/302 920 POST https://dl-web.dropbox.com/upload - DIRECT/50.17.242.125 text/html 1306913231.725 1625 ::1 TCP_MISS/200 49124 GET https://www.dropbox.com/home/Photos - DIRECT/208.43.202.53 text/html 1306913234.097 1999 ::1 TCP_MISS/200 6775 POST https://www.dropbox.com/browse2/Photos? - DIRECT/208.43.202.53 text/html
I downloaded a file named ‘jamie-eason_2.jpg’ and then I did a POST to delete a file. After that I browsed the photo gallery and then uploaded something in another POST.
This is a totally different level of visbility into the traffic. I could go further and dissect the POST’s and determine what each user was uploading to Dropbox. I could store the files that were uploaded and downloaded or their hashes (MD5 or SHA) and compare them to hashes for sensitive internal files.
The Implementation
Greater levels of inspection are inevitable due to the risks posed by exploits carried in encrypted traffic and the risk of users leaking sensitive information. In the immediate future users are going to have to get used to higher levels of inspection and surveillance (e.g. Packet Capture).
The implementation will be the most important aspect (rather than whether you can decrypt traffic on the fly). So much encrypted personal traffic (Internet Banking, Facebook and Twitter) is carried across corporate networks.
A Whitelist would allow Internet Banking traffic to avoid decryption using the Organisation’s Private Certificate whilst allowing inspection of all other Social Media and Cloud file hosting providers. A Blacklist would allow the specific targeting of sites such as Dropbox but really miss the mark. If not Dropbox it could be direct to Amazon S3.
So Whitelisting is the key I just don’t want to be around for the conversation you have with your users 
The problem is, that there are to many official sniffer man in the middle X509 certificates, I even found some private keys on some sides on the net.
So at least everybody could decrypt SSL if he or she is able to set up a transparent squid or bluecoat proxy. Furthermore by arpspoofing in many networks decrypting SSL becomes too easy with some private key CAs
he23
February 22, 2012 at 4:04 am
Totally agree he23. When I wrote this the ssl-bump feature was relatively new allowing an organisation to see into the traffic without a lot of effort. Since the article there has been plenty of press regarding SSL and Public CA’s. The Trustwave story comes to mind. Thanks for taking time to comment!
Michael Baker / @cloudjunky
February 24, 2012 at 9:42 pm
Hi there!
This is really a good article…
What do you think of allowing the client to directly connect to ssl sites “bypassing” the proxy?
pittsspiritspits
February 23, 2012 at 9:09 pm
I think a lot of enterprise organisations would force all traffic through a proxy for URL Filtering and Content Inspection. Most commercial offerings are starting to provide SSL decrypt features in the same way that Squid supports it. So I think in most companies direct access would not be permitted.
Michael Baker / @cloudjunky
February 24, 2012 at 9:44 pm
But thanks at all for implementing this feature, cause with some additions to bump-ssl and some md5 keyservers, that check online and cached md5 sigs, people might detect outer sniffers.
he23
March 8, 2012 at 12:03 am
but thanks at all for implementng this feature.
With a static cache or netwide online md5 certifacte signature you might be able to detect wider outside sniffers. You can’t detect inside arpspoofers or browser corruptions.
he23
March 8, 2012 at 12:18 am
I mean a static signature cache or a distributed md5 signature validation service, that checks the X509 certificate MD5 signature from many different location over several routes.
he23
March 8, 2012 at 12:24 am