TLS Training London – day 2

Written on 8 September 2018, 02:07pm

Tagged with: , , , ,

Again, some notes about the second day of the excellent TLS Training delivered by Scott Helme. 

  • symmetric encryption is fast. AES is fast enough for transferring large amounts of encrypted data (ex. streaming)
  • asymmetric encryption is slow, therefore it’s only used for the authentication, in the beginning of the secured session 
  •  RSA algorithm was actually invented 4 years before: The acronym RSA is made of the initial letters of the surnames of Ron Rivest, Adi Shamir, and Leonard Adleman, who first publicly described the algorithm in 1978. Clifford Cocks, an English mathematician working for the British intelligence agency Government Communications Headquarters (GCHQ), had developed an equivalent system in 1973, but this was not declassified until 1997.
  • Hashing: SHA256 (a subset of the SHA-2 family) is considered strong enough. Alternatives for the future are SHA384 and SHA512 (longer digests), but if the SHA-2 is fundamentally broken, then the SHA-3 family (Keccak) comes to the rescue. It’s like a never-ending cat vs mouse game between cryptographers and cryptanalysts. 
  • The CAs store their private keys in HSMs and rarely rotate them (a lifetime of a few decades is not uncommon)
  • There is a good analogy between digital certificates and passports
  • X509 is the standard describing the structure of the digital certificates. Currently at version 3, it introduced extensions (arbitrary metadata of key + values pairs). Example of an extension: the SAN (Subject Alternative Names) – where a number of domains can be given on top of the common name (CN). In fact, Google Chrome only looks at the SAN when parsing a certificate.
  • The certificate chain is typically composed of the Root CA certificate, then the Intermediate CA certificate(s) and finally, the end-entity certificate (the leaf). The last intermediate certificate has the ‘path length’ parameter set to 0 (it’s children can only be leaves).
  • The Root CA certificates are provided by the client (stored in the browser or OS), while the intermediate CA and end-entity certificates are provided by the server(the intermediate CA cert – for performance reasons)
  • It takes on average 5-6 years to become a Root CA. And if you want this, you must work with the following 5 relying parties carrying a set of root keys in their trust store: Apple, Google, Java, Mozilla, Microsoft. Let’s Encrypt started in 2016 and it’s not yet a Root CA; they are currently using another root CA to cross-sign their certificates (IdenTrust). 
  • The Web PKI is governed by the CAB Forum – an entity where the  Certificate Authorities and the major browsers are represented.
To be continued…

Leave a response