Skip to content

architecture.md

Latest commit

 

History

History
156 lines (114 loc) · 6.8 KB

architecture.md

File metadata and controls

156 lines (114 loc) · 6.8 KB
Raw

Architecture

Note

This doc is meant to be purely informative, and makes no commitment to any support level nor future plan.

Platforms

At the moment, TesseraCT can run on the following platforms:

TesseraCT is built on top of Tessera. At the moment, the Tessera MySQL-only driver is not supported by TesseraCT.

Common infrastructure

Regardless of the platform it's running on, a TesseraCT instance is composed of the following elements:

  1. At least one instance of a server built using the Tessera library configured with the appropriate driver and antispam implementations for that platform.
  2. An additional storage system to store issuer certificates, usually co-hosted with Tessera's log storage system.

TesseraCT uses the CT specific features in Tessera to be compliant with the static-ct-api specs.

By design, a TesseraCT server manages a single log. To increase reliability, multiple identical TesseraCT instances can run concurrently for a single CT log. To serve multiple distinct CT logs, bring up at least one TesseraCT server per log.

For additional details, read Tessera's design document, and the platform-specific details below.

Antispam

Tessera's antispam is used to minimise the number of duplicate entries accepted into a log.

When Tessera detects that a submission is a duplicate of previous one, it returns the index of that previous entry, without adding an additional entry. This index is required, but not sufficient to build the SignedCertificateTimestamp (SCT) returned to clients. To build this SCT, TesseraCT also needs the timestamp of that previous entry. TesseraCT fetches the previous entry at the given index, and extract its timestamp to rebuild the SCT.

TesseraCT can rate limit these duplicate submission independently from non-duplicate ones, thus allowing logs to prioritize non-duplicate submissions.

Garbage Collection

[Tessera's Garbage Collection] deletes partial tiles and entry bundles once a corresponding full tile or entry bundle has been published. It runs periodically in the background.

Chain filtering

TesseraCT needs to parse incoming certificate chains to process them. This allows:

  • TesseraCT to filter and reject chains based on various criteria such as the root certificates they chain up to, or their validity date
  • TesseraCT to construct the log entries which will be added to the log

By design, Go's crypto/x509 library blocks non-standard certificate chains, such as precertificate chains, or chains that are not safe to use. TesseraCT uses internal/lax509, a lightweight fork of Go's crypto/x509 library to parse chains.

Detailed architecture

Google Cloud Platform (GCP)

This implementation is composed of:

  1. One or multiple TesseraCT servers. For reliability, multiple servers can run concurrently.
  2. Tessera's backend infrastructure:
    1. A GCS bucket. TesseraCT reuses this bucket to store issuer certificates.
    2. A Spanner database used for sequencing entries, and antispam.
  3. Key materials, stored in Secret Manager

APIs:

  1. Submission requests (add-chain, add-pre-chain, get-roots) are processed directly by TesseraCT servers.
  2. Monitoring requests (fetching the checkpoint, tiles, log entries and issuers) are handled directly by GCS, without going through TesseraCT servers.

See the Tessera GCP design doc for additional details.

Amazon Web Services (AWS)

This implementation is composed of:

  1. One or multiple TesseraCT servers. For reliability, multiple servers can run concurrently.
  2. Tessera's backend infrastructure:
    1. An S3 bucket. TesseraCT reuses this bucket to store issuer certificates.
    2. A MySQL RDS database used for sequencing entries, and antispam.
  3. Key materials, stored in Secrets Manager

APIs:

  1. Submission requests (add-chain, add-pre-chain, get-roots) are processed directly by TesseraCT servers.
  2. Monitoring requests (fetching the checkpoint, tiles, log entries and issuers) are handled directly by S3, without going through TesseraCT servers.

See the Tessera AWS design doc for additional details.

Vanilla S3+MySQL

While TesseraCT's AWS implementation uses RDS and S3, its configuration APIs are intended to be compatible with any MySQL database, and S3 compatible backend, such as MinIO. If you are already running these services, this might be a good option to consider depending on your needs.

Warning

S3-compatible backends do not all provide the same guarantees that S3 does, and might therefore not be suitable to run TesseraCT.

POSIX filesystems

This implementation needs only:

  1. A POSIX-compliant filesystem (e.g. ZFS) to store the log, and
  2. Any HTTP server capable of directly serving the files from the log stored on that filesystem.

See the Tessera POSIX design doc for additional details.

If you are comfortable running a web-server and unix-style binaries in a VM (or on bare metal) and do not want the complexity of running additional storage and database services, this might be a good option.