ward/ssl-talk
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

update

Browse source
This commit is contained in:
Ward Wouts 2026-01-13 14:41:40 +01:00
parent 48bc1799bc
commit 8f9ac5b67d
1 changed files with 32 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

49
index.html
View file

@ -144,11 +144,11 @@ layout: false
## SSL, TLS, what's in a name?
]
.right-column[
SSL was originally developed by Netscape as a way to protect communications between browsers and web servers.
SSL (Secure Socket Layer) was originally developed by Netscape as a way to protect communications between browsers and web servers.
Then the browser wars started... No way other browser makers were going to using something that was branded by Netscape.
SSL was from 1999(!) on developed further with the name TLS. So if you want to be pedantic, you can correct every use of `SSL` to `TLS`, and make lots of friends.
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.
]
---
layout: false
@ -156,8 +156,11 @@ layout: false
## So what is it really?
]
.right-column[
Well, it's kind of a secure tunnel protocol over TCP. But it does not really fit into the OSI model. Which does not really fit with TCP/IP to begin with, so let's just not care and have a look.
<!-- XXX picture -->
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.
<img src="SSL-TLS-Layer-model.png"/>
.footnote[Encapsulation in TCP/IP is a lot of fun. Boxes in boxes in boxes in boxes, etcetera.]
]
???
$ openssl s_client -connect www.nu.nl:443
@ -170,10 +173,10 @@ layout: false
| Protocol | Published | Status |
| ----------- | ----------- | -------- |
| SSL 1.0 | Unpublished | Unpublished |
| SSL 2.0 | 1995 | Deprecated in 2011 (RFC 6176) |
| SSL 2.0 | 1995 | Deprecated in 2011 (RFC 6176) |
| SSL 3.0 | 1996 | Deprecated in 2015 (RFC 7568) |
| TLS 1.0 | 1999 | Deprecation planned in 2020 |
| TLS 1.1 | 2006 | Deprecation planned in 2020 |
| TLS 1.0 | 1999 | Deprecated in 2021 (RFC 8996) |
| TLS 1.1 | 2006 | Deprecated in 2021 (RFC 8996) |
| TLS 1.2 | 2008 | |
| TLS 1.3 | 2018 | |
@ -209,13 +212,15 @@ layout: false
.right-column[
A Man in the Middle attack is a situation where Alice wants to talk to Bob.
<img src="alice-bob.png" width="100%" />
<img src="alice-bob.png"/>
And Carol figures out a way to get in between.
<img src="alice-bob-carol.png" width="100%" />
<img src="alice-bob-carol.png"/>
This gives Carol full control over the conversation.
.footnote[Cryptographers love calling everyone Alice, Bob, and Carol. It's a tradition.]
]
---
@ -225,12 +230,13 @@ layout: false
]
.right-column[
To prevent a MitM attack, we need at least the following:
- a way to establish that we are starting the conversation with the right endpoint
- a way to make sure the conversation cannot be hijacked
- A way to establish that we are starting the conversation with the right endpoint.
- This is solved using certificates.
The first problem is solved by using certificates.
- 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. [*]
The second is solved by negotiating a session key (during the TLS handshake) and encrypting the whole conversation using that key.
.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.]
]
---
template: inverse
@ -257,10 +263,9 @@ show certificate
So, how does a certificate get signed?
]
<img src="document-signing-process.png" width="100%" />
<img src="document-signing-process.png" width="80%" />
???
<!-- XXX picture -->
Or how does this signing work:
- take the unsigned certificate
- calculate a hash of the certificate
@ -274,9 +279,8 @@ Or how does this signing work:
Now anyone can verify the signature:
]
<img src="document-verify-signature.png" width="100%" />
<img src="document-verify-signature.png" width="80%" />
???
<!-- XXX picture -->
Now anyone can verify the signature by:
- decrypting the signature with the CAs public key
- creating a hash of the website certificate
@ -336,6 +340,17 @@ This is where the client and server decide on:
9. Secure symmetric encryption achieved: The handshake is completed, and communication continues using the session keys.
---
.left-column[
## Key exchange, no certificate?
]
.right-column[
This is where the Diffie Hellman key exchange helps
<img src="250px-Diffie-Hellman_Key_Exchange.svg.png" width="50%" />
.footnote[Borrowed from: (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)]
]
---
.left-column[
## TLS1.3
]
.right-column[