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

Compare commits

base: ward:2853a28a50d3c305392593ea2c34ca33068df297
Branches Tags
ward:master
..
compare: ward:6438c55234bbd3662199daafa80327c481a56c0e
Branches Tags
ward:master

No commits in common. "2853a28a50d3c305392593ea2c34ca33068df297" and "6438c55234bbd3662199daafa80327c481a56c0e" have entirely different histories.
2853a28a50 ... 6438c55234

1 changed files with 5 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

21
index.html
View file

@ -173,10 +173,10 @@ layout: false
| Protocol | Published | Status | | Protocol | Published | Status |
| ----------- | ----------- | -------- | | ----------- | ----------- | -------- |
| SSL 1.0 | Unpublished | Unpublished | | 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) | | SSL 3.0 | 1996 | Deprecated in 2015 (RFC 7568) |
| TLS 1.0 | 1999 | Deprecated in 2021 (RFC 8996) | | TLS 1.0 | 1999 | Deprecation planned in 2020 |
| TLS 1.1 | 2006 | Deprecated in 2021 (RFC 8996) | | TLS 1.1 | 2006 | Deprecation planned in 2020 |
| TLS 1.2 | 2008 | | | TLS 1.2 | 2008 | |
| TLS 1.3 | 2018 | | | TLS 1.3 | 2018 | |
@ -263,7 +263,7 @@ show certificate
So, how does a certificate get signed? So, how does a certificate get signed?
] ]
<img src="document-signing-process.png" width="80%" /> <img src="document-signing-process.png" width="100%" />
??? ???
Or how does this signing work: Or how does this signing work:
@ -279,7 +279,7 @@ Or how does this signing work:
Now anyone can verify the signature: Now anyone can verify the signature:
] ]
<img src="document-verify-signature.png" width="80%" /> <img src="document-verify-signature.png" width="100%" />
??? ???
Now anyone can verify the signature by: Now anyone can verify the signature by:
- decrypting the signature with the CAs public key - decrypting the signature with the CAs public key
@ -340,17 +340,6 @@ 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. 9. Secure symmetric encryption achieved: The handshake is completed, and communication continues using the session keys.
--- ---
.left-column[ .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 ## TLS1.3
] ]
.right-column[ .right-column[