Information Security Asked by sentinel on January 20, 2021
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)?
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.
Answered by Navid on January 20, 2021
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.
Answered by AJ Henderson on January 20, 2021
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 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:
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:
Answered by mr.spuratic on January 20, 2021
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.
Answered by sneak on January 20, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP