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.
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
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:
Starting 01/01/2017 this blog is served via HTTPS. Thanks to Cloudflare, the certificate set up was a breeze.
But switching a WordPress site from HTTP to HTTPS is not that easy. Luckily, css-tricks.com came to help. Below the full list of steps I did to move this website to HTTPS: (more…)