alt.hn

5/30/2026 at 7:47:36 PM

Parallel Reconstruction of Lawful TLS Wiretapping

 https://remyhax.xyz/posts/reproducing-lawful-tls-wiretapping/

by jerrythegerbil

5/31/2026 at 4:25:05 AM

Yes this is to be expected. I've mentioned multiple times over the years that TLS CA issuance & validation's many security holes (>=14 at last count) could be solved by changing how certificates are issued. I've never had the kind of clout to get that message wide enough that anyone would take it serious.

One of Web PKI's security holes is the fact that any CA can issue valid certs for any domain. The only official "mitigation" for that is voluntary and can be defeated.

The solution to that is to rearchitect the Web PKI ecosystem to use domain registrars as the sole source of truth for which CA is allowed to issue valid certs, in addition to cryptographic fingerprints of the source of the originator and issuer. I won't rehash it here but it's not technically difficult and would make it so only the domain owner could issue certs, and valid certs could only come from the CA the domain owner authorizes.

Maybe if this keeps happening, people will realize it's worth working on? But I doubt it, as a lot of money is at stake, and nobody wants to risk that just to stop governments and cybercriminals from spying on the occasional connection. If it was blatant and obvious then they might have to act; as long as it's kept covert and hard to prove, things stay the same.

by 0xbadcafebee

5/31/2026 at 11:43:57 AM

> One of Web PKI's security holes is the fact that any CA can issue valid certs for any domain. The only official "mitigation" for that is voluntary and can be defeated.

In case you were not aware, Moxie Marlinspike spoke about this at length back in the early 2010s[1]. His view was that the problem is that certificate authority trust is controlled by the wrong people (web hosts, not users -- or browsers, as a proxy for user wishes) and is not possible to revoke because once a web host uses a particular CA you are stuck trusting them forever otherwise the internet will break.

> The solution to that is to rearchitect the Web PKI ecosystem to use domain registrars as the sole source of truth for which CA is allowed to issue valid certs, in addition to cryptographic fingerprints of the source of the originator and issuer. I won't rehash it here but it's not technically difficult and would make it so only the domain owner could issue certs, and valid certs could only come from the CA the domain owner authorizes.

