Hacker News Reader

Comment by ikeboy | Hacker News Reader

>One of the common one is to upload a certain file at a certain address of that domain.

I wonder if this can be socially engineered/tricked to gain a certificate for someone else's domain. Like, I've seen at least one service (Majestic Seo) that asks you to upload a document to your domain to get certain services. Now that this (will soon) exist, any such service that someone uses can generate a cert and MITM the site.

Also, if they're verifying over http, couldn't anyone just mitm the verify connection? Well, anyone with access to any computer along the route between Let's Encrypt and whatever domain they want.

View on HN

I think that this is a common way of verifying domain ownership, but something harder to spoof without actually owning the domain, like setting a custom TXT record or being able to respond to a WHOIS contact email would seem to make more sense than file upload.

Even if this is common, you have to expect fake certs will be easier to get if there's no cost in failure.

If you need to pay for a cert before seeing if your hack worked, there will be less attempts.

This way, if your mitm failed, you didn't lose anything.

There is an issue on that: https://github.com/letsencrypt/acme-spec/issues/131

Does verifying you have the right IP ensure you can't be MITMed? Could someone controlling a connection along the way change stuff?

I haven't heard it used in the "wild" yet, and it's not a MITM attack. Just shows how useless this verification method is - if you're hitting a PHP built site - a relatively simple hack would be to find a PHP page that allows you to upload something, most hosts don't upload to the root but I imagine it'd be trivial to use the upload process against itself.

I know W3schools is often thought of as useless, but for the upload script example on there there is no validation: http://www.w3schools.com/php/php_file_upload.asp

I imagine uploading something called "../verifyme.txt" would upload it to the root of the website.

it has to be uploaded to a specific path the server gives you "/.acme_something/something...". But I agree that it's not really perfect...

Well, if the PHP site gives you full control over the domain, then you have full control over the domain, don't you?

The security issue there is not the fact that MitM becomes slightly easier, it's that you can alter the site for all visitors and don't need MitM.

If someone MITMs the connection between the CA and the website itself, then yes. I believe LetsEncrypt uses a variety of proxies around the world to measure the website, so there'd have to be a lot of successful simultaneous MITMs for that to work.

Ultimately you have to bootstrap trust from somewhere. Perhaps in future DNSSEC can be used to solve this problem (though DNSSEC is of course itself just another PKI).

My understanding is that DNSSEC only proves IP. If you're in between the CA and the server, you don't care that the CA has the right IP.

DNSSEC authenticates DNS records. That can be IP addresses, but it could also be public keys or anything else.

A MITM can easily spoof IP addresses. You can't trust unsigned data, and IP address headers aren't signed.

You also can't trust signed data if you don't trust the signature. That's the real problem here. This whole protocol is an attempt to establish trust, but it's based only on temporary control of a server's network traffic. Probably that's the legitimate owner of the domain, but maybe it's somebody malicious who merely had access to their network for a time. You can't really be sure.

This (file upload) has been part of the CA/B Baseline for some time and most CAs already let you do it.

People have been able to get SSL certs for webmail domains before, as the webmail providers hadn't blacklisted some of the emails CAs can use for domain validation by email. e.g. see http://www.entrust.com/what-happened-with-live-fi/

Even if a MITM can intercept HTTP requests to your server, they still can't hijack your registration attempt.

The real problem is that if somebody can intercept your HTTP traffic, they can register their own account key. After all, they can control your domain, and that's all letsencrypt cares about! If you haven't already registered an account key, I can't see how anything would stop them. If you already use a different CA and don't want to bother with letsencrypt, you might never find out either!

I guess that’s why they will probably not use HTTP for the verification. Why would they? The client already generated a certificate and sent it to Let’s Encrypt, they can already use TLS.

But you don't know that this is the client. If all you're trusting is the cert they already generated, how do you know it's not an attacker?

You’re right, I did not think this through…

Except the cert used in that process is one uploaded by the user, and could easily be provided by an attacker. As long as the attacker can MITM the path to the domain's web server, they can provide that cert for TLS and successfully spoof the site.

Edit: Ok, technically it's a CSR signed by a private key, but you could still use the key to self-sign a cert or something... But none of that mitigates the MITM attack described above.

You wouldn't have a signed cert until after the challenge has been completed. The client generated a CSR, not a certificate.

I think this is the reason other validation forms exist, i.e. Organization Validation and Extended Validation.

It shouldn't be easy for me to generate a cert for your domain.

I've never heard conducting a MITM attack on the Internet backbone or hosting provider as "easy" before (other than by governments—but they probably already have plenty of vectors for generating fake certs). Now, if you're serving HTTP over an unknown wifi access point...

Those poor wifi-connected web servers in coffee shops across the world...

Reply on news.ycombinator.com