5 ms·
Can someone elaborate on what's going on here? If i replace his IP with some other random IP I get a 400 bad request error, so it's obvious that it works, but
by alex_marchant 13y ago
Can someone elaborate on what's going on here?
If i replace his IP with some other random IP I get a 400 bad request error, so it's obvious that it works, but curious how that resolves.
- gojomo 13y agoPutting 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.
- alex_marchant 13y agoBut seems like only the http connection is working, i get a warning in Chrome when visiting https://cloudflarechallenge.com https://cloudflarechallenge.com. Isn't that the only situation where the key would be checked. That's the part that doesn't make sense.
- fletchowns 13y agoTry https://www.cloudflarechallenge.com/ https://www.cloudflarechallenge.com/
- nolok 13y agoSubdomains 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 https://www.cloudflarechallenge.com or remove the www subdomain from your hosts entry.
- gojomo 13y agoTry 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 https://www.cloudflarechallenge.com'[/etc/hosts mapped to 165.225.128.15] in both FF and Chrome.
- alex_marchant 13y agoOk adding www to the hosts entry worked, appreciate it
- quasque 13y agoAlso 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.)
- pushrax 13y agoI would call this a "self-induced man in the middle attack". You're telling your computer that cloudflarechallenge.com is his server.
- jsmeaton 13y agoThe 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.
- Theriac25 13y agoHe 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.
- paulbaumgart 13y agoCAs will verify that you at least have control over hostmaster@ or an email listed in the WHOIS info for the domain before issuing certs.
- gojomo 13y agoHe 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.
- cpach 13y agoSee here how to verify that Indutny indeed snatched the private key from Cloudflare’s server: http://dankaminsky.com/2014/04/12/bloody-cert-certified/ http://dankaminsky.com/2014/04/12/bloody-cert-certified/
- 13y ago