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.

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.

share|improve this question
1  
Maybe this can help you .. . –  Arun Aug 21 '13 at 12:51
    
thanks, very helpful. –  vtortola Aug 21 '13 at 23:41

5 Answers 5

up vote 4 down vote accepted

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. 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

share|improve this answer
    
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 9:24
    
(Also, to a first approximation, OCSP doesn't work: imperialviolet.org/2011/03/18/revocation.html) –  armb Sep 12 '13 at 15:36
1  
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

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

share|improve this answer
    
Check this link 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
    
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? –  ntrrgc Aug 21 '13 at 16:05

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,

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
    
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

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.