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.
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.
throw0101a 3 hours ago [-]
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.
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).
Ajedi32 32 minutes ago [-]
Yeah, checking from multiple perspectives is a good idea, but still ultimately a band-aid over the top of a flawed system. A properly engineered solution would need to ultimately come down to cryptographic proof of domain ownership (whether through DNSSEC, or something similar). Even RPKI still seems a little too indirect for my tastes (it fixes BGP attacks but potentially leaves the door open to other forms of domain hijacking).
Maybe in practice this is good enough, but the security nerd inside me rebels at how sloppy the whole thing feels.
toast0 48 minutes ago [-]
The hijacker effectively established control over the domain. That's a properly issued cert in my book. There's no part of a domain control cert issuance where the CA is expected to establish the identity of the domain owner or obtain their consent.
woodruffw 2 hours ago [-]
70% adoption doesn't seem high enough or it to be a mandatory component of validation[1], that seems like it would be very disruptive to nearly a third of the Internet.
There's also the jabber.ru attack, the attacker physically intercepted the server's network cable and just issued themselves a cert.
cowlevel 1 hours ago [-]
RPKI is, unfortunately, dual purpose as a government censorship mechanism. It would be trivial for the government of the Netherlands (or the USA, which the Netherlands is subservient to) to compel RIPE NCC to stop publishing RPKI records for Russian networks, and if RPKI was mandatory when this happened, this would cut Russia off the internet.
Lex-2008 2 hours ago [-]
I think having multiple authoritative DNS servers in different networks might help with this.
I'm not sure how CAs deal with situations when a domain has several authoritative DNS servers, but not all of them respond with expected reply. Would it would be a good idea for CAs to ask *all* authoritative DNS servers and require a coherent answer from them?
throw0101c 1 hours ago [-]
> I think having multiple authoritative DNS servers in different networks might help with this.
For the case of the dns-01 challenge type, sure. But if you're using http-01 (or the attacker asks for it), then all those DNS servers will answer back with the same IP address for the A(AAA) query and you're back to the hijacking scenario.
Lex-2008 26 minutes ago [-]
> http-01
Good point, I forgot about that! But then CAA record might help, I guess, if you specify your accounturi?
tomveber 1 hours ago [-]
[flagged]
Schlagbohrer 3 hours ago [-]
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.
coldpie 2 hours ago [-]
Remember Firesheep? It used to be the normal thing to use plain HTTP over open wifi networks. Literally anyone else on that access point could read your whole network session, cookies and all. https://en.wikipedia.org/wiki/Firesheep
cowlevel 1 hours ago [-]
Firesheep and Snowden are the confluence of factors that happened around the same time and led to the current near-universal use of HTTPS.
onionisafruit 3 hours ago [-]
Before reading this I never considered Snowden could have been a motivator for Let’s Encrypt.
meuna 2 hours ago [-]
Same. Fact checking on Wikipedia seems to indicate that the letsencrypt initiative predates Snowden revelations.
onionisafruit 2 hours ago [-]
I did the same. I found the same about it predating Snowden, but I also found this quote from J Alex Halderman in a remembrance of Peter Eckersley.
> That summer, Edward Snowden came forward with chilling revelations
about NSA mass surveillance, and the need for ubiquitous encryption
became clearer than ever.
It’s not a claim that it was the instigator, but it seems like it was heavily on their minds.
educar 2 hours ago [-]
how are snowden and LE related?
iamnothere 2 hours ago [-]
The Snowden revelations did help drive the push towards having HTTPS everywhere, particularly the findings about snooping on internal Google traffic, which seemingly made Google obsessive about HTTPS afterwards. But I don’t think they are directly related.
Vvector 2 hours ago [-]
The Snowden revelations revealed just how vast the intercept of internet communications could be. There was already talk of needing HTTPS everywhere. Snowden's release got more support behind it, and brought the timeline forward.
throw0101c 1 hours ago [-]
> There was already talk of needing HTTPS everywhere. Snowden's release got more support behind it, and brought the timeline forward.
Google made HTTPS default-on in 2010, but there was a toggle so that you could disable the forced use:
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
nottorp 1 hours ago [-]
> duration of 1 year or longer
Let's Encrypt is bringing the duration of certs down not up. I believe their goal is 30 minutes validity.
FiloSottile 3 minutes ago [-]
As far as I know 30 minutes validity is no one's goal, even long term.
The most aggressive plans (not Let's Encrypt's specifically) target 7 day validities.
throw0101c 1 hours ago [-]
> Let's Encrypt is bringing the duration of certs down not up. I believe their goal is 30 minutes validity.
This is mandated by the CA/Browser Forum, which, as the name implies, is related to browsers. It says nothing about e-mail clients. In its Extended Key Usage filed (RFC 5280 § 4.2.1.12) a certificate could not have server or client authentication, but have email protection as an allowed use.
nazcan 1 hours ago [-]
Thoughts on why it hasn't been solved?
autoboy 6 minutes ago [-]
Just look above here, people still want to do cert reneval manually with long timespans. The most radical thing LE did was not to provide free certs, or even automated certs, but short-lived certs.
superkuh 8 minutes ago [-]
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.
arbor-group 41 minutes ago [-]
[flagged]
planyield 1 hours ago [-]
[flagged]
cowlevel 1 hours ago [-]
[flagged]
stronglikedan 33 minutes ago [-]
Because it was upvoted as such.
Rendered at 14:45:54 GMT+0000 (Coordinated Universal Time) with Vercel.
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...
But remote perspectives are still worth doing, Let’s Encrypt should not be the “less diverse” than the infrastructure of their typical certificate requestor.
> 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).
Maybe in practice this is good enough, but the security nerd inside me rebels at how sloppy the whole thing feels.
[1]: https://ipinfo.io/blog/rpki-protects-70-internet-routes
I'm not sure how CAs deal with situations when a domain has several authoritative DNS servers, but not all of them respond with expected reply. Would it would be a good idea for CAs to ask *all* authoritative DNS servers and require a coherent answer from them?
For the case of the dns-01 challenge type, sure. But if you're using http-01 (or the attacker asks for it), then all those DNS servers will answer back with the same IP address for the A(AAA) query and you're back to the hijacking scenario.
Good point, I forgot about that! But then CAA record might help, I guess, if you specify your accounturi?
> That summer, Edward Snowden came forward with chilling revelations about NSA mass surveillance, and the need for ubiquitous encryption became clearer than ever.
It’s not a claim that it was the instigator, but it seems like it was heavily on their minds.
Google made HTTPS default-on in 2010, but there was a toggle so that you could disable the forced use:
* https://workspaceupdates.googleblog.com/2010/01/default-http...
In 2014 the toggle was removed and all connections were forced to HTTPS.
The Snowden revelations occurred in 2013:
* https://en.wikipedia.org/wiki/Snowden_disclosures
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
Let's Encrypt is bringing the duration of certs down not up. I believe their goal is 30 minutes validity.
The most aggressive plans (not Let's Encrypt's specifically) target 7 day validities.
This is mandated by the CA/Browser Forum, which, as the name implies, is related to browsers. It says nothing about e-mail clients. In its Extended Key Usage filed (RFC 5280 § 4.2.1.12) a certificate could not have server or client authentication, but have email protection as an allowed use.
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.