Putting that mapping in /etc/hosts lets your machine skip DNS lookup for that hostname, and just use his IP for that domain name.

Then, your browser checks the received certificate against the authenticated TLS connection, and sees that all is well, allowing you to connect without a warning.

Since the browser does not warn of a certificate mismatch, he must have a valid certificate for 'cloudflarechallenge.com'. QED.

But seems like only the http connection is working, i get a warning in Chrome when visiting https://cloudflarechallenge.com. Isn't that the only situation where the key would be checked. That's the part that doesn't make sense.

Subdomains are separate domains, and you put www.cloudflarechallenge.com in your hosts, so when going to the domain without the www subdomain your entry in the hosts is not used.

Either go to https://www.cloudflarechallenge.com or remove the www subdomain from your hosts entry.

Try setting 'www.cloudflarechallenge.com' in /etc/hosts instead, and when visiting the URL hit <shift>-<reload> to ensure your browser isn't caching anything.

I see Indutny's blog for 'https://www.cloudflarechallenge.com'[/etc/hosts mapped to 165.225.128.15] in both FF and Chrome.

Ok adding www to the hosts entry worked, appreciate it

Also possible to verify using OpenSSL commandline:

    openssl s_client -connect 165.225.128.15:443 -showcerts \ 
                  -servername www.cloudflarechallenge.com

(Though to fully check, you need to compare certificates with the one off the real site, and ensure that his blog appears upon an HTTP request - to exclude proxying.)

Try https://www.cloudflarechallenge.com/

I would call this a "self-induced man in the middle attack". You're telling your computer that cloudflarechallenge.com is his server.

The point is you can connect to it with HTTPS and your browser doesn't throw up big flashy warnings. It's basically proof that he has got the private key, since he can impersonate cloudfarechallenge.com with regards to SSL.

Yes, of course. That's why it's a successful "man in the middle attack" of sorts. If the cert wasn't trusted then it would mean nothing.

He doesn't have to have the private key, only a private key that was signed by any of the hundreds (counting intermediate CAs, thousands?) CAs trusted by his browser.

He has to have the private key that matches the certificate he's presenting.

He's presenting the CloudFlare-obtained cert (which the site offers up on request), so the lack of a warning means he's got that private key.

Getting another CA-signed certificate, naming 'www.cloudflarechallenge.com' and matching another private key, would itself be an impressive compromise, though not the challenge CloudFlare made or what he's demonstrating.

See here how to verify that Indutny indeed snatched the private key from Cloudflare’s server: http://dankaminsky.com/2014/04/12/bloody-cert-certified/

CAs will verify that you at least have control over hostmaster@ or an email listed in the WHOIS info for the domain before issuing certs.