Tie-in to X.509/web PKI, and locking/unlocking a domain to Source Code Transparency

[estark37]

The explainer says:

To signal to the browser that a given web app is using Source Code Transparency, we could introduce a X.509 certificate extension, which would automatically be included in the Certificate Transparency logs

I don't think the security model quite holds together if the web PKI certificate is the signaling mechanism for when an origin is using Source Code Transparency. CT logs are designed for domain owners to monitor for malicious certificates for their own domains; the domain owner has full information to evaluate whether a certificate that appears in the logs is malicious or not. But in the Source Code Transparency case, it's external observers who would be monitoring the logs, and external observers don't necessarily have the information needed to distinguish an attack from an innocuous scenario (e.g., domain name transfers to new owner, or domain owner decides to stop using Source Code Transparency for some reason). Maybe in some limited scenarios it would be possible to pinpoint suspicious behavior (e.g., presumably a non-Source-Code-Transparency certificate appearing for signal.org would always be deemed suspicious), but I don't think it's a satisfying security story in general.

I think a more satisfying security story would involve some kind of browser-side enforcement, like origin separation when Source Code Transparency is in use vs when it's not -- though this is a complicated technical proposition. Another option could be some kind of browser UI that distinguishes the use of Source Code Transparency, but that's kind of icky. Or there could be some kind of pinning/HSTS-like solution where an app can ask the browser to refuse to load it subsequently if Source Code Transparency is not in use... I don't love any of these ideas, so I don't know what the right answer is, but I did want to note that the security story is unsatisfying IMO if we're relying on external observers to distinguish innocuous from malicious signals in CT logs.

I'll also note that extending web PKI certificates for this use case could be undesirable in other ways. It could complicate the path to deployment, as multiple CAs would need to get on board with signing this new extension, and there might be a tension between automating TLS certificate management and using Source Code Transparency, until automated certificate management software adapts to support the extension (if it ever does).

[twiss]

Thanks for the comments!

Maybe in some limited scenarios it would be possible to pinpoint suspicious behavior (e.g., presumably a non-Source-Code-Transparency certificate appearing for signal.org would always be deemed suspicious)

I agree that the scenario is somewhat limited, but this kind of scenario is exactly the target use case for Source Code Transparency. Of course it's not applicable to all or even most web apps, but this proposal is targeted at web apps that explicitly don't want to trust the server, and e.g. use end-to-end encryption or just don't send any private data to the server. In that scenario, a domain name ownership change, or removing Source Code Transparency after adding it (especially if it was communicated / advertised) should indeed always be suspicious.

I.e. in general, if a web application claims to use Source Code Transparency, but then security auditors find a certificate in the CT logs without the Source Code Transparency extension, that would be something to flag - similarly to if they found a security issue with the source code of the web app.

I think a more satisfying security story would involve some kind of browser-side enforcement

Since Source Code Transparency is inherently a detection mechanism, rather than a prevention mechanism, browser-side enforcement might not add that much, since it still doesn't prevent malicious code from running in users' browsers, it just makes it detectable. Checking the CT logs is similarly sufficient to detect whether malicious code could've run. The only thing that requiring Source Code Transparency would add is to make it detectable what (potentially malicious) source code was run - since any code not in Source Code Transparency wouldn't have run - which to be fair might still be very useful.

And, in cases where there is some kind of browser-side expectation of additional security, such as when installing an Isolated Web App, I could easily imagine requiring Source Code Transparency as well.

I'll also note that extending web PKI certificates for this use case could be undesirable in other ways. It could complicate the path to deployment, as multiple CAs would need to get on board with signing this new extension, and there might be a tension between automating TLS certificate management and using Source Code Transparency, until automated certificate management software adapts to support the extension (if it ever does).

That's fair enough. There's another potential solution which is, if we manage to agree on a Source Code Transparency log that all browsers check, then browsers could always check that, and accept any source code if the log could serve a non-inclusion proof for the domain in the latest epoch. If the log did include an entry for a given domain, it would be unable to serve a non-inclusion proof, and so auditors could simply check that every epoch has a (correct) entry.

However, this has downsides in that there would be some overhead and leakage, even in the case that the user doesn't use any web apps that use Source Code Transparency. So, having some signalling mechanism might be desirable.

And, having a signal in the certificate (making it automatically auditable) seemed like the best way to achieve that to me, but of course we'd have to see whether we can get Certificate Authorities on board, and if not, we might need some other kind of signalling mechanism.