How do I encrypt my http traffic so my company can't read it?

May 11, 2006 11:51 AM

How do I encrypt my http traffic so my company can't read it? Oh, did I mention SSL is no longer an option since they intend to decrypt all SSL traffic that passes through their proxies?

My company places a lot of importance on information security, which is good. Internet access, which isn't universally available in the company, is limited to ports 80 and 443. I've recently learned that they intend to upgrade our current proxies to one that can decrypt, and allow them to inspect the contents of, SSL communications. There are a number of companies who provide such products. Since we're allowed by policy to access our private web-based e-mail, and this isn't going to change, I'm not comfortable with this at all. I have a Linux box on the outside, and on that I have CGIProxy and GNU HTTP-Tunnel . (Our primary hardware vendor puts their updates on an FTP site, this is how I am able to get them). These are both run over https, but I'm hoping to find a method that will allow all requests to be encrypted before they leave the browser so they can't be decrypted. Does anyone know of such a solution?

I'm thinking of a proxy that runs on my machine. That proxy will create an encrypted tunnel between itself and my external https server going through the company's proxies. My browser will be pointed at the local proxy, thus encrypting all traffic before it even gets to the proxy. If I use a sufficiently high enough level of encryption, their decrypter would be useless. Oh, and the company proxies require authentication, so it would have to support that as well. And, the proxies will only proxy http and https traffic. I've tried the ones that try to get ssh traffic out over 80, they don't work.

For those preparing to give me a lecture, you can spare me the ethics of doing this. I'm fully aware it would be a violation of policy. I don't care. Considering they're not even telling people they're doing it, I find this kind of behavior reprehensible.

posted by Spoonman to computers & internet (35 answers total)

How can a company proxy decrypt SSL? Does this require they they install some proprietary software on your desktop machine? I was under the impression that SSL was fairly secure.
posted by reverendX at 12:08 PM on May 11, 2006

I'm confused as to how the products you link to work. Surely they can't just decrypt SSL willy-nilly. It's not a huge keyspace, but it's not that weak. Right? So how does it work?
posted by teece at 12:08 PM on May 11, 2006

Unless they're putting special client code on each desktop, they can't decrypt SSL. If they are, then there's a couple solutions that do allow them to read all SSL traffic.

If you want to check your personal resources, don't use corpnet. EVDO and a personal laptop that never touches corporate resources (except for electricity) works well.
posted by effugas at 12:11 PM on May 11, 2006

My reading of those product pages leads me to believe that you make an SSL connection to their proxy, then the proxy makes another SSL connection to your actual destination.
posted by Capn at 12:13 PM on May 11, 2006

Here's how those products decrypt SSL: The web browser will be unknowingly negotiating SSL with the proxy instead of the remote server. The new proxy will basically be doing a Man-in-the-middle attack. In such a case, your browser would notify you that the certificate wouldn't match. Unless your company runs its own root certificate authority, and installs that authority into your browser. I assume they'd do that while you were away from your desk, or via some remote software installation utility they have. Once that's all done, there's be very little that you'd be able to do to know if your SSL traffic is being monitored.
posted by zsazsa at 12:14 PM on May 11, 2006

Wow that's scary

Keep in mind, the Bluecoat SSL module isn't so much "decrypting" your SSL session as it is intercepting it and starting a new one on your behalf.

So forget the idea of a proxy on your system that has a high enough level of encryption that the Bluecoat can't decrypt it.

However, what you're proposing has plenty of merit. You need some way to bypass the Bluecoat. Whether this is possible depends on how your network is set up.

First of all, go ahead and set up your home system. Don't bother try to run an http or https proxy server on it on port 80 or 443, because it sounds at least like your company is intercepting that traffic in any case via the Bluecoat. Instead, try running your external proxy server on some random high port, say 64444, and see if you can reach that from your desktop at work. Alternately try setting up other services on your home server like SSH, FTP or some more "common" services. If you can reach one or any of these, you MAY be in business. If you can't reach any of them, you're probably SOL.

If one of these was reachable, then it is possible your solution can work. You point your browser towards the proxy on your local system, point that to port 64444 (or whatever) on your external proxy and your surfing the internet. Use SSL if you like or not.
posted by poppo at 12:16 PM on May 11, 2006

I was wondering how they could decrypt SSL too. Basically, they can't because if it was this easy then the whole damn protocol would be pointless.

What I think happens is they configure your browser to send HTTPS traffic unencrypted to the proxy. Then it's the proxy's responsibility to initiate the HTTPS connection, validate the certificate, and encrypt the content.

