TLS Training London – day 1
Written on 6 September 2018, 08:55pm
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
“The __Secure-
 prefix makes a cookie accessible from HTTPS sites only. A HTTP site can not read or update a cookie if the name starts with __Secure-
. “
- Likes (0)
- Comments (0)
-
Share