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…

TLS Training London – day 1

Written on 6 September 2018, 08:55pm

Tagged with: , , ,

Some notes after the first day of the TLS training session with Scott Helme

——

  • the core protocols powering the Internet were not designed with security in mind
  • you pwn the cookie, you pwn the user
  • the server should not encrypt the cookie contents because there is nothing to hide to the browser
  • the submarine cable map is amazing, but the landing sites are possible points of failure when it comes to your privacy
  • we’ve reached the HTTPS tipping point – meaning that more than 50% of the Internet traffic is encrypted, but 90% of the sites are still on plain, old HTTP
  • the goal of encryption: to encrypt the data for just as long as it’s needed
  • when checking into a hotel, we would rather not have running  water than not having wi-fi 🙂
  • SSL was initially the Netscape’s baby, but it was renamed to TLS under the pressure of Microsoft
  • TLS 1.3 was officially adopted as a standard, and it comes with major performance improvements as well as mandatory forward secrecy. But it will take a couple of years until it will be implemented at large scale by the hardware manufacturers 
  • TLS 1.3 should have been really named TLS 2.0 if it was not for some poorly coded, but widely used hardware
  • it becomes more and more clear the significant impact of the Snowden revelations on how people look at their privacy and web security (example: Lavabit and forward secrecy)
  • the recommended lifespan of a certificate is about 12 months
  • common domain validation methods: email challenge, DNS text record or a random HTTP path
  • client clock skew: you can change your device time to cheat on Candy Crush, but this can lead to invalid HTTPS certificates for your device only
  • if you are a big organisation, you better have a backup CA (or at least one that is ready to issue a new certificate in a matter of minutes, not days)
  • cipher suite format: TLS_KX_AUTH_CIPHER_HASH. 
    • Key Exchange (KX): just use ECDHE, or if not supported, DHE. But never use RSA because of the lack of forward secrecy
    • Authentication: RSA is still good enough
    • Symmetric key encryption (used because it’s faster than asymmetric): AES 128 is good enough; AES 256 better but slower
  • sometimes, good security practices are followed not because of the security advantages, but because of the performance improvements: ChaCha20
  • don’t create a system that relies on the human factor for security (ex. don’t ask the regular user to type https:// in his browser) 
  • good: HTTPS, better: HTTPS + HSTS, best: HTTPS + HSTS + preload. But having all the browsers load a static list of websites is not a scalable solution
  • BTW – seeing my own domain in the source code of all the modern browsers used by billions of people is cool: transport_security_state_static.json (warning – 6Mb file!) 
  • HSTS is a one-way street: you can’t easily go back from HTTPS to HTTP
  • people are terrified about changing the cookies standards / specifications
  • it looks like the attackers can overwrite your cookies even when using secure cookies over HTTPS. Cookie prefixes are a dirty, but effective solution: you just need to add __Secure- to your cookie name:
Set-Cookie: __Secure-ID=123; Secure; Domain=example.com