Autosave: 2025-02-27 18:27:46

neuron/4d2bba6b-63bd-4db1-a13f-46d124ed7b38/HTTPS.md

@@ -5,7 +5,7 @@ created: Friday, December 14, 2024
 
 # HTTPS
 
-The problem with standard, unencypted HTTP requests is that the data can be
+The problem with standard, unencrypted HTTP requests is that the data can be
 captured in transit and be observed or modified by malicious actors.
 
 HTTPS is the solution. It encrypts the entirety of the HTTP request and response
@@ -22,20 +22,42 @@ It utilises two types of encryption to send messages securely:
     shared freely so anyone can encrypt and send data to a peer but only the
     peer can receive and decrypt it
 
+> Symmetric encryption applies once the server has been authenticated and its
+> public key has been shared with the client. Asymmetric encryption applies at
+> the initiation phase only.
+
 The encryption protocol used is TLS - the **Transport Layer Security Protocol**.
 Previously SSL (Secure Sockets Layer) was used but has been deprecated over
 security concerns.
 
+The initial handshake process takes place entirely within the Network Layer,
+over TCP. Only once encryption is secured is HTTPS activated at the
+[Application Layer](Application_Layer_of_Internet_Protocol.md)
+
 ## How communication over HTTPs works
 
+![Server handshake diagram](static/https-handshake.png)
+
 - An initial handshake is shared between client and server, agreeing that
   communication will be encrypted. This is public. "Client hello" and "Server
   hello". Some random numbers are exchanged at this point
-- The server sends a digital [certificate](Certificate_authorities.md') key
-  The client checks that the certificate is valid
+- The server sends a digital [certificate](Certificate_authorities.md) key The
+  client checks that the certificate is valid
 - If valid, the client encrypts a string of bytes using the public key and sends
   it to the server. This is called the "premaster secret"
 - This is decrypted by the server
 - The premaster secret, along with the random bytes from the handshake is then
   used to compute a shared secret key (symmetric) which is used to encrypt all
   subsequent messages for the duration of the session
+
+## Caching
+
+Once symmetric exchange is achieved the TLS handshake is complete and lasts
+typically until either terminates it.
+
+However, some caching does occur on both the server and browser side. Both use
+session IDs to enact an abbreviated handshake such as when the session cache
+expires. This way, certificate validation and the asymmetric exchange can be
+skipped. These tickets are shared as part of the original exchange and the
+client can present them to the server as proof they already authenticated when
+they come back later.

neuron/4d2bba6b-63bd-4db1-a13f-46d124ed7b38/index.md

@@ -13,12 +13,13 @@ computer science.
 
 <a href="https://thomasabishop.github.io/eolas/tags">View tags</a>
  
-**Build ID:** 5b69d72b-62b5-4e7c-a093-2115c3fe6538
+**Build ID:** 4d2bba6b-63bd-4db1-a13f-46d124ed7b38
 
-**Published:** Mon 24 Feb 2025 18:04:55
+**Published:** Thu 27 Feb 2025 18:27:42
 
 ### Recent edits 
 
+- [[HTTPS]] 
 - [[How_tunneling_works_with_VPNs]] 
 - [[Network_tunnels]] 
 - [[Capturing_program_error_in_Bash]] 
@@ -30,7 +31,6 @@ computer science.
 - [[Disable_non-root_ssh_access]] 
 - [[Setup encrypted harddrive]] 
 - [[Disk_size_utilities]] 
-- [[Let's_Encrypt]] 
 
 
 ### All notes (535) 

zk/HTTPS.md

@@ -5,7 +5,7 @@ created: Friday, December 14, 2024
 
 # HTTPS
 
-The problem with standard, unencypted HTTP requests is that the data can be
+The problem with standard, unencrypted HTTP requests is that the data can be
 captured in transit and be observed or modified by malicious actors.
 
 HTTPS is the solution. It encrypts the entirety of the HTTP request and response
@@ -22,20 +22,42 @@ It utilises two types of encryption to send messages securely:
     shared freely so anyone can encrypt and send data to a peer but only the
     peer can receive and decrypt it
 
+> Symmetric encryption applies once the server has been authenticated and its
+> public key has been shared with the client. Asymmetric encryption applies at
+> the initiation phase only.
+
 The encryption protocol used is TLS - the **Transport Layer Security Protocol**.
 Previously SSL (Secure Sockets Layer) was used but has been deprecated over
 security concerns.
 
+The initial handshake process takes place entirely within the Network Layer,
+over TCP. Only once encryption is secured is HTTPS activated at the
+[Application Layer](./Application_Layer_of_Internet_Protocol.md)
+
 ## How communication over HTTPs works
 
+![Server handshake diagram](../img/https-handshake.png)
+
 - An initial handshake is shared between client and server, agreeing that
   communication will be encrypted. This is public. "Client hello" and "Server
   hello". Some random numbers are exchanged at this point
-- The server sends a digital [certificate](./Certificate_authorities.md') key
-  The client checks that the certificate is valid
+- The server sends a digital [certificate](./Certificate_authorities.md) key The
+  client checks that the certificate is valid
 - If valid, the client encrypts a string of bytes using the public key and sends
   it to the server. This is called the "premaster secret"
 - This is decrypted by the server
 - The premaster secret, along with the random bytes from the handshake is then
   used to compute a shared secret key (symmetric) which is used to encrypt all
   subsequent messages for the duration of the session
+
+## Caching
+
+Once symmetric exchange is achieved the TLS handshake is complete and lasts
+typically until either terminates it.
+
+However, some caching does occur on both the server and browser side. Both use
+session IDs to enact an abbreviated handshake such as when the session cache
+expires. This way, certificate validation and the asymmetric exchange can be
+skipped. These tickets are shared as part of the original exchange and the
+client can present them to the server as proof they already authenticated when
+they come back later.