The baddies also take a look at the CT logs and look for fresh wordpress instances that haven't yet been configured and will helpfully configure them for you within a few minutes.
Yes but a lot of non-browser software doesn't check CT logs, so if an attacker were to target such software they could use an unlogged cert and no one would notice.
The CT log is a property of the individual leaf certificate not a property of the issuing chain. You could have the same CA in the trust store issue an unlogged certificate and non browsers would trust it.
A CT log isn't super relevant (it's not the CRL, it's just a log), but it's maintained/delivered by the CA not the leaf. Never the leaf.
If you mean CRL/Revocation list, everything but the root [you can't revoke a root] is maintained by the tier above. Leaf -> intermediate (these), [Intermediate -> Intermediate*], Intermediate -> Root.
Not sure why you're mentioning transparency logs, they have nothing to do with this (nor help).
Because the thread: "a lot of non-browser software doesn't check CT logs", you replied saying it's a reason to use the OS trust store, not sure how that fixes things? Maybe it would relieve them of the responsibility of pushing out a distrust update?
That's not what woodruff is talking about (I hope). The CT logs allow us to (later) find who/why it happened. CT Logs in no way help you stop something. (Depends a bit on how software reacts to apparently invalid issuance - but since these have the real keys the issuance will look normal).
Revocation lists allow you to stop/block bad issues. Both are maintained/decided (you could post to another service) by the issuer, not the leaf. CRL records would stop this (but some software has decided that's too slow). In general software uses the OS trust-store first (fragmented on Linux). Firefox and Java have their own independent paths. Chrome ignores CRLs
CT logs only tell you something happened if the certificate was registered in the log. But if you are attacking software that doesn't check if the cert was registered, then you don't need to register the cert, and there won't be anything in the log.
My point is you can forge a cert, without putting it in the log, and a lot of software will still be vulnerable to it.
Curl does not check that certificates have a valid SCT attached. Thus it will accept a certificate that isn't in the CT logs. That's mostly independent of the OS trust stores.
Sure, but a client that doesn't do CT wouldn't care if they don't include a SCT promise. [ed.: this said "break the SCT promise", that doesn't quite make sense] Which you'd only notice if you see the certificate somewhere else afterwards…
It's all rather hypothetical and unlikely, but you could certainly try attacking something like downloads.openwrt.org¹ like that — especially if you can tell apart the TLS client in opkg from a normal browser.
(¹ luckily, OpenWRT and most other package repos don't actually rely on HTTPS for package integrity and authenticity. And OpenWRT would be the most susceptible due to the "exotic" TLS client stack, if any.)
To spell it out a bit further, an attack strictly in a non-browser context that is reasonably well targeted will most likely go undetected since what the attacker is up against is the chance of inadvertently running into a paranoid user who goes out of his way to perform verification.
I hold eMudhra's private key. I generate a cert signed by their intermediate on my box. eMudhra didn't issue the cert, so it is not sent to any CT logs, and I have no SCT to put in the cert.
I think I might just be talking past you. If your point is "anyone with these broken eMudhra keys can attack users without caring about CT", that's totally true --- it's just that browser/no-browser doesn't factor into it. I'm really only on this subthread because of the notion that CT enforcement requires browsers.
Right, I think I'm with you that browser/no browser shouldn't be a factor. I think I'd like to hear from Rust and Go webpki people on whether we could help the ecosystem enforce CT.
My point is more that as a user of a high-level library like reqwest, I'd like to talk safer defaults when root CAs are in use
There are plenty of ways you would never be able to tell if a fake cert had been generated and used via this attack vector (let's ignore validation attacks):
1. CT does not do anything if a state actor demands a CA in its borders generate a cert without publishing to the CT logs (or a three-letter-agency doing this illicitly). They can put SCTs in the cert, and still not publish to the logs, nobody is auditing the logs for every cert every browser sees.
2. Browsers won't check for SCTs in certs if they come from a private CA. you can MITM any domain through ZScaler all day long and nobody will notice
3. Wildcard certs make it easy to make/renew a cert that looks normal but hides requests on new/different hosts
“They can put SCTs in the cert, and still not publish to the logs, nobody is auditing the logs for every cert every browser sees”
I don’t think you can get the SCT from a log without the log publishing it? That would defeat the purpose.
“Certificates that support certificate transparency must include one or more signed certificate timestamps (SCTs), which is a promise from a log operator to include the certificate in their log within a maximum merge delay (MMD).[4][3] At some point within the maximum merge delay, the log operator adds the certificate to their log.”
> I don’t think you can get the SCT from a log without the log publishing it?
Well you can, but only if the log cooperates.
That is, the SCT is merely a promise to add the certificate to the log by some particular deadline. Nothing technically stops the log from disregarding that promise. But if it does fail to log the certificate, the SCT itself is proof of its misbehavior.
And it's not enough to subvert a single log, because browsers require SCTs from multiple distinct operators in order to consider a certificate valid.
The SCT may be proof that a log was supposed to be issued, but browsers don't submit every SCT they see (did you know "anonymizing" proxies send CT log companies a sampling of all your TLS traffic? fun stuff!), so in practice these logs aren't audited. As far as multiple operators, almost all of them are based in the US, so just pray the USG doesn't want to target you.
I feel somewhat confident in speculating that a bunch of people at large companies will, in fact, be auditing the logs following this. That’s their main value; they’re not really an online/active prophylactic.
The reason nobody bothers with NCs is because they don't work very well in practice. They also have their own baroque matching rules that are not intuitive if you're from the land of UNIX globs.
(In fairness this is a self-fulfilling prophecy: a lot of validators handle NCs poorly or not at all, so there's no impetus to rely on them. But that's not something we can really save in the Web PKI's current state.)
> But that's not something we can really save in the Web PKI's current state.
I agree with your assessment but it's not an excuse to give up without trying. I hope this is just because I'm not looking in the right places, but I don't see people trying.
What really makes me salty is that there was enough energy to mess with the rules around EKU, the primary effect of which is that non-browser software is now starting to just ignore the EKU bits. Even if it would've amounted to nothing, I'd really rather that effort had gone into NCs.
I think a lot of people have tried! The reason EKUs stuck where NCs haven’t is because EKU rules are simple (in relative terms) and OpenSSL didn’t make as much of a mess out of them.
I can't help but read your post as "OpenSSL didn't make a mess of EKUs so the CA/B had to fill that role instead" :/
(I really am salty about the EKUs. In a few years the EKU field will just be useless, due to operational annoyance driving devs to ignore it. Except in browsers of course.)
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.
> But PGP is useful if both sender and receiver agree to use PGP.
Anecdotally: this works until you add a third person who responds to the thread in plain text, with everything threaded beneath. Or when you do that by accident.
Applied cryptographers will tell you to use Signal or any other E2EE chat.
Signal's has buildable source code on the client side and all. However, the server code is closed source and the developers have made disquieting changes like uploading most users' contact lists to the server protected only by Intel SGX that is known to have vulnerabilities exploitable by a nation-scale actor.
The point of E2EE is that you don't need to trust the server that you're talking through. A secure E2EE scheme is secure in the presence of an actively malicious server.
I think SGX is a red herring in this context. You can find it risky or not, but it's (1) not material to Signal's E2EE property, and (2) materially better than email, which sends all contact metadata in plaintext, regardless of whether you try and encrypt your message bodies. Bringing it up in this context seems like a category error.
Is this accounting for the fact that they kill people based on metadata? More technically complex and unreliable protocols such as SimpleX attempt to also protect the metadata.
The point is that if the comparison point is PGP-encrypted email, which has no protection for any metadata and passes it on the wire in the clear, raising concerns about Signal’s metadata protections makes no sense.
This was my first question as well. There’s a big gap between “ad network delivers JS” and a zero-click browser exploit. CitizenLab has done some great research including OSINT on the former, but there’s a conspicuous gap between it and the DLL ending up on the victim’s machine.
This has one of the hallmark indicators of bad analysis: it leaves the reader to complete the author’s thoughts, assuming that we’ll reach the same bleak and conspiratorial conclusions as them.
Cases in point:
- The Rust Foundation has corporate sponsors. Have they, in fact, acted in a manner that should undermine our trust in Rust, the language?
- The Rust compiler could contain a backdoor. Does it, in fact, and what are the reasons we would have to believe that?
The 'woah, slow down' also just feels kinda... late? Rust is pretty mature by now, it's not really some new unproven thing that needs a bunch of work to be useful.
Gentoo’s decision to support source builds seems eminently reasonable to me, and I don’t think we should reward it with condescension.
The bigger problem, to me, is that it’s not really clear why this is actually a problem for Gentoo. I am glad they perform user-facing source builds, however, because they see things that other distributors don’t.
I think mgorny is aware of that; he’s been active on the relevant DPO threads.
(At the end of the day, this is exactly what support tiers are for. CPython, at least to my eyes, has been very transparent about not guaranteeing support for every platform that has a C compiler.)
I found this recently - couldn't compile it on HPUX. Trying to get rust on there would have been an absolute impossibility of course. I can get bash though, and lots of other GNU utilities - all written in C of course. Thank goodness some people care!
People who don't care about HPUX will never care about it but they would if e.g. we decided that only windows and Ubuntu were supported ... except for the windows and ubuntu python users who wouldn't care.
It's I'm-all-right Jack until it's your use case that gets bulleted.
Hi, one of the co-maintainers of GNU coreutils here. It is nice to hear things worked on HP-UX. I don't have access to it, and I don't think the other maintainers do either. See this commit [1].
[1] https://github.com/coreutils/gnulib/commit/c599eba7bed3baa30...
Yes we're using quite an old version 8.13 and yet it does the job for our build which maintains an EXTREMELY important bit of software in public service relating to healthcare.
It's on Itanium so obviously we have to move away from that to Linux but the existence of open source tools like coreutils gives us time.
No such luck with python. We have to postpone some changes as a result.
As I say, there's some kind of effect where changes that are only negative on the margins are cheered until one finds oneself on one of those margins.
Glad you could get an older version works well for you. We probably would have tried to continue supporting it if we had access to it. I'm a bit sad I never got the chance to use it once.
However, the other maintainers, who have been doing it for many more years than I have, and various other authors are certainly more deserving than I am. I am similarly thankful to them.
I think there’s a categorical difference between HP-UX (which seems to no longer even be maintained by HP) and something like Linux on the top 5-6 most popular architectures.
(But with all that said: there’s no ideological dispute here. If there was a reliable way to build and test for HP-UX, I assume a lot more people would declare support for it. The problem comes down to maintainers being asked to support platforms they ultimately have no ability to support, except in the weakest sense of “it compiles.”)
When you think about GNU autotools they're all about being able to compile on platforms that the software has never been compiled on before - that's why there are all those feature tests to see what the OS and compiler support.
I've done this many times on things like AIX 4.3 and HP-UX and so on. Sometimes you can get through the compile without any problems at all and the tool often works enough for your usecase and that's a win.
Sometimes there are particular little problems, sometimes it's something serious like an actual missing C library call or whatever and then you have to do some work. With nicely designed tools that have fairly wide support to begin with this tends to be easier.
(But in any case, CT ensures that it can’t be “quiet.”)
reply