Hacker News Reader

Comment by ratorx | Hacker News Reader

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.

View on HN

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.

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

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.

Let's not forget that it was mostly a manual process for most of us. Someone would obtain a cert, and email it to you, along with the private key. I'm sure old JIRA tickets would have so many "encrypted" zip files containing RSA 2048 keys and leaf certificates valid from 2008 to 2011.

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.

Business registration is cheap or free in many places. A sole proprietor is a business just because they say so.

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.

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.

dealing with this at work now, can you explain the situations in which you _should_ use OV/EV certificates? from my perspective they seem quite useless, even the NSA uses DV, but I don't know enough to actually say that. It seems like there are regulations which might make it required, but I also cannot find any link to anyone talking about what regulations those might be. Just that... "there are regulations"

Outside of regulatory requirements, they're useful for code signing (the extra hoops frustrate malicious actors, the legal identity behind the cert can be targeted for banning/suing/prosecuting), apps connecting to their own home services, and document signing, off the top of my head.

not trying to mess with you, the code signing one makes sense to me, but what do you mean by 'apps connecting to their own home services'? and document signing? like DocuSign? how would an OV cert help there?

Most apps don't need access to all web sites, they just need access to specific services. If the developer of the app controls some or all of those services, then the app can be coded to require the use of OV/EV certificates. With that rule in place, the app can then also inspect the subject DNs and check for the presence of its own organization details. The end result would be kind of like certificate pinning, except a little more flexible.

For documents, yes this includes things like DocuSign, but also signed PDFs, signed XML, etc. Any situation where a business, nonprofit, government agency, etc., is corporately attesting to something, like the signing of a contract or the public release of a statement, can use an OV/EV certificate.

awesome. thank you for the detailed reply!

> 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.

It wouldn't be immune to MitM on DNS - unless DNSSEC were to become mandatory.

Don't focus too hard on the current method. Just work with me and imagine a value that comes direct from the registry and there's some kind of secure link, maybe DNSSEC maybe not.

The problem with this is risk management. In reality, MITM attacks on DV issuance are vanishingly rare --- and close to infeasible in many important cases. But misissuance of DV certs is less rare; it just doesn't happen with MITM attacks. Rather, the usual cause is registrar account takeover.

DNSSEC isn't going to happen, among other things, because it doesn't address a meaningful threat to the WebPKI.

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

Reply on news.ycombinator.com