I am reading technical overview, and it is unclear to me, if I lose authorized key pair, what is the process of reauthorizing the key? Do I just have to retry the authorization and the process that I control the domain name?
Yes, currently there isn’t a recovery process, but you can simply re-authorize your domain and re-issue your certificate, keeping in mind the rate limits.
1 Like
Hmm, so if somebody temporary gets hold of the HTTP server through a vulnerability, they can re-authorize their own key and issue themselves a pair of keys for a domain without really much human interaction and detection? Hmm. This might open a new set of attacks against HTTP servers.
Well if they get access to HTTP server you have more things to worry about than the control over key pairs !
Hm, not necessary. Sometimes the access is just that you can put any content on the HTTP server, like a buggy CMS system. It can be pretty different than having full control of the server or access to keys.
in that case they won’t have full ability for domain validation with Letsencrypt anyway as they’d still need to be able to run Letsencrypt client itself on SSH terminal level and control domain DNS A records
From my understanding you need only control of HTTP, not DNS A records:
Provisioning an HTTP resource under a well-known URI on https://example.com/
You can probably call letsencrypt client from anywhere else? You just have to make sure that the "HTTP resource under a well-known URI" appears when requested by the letsencrypt validator.
yeah they only need HTTP control, but if they have breached the HTTP server they can still do damage without reissuing the SSL certificate The CA's Role in Fighting Phishing and Malware - #64 by tlussnig
Hackers have broken into a website operated by the World Bank Group, which was subsequently exploited to host a convincing PayPal phishing site. The fraudulent content deployed on the site was able to benefit from the presence of a valid Extended Validation SSL certificate.
The EV vetting process effectively guarantees that the domain used in this attack is operated by the organisation specified in the certificate, which in this case is the World Bank Group. Implicatively, any visitor to this site is likely to trust the content it displays.
But of course, this guarantee goes out the window if the site has been compromised by an attacker. That's exactly what happened on Tuesday, when fraudsters deployed a PayPal phishing site into a directory on climatesmartplanning.org, allowing the fraudulent content to be served with an EV certificate issued to The World Bank Group.
Maybe we think about different attacks here. For phishing you really do not care about access to SSL certificates and access to the HTTP server is enough. The attacks I have in mind is when you use HTTPS because you want to prevent others to eavesdrop. So an attacker could gain access temporarily, issue them SSL certificates, and then start doing MITM attacks without anyone noticing. By just exploiting what was before useful for phishing attacks. They do not even have to keep anything running on your server.
I see what you mean
The only way i see that happening is if they use letsencrypt client’s manual mode where the attacker has ability to copy and paste/upload the encoded token to the compromised HTTP server as other authentication plugins have an expected encoded token for the .well-known http-01 validation outside of attacker’s control.
@bmw @jsha @pde @kelunik @jcjones maybe for letsencrypt manual authentication they could add another security layer i.e. email verification to registered letsencrypt email account for a 2nd confirmation ? Afterall, you’re already doing it manually anyway, might as well add a step to check email for verification code or link ?
To my understanding, the letsencrypt client uses the same underlying protocol for authorization, just UI is different for different cases. So I think there is not much we can do about such attacks? Except to strengthen the re-authorization process?
well a DNS based check would be nice or an email to the whois and/or admin address…
but then for people who dont actually control the domain (dyndns for example) have a problem because they dont have a whois email.
in the end a service running over a different port where LE pings the domain on said port and the client pings back accordingly it would be epic.
Making manual harder than it already is is not a good idea. Additionally, why should manual mode be different from other modes?
There are existing CAs that also allow domain validation by provisioning a file on your server, so this doesn't open a new avenue for attackers.
1 Like
Could you name a few other CAs doing that?
My understanding is that WoSign and GoDaddy do validation by file provisioning. There may be others, but I haven’t done an exhaustive search.
More to the point, the CA/B Forum’s Domain Validation working group is working a on a set of requirements for validation. One of the specifically allowed methods is to provision a file on a web server.
But aren't there also manual steps required? The issue I am having here is that two properties are combined: provision of a file on a HTTP server might be easier to do then access to the SSL key on the server, when a server is compromised. And that the whole process is automatized. Once two things combine and this approach becomes widespread (like we hope Let's encrypt will) we can anticipate a new class of automatic attackers against websites, similar to how they try to deploy phishing sites, but in this case compromising SSL keys.
That a working group allows validation through a file on a server does not mean that the method is safe or that it does not invite new set of attacks, especially once it becomes widespread. 
This is a good point, but it's common to see attackers scripting web interfaces in the wild. So it's entirely possible to do this on today's Internet. If the argument is that it's easier to write such scripts, I think that's a qualitative one rather than a quantitative one.
I think my main argument is that this will get more widespread. Even if some CAs are using it at the moment, is not the standard practice. So there is not much interest in making it widespread. But once you have many sites supporting it, then attacks become more viable.
[quote=“kelunik, post:15, topic:4190, full:true”]
Could you name a few other CAs doing that?
[/quote]there’s a few including Comodo as it’s an option in my SSL reseller control panels for file based validation as well
i had a client who’s email validation for DV SSL certificate was delayed so I changed to file based validation for domain