4

Say my domain (https://example.com) SSL private key has been stolen and was not protected by a passphrase then.

  1. Can the attacker uses that key and certificate to host the same domain on different server, if he can some how convince DNS server to point to new server ip address.
  2. Will there be any alert at users end

I just want to know if the above case is possible,I am aware about how he can use that to decrypt traffic.

Ali Ahmad
  • 4,784
  • 8
  • 35
  • 61
Kevin Parker
  • 197
  • 1
  • 10

4 Answers4

7

Yes, if someone steals your private key, then he can make a fake server with the same name, and users won't see anything wrong with it (provided the attacker redirects connections to his server, e.g. by altering the DNS).

No, users will not be warned.

From the point of view of both the CA and the user browser, a fake server with a stolen key is not different from a Web server being moved to another IP address, e.g. as part of a DNS-based load balancing. When you have a server and a certificate, the certificate is in no way locked to whatever IP address you presently used; browsers only check that the server name appears in the certificate (see RFC 2818, section 3.1). You are free to copy your private key and certificates to another server with another IP address, and make the DNS point to that new address. The only difference with the attack scenario you describe (key theft) is that this time you really want it. Whether you agree to the IP move or not cannot be checked by the client, and, correspondingly, the client does not check it in any way.

So protect your private key, and, if it gets stolen, report the theft to your CA which will then revoke the certificate.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
6

As an extra information to the other answers:

Assuming you know that an attacker has stolen your key and you have contacted your CA and asked them to revoke the certificate, then browser alerts may be triggered.

Modern browsers check if a certificate is valid by using OCSP (Online Certification Status Protocol) and the users are warned when they access sites with revoked certificates.

Dinu
  • 3,166
  • 14
  • 25
  • 1
    That being said, some browsers treat inability to verify revocation status as a "soft fail" and will trust the certificate. So, if the attacker that has your site's private key is able to fully MITM your traffic (e.g. via a rogue AP), they can refuse access to the OCSP server and pass the revoked certificate as still valid. Chrome has repeatedly threatened to not even bother with OCSP, famously calling it "seat belts that snap when you crash" (http://arstechnica.com/business/2012/02/google-strips-chrome-of-ssl-revocation-checking/). – mricon Jan 31 '13 at 15:34
  • It is true, but the problem was that the server certificate is compromised and not every user's network. I checked today and Chrome is performing Ocsp checks. – Dinu Jan 31 '13 at 19:43
2
  1. Yes
  2. No

If you can use that key and certificate to host that domain on your server then also the attacker can use that key and certificate to host the same domain on a different server.

That is if he can convince the DNS server to point to the new server IP address or he can just poison some DNS server on some network (which is easier than most people think) and target only users of that network, or spoof DNS responses on some some LAN and target users that are nearby (also easy).

Your users will not only not be warned. They will in fact get the information that the connection is secure - the padlock, green address bar, company name and all that.

Zed
  • 121
  • 2
1

It depends on your SSL certificate. Most SSL certificates are only 'locked' to a specific domain ('domain validated SSL Certificate'), so if an attacker could do what you describe, convincing DNS servers to point to a new IP address, then yes the attacker could use it to spoof your website as a phishing location. Some advanced 'single IP-address SSL certificates' can also be locked to a specific IP, though. In that case the scenario you mention couldn't happen and the user would be notified there's a problem with the SSL certificate used.

TildalWave
  • 10,801
  • 11
  • 45
  • 84
  • 5
    I have yet to see a certificate in the wild with an IP address in it, and, more to the point, a browser which checks that IP address. – Thomas Pornin Jan 31 '13 at 12:17
  • You often need **an IP address** per domain not because any specific address is embedded in the certificate but because the SSL handshake takes place before the browser gets a chance to send the HTTP `Host` header. The server has to know which certificate to send and it's easiest if every domain uses a separate IP. You can also use different port per domain, but then your address will be `https://example.com:12345/` instead `https://example.com/` for every port other than 443. There is now Server Name Indication to solve that issue but it doesn't work on Windows XP which stops its adoption. – Zed Jan 31 '13 at 12:36
  • @Thomas Pornin - To my knowledge the common name header in the SSL certificate (the one it's verified against with CA) can contain an IP address. Or a wildcard, for example for sub-domains `*.example.com`. I'm not sure what number of web browsers support such certificates, but according to the link I now added to my post, they quote 99.99% browser support. – TildalWave Feb 01 '13 at 01:34
  • @TildalWave: it is true that the `Subject Alt Name` extension can contain IP addresses; but it is equally true that no client checks them. Clients follow RFC 2818 and check names of type `dNSName`, i.e. server names. As for wildcards, they are supported but they are still about names, not IP addresses; and they are quite the opposite of "locking". – Thomas Pornin Feb 01 '13 at 11:59
  • @Thomas Pornin - But couldn't technically speaking that header simply contain an IP address? Saying it otherwise, if the DNS look-up doesn't resolve, wouldn't it default to the IP then? I'm not saying this is how it works, don't get me wrong, I'm just assuming based on my own understanding of things and it's also what value I return for non-resolvable DNS look-ups with my own socks libraries (default behavior, which can be changed of course). How can that business I link to in my post then offer _'SSL Certificates that are specially issued to secure an IP-address'_? Thanks & cheers! – TildalWave Feb 01 '13 at 15:32
  • @TildalWave: that name-checking business is totally disjoint from DNS. This is a certificate business and is described by RFC 2818 and it will certainly not look at the names of `iPAddress` because 1) it is not defined that way, and 2) it would break the security model: the idea is to verify that the _name which the user sees in the URL_ is found in the certificate. The user does not see the IP address. The IP address was obtained from the DNS in a non-secure way. – Thomas Pornin Feb 01 '13 at 16:16
  • @Thomas Pornin - OK, so if I get this right what you're saying is, if I make some website accessible through an IP only (say `https://1.1.1.1/`) for SSL encrypted connections, and the certificate is also pointing to this IP address instead of a domain name, then the certificate would not report any errors and there is indeed a way to _'protect an IP address with a certificate'_ like [that business](http://www.networking4all.com/en/ssl+certificates/products/by+type/ip-address/) is promising? Did I get this right? TA – TildalWave Feb 01 '13 at 16:51
  • @TildalWave: no, it is the opposite. You can put an IP address in a certificate, but no browser will look at it. Browsers _insist_ on using names (and the standards say that they must do so). – Thomas Pornin Feb 01 '13 at 16:55