12

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)?

sentinel
  • 121
  • 1
  • 1
  • 3

4 Answers4

11

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.

sneak
  • 211
  • 1
  • 3
  • " 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 '14 at 05:18
  • @Shurmajee, it's not possible. The proxy has to create and sign a custom certificate for each site visited. – John Deters Jan 29 '14 at 05: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 '14 at 05: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 04 '14 at 12:02
11

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 the connection, only the matching private 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 (i.e. does not have the corresponding private key)
  • the client verifies the server certificate details (DNS name, date range, optionally revocation, and possibly "usage" attributes)
  • 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). There are some mitigations for this, including DANE, CAA and key-pinning.

The minimum set of fields that will change between a legitimate certificate and a proxy-generated one will be the public key modulus and certificate signature. If present the SKID and AKID fields (being derived from the relevant keys) will also differ. Validation related fields (OCSP, CRLs) will also likely be stripped, though it would be technically possible to provide these services for the pseudo-CA also.

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, fetching the real certifiate, duplicating every other detail of the certificate chain (excepting modulus and key-derived AKID/SKID, and signatures). Once any detail of a certificate is changed, the computed fingerprint (digest) will also (with a high probability) change.

(With corrections for confusing of exponent/modulus, thanks to dave_thompson_085 for noting this.)

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 may give it away (though this is not always true)
  • may have many other fields in common (serial number, date) but probably won't (serial numbers need special handling since they must never be reused per-CA)
  • revocation (CRL, OCSP) details will probably be subverted or removed from the certificate
  • will should not be signed by a commercial CA (Trustwave engaged in this dubious practice in the past), 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 or the AKID/SKID linkage.

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:

Community
  • 1
mr.spuratic
  • 7,977
  • 26
  • 37
  • 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 '14 at 15:39
  • 1
    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 '14 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 '14 at 21:51
  • 1
    Nit: the faked cert must have a different _publickey_ and _issuer_, and thus signature because both of those are in the signed content, and thus fingerprint. For RSA publickey the modulus must be different but the public exponent is almost always one of a handful of conventional values, and usually 65537 (chosen as the fourth Fermat prime and nicknamed F4) thus the same. For DSA and ECDSA publickey is a group element and there is no exponent (privatekey is exponent, but is not in cert, or handshake). Otherwise excellent. – dave_thompson_085 Oct 23 '17 at 03:42
1

HTTPS or SSL proxies are not secure, Constantly they use alternative SSL certificates to show on user's browser, In other word you have not a real HTTPS connection with web server, and your login pages and private data open in proxy server. Simply by checking https://google.com certificate via a proxy and Direct mode you will find different Verifies.

Benoit Esnard
  • 13,979
  • 7
  • 65
  • 65
Navid
  • 11
  • 1
1

Depending on the key exchange used, with RSA key exchange the client will essentially choose the session key (it's a bit more complicated than that, but irrelevant to this discussion) and encrypts it with the server public key (from the certificate). Since the proxy 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.

In a DH key exchange, the initial exchange could be completed, but the client would then challenge the proxy to respond with a verification that it has the private key associated with the certificate and the proxy would be unable to provide a response to this challenge.

The proxy must instead clone the certificate details on the fly and create a new certificate to be used for that site. This way, it has the private key that corresponds and can form it's own connection to the desired server. Because the proxy has a root trust on the systems it is servicing, the cert is accepted as valid, though if a system is used both on and off the proxy, certificate pinning may result in an error being detected due to the public key changing.

AJ Henderson
  • 41,896
  • 5
  • 63
  • 110
  • 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 '14 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 '14 at 15:35
  • The session key is not generated by the client; is not encrypted; is not transmitted; and is not decrypted. It is calculated independently by both peers via a key agreement protocol. – user207421 Mar 21 '17 at 04:12
  • @EJP - while my explanation is a simplification (perhaps an oversimplification), it is also incorrect to say that the key is generated independently on both without any encryption, decryption or transmission. The exact mechanism depends on the key exchange algorithm used, but if RSA is used, then a pre-master will be generated on the client, encrypted, sent to the server and decrypted, then combined with portions of the hello messages to generate the session master key. The full details weren't really relevant to the question being asked though. – AJ Henderson Mar 21 '17 at 13:53
  • @EJP - I have updated the answer to include details for both DH and RSA key exchanges as well as some additional clarification just in case someone tries to read too much in to a simplified explanation. – AJ Henderson Mar 21 '17 at 14:08