Let's Encrypt is adding two additional remote perspectives for domain validation

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

In August an attacker was able to get a certificate issued even with multi-perspective validation:

> For 33 hours in late August, a rival network hijacked a block of Hetzner-hosted infrastructure serving Softaculous and Virtualizor, using it to issue a valid TLS certificate and push a malicious software update. The stolen route was RPKI-invalid the entire time, on file, checkable by anyone. It still won on most of the internet.

> At 20:57 UTC on 28 August, a network nobody at Hetzner or Softaculous had dealt with before started announcing 162.55.80.0/24 to the internet. It was a small, unremarkable-looking slice of Hetzner’s own address space — the block hosting Softaculous’s client area, its billing pages, and the update endpoint that every Virtualizor-licensed control panel on the internet periodically calls home to. For the next 33 hours, with an 11-hour lull in the middle, a meaningful share of global traffic bound for that block went to the hijacker instead. Some of it was Let’s Encrypt’s own domain-control validation, which is how the attacker walked away with a certificate for virtualizor.com that no browser would ever flag.

* https://cloudpunk.blog/post/bgp-hijack-rpki-gap/

So it's all very well to have multiple network locations to prevent hijacking on the path (i.e., you have to attack multiple paths), but if the network as a whole thinks the destination is someplace else then all those paths will lead to the same (false) location.

Perhaps the CAB should consider RPKI validation as a "MUST" rather than piling on multiple sources of validation who still have the same single point of failure (the spoofing of the destination).

It is wild to think that enabling HTTPS used to be difficult and expensive before Let's Encrypt came along in the wake of the Snowden revelations.

It's a shame that now, where S/MIME is a feature of pretty much every mail app, noone uses it outside of businesses. Opportunistic encryption between mail servers isn't good enough.

We really need a CA that does for mail what Let's encrypt has done for HTTP:

The CA needs to provider proper S/MIME certificates:

- free like Let's Encrypt

- duration of 1 year or longer and

- users generate their own keys

Does anybody know if Let's Encrypt plans to support C2PA certificates?

What we really need form Lets Encrypt is stability and lack of change. But LE is just following the megacorps down the current TLS road. We're already down to only 30 day certs and on the second iteration of acme. Acme original protocol setups no longer work, they were broken by the dropping of support.

Addding new methods of validation does not help nearly so much as just supporting existing methods for more than a few years would. The race to the bottom will end up with an incredibly fragile system that breaks the moment automation does. Combine this with the trend towards HTTP-only and any given website will only have a lifetime of a couple years without direct human intervention. This is a drastic change from the status quo of websites simply lasting forever and being accessible till their webservers stop.

It is 100% a corporate-for-profit-only mindset and architecture. LE is not designing or accomidating human person goals and needs.

[flagged]

[flagged]

[flagged]

[flagged]