Comment by nbadg
13 hours ago
For anyone else who didn't have "remote perspectives" in their personal technical lexicon: this refers to performing the ACME challenge/response check when validating the domain of a certificate signing request from multiple physical locations, and therefore via multiple physical network routes, in order to make network-level attacks more difficult.
For example, if you were validating example.com, you'd need to set up some response to the ACME challenge somewhere, either through direct DNS-based validation (DNS-01, DNS-PERSIST-01) or through a server running at the resolved A/AAAA IP address for example.com (HTTP-01, TLS-ALPN-01). In all cases, when a CA goes to validate your challenge response, it relies both upon DNS and upon the network integrity between the CA's datacenters and your DNS and/or app servers. Both of these can be subverted, eg via BGP attack, to allow an attacker to replace a DNS response, re-route the destination IP address to a different server, etc, at which point they can inject their own challenge response, and therefore issue their own (unauthorized) certificates.
Multi-perspective validation means that the CA validates your challenge response from multiple datacenters on different networks instead of just one, such that a hypothetical network attack would have to target multiple independent networks in order to successfully issue their unauthorized certificate.
More info:
https://letsencrypt.org/2020/02/19/multi-perspective-validat...
https://community.letsencrypt.org/t/multi-perspective-valida...
Being pedantic, the risk/benefit of remote perspectives are theoretical and dependent on the destination network also having multiple independent links. Otherwise any “uplink” ISPs are all SPoF regardless of anything Let’s Encrypt does because the traffic must traverse them to get to the destination.
But remote perspectives are still worth doing, Let’s Encrypt should not be the “less diverse” than the infrastructure of their typical certificate requestor.
Sure, if you can MitM the connection to a single-homed destination network, you can get Let's Encrypt to sign you certificates for things in that network, regardless of how many perspectives Let's Encrypt uses.
However, if you can MitM the uplinks at all of Let's Encrypt's perspectives, you can basically break the entire CA for everyone. Adding more perspectives reduces the risk of that.
Let's encrypt only offers DV certs. For DV, if you can successfully MitM every connection to a destination, then you _do_ own the domain. From [DigiCert](https://www.digicert.com/difference-between-dv-ov-and-ev-ssl...):
> Domain Validated (DV) certificates are the least-identity-validated SSL certificates and can be obtained quickly and easily—even by a malicious bot. These certificates are low-cost certificates that only require validation that a company or person can demonstrate control over a web domain for which they want to secure a certificate.
This is arguably a flaw in allowing DV certs at all, but given that it's there, LE doing this raises the bar for spoofing about as far as it can be raised.
Without DV certs, much of the web might not be encrypted at all.
I think few independent site owners would go through the more costly and complicated EV process.
3 replies →
> For DV, if you can successfully MitM every connection to a destination, then you _do_ own the domain.
That's a policy, not an inherent consequence of DV certs.
If every verification method other than DNS was shut off, it would still be DV, but with care it could be immune to MitM. I'm not advocating for that, but it's an option.
2 replies →
Without major cross-national legal changes, OV/EV certificates on the open web are pointless at best and misleading to the point of being dangerous at worst. They remain quite useful in specific scenarios outside of normal web browsing, but that's not the issue at hand.
I liked the idea conceptually of CAA record only allowing DNS validation. Then use DNSSEC.
I say “conceptually” since I know: 1. Actual attacks found with CT have used compromised TLDs, which kills the whole thing anyway, and 2. I haven’t really seen where the hosting company’s infrastructure (BGP ads and internal routing) is what’s compromised. Well certainly in the latter case they can probably also get in to the hosting machines directly.
On the contrary I have personally seen the attacks and the impact. My understanding was that CAs are required to do that by spec and Let's Encrypt already does that.
The Use case - Lot of SAAS based products allow/require the administrators to prove the ownership of a domain via ACME methods. The administrators then are allowed to manage the profiles for users that have email address with same domains in the SAAS product.
Ironically the testing setup itself used the network hack for the successful ACME challenge