Ty/ct-rs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
No description
32 commits 1 branch 0 tags 147 KiB
Find a file
Exact
Tyler Beckman f061b94d35
 revamp downloading, add validation and proper hashing and signature validation
2025-02-08 02:42:32 -07:00
.vscode log lists, some examples, clippy, and more 2025-02-06 00:17:37 -07:00
bin revamp downloading, add validation and proper hashing and signature validation 2025-02-08 02:42:32 -07:00
lib revamp downloading, add validation and proper hashing and signature validation 2025-02-08 02:42:32 -07:00
.envrc update 2025-02-04 22:52:03 -07:00
.gitattributes vendor 2025-02-06 00:20:06 -07:00
.gitignore update 2025-02-04 22:52:03 -07:00
Cargo.lock revamp downloading, add validation and proper hashing and signature validation 2025-02-08 02:42:32 -07:00
Cargo.toml chore: Restructure into workspace w/ bin crate 2024-11-05 22:59:09 -07:00
deny.toml make rustls, rustcrypto, and webpki-roots deps dependent on api feature 2025-02-06 15:19:56 -07:00
flake.lock revamp downloading, add validation and proper hashing and signature validation 2025-02-08 02:42:32 -07:00
flake.nix revamp downloading, add validation and proper hashing and signature validation 2025-02-08 02:42:32 -07:00
LICENSE.md License under the GPLv3 and setup cargo-deny properly 2025-02-06 01:52:28 -07:00
README.md License under the GPLv3 and setup cargo-deny properly 2025-02-06 01:52:28 -07:00
rustfmt.toml Initial commit for Jujitsu (JJ) vcs 2024-10-25 19:50:05 -06:00

README.md

ct-rs

A certificate transparency client written in Rust, in the form of a library and accompanying CLI.

Supported versions

As of the present, the only "certificate transparency" API supported is the original v1 API, however after I feel the v1 API support is mostly feature complete I would like to implement some of the newer (though rarely used) APIs in addition.

  • [/] RFC6962 v1
    • The original API, and the only one truly used by current CT ecosystem
  • C2SP/static-ct-api static-ct-api (f.k.a. "sunlight")
    • A substitute for the RFC6962 v1 monitoring APIs, based on static asset paths hosting "tiles" of the merkle tree rather than dynamic GET endpoints
  • RFC9162 v2
    • A much more modern rendition of the full certificate transparency spec, extremely backwards in-compatible with the v1 systems, though with many notable improvements.

FAQ

What is certificate transparency?

Certificate Transparency is a lesser-known part of the web public key infrastructure that is intended to help hold Certificate Authorities accountable for their issuances, and catch any maliciously or mistakenly issued certificates early. The basic idea is that all major trusted CAs will publish every single certificate they issue to a world-readable, append-only, cryptographically secure log. Large browsers (namely Chromium, Safari, and Firefox) all require website certificates to be published in these logs in order to encourage adoption by CAs.

As we often give full trust in CAs to properly issue certificates and validate ownership of domains, certificate transparency alleviates this partially by cryptographically guaranteeing that a presented website certificate is published in a public log and that that public log has only ever appended certificates, never modified or deleted. This is done by utilizing a Merkle Tree structure, in which all entries are hashed in a binary tree format. Utilizing this structure, a given log at two times can be verified for its append-only nature trivially, and any given entry can be validated as a part of the larger log in logarithmic time. If a given log fails due to modification or deletion of entries, anyone actively verifying the log can easily tell and raise the alarm that something has gone wrong.

Besides the cryptography, Certificate Transparency is useful to the average domain owner because by trivially scanning all public CT logs, you can tell if any unauthorized certificates were issued for domains you own, allowing you to independently verify that your domain can't be impersonated and your HTTPS will always be MITM-free (for the average person using a standard root store and updated browser, of course).

Why does this exist?

This exists because after I personally learned about Certificate Transparency and realized that there was really only one self-hosted solution, certspotter. Thus, I decided it would be a fun project to implement CT in rust, mostly tailored to my needs (scan CT logs, but not necessarily verify them). At some point I might end up using this to monitor CT logs for my personal website, but this is nowhere near complete nor functional in its current state.