8

As far as I know, the browser contains the certificates of several CA. When I access http://gmail.com, the site says it is Gmail, it exposes a certificate signed by one of the CA I have in my computer, that way it knows that the site is who it pretends to be since a CA back this claim.

But, what if in my office computer, my employer set its own CA certificate in the machines, and does a Man-in-the-Middle attack?

  1. My employer store a fake CA certificate in all the machines as Googlee Corp. (note the typo)
  2. I access http://gmail.com
  3. A proxy catches the request, proxy the response.
  4. The proxy returns custom certificate signed by Googlee Corp.
  5. My computer assumes that the certificate is valid, because a CA certificate installed in my computer backs the claim.
  6. The browser shows that I am through a secure connection to Gmail.

Thanks.

vtortola
  • 183
  • 1
  • 4
  • 1
    Maybe [this](http://security.stackexchange.com/questions/16293/how-can-end-users-detect-malicious-attempts-at-ssl-spoofing-when-the-network-alr) can help you .. . – Arun Aug 21 '13 at 12:51

6 Answers6

9

Once upon a time, you could check your root certificates against a paper book: http://www.cl.cam.ac.uk/research/security/Trust-Register/

These days, try to check as many independent sources as possible - for example install different browsers on different operating systems on virtual machines, and see if they agree with each other.

If you are worried specifically about your employer, print out a list of the root CAs at work and take it home and compare it with your home machine. (Or vice versa, bring in a printout from home.) If you work somewhere that isn't allowed, I'm surprised you haven't just been told to accept a new certificate and that you will be monitored anyway.

If you think the NSA have compromised both your work and home, and anyone you ask to burn you a CD-ROM for a clean install might also be an NSA plant, you have bigger problems. (And if you're right to think that, even bigger problems than that.)

Edit: Something I forgot - certificate pinning (draft standard). This will warn you if the certificate used by e.g. http://gmail.com changes in an unexpected way, so may alert you to a MITM attack. A explanation of how it works for Google: https://www.imperialviolet.org/2011/05/04/pinning.html

And DANE. That's not really something you can do, but it's something that may alert you to that sort of attack if it is adopted. See also https://www.imperialviolet.org/2011/06/16/dnssecchrome.html

armb
  • 622
  • 4
  • 9
  • what about OCSP? Cannot be used for this scenario? – vtortola Aug 21 '13 at 23:50
  • If someone has inserted a root CA, then it will point at an OCSP server they control. – armb Aug 22 '13 at 09:24
  • (Also, to a first approximation, OCSP doesn't work: https://www.imperialviolet.org/2011/03/18/revocation.html) – armb Sep 12 '13 at 15:36
  • 2
    Something I didn't mention and should have - if your browser has been replaced by a patched copy, the list of root certificates it displays might not be the real list it effectively uses internally. And the certificate it displays when you say "show me details of the current connection" might not be the real one. If you aren't allowed to install new software, even inside a VM, nor run portable software from e.g. a USB memory stick, there's not much you can do about that. That's going further than the scenario in your original question though. – armb Sep 16 '13 at 10:49
  • Yes, that is probably the key thing. If the machine cannot be trusted, nothing in it can be trusted. – vtortola Sep 17 '13 at 21:58
7

If somebody (anybody) has root/admin access to your machine, it's not your machine any more: you're, at best, sharing it with them. Technically speaking, they are free to replace any (or all) your root certificates with exact copies that just have a different public key.

The only way for you to detect the forgery is to verify the fingerprint of EACH root certificate against a known good version (perhaps taken from another trusted computer).

Also, unless you verify the whole trust chain manually each time you connect to a web site, you will have to verify ALL the certificate in your trusted root store. Otherwise, a single root can be used to sign intermediate and leaf certificates that have nothing to do with the CA name (for instance, you can use a root labeled as "Microsoft root CA" to sign an intermediate CA cert claiming to be from Thawte and use that intermediate cert to validate a web server certificate for www.gmail.com).

Stephane
  • 18,557
  • 3
  • 61
  • 70
  • Check this [link](https://www.grc.com/fingerprints.htm) for fetching the fingerprint of a site's certificate . – Arun Aug 21 '13 at 12:53
  • 3
    GRC ? From Steve Gibson ? I'd really go to some more reputable source. – Stephane Aug 21 '13 at 12:56
  • I dunno much about GRC but why do u say that ? – Arun Aug 21 '13 at 13:01
  • 3
    Old history, mostly. Lookup Steve Gibson and forge your own opinion. Personally, I would be doubtful of anything he publishes: not about bad intends but about sloppy execution or incomplete understanding of the problem at hand. For instance, listing fingerprint of leaf certificates is of dubious use: a certificate can be changed at any time and it is very possible for several, different, legit certificates to be used by the same domain. – Stephane Aug 21 '13 at 13:16
  • 1
    If somebody has root access to your machine, they could have modified your web browser to ignore certificate issues or just installed a backdoor that sends them your password. What's the sense of worrying about CA being spoofed then? – Alicia Aug 21 '13 at 16:05
  • what about OCSP? Cannot be used for this scenario? I see that firefox has options about it. – vtortola Aug 21 '13 at 23:52
  • OCSP will not help you: the OCSP server's address is in the certificate itself and the attacker controls this field (he can just set it to blank). OCSP and CRLs are mechanism for checking the revocation of valid certificate, not detect fraudulent ones. – Stephane Aug 22 '13 at 07:35
5

One thing to mention is that Google Chrome expects all Google-owned sites (GMail, YouTube, Google+, and all the search sites) to present a very specific certificate. Not only a trusted one, but the one Google itself knows it provides with these sites. If you've been MITMed, the certs won't match and Chrome will warn you. This practice is called "certificate pinning", and it's not uncommon (though different software will pin different certificates of course). You can also do it yourself, by going into your certificate store and installing a certificate that you know is from GMail, then specifying that you will accept no other certificate for the listed domain until you say otherwise.

Since the computer, in this case, belongs to your employer, it's relatively easy for your employer to work around it; they can simply take steps to enforce an IE-only office. Group Policy also allows a Windows domain controller to push whatever certificates they like (and rescind or revoke others). In short, if it's your employer's network and your employer's computer, there is very little your employer is not allowed to do with it with regards to your expectations of privacy at work,

KeithS
  • 6,678
  • 1
  • 22
  • 38
3

If a bad guy controls a CA that your computer trusts (e.g. because it was installed as a root CA on your machine), then that attacker does not need to rely on anything as crude as a typographically similar name; he can make a fake certificate which says "gmail.com" in all its details, and claim to be certified by VeriSign, the Food&Drug Administration, and the Pope. Root certificates are said to be "root" because they really are at the root of your trust.

You could try to get some external validation; for instance, you could try to phone Google's headquarters, ask to speak to a sysadmin, and see if he could spell out to you, over the phone, the "thumbprint" of the certificate. You could then compare it with what you see on your side; this would detect foul play. However, this assumes that the phone is "intrinsically secure" (a rather dubious assertion at the best of times), and also that you will find at Google's a sysadmin with enough free time and humour to actually respond to such a request.

A more fundamental issue is that if some attacker could plant a rogue CA in your computer, then there is little reason to believe that he stopped there. Manipulating the trust store requires administrative rights; the same attacker could have installed a key logger or other kinds of malware. He could even do it afterwards because normal software updates are signed: with his rogue CA, the attacker could fake-sign some fake updates full of nasty code.

Thus, usual wisdom are that if you suspect that your root CA have been manipulated, then you cannot really salvage your machine except with a full format-and-reinstall of the operating system (and, even then, this cleanses the machine only if no virus has been installed in the flashable parts like the BIOS and the firmware of some peripherals).

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • what about OCSP? Cannot be used for this scenario? – vtortola Aug 21 '13 at 23:51
  • OCSP has no relation whatsoever with the problem at hand. An OCSP response may be trusted only after verifying its signature against a "known good" public key, so it comes after certificate validation, not before; and, in any case, OCSP does not give you assurance that a given certificate is "correct", or even that it exists at all. – Tom Leek Aug 22 '13 at 12:14
2

Trust has to start somewhere. The Root CA Certs on your system are the start of that trust. There is no way to validate them. You can try to obtain them from multiple locations to make sure that they are from the company they claim to be, but ultimately, installing them is a declaration that you trust them to say who you should trust and that is a leap of faith.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
1

Late to the party... You can use this fingerprint tool:

https://www.grc.com/fingerprints.htm

Go there, type in any website (URL) that you are interested in and compare the fingerprint displayed with the one your browser displays.

If the fingerprints don't match, your employer's proxy does intercept your connection.

This most likely even works, when the organisation running the proxy is itself a trusted Certificate Authority or the root certificates of your machine have been manipulated, because the certificate, although issued with the website's matching name, will not have the same fingerprint.

To work around this, the employer would have to manipulate the browser to display a different fingerprint than the certificate in use actually has, which I consider unlikely. You could test even this case with a machine with a "clean"/live OS on the employer's network and compare the displayed certificates.

Marcel
  • 3,494
  • 1
  • 18
  • 35
  • 2
    They don't _have_ to manipulate the browser, they can edit the results page from GRC so that they appear to match. That's unlikely, but to test against it you need to compare with a machine outside the employer's network. (Also, there are legitimate (but unlikely) scenarios where you will get a mismatch - if the site is actually using multiple load balanced servers around the world, they could use different valid certificates for different machines. Or a server might have both RSA and ECDSA signed certificates, and your browser use one that GRC doesn't ask for.) – armb Jan 02 '15 at 15:09