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.
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.
Certificate authorities?
Domain registrars?
Both of them are subject to government control and regulation and as such Web PKI provides normal commercial level of security, it doesn't protect from government agencies.
To protect from government agencies we would need to move from addressing web pages using domain names to addressing web pages using public keys. This is hard because of Zooko's triangle.
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.
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.
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.
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 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.
Every single mitigation for known Web PKI vulns can be worked around (if people use them, which virtually nobody does).
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?
This method has been (mostly?) banned for a reason, see for example CA/B's ballot SC080v3.
Sprinkle some DNSSEC on the CAA record too, if you'd like.
[0]: https://developers.cloudflare.com/ssl/edge-certificates/caa-...
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...
You either need to disable PFS on the server, or export TLS master keys for each session in some way, or MiTM.
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.
This has been upheld as lawful, but also can unfortunately be used to disguise unlawful behavior.
Reverse engineering is not related to parallel construction.
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?
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.
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.
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
>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://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.
