audit F-Droid's TLS/HTTP usage for info leaks

• TLS client_random - this may contain the user's current time, enabling tracking based on clock skew
• TLS Session IDs
• TLS Session Tickets
• client certs - don't send em. They're in plaintext. Requesting them by the server usually leaks the client Cert CA configured on the server.
• TLS SNI is in plaintext
• Unusual features like trusted_ca_keys, SRP, and cached_info (the last one is new) will also enable tracking.
• HSTS and HPKP Headers can be used as supercookies. Browsers may copy the state into private browsing mode also.
• Content Security Policy (CSP) Pinning can be used as a supercookie

Certificate/Path Building Stuff

Notation: R -> I -> E : Root cert signed an Intermediate Cert signed an End-Entity Cert EE - end entity or a cert for a website

• You can learn clock skew using expired or about-to-expire certificates.

• Intermediate Caching - some stacks cache intermediates, meaning a webserver can send R -> I -> E on connection 1, and then send E on connection 2. If I was not cached, the client shows a certificate error and does not connect. If it is cached, then it connects.

• Name Constrained Intermediates - eventually, we'll start seeing NC-ed intermediates being operated by websites. Imagine you have a CA cert that can issue for *.guardianproject.info - you then get to issue as many EE certs as you want. This makes it easier for you to do tracking in stuff like intermediate caching, PKP, and clock skew.