Unfortunately, this is problematic for a bunch of other reasons. Yes, this means that a classic Comodo or DigiNotar attack might be blocked (though it is also just as likely they would've been included on the allow-list for American websites), but it also means that registrars could force you to use VeriSign and you would have no choice in the matter -- that is what originally happened with TLS and was what originally happened with DNSSEC too. It seems prudent to me to avoid creating schemes that allow that kind of institutional capture.

There is also in my view a mistake to assume that anyone with a ".com" or ".us" address would want to have the US government decide who they can get certificates from, ditto for any national TLD (let's not forget all of the Rust projects with ".rs" which is controlled by Serbia, tech websites with ".io" that is controlled by the UK, and so on).

If you really wanted to do this, DANE would allow website owners to do this by pinning the CA root and intermediate certificates hashes via DNSSEC -- basically acting as a client-side (and more strict) version of CAA (which I'm guessing is what you were referring to in your comment). Unfortunately it's not supported by Chrome and Firefox, and it would be quite fragile. It would be nice to have this as an option, and I am quite disappointed with the fact that clients are expressly forbidden from parsing CAA by RFC 8659.

[1]: https://youtu.be/UawS3_iuHoA?t=292

by cyphar

5/31/2026 at 4:20:40 PM

> once a web host uses a particular CA you are stuck trusting them forever otherwise the internet will break.

If you switched CAs you would only need to trust the old one until the previous cert expired, or when you get a newer cert. Once the cert expires there's no point in trusting the old CA - for that domain. (In my solution you still keep all the CAs in your cert store, but they can't validate a cert that wasn't also signed by the domain owner's and registrar's keys)

> it also means that registrars could force you to use VeriSign

The check on that is the combination of the CA/Browser Forum and ICANN. The CA/Browser Forum is a proxy for Google, Apple and Microsoft, who control the browser market, and ICANN who controls the accreditation of domain registrars. A single registrar has a lot less money and influence today than back in the day.

> would want to have the US government decide who they can get certificates from

Because of the aforementioned bodies I don't believe registrars would be allowed to enforce specific CAs (architecturally they would just be signing requests on a REST API based on the CA keys the domain owner authorized, so there's no need to integrate into specific CAs). I also think CA/Browser Forum would want to enable Let's Encrypt to be used everywhere (LE usage is in the interest of the CA/Browser Forum) so that would mean they need rules to allow CAs independent of registrars.

DANE and DNSSEC are not a good solution architecturally or security-wise. DANE is duct tape; duct tape is a temporary fix, not a permanent one.

by 0xbadcafebee

5/31/2026 at 4:35:02 PM

I think a lot of people who work on the root programs would push back on the idea that the CAB Forum is a proxy for Google, Apple, and Microsoft.

by tptacek

5/31/2026 at 12:26:59 PM

You seem to be talking about registries (who manage tlds, so you have no choice for a particular tld). OP talked about registrars (who sell domains, and there's a wide choice). Though I'm not sure how that's supposed to work.

by masfuerte

5/31/2026 at 12:51:50 PM

> is not possible to revoke because once a web host uses a particular CA you are stuck trusting them forever

So, the fun thing about historical claims is that you can do Science (insert sound effect) by assuming they're right to make a prediction from that baseline and comparing what actually happened against that prediction.

Moxie gave that talk in August 2010, hence the "DEF CON 19" background. So almost 16 years ago. Over that time of course there have been numerous incidents that would give you good cause to distrust companies such as DigiNotar, StartCom and Symantec. Moxie's prediction tells us that we were "stuck trusting them forever" but er... nope, DigiNotar went bankrupt, StartCom exists only as some branding for the (now distrusted) Chinese company which bought it, and Symantec "pivoted" away from the CA business and now exists largely as branding as well.

> I am quite disappointed with the fact that clients are expressly forbidden from parsing CAA by RFC 8659.

This is a bad idea because it doesn't signal what you think it does. CAA is a signal about who may issue right now not a signal about who has issued in the past whether that's five seconds ago or five weeks ago. That's why it's a signal for the CAs and not for you.

by tialaramex

5/31/2026 at 2:51:50 PM

If the wrong CA issued a certificate then wouldn’t that show up in the transparency logs? It seems like by monitoring them, you could see if a security bug is being exploited.

by skybrian

5/31/2026 at 9:17:51 AM

How would clients receive the trusted CA data from the registrar? DNS?

This would very easily be susceptible to MITM attacks. Any DNS security to prevent MITM attacks is going to have the same CA issue we currently have.

by mtucker502

5/30/2026 at 10:22:01 PM

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

by aleksejs

5/30/2026 at 11:16:59 PM

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.

by 8organicbits

5/31/2026 at 3:48:04 AM

Just be careful, if you host your DNS at Cloudflare (maybe others?), they will rewrite your CAA record[0] if you use TLS with them. This is in the name of convenience but it was surprising when I first learned.

[0]: https://developers.cloudflare.com/ssl/edge-certificates/caa-...

by cobertos

5/31/2026 at 10:01:29 AM

Cloudflare is basically MITMAAS for the US Gov. If you are worried about state actor wiretapping, you should avoid them altogether.

by flarzzarp

5/30/2026 at 11:35:13 PM

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

by aleksejs

5/31/2026 at 12:03:21 AM

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.

by mcpherrinm

5/31/2026 at 12:11:51 AM

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

by j16sdiz

5/31/2026 at 3:55:12 AM

Even without DNSSEC, the CAA record approach can help, as it requires MITMing between the CA and the DNS server, which may be harder in some cases than just MITMing a target site.

There’s some upcoming attempts at transport security for authoritative DNS servers which might help too: https://datatracker.ietf.org/doc/html/draft-hoffman-deleg-se...

by mcpherrinm

5/31/2026 at 1:12:09 AM

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

by Hizonner

5/31/2026 at 2:37:25 AM

It is self-evidently not correct that companies that can't keep DNSSEC running can't keep certs running. Entire TLDs have fallen off the Internet because DNSSEC has broken. A certificate never took Slack down for half a day. It's just obviously not true.

by tptacek

5/31/2026 at 12:29:03 PM

It's amazing what practice and investment can do, even for a fragile system like X.509. Yet certs still break constantly. Like permanently killing people's "perpetual" Microsoft Word licenses in a story posted within hours of this one.

by Hizonner

5/30/2026 at 10:28:49 PM

That's right, it's easier to setup such MiTM using an intermediate server, because only getting the private key of the certificate won't get you the user's traffic due to PFS.

You either need to disable PFS on the server, or export TLS master keys for each session in some way, or MiTM.

by ValdikSS

5/31/2026 at 2:55:15 PM

We should have listened to Rachel!

>I've been aware of the ACME protocol for a while. I have tech notes going back as far as 2018, and every time I looked at it, I recoiled in horror. The whole thing amounts to "throw in every little bit of webshit tech that we can", and it makes for a real problem to try to implement this in a safe and thorough way. Many of the existing clients are also scary code, and I was not about to run any of them on my machines. They haven't earned the right to run with privileges for my private keys and/or ability to frob the web server (as root!) with their careless ways.

https://rachelbythebay.com/w/2025/05/22/ssl/

by arowthway

5/31/2026 at 2:12:03 AM

This isn't what parallel reconstruction means. This seems to be reverse engineering the attack.

by nl

5/31/2026 at 3:21:56 AM

Parallel Construction is a term: https://en.wikipedia.org/wiki/Parallel_construction

Parallel *Re*construction is a play on words I wrote related to a lot of the nuance at play I wasn’t able to cover in the blog without making it very long.

by jerrythegerbil

5/31/2026 at 5:57:17 PM

Thanks for explaining. It's an interesting turn of phrase. I don't see how it relates to parallel construction.

by crystaln

5/31/2026 at 2:26:16 AM

Indeed. Parallel construction is when law enforcement doesn't want to burn their source or their source is unlawful, so they find another way to justify a warrant or prosecution even tho their initial justification comes from a different source.

This has been upheld as lawful, but also can unfortunately be used to disguise unlawful behavior.

Reverse engineering is not related to parallel construction.

by crystaln

5/31/2026 at 2:28:08 AM

Parallel construction would be if LE unlawfully intercepted transmissions using this technique and discovered a crime, then found other unrelated evidence to begin an investigation of that crime.

by crystaln

5/30/2026 at 9:16:43 PM

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

by edelbitter

5/31/2026 at 1:16:20 AM

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.

by wahern

5/31/2026 at 3:45:48 AM

I'd say it's usually on the packager (or caller) because specying privileges depends on the platform you run on, which is better known by the packager or caler

by LelouBil

5/30/2026 at 8:24:03 PM

> TLS wiretapping with root-CA-signed certificates is a thing that both happens and verifiably has happened. (...) This being a fact rather than a conspiracy theory tends to upset people.

Maybe what people get upset about is catchy misleading [0] summaries like this, which suggest [0] a CA - nation state collusion, despite the actual story going in a completely different [0] direction? The thing that would be actually big news [0]?

[0] in the eye of the beholder of course, as always

by perching_aix

5/30/2026 at 8:42:42 PM

I could see this actually being a real parallel reconstruction for a state actor that did issue certificates from a compromised CA. If any evidence points back to them, they can just say the server was hacked with the acme RCE to generate different certs. There probably won't be a way to legally verify that such a thing never happened.

by ranger_danger

5/30/2026 at 10:31:14 PM

This is a reminder why you should use E2EE messengers only.

by codedokode

5/31/2026 at 3:35:49 AM

One day that'll be illegal. End to end encryption? That obviously means you're a drug trafficking money laundering pedophile terrorist. Off to jail with you despite zero evidence. Maybe they'll declare your efforts to protect yourself as being in contempt of court and then jail you indefinitely until full decryption.

by matheusmoreira

5/31/2026 at 8:47:37 AM

Sounds heartwrenching until you see a story like this: https://youtu.be/hKLIxxBrM-o

To absolutely no sane person's surprise, the main audience of e.g. anti-censorship platforms is exactly people who typically feel or find themselves censored, which in a harmonious or at least well-functioning society will not be a particularly cheritable set of individuals. In one where that's not the case, the audience would change alongside too, sure, but clearly these narratives mismatch reality, at least for now.

Conversely, (actually) high privacy platforms will be primarily seeked out and leveraged by those who value precisely that. While the privacy scares have been pretty serious for a while, for now that is still both evidently, and indeed obviously, in good part criminals or other high risk individuals.

It's like trying to pretend people are shopping for regular items on .onion webshops rather than for contraband. I'm sure that crowd exists, but like, who are we trying to fool here exactly?

Performative victimhood only works so well, and until such blatantly deceptive narrative is being pushed, you may very well see your doomsday scenario realized. It's a trivially vulnerable position, so much so that it feels like a rhetorical trap almost. Like a poet self-sabotaging the monetization of their work, while waxing poetic about how they're (financially) un(der)appreciated. Although people have been getting into anti-government conspiracies pretty hard in the past few years, and governments have been working hard to demolish whatever good standing they have in parallel, so that does help your case I suppose. One may even recognize this miraculously well oiled process and nosedive in social trust as uncoincidental, in fact. But I digress. I wouldn't wanna spread conspiracy theories after all, would I?

by perching_aix

5/31/2026 at 11:57:42 AM

Well-funded criminal networks like the ones in the video you linked would have little issue if all e2ee chat apps disappeared tomorrow, they have enough money and operational incentives to pay someone to make custom encrypted chat apps (not to mention the myriad of open source ones available).

The only people actually hurt by banning e2ee are regular people.

> It's like trying to pretend people are shopping for regular items on .onion webshops rather than for contraband. I'm sure that crowd exists, but like, who are we trying to fool here exactly?

Based on public metrics, 3% of Tor traffic is .onion traffic and it is incredibly likely the vast majority of that is the Facebook .onion service (based on some stats posted by Facebook a few years ago).

So no, I think the burden of proof falls on you to show that the vast majority of .onion usage is illegal.

by cyphar

5/31/2026 at 1:01:51 PM

Despite that, for some reason, these well funded criminal networks keep buying into these weird phone deals instead. I genuinely don't understand why, but they do.

> So no, I think the burden of proof falls on you to show that the vast majority of .onion usage is illegal.

How does the burden of proof fall on me for a claim I (intentionally) did not make?

by perching_aix

5/31/2026 at 1:15:04 PM

> Despite that, for some reason, these well funded criminal networks keep buying into these weird phone deals instead. I genuinely don't understand why, but they do.

Given how many of them have been CIA honeypots, they must have amazing marketing.

> How does the burden of proof fall on me for a claim I (intentionally) did not make?

Nice trick -- make a very clear implication and claim that you didn't make a positive claim.

by cyphar

5/31/2026 at 1:47:59 PM

The implication (representing a belief, not a claim) was about the nature of item purchases on .onion webshops (that they're primarily contraband), not about the composition of .onion or Tor traffic. If anything, the attempt to pivot to that was a trick.

You may still fault me for mixing in beliefs into an argument, it is of poor form from me. Up to you. But then I don't think sentiments are just pure hard logic and evidence, so it'd have been potentially more dishonest from me to exclude it than to not.

by perching_aix

5/31/2026 at 11:52:57 AM

I skim-watched your link and it doesn’t seem to support your thesis.

First, the secure end-to-end encryption was broken by international police and messages were read without making it illegal.

Second they suggest reading hundreds of thousands of people’s messages to catch a dozen or so gang members - not supporting your claim that only crooks use it.

Third, the video ends by the gang leader saying he was working for the President; not supporting your implication that criticism of government is all baseless conspiracy theories.

by jodrellblank

5/31/2026 at 12:54:55 PM

I have very serious concerns on the human vs LLM effort that went into this comment, but sure, let's go point by point then.

The first counterpoint I can't even decipher, it makes no grammatical sense. Are you saying that law-enforcement-intercepted encrypted messages are not necessarily illegal? ...why would they be? Sounds like a strawman.

The second is explicitly a strawman. I intentionally left space for legitimate use, because it's a trivial rhetorical target, so I just said that it primarily interests "illegitimate" use for now. While I do not have actually comprehensive data on the Sky userbase, the way these devices were distributed, the volume of criminal-use-connected messages uncovered, and the globally dispersed gang use presented in the video did suggest to me exactly what I said. I'm not sure why you think "just catching a dozen or so gang members" is a reasonable takeaway either, given that the video's focus was exactly just those people.

We can take issue with this, and downgrade this to just being evidence of significant (in the statistical terminology sense of the word) criminal use rather than primary criminal use. I just both fail to find that particularly compelling, and don't really feel like arguing on your behalf.

The third counterpoint I also struggle to decipher. It seems to also build on a strawman like the other two points. You accuse me of implying that "criticism of govt is all baseless conspiracy theories". I don't know how you managed to extract such a thing out of what I wrote, so I'm not sure how to respond. Governments around the world are routinely criticized, have plenty of perfectly valid things going against them, on which both the media and the general public report on plenty. It is - thankfully - only a select few places in the world where such speech is actually restricted. Now that was more a part of my point.

by perching_aix

5/31/2026 at 1:21:50 PM

The first counterpoint is that you took the position E2E Encrypted messaging will be made illegal because of criminals. The video you linked to support this shows criminals being caught without banning E2E encrypted messaging. Therefore your link does not support the claim that catching criminals needs E2EE apps banning.

The second is not a strawman, you claimed that only criminals are attracted to E2EE messaging when the link you gave showed some 170 thousand users of that specific messaging app with no suggestion that most of them were criminals. "I just said that it primarily interests "illegitimate" use for now" yes you did say that, and that thing you said is not supported by your link.

The third is about your writing about how people who want privacy are performative victims who are falling into anti-government conspiracy theories, but your link shows a thing which was not a conspiracy theory and the government in question actually was accused of targetting their political enemies with gangs, and it would be reasonable to want privacy against such.

> "I don't know how you managed to extract such a thing out of what I wrote"

> "But I digress. I wouldn't wanna spread conspiracy theories after all, would I?"

maybe write less of this winky-face bs and just say what you mean.

by jodrellblank

5/30/2026 at 11:44:47 PM

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.

by upofadown

5/30/2026 at 8:28:18 PM

I thought certificate transparency was the thing that was supposed to prevent exactly what this article is describing. What if anything is incorrect about my model of the world in this respect?

by ls612

5/30/2026 at 8:35:31 PM

Basically, CT did indeed worked as designed, but there was no monitoring by the domain authors (which to be fair there are a dearth of solutions of the time).

On a related note, Let's Encrypt also issued the presumably-interception certificates. This can be possibly something that requires interception at the VPS level (otherwise we already detected the BGP leaks). Presumably, Hetzner was forced to do a raw interception and then redirecting all relevant ports to a middlebox for inspection and CA issuance (and since that the ACME spec is well-defined, they can simply check if the handshake contains the TLS ALPN challenge and then redirect them to special code that will reply with the correct things).

by zinekeller

5/30/2026 at 8:51:37 PM

Certificate transparency worked exactly as designed in this case. Monitoring public certificate transparency logs for anomalies is a different story entirely.

By breaking the software facilitating https via ACME itself, no anomalous certificate transparency logs would have needed to have been created at all.

The front door is locked quite tightly with a watchful security camera, but the window has been left unlocked. Also no one is watching the camera feed.

by jerrythegerbil

5/30/2026 at 8:35:44 PM

Nothing, although it's more mitigate than prevent per se. They simply did not have alerting set up against the CT logs. It is one of the lessons they highlighted in their own postmortem.

by perching_aix

5/30/2026 at 9:31:54 PM

Yeah I suppose the prevent part came from the Browser/CA forum giving the CA that did it the death penalty like they did for Kazakhstan's CA in 2015 but if the men with guns point them at executives of browser providers and say "trust this CA or else" then CT is more of a cosmetic system than anything else.

by ls612

5/30/2026 at 10:31:06 PM

What I more meant is that it's a reactive arrangement rather than a proactive one, so it cannot be preventative outright. Domain owners are expected to actively monitor the CT logs for abuse, and take action if they see any. This necessarily means that abuse can still happen, at least for a little while.

by perching_aix

5/30/2026 at 9:58:09 PM

Do the executives implement program features?

The most striking thing about these types of conspiracy theories is people seem to completely forget that whoever you imagine you can threaten generally doesn't have the ability to do the thing you want them to do: they'd have to delegate it.

by XorNot

5/30/2026 at 10:02:02 PM

So given that this is widely accepted to have actually happened why has the CA involved not received the death penalty like the Kazakh one did?

by ls612

5/30/2026 at 10:17:59 PM

Because unlike in that case, the CA in this story is not suspected to have done anything wrong, despite what the post's wording might suggest. See my other comment: https://news.ycombinator.com/item?id=48340259

by perching_aix

5/31/2026 at 4:32:32 AM

If you're a CA you can just issue a cert and not publish it in the CT logs. You're not supposed to do that, but there is nothing stopping it. And the attack isn't stopped even if they do publish in CT. And you have to monitor for it anyway.

Every single mitigation for known Web PKI vulns can be worked around (if people use them, which virtually nobody does).

by 0xbadcafebee

5/31/2026 at 7:07:07 AM

> If you're a CA you can just issue a cert and not publish it in the CT logs. You're not supposed to do that, but there is nothing stopping it.

Browsers have mandated CT logging for years and will not accept such a certificate.

Why is it so common to incorrectly assume that the people who came up with CT were stupid?

by joxdosba

5/31/2026 at 4:29:13 PM

> Browsers have mandated CT logging for years

They did, yes. Any CA caught issuing a non-logged cert would be in big trouble.

> ... and will not accept such a certificate

Do they not?

According to RFC 9162 including CT information inside the cert itself is optional, and the extension is noncritical. Clients are not required to support CT, and they MAY fetch inclusion proofs. Servers are supposed to send CT info via one of various methods - but they aren't required to supply a complete proof of inclusion. Considering how OCSP was implemented in practice, I highly doubt any browser is willing to completely block the connection until it has managed to fetch an inclusion proof - both from a speed perspective and a privacy perspective.

CT's main value is in giving the browser vendors a stick to hit the CA with in case of non-logging, which is indication that something fishy is going on. Send the cert itself to a mailing list and anyone can check with the logs. Log getting DDoSed? Just try again tomorrow, the CAs judgement can wait another day. This is completely different from having a browser verify the proof in realtime while setting up the connection, and having it fail hard if it can't be 100% sure.

by crote

5/30/2026 at 9:11:33 PM

CT indeed worked out pretty well. At least until bots started hammering crt.sh making it unreliable, and those that want to be alerted to newly issued certificated appeared in the logs need to pay for some purpose-built service instead of just adding a relevant query to their feed reader.

by edelbitter

5/30/2026 at 10:29:57 PM

The wrong part is that Let's Encrypt was willing to issue a valid cert to anyone who can temporarily redirect traffic. The authorization should have been done better, for example, sending a certificate to operator's email.

by codedokode

5/31/2026 at 4:38:17 PM

There is no such thing as an "operator's email". Over time there has been a wild growth of webmaster@, admin[istrator]@, root@, postmaster@ and so on, but having access to them proves very little. Some email operators just aren't very restrictive with their allowed usernames, and that's before we get into the corporate world where the first-line helpdesk person weeding out the email received on that address probably isn't supposed to issue certificates!

This method has been (mostly?) banned for a reason, see for example CA/B's ballot SC080v3.

by crote

5/31/2026 at 8:18:20 AM

Can we get an RSS feed? Loved the post.

by Peacefulz

5/31/2026 at 7:00:46 AM

So it looks like Hetzner is doing the same thing OVHCloud did with EncroChat and SkyECC. But hey, we have GDPR, keep your data hosted in the EU it is very "safe" there (ironic).

https://en.wikipedia.org/wiki/Shutdown_of_Sky_Global#Communi...

EDIT: Based on German law this certainly is not a lawful interception but one made by an intelligence agency.

by janmo

5/30/2026 at 8:14:00 PM

What LI vendors can break https?

by TZubiri

5/30/2026 at 8:36:02 PM

The sloppy ones who want a huge headache and leave a publicly auditable trail a mile long that get analysis blogs written about their mistakes.

by jerrythegerbil

5/31/2026 at 11:19:21 AM

[dead]

by ghostlyInc