Pale Moon should consider changing their certificate authority

[Sob__]

LE relies completely on DNS for authentication of the cert issuance request ...

It's not that much different from traditional DV certificates. Sure, they send verification mail to some likely-to-be-owned-by-admin account on requested domain. But if you control DNS, you also control mail (just give CA the right MX record).

There is no check with the domain owner. This means that a "domain verified" certificate is NOT domain-verified, because there is no domain verification being done at all.

LE verifies that you have control over hostname.domain.tld and it gives you certificate for just this one hostname. You could previously do bad things with http://hostname.domain.tld and LE just enables you to upgrade to https://hostname.domain.tld. Ok, it is a difference from original DV certificates, but can it really hurt that much?

[half-moon]

There is no check with the domain owner. This means that a "domain verified" certificate is NOT domain-verified, because there is no domain verification being done at all.

LE verifies that you have control over hostname.domain.tld and it gives you certificate for just this one hostname. You could previously do bad things with http://hostname.domain.tld and LE just enables you to upgrade to https://hostname.domain.tld. Ok, it is a difference from original DV certificates, but can it really hurt that much?

hmmmm....

A real-life example: remember sur.ly? Through LE they were able to get an https certificate issued to outbound.palemoon.org without my knowledge or permission. No verification with the palemoon.org domain owner (me) occurred at any point in time.

Combine that with the 3-month lifetime and no-revocation "policy" they have and there you go: for 3 months, a foreign server will have a valid certificate under your domain and there's nothing you can do about it.

[Moonchild]

Sure, they send verification mail to some likely-to-be-owned-by-admin account on requested domain.

No, a CA will send e-mail to the registered domain contact e-mail in whois. That may or may not be an e-mail address on the domain in question (very often it isn't.)

LE verifies that you have control over hostname.domain.tld

No, they don't. LE only verifies that the hostname resolves to the IP of the requesting server. There is no other requirement, at all.
The sur.ly example underlines this. I had no control over the sur.ly server, and they got a cert issued for it.

[Sob__]

Every time I bought DV certificates in the past (RapidSSL, AlphaSSL, Comodo), I was simply given choice between few "standard" confirmation addresses on target domain and none of them was listed in whois. When I look at my usual reseller now, it's still the same: admin, administrator, hostmaster, webmaster, postmaster, all on domain I request certificate for.

LE only verifies that the hostname resolves to the IP of the requesting server.

They also have this challenge-response system where they download response from webserver running on target host. So you can't be just a random user on the machine, you need to have decent amount of control over it to run/configure the webserver.
I'm not sure what would happen if MITM (e.g. evil ISP) redirected traffic to own server and tried to get certificate that way. I would guess that renewals could be tied to previously used account key (but I didn't test it), but I don't see anything that would prevent it for the first time, when hostname doesn't have any LE certificate yet.

[Moonchild]

I never said it was dead-easy for script kiddies, but I did say it was fragile; It's certainly far from robust, and certainly not the kind of cert issuance I can agree with.

You also seem to be confusing having control of the requesting server (which a malicious party would always have) and having control of a named entity in DNS terms.

[Sob__]

Ok, there may be some confusion in used terms. What's your definition of "requesting server"? Because there can be more than one server involved. I can request certificate from server A (run the client there) for hostname pointing to completely different server B. And it works great. The only important thing is that LE's verification finds the response to challenge on server B. That's easy to do, if I control both A and B. But close to impossible for random attackers controlling only A but not B.

Their only chance would be to fool LE by giving them different DNS record, to make them think that requested hostname points to attacker-controlled server A. But LE is supposed to ask domain's nameservers directly and from multiple places, so that's extremely unlikely to succeed even with bare DNS. Add DNSSEC (I don't know if LE uses it, I'd hope so) and this option is out.

The only problem I see is with less random attacker. Someone who controls server B's network (ISP, hosting company) can easily set up fake server B, redirect traffic to it for few seconds and get valid certificate that way. How much useful it would be is a question. It would be different from real one, so it could not be used for passive sniffing. They would have to use it actively with proxy, but then the owner of real certificate could notice (if he connected to server from outside) that it's not the same certificate as on his server. But if they only used it for targeted attacks, it could work. So this is worse than email-validated DV certificates, you're right there.

What I think we mainly don't agree on is your sur.ly example. I get it, you just pointed outbound.palemoon.org to them and they were able to get certificate for it, without anyone asking you as the owner of palemoon.org. It may feel wrong. On the other hand, so what? You pointed the hostname to their server, so you obviously trusted them enough to let them use it for http (and possibly other services not requiring anything special). Why is it so wrong that they could also get a certificate for it? They can't get it for www.palemoon.org or anything else, just outbound.palemoon.org.

[Moonchild]

DNS resolution can (and often is) manipulated in pointing to different than intended servers. The moment that happens for LE's checking is the moment someone completely unrelated to a domain can get a certificate irrevocably (mis)issued for that domain (including www.) -- the sur.ly example is not an actual attack because *I* made a canonical name record (and CNAME already suffices for LE to issue) so of course there was no immediate problem, but it demonstrated a point.
With how DNS is in no way enforced to be secure, this request for a certificate can be made for any domain and host as long as LE's issuing servers are given the IP of a malicious server to verify against under a domain.

I guess I'm unable to get my point across to you, so I'm sorry but I'm not going to put any more time into it. Maybe someone else can explain if you still don't understand the severe issue here.

[Sob__]

But everything depends on DNS. If attacker is able to give fake A/AAAA/CNAME to LE's checking server, what's the difference from giving fake MX to other CA's server (one that does DV by sending confirmation link by mail)? Aside from being different entities, using different networks and everything, so difficulty would depend on many circumstances, it's exactly the same principle.

If anyone wants to pick it up, I'm all ears.

[New Tobin Paradigm]

The difference is, if I am correct, that in that event the cert is valid for 3 months without any way to revoke it or contest it. That is the problem with Let's Encrypt.