Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I know that TLS (commonly but mistakenly called SSL) interception works by establishing two encrypted tunnels between a client and server, with the interception device (proxy) terminating both tunnels in the middle. To obfuscate that interception is occurring, however, the client's machine must be configured to accept the proxy's certificate as trusted, so the user doesn't receive a pop-up message that identity cannot be established. This is easy to do in corporate environments where client machines are joined to a domain that can quietly push out certificates in users' root directories.

Now, when you access a website through TLS, you can view that site's certificate in your browser. If there is an intercepting proxy in the middle, does the site's certificate in the browser change if you check it? In other words, while the proxy can't duplicate the server's certificate for the purpose of establishing the TLS tunnel to the client (because it needs the server's private key which it doesn't have), can it still just visually output the server's certificate to the user, so that they are unaware, just by looking at the certificate, that interception is occurring? So for example, you're in a corporate environment that intercepts all TLS connections, and the organization's proxy certificates are installed on all clients. You don't get a pop-up if you connect via TLS to your bank account, but on the bank's site, will the certificate still display the same fingerprint as it does when you connect from home, where you can assume (at least for the purpose of this discussion) that you are connecting securely and directly?

Stated differently, is checking a secure site's certificate enough to detect a man-in-the-middle, or do you have to look through all your trusted certificates on your corporate laptop to determine if any of them are unusual (i.e. the company's)?

share|improve this question
add comment

3 Answers

As noted by sneak, the client will receive a certificate generated by the proxy, not the original site certificate. The reason being that the proxy cannot impersonate a site with its certificate alone, it must have the corresponding private key.

