add SSL learn page, lessen some of the auto-formatted lists and bold …

…type

site/content/learn/monitoring/tcp-and-ssl.md

@@ -21,7 +21,7 @@ At the time, I didn’t fully understand SSL connections. I made a change to a V
 
 For an hour, I had no idea I was the cause. Then, while checking reports, I noticed tons of dropped connections. I realized my mistake, reverted the change, and everything went back to normal.
 
-The impact? About $11 million in revenue was lost because transactions couldn’t be processed. 
+The impact? About $11 million in revenue was lost because transactions couldn’t be processed. Ouch .
 
 This taught me why understanding SSL connections is critical. A small mistake can have huge consequences. Always double-check certificates and configurations—especially when dealing with critical systems.
 
@@ -36,37 +36,37 @@ As an application developer, you need to know how TCP and SSL/TLS work together
 
 TCP provides the underlying communication channel for SSL/TLS. Here’s how they work together:
 
-1. **TCP Connection Establishment**: First, a TCP connection is established using the three-way handshake (SYN, SYN-ACK, ACK). This creates a reliable communication channel between the client and server.
-2. **SSL/TLS Handshake**: Once the TCP connection is established, the SSL/TLS handshake begins. This process negotiates encryption algorithms, authenticates the server (and optionally the client), and establishes shared encryption keys.
-3. **Secure Data Transmission**: After the SSL/TLS handshake, all data transmitted over the TCP connection is encrypted and secure.
+ TCP Connection Establishment: First, a TCP connection is established using the three-way handshake (SYN, SYN-ACK, ACK). This creates a reliable communication channel between the client and server.
+ SSL/TLS Handshake: Once the TCP connection is established, the SSL/TLS handshake begins. This process negotiates encryption algorithms, authenticates the server (and optionally the client), and establishes shared encryption keys.
+ Secure Data Transmission: After the SSL/TLS handshake, all data transmitted over the TCP connection is encrypted and secure.
 
 The SSL/TLS handshake is critical for authentication, ensuring that the client is communicating with the intended server and not an imposter.
 
 
 ## SSL/TLS Authentication
 
-Authentication in SSL/TLS ensures that the parties involved in the communication are who they claim to be. This is typically done using **digital certificates** and **public-key cryptography**.
+Authentication in SSL/TLS ensures that the parties involved in the communication are who they claim to be. This is typically done using digital certificates and public-key cryptography.
 
 ### Server Authentication
 
 In most cases, SSL/TLS is used to authenticate the server to the client. Here’s how it works:
 
-1. **Server Certificate**: The server presents its digital certificate to the client during the SSL/TLS handshake. This certificate contains the server’s public key and is signed by a trusted Certificate Authority (CA).
-2. **Certificate Validation**: The client verifies the server’s certificate by checking:
+ Server Certificate: The server presents its digital certificate to the client during the SSL/TLS handshake. This certificate contains the server’s public key and is signed by a trusted Certificate Authority (CA).
+ Certificate Validation: The client verifies the server’s certificate by checking:
    - The certificate’s validity period (not expired).
    - The certificate’s signature (signed by a trusted CA).
    - The server’s hostname matches the certificate’s Common Name (CN) or Subject Alternative Name (SAN).
-3. **Key Exchange**: If the certificate is valid, the client uses the server’s public key to encrypt a shared secret (e.g., a pre-master secret) that is used to generate encryption keys for the session.
+ Key Exchange: If the certificate is valid, the client uses the server’s public key to encrypt a shared secret (e.g., a pre-master secret) that is used to generate encryption keys for the session.
 
 This process ensures that the client is communicating with the legitimate server and not a man-in-the-middle attacker.
 
 ### Client Authentication (Optional)
 
 In some cases, the server may also require the client to authenticate itself. This is less common but is used in scenarios where mutual trust is required (e.g., enterprise applications, APIs). Here’s how it works:
 
-1. **Client Certificate**: The client presents its digital certificate to the server during the SSL/TLS handshake.
-2. **Certificate Validation**: The server verifies the client’s certificate, checking its validity, signature, and other attributes.
-3. **Mutual Trust**: If the client’s certificate is valid, the server proceeds with the handshake. Otherwise, the connection is terminated.
+ Client Certificate: The client presents its digital certificate to the server during the SSL/TLS handshake.
+ Certificate Validation: The server verifies the client’s certificate, checking its validity, signature, and other attributes.
+ Mutual Trust: If the client’s certificate is valid, the server proceeds with the handshake. Otherwise, the connection is terminated.
 
 Client authentication adds an extra layer of security but requires managing client certificates, which can be complex.
 
@@ -80,75 +80,75 @@ The SSL/TLS handshake is a multi-step process that establishes a secure connecti
 
 After a TCP handshake is complete, at the ACK step:
 