Now, how do you defeate it? Theoretically, it isn't that hard and you're on the right track with a local proxy. Basically, your local proxy would take the HTTP data, encrypt it somehow, and then post it as the body to a CGI on a remote server over HTTP. The remote server decrypts the body, performs the request, and encrypts the response and places it in the body. Your proxy would decrypt this and send it to the browser.

I'm not aware of a proxy that does this, but that's basically how you'd do it.
posted by sbutler at 12:20 PM on May 11, 2006

poppo: spoonman already said only 80 and 443 was allowed.

If you're only after email what I'd do is have something to pick up your email, PGP encrypt it and make it available in a standard web email system for you to download. You can decrypt it at your end by hand. Since you have fixed a definite key at both ends yourself, manually, you are safe.

I'd give up trying to do any actual web surfing (especially any internet banking etc.) from your workplace.
posted by edd at 12:20 PM on May 11, 2006

So, how do you defeat this? Tunnel SSH over HTTP(S). Since they're intercepting HTTPS already, you might as well not use it. They'd know pretty much for sure, though, that you're tunneling large amounts of data over HTTP.

But, one may say, if they can intercept SSL, they can intercept SSH, right? Detecting man-in-the-middle attacks on SSH can be a lot easier, since your SSH client doesn't blindly trust installed certificate authorities like a web browser does. It trusts the private key of the remote server, and that alone. That's why when you first connect via SSH, it asks to accept and save the remote server's key, so it can positively identify it in the future. The weak point is that first connection, though. If that's compromised, the game is over. You'd have to bank on the fact that your company isn't going to intercept the somewhat novel tunneling of SSH over HTTP.
posted by zsazsa at 12:21 PM on May 11, 2006

Wow, Finjan declares that it's protecting you from a man-in-the-middle attack by participating in one! Novel idea.

If your company is going to the extreme of installing an SSL proxy that tricks your browser into communicating with it rather than the end server, then you're probably hosed. I can't imagine that your company is going to use the new proxy but still allow your computer to directly access an outside computer's port 443 -- I'd imagine that with the proxy will also come new firewall rules that prohibit direct connectivity out to an SSL server, which means that your use of some software tunnel is dead in the water. I agree with effugas -- your only option is probably using EVDO or other wireless service to access whatever you're interested in accessing. (And such an option is probably OK with your company, too -- it's on your dime, it's on your bandwidth, and it's not touching their network.)

