GitHub/school-of-sre
1
0
Fork 0
mirror of https://github.com/linkedin/school-of-sre synced 2026-01-21 07:58:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

review language to be inclusive (#33)

Browse Source 
* review language to be inclusive

* review language to be inclusive

* fix typo for Example

Co-authored-by: Kalyanasundaram Somasundaram <ksomasun@ksomasun-mn1.linkedin.biz>
This commit is contained in:
kalyan
2020-12-03 11:36:19 +05:30
committed by GitHub
parent 5a5bb9d1b5
commit 9d7218b95e
11 changed files with 13 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
courses/security/fundamentals.md
View File

@@ -331,4 +331,4 @@ At the end of the handshake, both parties possess a secret session key used to e
- An ephemeral key exchange like DHE, or its variant on elliptic curve, ECDHE, solves this problem by not transmitting the pre-master key over the wire. Instead, the pre-master key is computed by both the client and the server in isolation, using nonsensitive information exchanged publicly. Because the pre-master key can’t be decrypted later by an attacker, the session key is safe from future attacks: hence, the term perfect forward secrecy.
- Keys are changed every X blocks along the stream. That prevents an attacker from simply sniffing the stream and applying brute force to crack the whole thing. "Forward secrecy" means that just because I can decrypt block M, does not mean that I can decrypt block Q
- Downside:
- The downside to PFS is that all those extra computational steps induce latency on the handshake and slow the user down. To avoid repeating this expensive work at every connection, both sides cache the session key for future use via a technique called session resumption. This is what the session-ID and TLS ticket are for: they allow a client and server that share a session ID to skip over the negotiation of a session key, because they already agreed on one previously, and go directly to exchanging data securely.
- The downside to PFS is that all those extra computational steps induce latency on the handshake and slow the user down. To avoid repeating this expensive work at every connection, both sides cache the session key for future use via a technique called session resumption. This is what the session-ID and TLS ticket are for: they allow a client and server that share a session ID to skip over the negotiation of a session key, because they already agreed on one previously, and go directly to exchanging data securely.