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


Leave a response