(In the end, though, these kinds of questions give me the willies. Your company has the right -- and, in this day and age, the absolute responsibility -- to decide what traffic is OK on its network, and efforts to get around that don't do anything but add to network insecurity by opening up paths of ingress/egress that the IT people don't know about and can't think through. I agree that a lot of companies tend to go overboard a bit... but I also agree that the best option is to work with them to find a solution.)
posted by delfuego at 12:22 PM on May 11, 2006

poppo: spoonman already said only 80 and 443 was allowed.

ah crud
posted by poppo at 12:24 PM on May 11, 2006

I'm thinking of a proxy that runs on my machine.

(1) If they are paranoid enough to decrypt your SSL, then attempting to defeat their security process will only get you in deep, deep trouble.

(2) Connecting to a bank or broker via your company's link probably violates your TOS agreement. Most banking TOS explicitly prohibit trying to decrupt or reverse-engineer the secure link. You could contact your bank and inform them that your company plans to read all your SSL traffic. The bank will probably tell you not to connect while at work, but they also might send a (politely worded) nasty note to your company about their plans.

(3) Your own laptop plus your own cellular data connection, as effugas suggests is probably the way to go here.

For those preparing to give me a lecture, you can spare me the ethics of doing this.

I hear you, and agree. I'm just trying to say that fighting The Man at work will get you fired. You may be better off quitting on good terms so you can get a positive recomendation for your next job.
posted by b1tr0t at 12:25 PM on May 11, 2006

The Proxomitron web proxy implements an SSL unwrapping/rewrapping scheme that is probably very similar to how their proxy works (and I've implemented one myself before, too.)

That's why when you first connect via SSH, it asks to accept and save the remote server's key, so it can positively identify it in the future. The weak point is that first connection, though.

I agree that this is probably the right way to tunnel. However, you can fix the key problem, because you can just bring your personal server's public key in on a disk and install it on your computer, avoiding a network intercept. (I assume that if you can install the tunneling software, that that won't be a problem.)
posted by sonofsamiam at 1:00 PM on May 11, 2006

Strange and ironic that they claim to be looking for maximum security, and then proceed to demolish any sign of it.
posted by clord at 1:09 PM on May 11, 2006

Yeah hombre ssh tunnelling is your only hope.
posted by Mean Mr. Bucket at 1:14 PM on May 11, 2006

No, that is maximum security for the company. Anything can be piped over SSL, without the ability for anyone to know what is being passed through. A firewall becomes useless if you can map any port through an SSL or SSH tunnel. The security is from an operations perspective, not from a user perspective.

Here's a thought: could an IPSec VPN be setup? I don't know if those solution would also be able to monitor IPSec traffic. Might be more of a hassel to set up, but would have better security.

What ever you use, if they go through all the trouble to intercept SSL, they will also have an IDS on the outgoing pipe that uses stateful packet inspection, which will find anything funny like an IPSec tunnel, and cut it off.
posted by zabuni at 1:18 PM on May 11, 2006

For a real example of decrypting SSL and SSHv1 (!), just look at ettercap. SSH will show a huge warning banner or prompt you to add a key (ettercap forces ssh1 - keys are different than ssh2).

I really doubt that tunneling SSH2 over SSL will work. When there's already this level of sophistication, I bet HTTPS's CONNECT method is blocked. I've only ever seen it used for things like this anyways.

You should complain right now that you can't get those updates that are required to do your job. Do not mention that you've been bypassing security to get them. They might (and should) give you special privileges. Otherwise, start complaining up the management chain.

I've been down this path before. Once I was caught, the repercussions were not too bad - I can't guarantee the same for you.
posted by easyasy3k at 1:29 PM on May 11, 2006

Actually, HTTPS CONNECT probably isn't blocked, just not implemented. Why bother implementing something that's almost never used (and mostly for defeating your product)?
posted by easyasy3k at 1:33 PM on May 11, 2006

Buy a USB flash drive and install portable Firefox on it. This gives you a trusted endpoint for your communications - a client YOU can trust, ahem, not to be backstabbing you in the encryption department.

Using that Firefox, you'll either be able to continue to access your webpages or you won't. If you get SSL warnings about bad certificates - which you will, if they're screwing around with proxies - then you can either accept their proxy certificate (in which case the employer can read everything) or not, in which case you probably won't be able to connect. But at least you'll know the score, when you're using a secure client, one that you installed on your own flash drive.

You can't stop them from blocking you from connecting - after all, they could just cut your ethernet cable. But you can know whether your allowed connection is being eavesdropped upon.
posted by jellicle at 1:44 PM on May 11, 2006

Similar to jellicle's suggestion, use TorPark (which includes Portable Firefox and the Tor anonymizing system from a USB key. Tor can run over http proxies, and will encrypt things on a higher level than the local decrypting & re-encrypting proxy does, so they won't be able to see what you're doing.

As far as them making your machine trust the Proxy server's SSL cert- they don't need to touch your machine at all. There are specific settings in Microsoft's Group Policies to enable this. You won't have any idea that they've applied these settings; it'll just happen.
posted by AaronRaphael at 2:02 PM on May 11, 2006

Oh, and note that Tor will slow your internet browsing down, so you'll want to run a TorPark instance for your personal sites and do everything else through whatever is company-provided.
posted by AaronRaphael at 2:03 PM on May 11, 2006

I'm going to second the EDGE/EVDO card for your laptop suggestion. It'll be slower, but won't touch the company's network. How's your cell signal in your office?
posted by Mr. Gunn at 3:33 PM on May 11, 2006

If you use tor or torpark (my suggestion also), make sure you configure it to only use ports 80 & 443 to make sure it gets through the firewall.
posted by scalefree at 3:55 PM on May 11, 2006

Heh, as a sys admin who looks after a bluecoat proxy I guess that makes me the bad guy here (Although we havent implemented the SSL interception).
I'm not familiar with some of the suggestions like TorPark, but if I understand correctly all that will do is bypass the proxy but any company that is employing that level of security is going to refuse any outbound traffic that hasnt originated from the proxy anyway.
I would second/third/fourth a connection that doesnt go anywhere near the corporate firewall - be it stealing an analogue phone line out of the nearest fax machine or installing a 3G card in your laptop. All solutions that are just as likely to get you fired, of course.

A little OT, but it seems really bizarre that a company would go to the lengths of intercepting https traffic, but still allow access to web-based email accounts as a matter of course. In my experience when companies start thinking about security and web browsing policy, access to hotmail and the rest, is the first to go.
posted by qwerty155 at 6:01 PM on May 11, 2006

*to have a firewall configured to refuse any outbound traffic that hasnt originated from the proxy
posted by qwerty155 at 6:05 PM on May 11, 2006

Buy a USB flash drive and install portable Firefox on it. This gives you a trusted endpoint for your communications - a client YOU can trust, ahem, not to be backstabbing you in the encryption department.

Sorry but that is nonsense. If they set up their proxy as a transparent proxy (which is a very common thing since it requires no tweaking of the individual desktop systems) it will intercept all outbound network traffic on port 80 or 443. This means that regardless of what your browser is configured to do, your traffic is going through their proxy. Period. Just because your browser thinks it's not using a proxy doesn't mean it's not.
posted by Rhomboid at 6:44 PM on May 11, 2006

SSH to your home computer. Best suggestion I have.
posted by i_am_a_Jedi at 7:13 PM on May 11, 2006

If you need to defeat draconian security policies to do your job, the correct course of action is to speak to your boss.

If you need to defeat draconian security policies for personal reasons, the correct course of action is to be prepared to be fired.

If it's the latter, my suggestion is to get a Series 60 mobile phone with a data connection. If your personal use of the company's Internet connection requires more than Opera Mobile or an IM client on a mobile phone, and you work at a place that implements what you've decribed, they're probably already building a case to get rid of you.
posted by krisjohn at 8:50 PM on May 11, 2006

Rhomboid: you dont understand SSL. Please read up about SSL before writing on this subject again. SSL has among its design goals prevention (or more precisely, detection) of man-in-the-middle attack. Since the corporate proxy will not possess legitimately signed certificates for the end of the SSL connection, they will not be able to proxy SSL communications without a certificate warning appearing in the browser.

There's no such thing as "transparent proxying" of SSL connections. By design.
posted by jellicle at 5:38 PM on May 12, 2006

Oh, no I know exactly how SSL works. I think it's you that need to read up. In fact others have already explained in this thread above how transparent proxying and SSL works. The proxy replaces the certificate presented to the browser with one of its own, and establishes the connection with the end destination server as usual. The difference to the browser is that it will be presented with the certificate of the proxy and not the end site. Of course, for this to work without a dialog the CA used to sign the cert of the proxy needs to be added to the trust list in the browser, but again this can be easily automated using group policy under AD.
posted by Rhomboid at 6:51 PM on May 12, 2006

And you might say "well that is why you need your own trusted browser that does not have the proxy's CA in the trust list", but that is also nonsense, because it doesn't do anything to solve the problem. Even if you had such a browser, you would either a) get a warning dialog for every https site you visit, b) add the proxy's CA to the trusted list to make the dialog go away, or c) not browse https sites. But none of a), b), or c) involves actually going to the site without your traffic going through the transparent proxy and being decypted along the way, which was the goal of the question.

