* 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](https://w3c.github.io/webappsec-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.