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.

With the proliferation of low-cost automated CAs what can be done to mitigate the attack of someone doing a spear phishing attack to get a login to our webmail system, then using an automated service like RapidSSL to issue a new certificate for widgetco.com to OverlyTrustingReceptionist@widgetco.com?

I am sure some eyebrows would be raised at RapidSSL, if someone like google.com requested a certificate. Is there anything I can do too?

share|improve this question
1  
Don't most (all?) ssl providers only allow verification from a specific list of email addresses for a given domain? –  BrianAdkins Jun 2 '13 at 16:32
add comment

4 Answers

up vote 6 down vote accepted

This is really a matter of each CA's policies. Most of them require proof of ownership of a domain before issuing a certificate. Even with cheap CAs this usually involves either verifying an e-mail can be received by a WHOIS contact or making entries in the DNS records for the domain.

share|improve this answer
add comment

I agree with AJ that even cheap CAs involve verifying emails from data retrieved from a WHOIS request. But this sort of verification often has many holes in it and doesn't cryptographically ensure the validation. That is an attacker who can eavesdrop/alter unencrypted traffic on the internet can potentially:

  • intercept the email sent over the internet from the CA (SMTP is plaintext protocol; only sometimes sent with TLS),
  • alter the DNS response (again often sent in plaintext) for the domain of the administrative contact where the email is sent to,
  • do an ARP spoofing attack on the CA which again directs traffic from the CA to another computer,
  • alter the WHOIS request the CA makes (replacing the administrative contact email address with an attacker controlled address).

An attacker who can pull off any of these attacks should be able to then generate a CA-signed certificate. Again, these generally aren't the types of attacks that script kiddies could do, but an ISP or government potentially could do.

share|improve this answer
    
It's worth pointing out that a governmental agency that is local to the CA could also probably just force the CA to issue a cert without much in the way of tricks if they really wanted to. –  AJ Henderson Jun 2 '13 at 19:42
    
@AJHenderson - Agree completely. My point was the (weak) verification of free certificates has holes that people who can alter HTTP traffic may also be able to attack (not that powerful adversaries wouldn't have other options). Personally, I couldn't force you to go to the wrong IP when you try looking at security.stackexchange.com (as I don't control computers/routers in the path from your computer to SEC.SE), but others can (e.g., on your/SEC.SE local network or control a router between you). Not to say its hopeless; there are solutions (e.g., DNSSEC, doing WHOIS over TLS, etc.) –  dr jimbob Jun 2 '13 at 20:22
    
well actually for sec.se it is hopeless since there is no SSL so DNSSEC wouldn't do any good if they can fake an IP address. But yes, I get your point. –  AJ Henderson Jun 3 '13 at 4:32
    
@AJHenderson - Sorry that was confusing--I tried making two points. (1) While eavesdropping/altering HTTP/unencrypted data is straightforward to a local attacker (on your network/access your computer); I couldn't get you to go to an IP I control when you type the URL of sec.SE, even over HTTP with no crypto. A CA doing validation using unencrypted data over the internet is not trivial to attack; an average adversary can't MitM a CA doing a WHOIS query; most email uses TLS, etc. (2) Even so, crypto (DNSSEC, etc) could stop powerful adversaries (who in principle could do those attacks). –  dr jimbob Jun 3 '13 at 14:40
add comment

Browser and OS vendors (Firefox, Chrome, Microsoft...) include CA certificates in their default "trusted CA store" under some stringent conditions about how the CA operates -- its Certification Practice Statement. The premise is that if a CA misbehaves, e.g. by being too easy to swindle into issuing forged certificates, then the browser/OS vendors will remove the CA from the default trusted CA store. And the browser/OS vendors will do that only if it fits their own interest, a concept which is best expressed in financial terms.

So the only thing you can do, really, is to keep your lawyer primed and ready to fire. If a CA misbehaves and issues a fake certificate for your domain, threaten the CA, and threaten the browser/OS vendors, who must, by necessity, be the ones who ensure the cleansing of default trust stores. Ultimately, it is all a question of market pressure. "Fear will keep the local systems in line."

share|improve this answer
    
+1 for the answer and dead-on quote. –  u2702 Jul 22 '13 at 22:29
add comment

AJ got it right, there's very little a customer can do. The nature of this system is interesting in that it doesn't matter what the customer does, they can still be victimized. Going with a top-tier CA (and probably paying more) doesn't make you safe, any of the other CAs can issue a cert for your domain.

In a sense, the browser makers are the real customers of the CA. They accept and use the product of the CAs in the form of signed certs. If a CA behaves badly or has poor practices that lead to malicious certs, the browsers manufacturers can choose to remove that CA from their trusted store. That's probably a difficult call because removing a CA could impact a huge number of sites and businesses.

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