The fact is you can argue semantics about how requiring the browser to have the proxy's CA added to its trusted list means it's not truely transparent, but in reality transparent SSL proxies are extremely common and in widespread use in business/enterprise settings for the very reason that it is so effective and easy to administer. So it is nonsense to say that "there is no such thing as transparent proxying of SSL".
posted by Rhomboid at 7:02 PM on May 12, 2006

Rhomboid -

I think your definition of transparent is different than everyone else's. Cheers!
posted by cactus at 4:18 AM on May 13, 2006

It is transparent in that the end user has no explicit proxy configured in their browser, can visit any https site without any security warnings or popups, and yet all traffic goes through the proxy where it can be decrypted and logged. An unaware user would have no idea that a proxy is even in the picture -- just as with a standard transparent proxy used for unecrypted traffic on :80.
posted by Rhomboid at 4:15 PM on May 13, 2006

Well, quite the war I've started here. Sorry 'bout that. :) I think I'm going to have to go the personal laptop/EVDO route. I've already tried a number of the suggestions here, and for the most part they all rely on HTTP CONNECT, which I'd already determined was disabled (I know it's implemented in the proxy they use, but they were actually smart enough to disable it).

I appreciate all the suggestions, though. I'm actually not all that surprised I wouldn't find a route out. As an SE, I've worked with this security team for a year and a half and haven't been impressed with their skills, except the one guy they fired for constantly pointing out their miscomings. :) Of course, they pretty much outsource every project I've been on with them, so it's really not them securing the network...
posted by Spoonman at 5:14 PM on May 15, 2006

Couldn't you run another SSL session through the first SSL session? I found this article on SSL.com (http://info.ssl.com/article.aspx?id=10241&query=secure) that describes the fact that you need a public key and a private key. How are they going to decrypt your SSL session without the private key?
posted by nuttysqurrl at 6:02 PM on May 30, 2006