This is a reminder why you should use E2EE messengers only.
Parallel Reconstruction of Lawful TLS Wiretapping
21–30 of 81 posts
Re: Parallel Reconstruction of Lawful TLS Wiretapping
#22The jabber.ru post referenced here presents clear evidence (in the section titled "Network") that the malicious actor was able to reroute traffic going to the legitimate jabber.ru server. An attacker in this position does not need an RCE to get a cert, they can just get one issued the normal way, because they do effectively control the IP address that the domain is pointing to.
One suggestion for anyone concerned about this weakness. You can use the CAA record to pin the domain to a specific certificate authority, issuance method, and account. This is imperfect, as CAA record validation (edit: of CAA extensions) is not mandatory yet. But by March 2027 all the CAs a supposed to have support.
Sprinkle some DNSSEC on the CAA record too, if you'd like.
Re: Parallel Reconstruction of Lawful TLS Wiretapping
#23The jabber.ru post referenced here presents clear evidence (in the section titled "Network") that the malicious actor was able to reroute traffic going to the legitimate jabber.ru server. An attacker in this position does not need an RCE to get a cert, they can just get one issued the normal way, because they do effectively control the IP address that the domain is pointing to.
One suggestion for anyone concerned about this weakness. You can use the CAA record to pin the domain to a specific certificate authority, issuance method, and account. This is imperfect, as CAA record validation (edit: of CAA extensions) is not mandatory yet. But by March 2027 all the CAs a supposed to have support. Sprinkle some DNSSEC on the CAA record too, if you'd like.
> This is imperfect, as CAA record validation is not mandatory yet. But by March 2027 all the CAs a supposed to have support.
Is that true? My read of Section 1.2.1 in [1] suggests CAA checking has been mandatory since 2017‐09‐08.
[1] https://cabforum.org/working-groups/server/baseline-requirem...
Re: Parallel Reconstruction of Lawful TLS Wiretapping
#24This is a reminder why you should use E2EE messengers only.
I guess there is an interesting possibility here. Perhaps the targets were encrypting end to end (that is more or less the default now with XMPP clients). With the TLS over top of everything the attackers would not know that. Perhaps they went to all this trouble for nothing.
Re: Parallel Reconstruction of Lawful TLS Wiretapping
#25Earlier quoted context omitted.
One suggestion for anyone concerned about this weakness. You can use the CAA record to pin the domain to a specific certificate authority, issuance method, and account. This is imperfect, as CAA record validation (edit: of CAA extensions) is not mandatory yet. But by March 2027 all the CAs a supposed to have support. Sprinkle some DNSSEC on the CAA record too, if you'd like.
> This is imperfect, as CAA record validation is not mandatory yet. But by March 2027 all the CAs a supposed to have support. Is that true? My read of Section 1.2.1 in [1] suggests CAA checking has been mandatory since 2017‐09‐08. [1] https://cabforum.org/working-groups/server/baseline-requirem...
CAA checking is mandatory, so you can always restrict to a given CA.
To get complete control with DNSSEC, you also need the accounturi and validationmethod extensions (which you need to guarantee only your account can issue, and only with the DNS validation type).
Those aren't yet mandatory, but you can restrict to a CA today which implements them, like Let's Encrypt.
Re: Parallel Reconstruction of Lawful TLS Wiretapping
#26Earlier quoted context omitted.
> This is imperfect, as CAA record validation is not mandatory yet. But by March 2027 all the CAs a supposed to have support. Is that true? My read of Section 1.2.1 in [1] suggests CAA checking has been mandatory since 2017‐09‐08. [1] https://cabforum.org/working-groups/server/baseline-requirem...
CAA checking is mandatory, so you can always restrict to a given CA. To get complete control with DNSSEC, you also need the accounturi and validationmethod extensions (which you need to guarantee only your account can issue, and only with the DNS validation type). Those aren't yet mandatory, but you can restrict to a CA today which implements them, like Let's Encrypt.
DNSSEC is the weakest link here.
It is too fragile (multiple point of failure). It is high volume (=it need be cacheable).
Puting authentication cert in dns sounds good in theory, but we have never get that reliability
Re: Parallel Reconstruction of Lawful TLS Wiretapping
#27Earlier quoted context omitted.
One suggestion for anyone concerned about this weakness. You can use the CAA record to pin the domain to a specific certificate authority, issuance method, and account. This is imperfect, as CAA record validation (edit: of CAA extensions) is not mandatory yet. But by March 2027 all the CAs a supposed to have support. Sprinkle some DNSSEC on the CAA record too, if you'd like.
> This is imperfect, as CAA record validation is not mandatory yet. But by March 2027 all the CAs a supposed to have support. Is that true? My read of Section 1.2.1 in [1] suggests CAA checking has been mandatory since 2017‐09‐08. [1] https://cabforum.org/working-groups/server/baseline-requirem...
I have it partially right. The extensions are not yet mandatory.
https://www.feistyduck.com/newsletter/issue_137_acme_caa__ex...
Re: Parallel Reconstruction of Lawful TLS Wiretapping
#28Earlier quoted context omitted.
CAA checking is mandatory, so you can always restrict to a given CA. To get complete control with DNSSEC, you also need the accounturi and validationmethod extensions (which you need to guarantee only your account can issue, and only with the DNS validation type). Those aren't yet mandatory, but you can restrict to a CA today which implements them, like Let's Encrypt.
DNSSEC is the weakest link here. It is too fragile (multiple point of failure). It is high volume (=it need be cacheable). Puting authentication cert in dns sounds good in theory, but we have never get that reliability
> It is too fragile (multiple point of failure).
If your DNS isn't working, you're not going to be making connections anyway. And if you can't keep DNSSEC running, you can't keep certs up to date either. DNSSEC is actually much simpler, with fewer failure points, once you set it up.
> It is high volume (=it need be cacheable).
It is. Unlike certificates. And the cache lifetimes are much shorter than typical certificate lifetimes.
Re: Parallel Reconstruction of Lawful TLS Wiretapping
#29>the various ACME clients like acme.sh are run with elevated privileges Its really not that difficult to not grant excessive privileges - at the very least for recurring ("cron") runs, once filesystem structure, cache invalidation triggers and web server configuration are in place. Its a shame this is still taught in the "just run as admin" style.
That capability should be added to acme.sh, etc so that it automatically runs with minimal privileges for the invoked task. But people seem to assume privilege management is the sole responsibility of the packager or caller, despite the tool itself being better placed to know precisely which privileges are needed for the particular task it's performing.
acme-client on OpenBSD does this, using privilege separated processes that each in turn use pledge and unveil. You wouldn't know without looking at the source code because it's entirely transparent.
Re: Parallel Reconstruction of Lawful TLS Wiretapping
#30This isn't what parallel reconstruction means. This seems to be reverse engineering the attack.