Performant Certificate Transparency Monitoring Intermediate talk for - PowerPoint PPT Presentation

Chair of Network Architectures and Services Department of Informatics Technical University of Munich Performant Certificate Transparency Monitoring Intermediate talk for the IDP by Otto Breitwieser advised by Max Helm, Patrick Sattler Monday 8 th June, 2020 Chair of Network Architectures and Services Department of Informatics Technical University of Munich

Overview • Why • How • Architecture • Numbers • Encounters • Outlook O. Breitwieser — Performant Certificate Transparency Monitoring 2

Why Motivation Certificate Transparency[1] (CT) is a framework introduced by Google and rolled out in Chrome and other internet browsers to close some attack vectors on HTTPS connections. It inspects not only the formal, but also the factual validity of certificates and their issuer certifi- cates. To be able to do some research on this field, data (in this case the certificates) is needed. The certificates are stored in so called logs. To be independent of these logs, a local copy of the certificates is useful. O. Breitwieser — Performant Certificate Transparency Monitoring 3

Why Goals Having some data points in a database for easy searching and asserting is nice, for more in-depth analysis the full data is needed. The goal of this IDP is to have a running service that continuously scans all known logs for new certificates and stores them for future use. O. Breitwieser — Performant Certificate Transparency Monitoring 4

How Used technologies (Hard-/Software) • Software • Go[4], version 1.12 • Google’s certificate-transparency-go[2] Codebase • Previous works on ctlogs from Max Helm[8] • PostgreSQL[9], version 11, for the FAS (Fast Access Storage) • LevelDB[3] for the RDS (Raw Data Storage) • Hardware, supplied by the LRZ • VM running Debian 10, 20 cpu cores, 88 GB memory in the Compute Cloud[6] • Data Science Storage[7] for storing FAS and RDS, mounted via NFSv3 Storage systems can be swapped to every other SQL-Database/Key-Value Store, after imple- menting connector O. Breitwieser — Performant Certificate Transparency Monitoring 5

Architecture Main • ct-scanner systemd service scanning 10 logs in parallel • ct-loglister systemd service running each Monday, getting new logs from the Certificate Transparency project homepage[1] Helpers • cachefiller: to fill optional cache and copying KV-Pairs from one RDS location to another • kvmaintenance: checks if the size of the RDS is correctly saved in the FAS • retriever: Used to get certificate from the RDS by a given key Scripts • Installer for the service • Creation of the needed database and tables • Scripts for graceful stop/resume of the service Most settings are controlled by the ct-scanner.conf configuration file O. Breitwieser — Performant Certificate Transparency Monitoring 6

Numbers Various statistics • Number of known logs: 94 • Number of active logs: 60 • Number of certificate entries in all known logs: ~9G[5] • Number of certificates already downloaded: 423M* • Number of Logs scanned in parallel: 10 • Speed of scanning: ~100 certificates/second* • Max send used bandwith towards DSS: ~310MB/s (2,4Gb/s)* Timings for retrieval of random entry* Name Type Location # Entries (certs) # Files Size Time for retrieval storeOne RDS DSS (~340.000.000) 135.085 362GB cns storeTwo RDS local disk 80.499.306 42.949 78GB 595ms storeThree RDS DSS 107.219 63 125MB 1,25ms cert FAS DSS cns - cns 89 - 319s * = Numbers from before the Maintenance Window of the Compute Cloud, see Encounters slide O. Breitwieser — Performant Certificate Transparency Monitoring 7

Encounters • Hit Bug in LRZ DSS, that made it impossible to access the files on the filesystem. Fixed by LRZ • Bug in LRZ DSS, that files belong to the user nobody. Work-around is using NFSv3 to mount the DSS • After the Maintenance Window of the LRZ Compute Cloud last week the FAS lost all con- tent from the unlogged tables due to non-graceful stop of the database, due to issues in the configuration of the postgresDB. So we have to start again from scratch. Switched to logged tables and tweaked the configuration to prevent this issue. O. Breitwieser — Performant Certificate Transparency Monitoring 8

Outlook Performance is crucial to be up to date with the logs. Recorded speed at a filling state of ~483M certificates was ~100 certificates/second, which is too slow. With starting from zero, speed is at ~1.200 certificates/second. Basic coding for the scanner is complete, so the rest of the time I will try to increase the speed of the scanning by various means. Right now it is not yet clear what the real bottleneck is. Candidates are: • Code • Network connection to the DSS • Timing of the FAS writes • Timing of the RDS reads (to check if certificate is already stored) • Timing of the RDS writes • Settings of the logs (e.g. rate-limiting, only small amounts of certificates per call...) The list is not exhaustive and any combination is also possible. O. Breitwieser — Performant Certificate Transparency Monitoring 9

Bibliography [1] Google. Certificate Transparency. https://certificate-transparency.org. [2] Google. certificate-transparency-go. https://github.com/google/certificate-transparency-go. [3] Google. LevelDB. https://github.com/google/leveldb. [4] Google. The Go Programming Language. https://golang.org/. [5] S. Limited. crt.sh monitored logs, 2020. https://crt.sh/monitored-logs. [6] LRZ. LRZ Compute Cloud. https://doku.lrz.de/display/PUBLIC/Compute+Cloud. [7] LRZ. LRZ Data Science Storage. https://doku.lrz.de/display/PUBLIC/Data+Science+Storage. [8] net.in.tum.de. tumi8-certificate-transparency-go. https://github.com/tumi8/certificate-transparency-go. O. Breitwieser — Performant Certificate Transparency Monitoring 10

Bibliography [9] PostgreSQL. PostgreSQL: The World’s Most Advanced Open Source Relational Database. https://www.postgresql.org/. O. Breitwieser — Performant Certificate Transparency Monitoring 11