SSL Certificates and Proxies

[Lost In Cyberia]

In light of the recent Komodo fiasco, I was curious as to how SSL connections work with regards to proxies. In my company, when I'm at the desk or I vpn in from home, and I browse to an SSL connection... I look at the corner of my browser and ssl certs are all still unique. Meaning if I go to chase from behind the company proxy, chase's verfsign ev cert is given. Like wise if I go to say hak5, their geotrust cert is displayed.

Having thought about this, isn't the proxy supposed to hide these from me, and display to me a cert that the IT staff at my company created? So instead of seeing the Geotrust site, I may see our IT department's self signed cert? Is this not always the case?

So, because I still receive the "real" certificate from amazon or chase or something, what does this imply? What is the proxy actually doing then? Is it still even intercepting the SSL connection?

My thoughts on how it worked was that your browser makes the SSL request, which unbeknownst to your broswer it goes to the proxy instead. And the proxy makes the connection, and then passes down to you a certificate that is just for inside the company or something.

Like I said, since each ssl connected site I go to, appears to have it's original certicate path displayed, I don't think my companies proxy is actually doing any intercepting and changing. Anyone (Cooper) care to shed some light on this?

[cooper]

Anyone (Cooper) care to shed some light on this?

You rang, milord?

There are 2 options:

1. The proxy simply gives you a socket to the intended target machine. This is by far the most common form of SSL proxying, and it's what, for instance, allows me to connect to my home SSH server. Precisely because the proxy can't look at the actual traffic that passes through it, it just passes the data back and forth, much like a tunnel, and assumes you know what you're doing. All you told the proxy is the name of the target machine and the destination port which, in most cases, will be restricted to 443. At some places the hostname will need to be on a whitelist, but this already fairly uncommon.

2. The proxy has its own certificate for SSL traffic and this certificate is in your local machine's truststore which means that any cert signed with that cert for the given domain name will be considered by your machine as the real host. What the proxy does is when you connect to it saying "Gimme a socket to website.com on port 443" it will MITM you by providing your an HTTPS connection with itself using a self-generated cert signed with the proxy's own SSL cert. Because the cert is for the domain you requested and signed by someone in your truststore, your browser will show all the requisite signs of a proper HTTPS connection but all traffic goes encrypted to the proxy, gets decrypted and the proxy then does its own HTTPS connection to website.com to do whatever you wanted to do. This allows better performance from your proxy server (because it can cache server responses) and allows your employer to ensure what you're doing is on the up-and-up so you tend to see this setup mostly at higher-security locations like banks and the military. The only way for you to see something might be amiss is by inspecting the certificate chain and noticing that the root cert in the chain isn't one of the big boys.

[digip]

In light of the recent Komodo fiasco

Is there something recent/new with Comodo, or is this from last year or so's SSL Cert incident? Just curious since I can't find anything recent about any new issues and wondering what's up.

https://www.google.com/search?q=comodo+ssl&num=50&newwindow=1&hl=en&gl=us&authuser=0&biw=1916&bih=924&tbs=qdr:m,sbd:1&tbm=nws&source=lnt&sa=X

[Lost In Cyberia]

Been away for a while, thanks for the response Cooper! The first option you gave, is is a probably a very basic proxy. It checks domain names, ip's etc, but can't peer into ssl connections right?

The 2nd option you gave, the proxy that you connect to (this makes sense because when I'm at work I have to switch my internet browser to use 'local proxy settings") That proxy that you connect to should have it's own pair of ssl keys correct? Also the proxy will install a cert on your OS cert store...but for a browser like firefox which doesn't use the OS Cert store ( Firefox has it's own store of certs) does the act of me selecting the "use local proxy setting" then switch firefox to use the certs on the OS?

Lastly, I'm currently on my work network now, and when I look at the cert heirarchy for SSL sites, the heirarch checks out, I'm seeing top CA's like verisign, equifax, and digicert. Can these be faked? What about the original cert fingerprint? will that be the same rather you're using a proxy or not?

[cooper]

can't peer into ssl connections right?

Exactly.

That proxy that you connect to should have it's own pair of ssl keys correct?

It's not a "pair of keys" but a "key pair". The distinction being that the former implies 2 separate keys whereas the latter implies a single key made up of 2 parts, which is what we have here. Otherwise, correct.

Also the proxy will install a cert on your OS cert store.

Um, no. A proxy can't make that happen. It can serve you with a cert when you go to a website, but you're going to have to accept that in your browser before any data gets transferred, meaning that your friendly sysadmin must've already placed the proxy's certificate inside your keystore as a trusted cert.

does the act of me selecting the "use local proxy setting" then switch firefox to use the certs on the OS?

The 'local proxy settings' specify where the proxy is for which protocol, and which domains should be accessed directly, rather than by going via the proxy (a.k.a. non-proxy hosts), which is useful for intranets and locally hosted (development) webservers for which your friendly sysadmin set up a dns name.

Can these be faked? What about the original cert fingerprint? will that be the same rather you're using a proxy or not?

Well now, this would be rather disingenuous, but it's fair to check for it. The friendly sysadmin could've replaced a trusted CA's cert in your local keystore with the proxy's cert which was constructed such that it appears to be the cert for that trusted CA. One way to verify it is to compare the chain you see at work with the chain you see elsewhere (at home, mobile, what have you) where you compare the Certificate Signature Value field of each link in the chain with the one you see elsewhere. The certificate chain should be identical everywhere, so the same links should appear and the signatures of each of the links should be the same as when viewing the chain elsewhere.

From a management perspective, it doesn't make a lot of sense to replace the trusted CA's cert in your keystore because certificates expire every so often so they need to be replaced once every few years and if you replace the cert of a known CA the installation of an update to the keystore brings with it the risk of it replacing the proxy cert with the CA's cert again.

The sysadmin simply wants you browser to accept the proxy's signed key to be accepted by your browser which can be accomplished easily by just adding "Company Proxy Cert" to your keystore. Hardly anybody verifies their traffic is using HTTPS, and those that do only look at the icon in front of the URL. Practically nobody verifies the certificate chain. So why bother with trying to hide the proxy cert in your keystore? The only reason would be because you're explicitly trying to hide the fact that you're decrypting the https traffic on the proxy from the user, which is pretty evil and potentially actionable since it means you know your users aren't aware they signed away their right to private communications and you're trying to make sure they can't find out about it either. Signing the right away can be made legal, but not being up-front about it is likely to undermine that legality.

Consult a lawyer if you feel something like this is happening though - I'm just a tech.

[Lost In Cyberia]

There is a reason why I specifically 'rang' for you cooper. You are a gentleman and a scholar!