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.

▲

muvlon 6 hours ago | parent | next [-]

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.

▲

dabraham1248 5 hours ago | parent | prev | next [-]

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.

▲

dannyw 5 hours ago | parent | next [-]

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.

▲

duskwuff 42 minutes ago | parent | next [-]

Most independent site owners couldn't obtain an EV certificate even if they wanted to - the process effectively requires that the applicant be a business.

▲

failbuffer 4 hours ago | parent | prev [-]

Bingo... that was muchly the case prior to Let's Encrypt's introduction. They single handily changed prevailing practices outside of big tech.

	▲	duskwuff 41 minutes ago \| parent [-]
		That's a bit of an exaggeration. Domain-validated certificates already existed, and were fairly commonplace, before Let's Encrypt. What was different about LE was that their certificates were free.

▲

kbolino 3 hours ago | parent | prev | next [-]

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.

▲

mwwaters 5 hours ago | parent | prev [-]

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.

▲

sandeepkd 5 hours ago | parent | prev [-]

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