On 10/09/16 22:37, Lee wrote:
> Right - I figured that out about 30 seconds after reading an email
> about allowing verification on ports 80 and 443. But you only need
> to get the initial certificate one time - after that you should be
> able to renew using port 443 and I didn't see anything in the
> requirements about checking via an encrypted connection first. Did I
> miss something or is getting a renewal cert over port 80 allowed?
In order to spoof a CA's domain validation request, an attacker would
need to be in a position to MitM the connection between the CA and the
targeted domain. This is where (the authentication part of) TLS would
come in handy. That leaves us with the problem of determining whether
the domain name in question should be considered to support TLS:
1. The CA could look at prior records for that domain - if a
certificate has been issued before, treat it as a renewal.
2. The CA could similarly search Certificate Transparency logs and
treat the issuance as a renewal if a certificate is found.
Option 1 has one big problem: The attacker only has to chose a CA that's
different from the CA the domain has used before.
Option 2 is problematic because not all CAs log to CT at the moment.
Both options do nothing to solve the problem of a domain owner losing
the private key of their certificate (for example due to a hack, data
loss, or just a domain transfer).
You might be thinking of an option 3 - just connect to port 443, see if
the domain has a valid certificate, and use HTTPS if available. This
sounds great in theory, but since the attacker would need to be able to
MitM the connection in the first place in order to spoof the validation
request, they could simply intercept this request and force validation
on port 80.
All in all I think this would do more harm than good. Adding complexity
to the DV process means slower HTTPS adoption in general. I'd rather see
a "good enough" DV process and HTTPS everywhere when the alternative is
a perfect-in-theory DV process where HTTPS is available only for sites
that can deploy all these things competently. Even if we push for
encryption for this validation method, we still have DNS validation
without any encryption, and given the rate at which DNSSEC is deployed,
that's not going to change any time soon. (Not to mention that there's a
lot of opposition to DNSSEC in general.)
Patrick
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
