akerl_

I don’t understand.

The name of the site is GitHub. The repo is called tttt, with the description “The Tess TypeScript Type checker”.

How did it seem like the title you wrote reflected the rules?

It’s worth noting that while folks were getting busy with 11 and 13, plenty of experts in the field were saying ~“yes, we do have viable exploits here, but we’re not sharing them at this time. This is a big deal.” And that the person who spun up 13 spun up a static html page at first and also misrepresented how vanilla the stack was.

We could have skipped from 7 to 19 if folks had just taken seriously the guidance from experts in the field.

A bunch of folks tried to say the challenge was dubious at best and that the vulnerability was a legitimate concern, and were told by commenters here that they were fearmongering or shills.

Evidence has shown they were pretty spot on about the first part (the test originally served static html, the php code wasn’t actually as vanilla as described, and the bitcoin key wasn’t actually there).

I’d have hoped this kind of clear vindication on the first point might have caused folks to revisit their stance on whether to trust the expert stance on the second. But maybe I’ve been overly optimistic.

I’ve been using docker since the early days. One of the early choices I made and stuck with is to never let Docker touch iptables.

I make a bridge for Docker to use and configure iptables rules myself via parallel config management.

That assumes the key is actually on the server.

A reminder that this cannot falsify the existence of an exploit, trivial or otherwise.

It can only show you if someone has used an exploit against this server.

Sure, but I’m only worried about CAs that exist in root trust stores, and a CA that ignores CAA records has two options:

1. Publish a CT record and tattle on themselves when they issue

2. Don’t publish a CT record and tattle on themselves when they try to use the cert

Either one ends with them getting the boot from the root trust stores. There’s very few folks out there whose adversaries are willing to burn an entire root-trusted CA to attack.

> have the website define which CA they use, and don't let any of the others certify it.

Isn’t this exactly what CAA records are for?

Similarly to vaccines, part of the magic is that you don't need "all", you just need "most".

Right now CT support is rough for things outside of browsers; it's a pretty fair bet that if you pick up a command line tool or library, it is not checking SCTs, and that makes those workflows vulnerable. If we flipped that, and the average command line tool or library did validate by default, it would dramatically alter the risk calculus for attackers.

You said "yes" but then answered "no"?

Like it seems your disagreement is that you're pointing out there are systems today that trust WebPKI CAs but don't validate CT/SCTs. I'd agree that that's an issue and I want those systems to join the world where CT exists.

As I said, in a world with CAA records and CT logs, this isn't an issue. If your CA wants to be in root trust stores, you have to put your certs in CT logs. CAA records are "advisory" in the sense that we mandate that root-trusted CAs obey CAA records and that they write cert issuance to CT logs, so a trusted CA that violates CAA records has to tell on itself in a very detectable way.

In a world with CT logs and CAA records, is that actually the case?

I don’t think you’re grokking what “death penalty” means here.

If a CA does something stupid or malicious, the browsers remove that CA from their root stores, effectively ending that CA’s existence as a going concern. People with websites go buy replacement certs from a new vendor and life goes on. This has happened before and is a massive incentive for CAs to not fuck around, and it incentivizes everybody to lean into improving the security of issuance.

It’s basically impossible to do the same thing to a TLD. If .io goofs around and is negligent in handling their security, you can’t do anything unless you’re willing to make every .io website rehome to a new TLD.

Seems to be 100% AI-written content.

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 is an especially interesting comment given that it misunderstands the Dropbox comment in the common way.