-1. **Client Hello**: The client sends a "Client Hello" message to the server, specifying supported SSL/TLS versions, cipher suites, and a random byte string.
-2. **Server Hello**: The server responds with a "Server Hello" message, selecting the SSL/TLS version, cipher suite, and providing its own random byte string.
-3. **Server Certificate**: The server sends its digital certificate to the client.
-4. **Key Exchange**: The server may send additional key exchange information (e.g., Diffie-Hellman parameters) depending on the cipher suite.
-5. **Client Key Exchange**: The client generates a pre-master secret, encrypts it with the server’s public key, and sends it to the server.
-6. **Certificate Verify (Optional)**: If client authentication is required, the client sends its certificate and a signature to prove ownership of the private key.
-7. **Finished Messages**: Both the client and server exchange "Finished" messages to verify that the handshake was successful and that the keys are correct.
+1. Client Hello: The client sends a "Client Hello" message to the server, specifying supported SSL/TLS versions, cipher suites, and a random byte string.
+2. Server Hello: The server responds with a "Server Hello" message, selecting the SSL/TLS version, cipher suite, and providing its own random byte string.
+3. Server Certificate: The server sends its digital certificate to the client.
+ Key Exchange: The server may send additional key exchange information (e.g., Diffie-Hellman parameters) depending on the cipher suite.
+4. Client Key Exchange: The client generates a pre-master secret, encrypts it with the server’s public key, and sends it to the server.
+5. Certificate Verify (Optional): If client authentication is required, the client sends its certificate and a signature to prove ownership of the private key.
+6. Finished Messages: Both the client and server exchange "Finished" messages to verify that the handshake was successful and that the keys are correct.
 
 Once the handshake is complete, the secure connection is established, and encrypted data transmission begins.
 
 ---
 
 ## What Application Developers Need to Know
 
-### 1. **Certificate Management**
-   - **Server Certificates**: Ensure your server has a valid certificate signed by a trusted CA. Self-signed certificates are not trusted by default and may cause errors in clients.
-   - **Client Certificates**: If your application requires client authentication, you’ll need to manage client certificates, including issuing, distributing, and revoking them.
+ Certificate Management
+   - Server Certificates: Ensure your server has a valid certificate signed by a trusted CA. Self-signed certificates are not trusted by default and may cause errors in clients.
+   - Client Certificates: If your application requires client authentication, you’ll need to manage client certificates, including issuing, distributing, and revoking them.
 
-### 2. **SSL/TLS Configuration**
+ SSL/TLS Configuration
    - Use strong cipher suites and disable weak ones (e.g., SSLv2, SSLv3, and weak ciphers like RC4).
    - Keep your SSL/TLS libraries up to date to protect against vulnerabilities (e.g., Heartbleed, POODLE).
 
-### 3. **Hostname Verification**
+ Hostname Verification
    - Always verify that the server’s hostname matches the certificate’s CN or SAN. Skipping this step can expose your application to man-in-the-middle attacks.
 
-### 4. **Error Handling**
+ Error Handling
    - Handle SSL/TLS errors gracefully. Common errors include expired certificates, mismatched hostnames, and untrusted CAs. Provide clear error messages to users or logs.
 
-### 5. **Performance Considerations**
-   - The SSL/TLS handshake adds latency to the connection establishment process. Use techniques like **session resumption** or **TLS False Start** to reduce handshake overhead.
+ Performance Considerations
+   - The SSL/TLS handshake adds latency to the connection establishment process. Use techniques like session resumption or TLS False Start to reduce handshake overhead.
    - Offload SSL/TLS processing to dedicated hardware or services (e.g., load balancers) if your application handles high traffic.
 
 ---
 
 ## Common Issues and Troubleshooting
 
-### 1. **Certificate Expiry**
+ Certificate Expiry
    - Certificates have a limited validity period. If a certificate expires, the SSL/TLS handshake will fail. Monitor certificate expiration dates and renew them before they expire.
 
-### 2. **Untrusted Certificates**
+ Untrusted Certificates
    - If the client does not trust the CA that signed the server’s certificate, the connection will fail. Ensure your server’s certificate is signed by a widely trusted CA.
 
-### 3. **Mismatched Hostnames**
+ Mismatched Hostnames
    - If the server’s hostname does not match the certificate’s CN or SAN, the client will reject the connection. Double-check your certificate’s hostname configuration.
 
-### 4. **Weak Cipher Suites**
+ Weak Cipher Suites
    - Using weak cipher suites can expose your application to attacks. Regularly review and update your SSL/TLS configuration to disable weak ciphers.
 
-### 5. **Handshake Failures**
+ Handshake Failures
    - Handshake failures can occur due to mismatched SSL/TLS versions, unsupported cipher suites, or network issues. Use tools like `openssl` or `ssllabs.com` to diagnose handshake problems.
 
 ---
 
 ## Best Practices for SSL/TLS Authentication
 
-1. **Use Strong Certificates**:
+* Use Strong Certificates:
    - Use certificates with a key length of at least 2048 bits (RSA) or 256 bits (ECDSA).
    - Prefer certificates from widely trusted CAs.
 
-2. **Enable HTTPS Everywhere**:
+* Enable HTTPS Everywhere:
    - Use SSL/TLS for all communication, not just sensitive data. This prevents attackers from intercepting or tampering with any part of the communication.
 
-3. **Implement HSTS**:
+* Implement HSTS:
    - Use HTTP Strict Transport Security (HSTS) to enforce HTTPS and prevent downgrade attacks.
 
-4. **Monitor and Rotate Certificates**:
+* Monitor and Rotate Certificates:
    - Use automated tools to monitor certificate expiration and rotate them before they expire.
 
-5. **Test Your Configuration**:
+* Test Your Configuration:
    - Regularly test your SSL/TLS configuration using tools like SSL Labs’ SSL Test or `openssl` to ensure it meets security best practices.
 
 ---