Is there some high-level overview of this "cascade of Ribbon filters" data structure? I understand bloom filters, but couldn't get any intuition for this one from FB's blog post.
INFO - Loaded 21 CRLite filter(s), most recent was downloaded: 0 hours ago
DEBUG - Loaded certificate from github.com
DEBUG - Issuer DN: C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo ECC Domain Validation Secure Server CA
DEBUG - Subject DN: CN=github.com
DEBUG - Serial number: 00ab6686b5627be80596821330128649f5
DEBUG - Issuer SPKI hash: 6YBE8kK4d5J1qu1wEjyoKqzEIvyRY5HyM_NB2wKdcZo=
TRACE - 20250809-1-default.filter: Good
TRACE - 20250810-0-default.filter.delta: Good
TRACE - 20250810-1-default.filter.delta: Good
TRACE - 20250811-0-default.filter.delta: Good
TRACE - 20250811-1-default.filter.delta: Good
TRACE - 20250812-0-default.filter.delta: Good
TRACE - 20250812-1-default.filter.delta: Good
TRACE - 20250813-0-default.filter.delta: Good
TRACE - 20250813-1-default.filter.delta: Good
TRACE - 20250814-0-default.filter.delta: Good
TRACE - 20250814-1-default.filter.delta: Good
TRACE - 20250815-0-default.filter.delta: Good
TRACE - 20250815-1-default.filter.delta: Good
TRACE - 20250816-0-default.filter.delta: Good
TRACE - 20250816-1-default.filter.delta: Good
TRACE - 20250817-0-default.filter.delta: Good
TRACE - 20250817-1-default.filter.delta: Good
TRACE - 20250818-0-default.filter.delta: Good
TRACE - 20250818-1-default.filter.delta: Good
TRACE - 20250819-0-default.filter.delta: Good
TRACE - 20250819-1-default.filter.delta: Good
INFO - github.com Good
I remember you talking about this the other day when we met at RustWeek.
The CLI tools on Linux have certainly missed many of the recent great improvements in verification technology, so there is a gap between browsers and non browser components doing TLS now. OpenSSL doesn't enable CT by default, unlike Chrome, and it also doesn't handle revocations well either, nor does it enforce the certificate lifetime requirements.
The best solution would be a very stable IPC based API which connects to a systemd service (or something deployed as widely as systemd).
That component could probably also manage the certificates, and only apply these restrictions to "global" certificates. It could distinguish manually configured ones from explicitly configured ones. IIRC most of the file based standards the linux distros adopt can't even distinguish that.
That service would then do the locking needed to have on disk state (CRLite).
It's a complicated project, but also not on the scale of hundreds of thousands of lines of code: most of the components and libraries are available already. One needs to glue it together in the right way and then package it up nicely.
The complicated part would be to convince the Linux community to adopt it hahah.
Is there some high-level overview of this "cascade of Ribbon filters" data structure? I understand bloom filters, but couldn't get any intuition for this one from FB's blog post.
edit: found an overview here that helps a bit: https://news.ycombinator.com/item?id=27800788 This seems good but will take more time to absorb: https://pangyoalto.com/en/ribbon-filter/
The Github repo for the backend implementation is here: https://github.com/mozilla/crlite/ Notably, you can query CRLite from the CLI using https://github.com/mozilla/crlite/tree/main/rust-query-crlit... - like:
$ git clone https://github.com/mozilla/crlite.git $ cd crlite/rust-query-crlite/ $ cargo run -- -vv --update prod https github.com
INFO - Loaded 21 CRLite filter(s), most recent was downloaded: 0 hours ago DEBUG - Loaded certificate from github.com DEBUG - Issuer DN: C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo ECC Domain Validation Secure Server CA DEBUG - Subject DN: CN=github.com DEBUG - Serial number: 00ab6686b5627be80596821330128649f5 DEBUG - Issuer SPKI hash: 6YBE8kK4d5J1qu1wEjyoKqzEIvyRY5HyM_NB2wKdcZo= TRACE - 20250809-1-default.filter: Good TRACE - 20250810-0-default.filter.delta: Good TRACE - 20250810-1-default.filter.delta: Good TRACE - 20250811-0-default.filter.delta: Good TRACE - 20250811-1-default.filter.delta: Good TRACE - 20250812-0-default.filter.delta: Good TRACE - 20250812-1-default.filter.delta: Good TRACE - 20250813-0-default.filter.delta: Good TRACE - 20250813-1-default.filter.delta: Good TRACE - 20250814-0-default.filter.delta: Good TRACE - 20250814-1-default.filter.delta: Good TRACE - 20250815-0-default.filter.delta: Good TRACE - 20250815-1-default.filter.delta: Good TRACE - 20250816-0-default.filter.delta: Good TRACE - 20250816-1-default.filter.delta: Good TRACE - 20250817-0-default.filter.delta: Good TRACE - 20250817-1-default.filter.delta: Good TRACE - 20250818-0-default.filter.delta: Good TRACE - 20250818-1-default.filter.delta: Good TRACE - 20250819-0-default.filter.delta: Good TRACE - 20250819-1-default.filter.delta: Good INFO - github.com Good
CRLite is awesome, and it deserves more usage; notably most non-browser clients on Linux machines don’t get any revocation handling at all.
I remember you talking about this the other day when we met at RustWeek.
The CLI tools on Linux have certainly missed many of the recent great improvements in verification technology, so there is a gap between browsers and non browser components doing TLS now. OpenSSL doesn't enable CT by default, unlike Chrome, and it also doesn't handle revocations well either, nor does it enforce the certificate lifetime requirements.
The best solution would be a very stable IPC based API which connects to a systemd service (or something deployed as widely as systemd).
That component could probably also manage the certificates, and only apply these restrictions to "global" certificates. It could distinguish manually configured ones from explicitly configured ones. IIRC most of the file based standards the linux distros adopt can't even distinguish that.
That service would then do the locking needed to have on disk state (CRLite).
It's a complicated project, but also not on the scale of hundreds of thousands of lines of code: most of the components and libraries are available already. One needs to glue it together in the right way and then package it up nicely.
The complicated part would be to convince the Linux community to adopt it hahah.
CRLite sounds like an elegant solution. Are there reasons why Chrome is not implementing it or do they just have other priorities?