SSL was from 1999(!) on developed further with the name TLS (Transport Layer Security). So if you want to be pedantic, you can correct every use of `SSL` to `TLS`, and make lots of friends.
Well, it's kind of a secure tunnel protocol over TCP. But it does not really fit into the OSI model, or the TCP/IP model. Which does not really fit with eachother to begin with, so let's just not care and have a look.
<imgsrc="SSL-TLS-Layer-model.png"/>
.footnote[Encapsulation in TCP/IP is a lot of fun. Boxes in boxes in boxes in boxes, etcetera.]
Now, on a network you know and control completely there is no need for something like SSL/TLS. TCP can detect broken packets perfectly fine, so integrity is taken care of. There is no one snooping, because you are in control of the network. No one else has access, and you already know what systems you are talking to: your own.
- A way to make sure the conversation cannot be hijacked.
- This is solved by negotiating a session key (a shared secret) and encrypting the whole conversation using that key. This happens in the TLS handshake. [*]
.footnote[[*] To me this still feels like magic. How can you get to a shared secret that Carol, while snooping the handshake, cannot know? We'll get back to that. No magic, I promise.]
The certificates of a certificate authority are, in the end, signed by root certificates.
Built in in your browser/OS is a list of root certificates. These are trusted by.... euh.... people who trust stuff... who we trust.... because.... euh.... This is just how it works, ok?
]
???
Show root certificate list
---
template: inverse
# Handshake
---
.left-column[
## Handshake
]
.right-column[
Or how to get to a state where an attacker that can watch all traffic, including the handshake, cannot snoop on or change the conversation.
This is where the client and server decide on:
- Which version of TLS/SSL to use
- Decide on which encryption (cipher suite) to use
1. The 'client hello' message: The client initiates the handshake by sending a "hello" message to the server. The message will include which TLS version the client supports, the cipher suites supported, and a string of random bytes known as the "client random."
2. The 'server hello' message: In reply to the client hello message, the server sends a message containing the server's SSL certificate, the server's chosen cipher suite, and the "server random," another random string of bytes that's generated by the server.
3. Authentication: The client verifies the server's SSL certificate with the certificate authority that issued it. This confirms that the server is who it says it is, and that the client is interacting with the actual owner of the domain.
4. The premaster secret: The client sends one more random string of bytes, the "premaster secret." The premaster secret is encrypted with the public key and can only be decrypted with the private key by the server. (The client gets the public key from the server's SSL certificate.)
5. Private key used: The server decrypts the premaster secret.
6. Session keys created: Both client and server generate session keys from the client random, the server random, and the premaster secret. They should arrive at the same results.
7. Client is ready: The client sends a "finished" message that is encrypted with a session key.
8. Server is ready: The server sends a "finished" message encrypted with a session key.
9. Secure symmetric encryption achieved: The handshake is completed, and communication continues using the session keys.
Forward secrecy (also named Perfect Forward Secrecy) means that a message cannot be decrypted after the fact. Not even when you have the private certificates of the webserver. This is awesome! This is what you have this whole crypto stuff for!
Except.... if you're a company and you want to inspect traffic after the fact. This is why some groups have created a variation of TLS1.3 that intentionally weaken it: ETS (or eTLS).
The obvious problem with the SNI approach is that the name is send at the start of the handshake, so before encryption starts. An observer can sniff this traffic and learn to which site the client wants to connect. This also allows for blocking sites on this level. To work around this blocking, domain fronting has been used: start a connection with requesting a non-blocked site (i.e. google). Then after establishing the connection (when the inner HTTP connection is established) request the name that is actually wanted (i.e. signal).
Since mid 2018 ESNI (Encrypted SNI) is being rolled out, to solve the problems with SNI.
Back to the MitM scenario. Traditionally when I type a URL in my browser the first thing that happens is an insecure HTTP request for the URL. With a bit of luck the browser then gets redirected to the safe HTTPS version. An attacker that can use a MitM attack on the connection can prevent this redirect.
For this reason HSTS (Hypertext Strict Transport Security) has been invented. This let's a website state "always use HTTPS to connect to me". Which the browser will remember. So don't let those certificates expire.
The big problem with HSTS is that it only helps after visiting the target website for the first time. If an attacker can MitM the first connection they can prevent the HTTPS from ever being used and the HSTS header from ever being set. To counter this HSTS preloading was invented by Google. This is a mechanism where sites are pre-registered in a browser as being HTTPS only sites. You can apply for this registration[*] and in the next browser version your site will be included in a built in list.
The downside of this is, of course, that it gives Google more control than it should have. But not excessively so, as the failure mode is back to HSTS TOFU.
Once upon a time certificates were expensive. Because of this reason only organisations that could afford them bought certificates. This gave the illusion that when a website had a certificate it was trustworthy. With dropping prices for certificates it became more and more evident that this trustworthyness was an illusion[*]. Let's Encrypt shattered the illusion completely by makeing certificates free and automatically deployed (using the ACME protocol). This has caused a huge uptake of secure connections on the internet, which in general is regarded a good thing.
.footnote[[*] Diginotar was hacked by an Iranian and Iran was happily creating certificates on Diginotar's infrastructure.<br>
The same thing happened to Comodo, but they were too big to fail.<br>
Recently Symantic was banned for running an unsafe operation.<br>
In an attempt to keep the business model of certificates alive EV (Extended Validation) certificates were invented. In theory these certificate validate more than the site owner having a working creditcard.]
Well, actually: multiple. One of which is called DANE. DANE lets the owner of a domain certify the keys used by TLS by storing them in DNS. Which can be secured using DNSSEC. So, certificates without a CA being involved.
Additionally, it lets the domain owner specify which CA is allowed to sign these certificates. So we'd need to trust the certificate authorities a lot less.
DANE is not used much for HTTP, so this is mostly a theoretical fix. For obvious reasons CA's were against DANE. There is no native support in browsers.