The certificate is an integral part of the TLS* set up (i.e. it's not a "site seal" or similar nonsense). Its content (public key) is used by the client to encrypt connection details, only the matching server key can decrypt this to successfully complete the connection. The proxy can only present its look-alike certificate for which it does have a key, this will have (with a very high probability) a different fingerprint or hash.

[* There are lots of options when negotiating TLS, two of the main features authentication and encryption have "null" options, though these are not typically seen for HTTPS. If you use a null authentication method, no certificate is required, e.g. ADH]

The general method of such TLS interception is that the proxy will generate (on the fly, thereafter cached) a key and certificate which match the DNS name(s) of the destination, the certificate will be signed by a pseudo-CA, stored on the proxy, which will be "trusted" by your OS/browser.

The trust works like this (to simplify slightly):

  • the server presents a certificate containing the public key, because the client uses the server's public key to subsequently encrypt the symmetric key, the TLS setup will fail if the server is unable to decrypt the message from the client
  • the client verifies the server certificate details (DNS name, date range, optionally revocation)
  • the client verifies the chain of trust up to a known (local copy) trust anchor (typically a self-signed root CA)

The reason the proxy can succeed is that your browser "trusts" the corporate pseudo-CA, usually by virtue of desktop policy, customised browser deployment or similar. The problem with the trust model is clear: conventionally any CA can sign a certificate for any name (and usually, delegate by way of a subordinate CA too).

The minimum fields that will change between a legitimate certificate and a proxy-generated one will be the exponent and signature. In reality though the generated certificate will probably only superficially resemble the real certificate (enough to pass the date and DNS name tests), and be directly signed by your company proxy's pseudo-CA. It is however entirely possible to reproduce a legitimate looking CA hierarchy, duplicating every other detail of the certificate chain (exponents and signatures excepted). Once any detail of a certificate is changed, the computed fingerprint (digest) will also change.

To summarise, any proxy-generated certificate:

  • must superficially resemble the real certificate, the DNS parts (CN and/or subjectAltNames) must match
  • is probably immediately obvious since the "issuer" field should give it away
  • may have many other fields in common (serial number, SID, date) but probably won't
  • will not be signed by a commercial CA, will not have the same signature data, and will not have the same fingerprint

does the site's certificate in the browser change if you check it?

Yes, you can probably just inspect the Issuer field, or computed fingerprint, but you need to validate the entire chain to be certain.

can it still just visually output the server's certificate to the user, so that they are unaware, just by looking at the certificate, that interception is occurring?

No. The HTTPS server (be it a real web server, or a proxy) has no control over this (user-interface problems, rogue extensions, and faked location bars aside). What the browser displays is the certificate that was used during the TLS connection set up, it is not a file fetched over HTTP.

is checking a secure site's certificate enough to detect a man-in-the-middle, or do you have to look through all your trusted certificates on your corporate laptop to determine if any of them are unusual?"

It's probably obvious from the certificate alone, the generated certificate will likely be directly signed by the proxy's pseudo-CA certificate, and that will probably be easily identifiable by text fields (at least "Issuer") in the certificate. To be thorough, you should compare all certificate fingerprints.

FWIW, EV certificates get you a tiny little bit of extra protection here: the proxy cannot fake a true EV certificate because any competent browser will have a hard-coded list of EV capable CA certificates. (It doesn't solve the chicken-and-egg problem though: how do you know when to expect or require an EV certificate?)

The IETF's DANE is proposed as a more robust solution. It addresses the underlying problem with the trust model:

The public CA model upon which TLS has depended is fundamentally vulnerable because it allows any of these CAs to issue a certificate for any domain name.

In order to actually solve the problem, rather than kicking it a little further down the road, DANE requires DNSSEC. There is also one simple countermeasure: client certificates, but that's not a general solution for various reasons.

Other (partial) solutions include:

There are others such as Convergence, Verikey [PDF], CertPatrol (Firefox plugin), Monkeysphere (multi-protocol)

See also:

share|improve this answer
    
Thank you for the wealth of information. So, maybe I wasn't clear in my wording, but my question was if it is possible for the proxy to present a different certificate to the client than the one actually used. If I notice that the SHA-1 checksum for Gmail is the same on two computers, one corporate at work and one personal from home, does that mean there is no proxy at work, or could it be that the proxy is presenting me with Gmail's certificate, while actually using its own for TLS (which means the company's certificates are installed on my machine and I'd have to scout them out). –  sentinel Jan 30 at 15:39
    
Lacking the matching key, such a proxy cannot simply present the real site certificate. The certificate is an integral part of the TLS set up, its content is used by the client to encrypt connection details. Only the matching server key can decrypt it to complete the connection. No key = no TLS. The proxy can only present its look-alike certificate for which it does have a key, this will have (with a very high probability) a different fingerprint or hash. This property of TLS is referred to as "authenticity". –  mr.spuratic Jan 30 at 17:26
    
"The HTTPS server (be it a real web server, or a proxy) has no control over this (user-interface problems, rogue extensions, and faked location bars aside). What the browser displays is the certificate that was used during the TLS connection set up, it is not a file fetched over HTTP." Bingo, that's the answer to my question. I wanted to know if the proxy could subsequently inject the real certificate during the local retrieval process; it would still use its own certificate for the tunnel (which means it would show up if you looked for it carefully), but not at first sight. So, it can't. –  sentinel Jan 31 at 21:51
add comment

The certificate sent to the client will be the one generated by the proxy, not by the originating server. It can't send the end server's certificate because that certificate is specific to the key in use by the end server. If it changed out the key being sent to the client and didn't change out the certificate, validation would fail because the calculated hash of the public key would not match the hash in the certificate, rendering it invalid.

The browser or TLS client should show the trust path to whatever CA the intercepting proxy is using, whether installed by default (there are actually intermediate certificates for sale for these sorts of MITM setups, if you're a big enough corporation!) or installed by an organization through policy/management.

share|improve this answer
    
" changed out the key being sent to the client and didn't change out the certificate"..How is that even possible? The certificate is the carrier for the public key of the server. –  Shurmajee Jan 29 at 5:18
    
@Shurmajee, it's not possible. The proxy has to create and sign a custom certificate for each site visited. –  John Deters Jan 29 at 5:39
    
@JohnDeters yup, that was the point I was trying to make. I feel that this answer gives a wrong perception about the crypto and can be improved.. –  Shurmajee Jan 29 at 5:56
    
You guys are right, of course, though I was trying to clarify conceptually because of how the question was posed. The certificate of course does contain the public key of the server, but rather than go down that rabbit hole I was trying to ignore that fact and explain logically why the key has to be different (because of the fingerprint of the key itself in the signature part of the certificate). –  sneak Feb 4 at 12:02
add comment

Since the client chooses the session key and encrypts it with the certificate, the proxy can not use the certificate of the server. Since it does not have the private key to go with that certificate, it would be unable to decrypt the client's chosen key and would thus be unable to communicate on the connection. It instead has to clone the certificate details on the fly and create a new certificate to be used for that site.

share|improve this answer
    
Hello AJ, so what I meant was, even though the proxy must use its own certificate for establishing the tunnel with the client, can it still display the server's certificate to the client's user? In other words, can it use one certificate for the actual connection, and advertise a different certificate when the user checks a website? The advertised certificate is not the one used for encryption. The proxy would literally just have to clone it since it's publicly available. Or does the proxy not have that capability, that was my question? Thanks for your input. –  sentinel Jan 30 at 15:31
    
@sentinel - only one certificate is given to the client. You can't say "use this for encryption, but please believe me this other person is who I really am" That would defeat the entire point of the system. The server says "this certificate is who I am, encrypt something with the public key and I'll decrypt it to prove I am the owner." What they do is clone the certificate data, put in their own public key and sign it with their trusted root authority. Thus the data looks the same, but it is a different certificate with a different public key and a different signing authority. –  AJ Henderson Jan 30 at 15:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.