How SSL/TLS uses cryptography

This section explains how symmetric encryption, asymmetric encryption, and hashing secure Internet communications via SSL/TLS

Learning objectives

  • Understand why hashing acts as a foundational layer for securing web traffic

  • Understand how in SSL/TLS a combination of hashing and cryptographic encryption secures websites and online transactions

This section explains how cryptographic tools (symmetric encryption, asymmetric encryption, and hashing) secure Internet communications via SSL/TLS.

Topics covered in this section

  • SSL/TLS use cases

  • How SSL/TLS uses hashing

  • How SSL/TLS uses asymmetric encryption

  • How SSL/TLS uses symmetric encryption

SSL/TLS use cases

SSL/TLS are cryptographic protocols that provide encryption, authentication, and data integrity for secure communication over a network. For example, the HTTPS protocol ensures that data exchanged between a client (e.g., a web browser) and a server (e.g., a website) is private and tamper-proof.

While commonly associated with HTTPS (securing web traffic), SSL/TLS is widely used in many other applications, including:

  • Email (SMTPS, IMAPS, POP3S) – Secures email transmission (sending/receiving) and prevents eavesdropping.

  • VPNs (e.g., OpenVPN) – Encrypts all traffic between a client and a private network.

  • File transfers (FTPS) – Protects file transfers (different from SFTP, which uses SSH).

  • Databases (MySQL, PostgreSQL, MongoDB with TLS) – Encrypts queries and prevents unauthorized access to sensitive data.

  • Directory services (LDAPS) – Secures authentication and queries in systems like Active Directory.

  • VoIP & messaging (SIP over TLS, XMPP) – Encrypts call setup (VoIP) and instant messages.

  • IoT & APIs – Ensures secure firmware updates and encrypted API communications (e.g., payment processing).

  • DNS security (DNS over TLS) – Prevents tampering or spying on domain name lookups.

  • Remote desktop (RDP with TLS) – Secures remote access to workstations/servers.

SSL/TLS is the backbone of secure communications. SSL/TLS is used almost anywhere secure communication is needed—not just for websites. If an application transmits sensitive data over a network, there’s a good chance TLS is involved.

How SSL/TLS uses Cryptography

How-SSL-TLS-uses-Cryptography
How SSL/TLS uses cryptographic tools to secure data transmission (image courtesy of Ed Harmoush, Practical Networking)

How SSL/TLS uses hashing

SSL/TLS uses hashing for fingerprint verification, Message Authentication Codes (MAC), and digital signatures, thus ensuring data integrity, authentication, and non-repudiation in encrypted communications.

Hashing role in TLS handshake:

  1. Digital Signatures (asymmetric encryption + hashing): Authenticates server identity (ensures the server is trusted, preventing MITM attacks). Example Algorithms: RSA + SHA-256, ECDSA.

  • When does this occur?

    • During the handshake, in two distinct phases:

      1. Certificate Verification:

        • The server sends its certificate (signed by a CA using RSA+SHA-256 or ECDSA).

        • The client verifies the CA's signature on the certificate to authenticate the server's identity (preventing MITM).

        • Hashing role: The CA’s signature includes a hash (e.g., SHA-256) of the certificate data.

        • This happens before key exchange.

      2. Key Exchange (e.g., RSA or ECDHE):

        • In RSA key exchange (deprecated in TLS 1.3), the client encrypts the pre-master secret with the server's public key.

        • Server authentication (optional): In TLS 1.2, the server may send a CertificateVerify message (signed with RSA+hash) to prove it owns the private key.

        • The pre-master secret is combined with nonces to derive the master secret (then session key). Hashing role: SHA-256 is used in the PRF (Pseudo-Random Function) to derive master secret (e.g., combining pre-master secret + nonces).

        • In ECDHE (TLS 1.2), the server signs its ephemeral public key (e.g., using ECDSA+SHA-256 or RSA-PSS+SHA-256) to prove it owns the certificate. Hashing role: The signature includes a hash (e.g., SHA-256) of the handshake messages (for integrity).

        • The pre-master secret is combined with nonces to derive the master secret (then session key). Hashing role: SHA-256 is used in the PRF (Pseudo-Random Function) to derive master secret (e.g., combining pre-master secret + nonces).

  1. Integrity Checks: Verifies data integrity (prevents data alteration in transit). Example Algorithms: SHA-256, HMAC.

Hashing for Integrity Checks (e.g., SHA-256, HMAC)

  • After symmetric key negotiation. Once the TLS handshake establishes a shared session key, hashing (often via HMAC or AEAD ciphers like AES-GCM) is used to verify message integrity during the encrypted application data exchange (not during the handshake itself).

  • Example: In TLS 1.2, HMAC-SHA256 is used with the session key to generate MACs for each encrypted record. In TLS 1.3, AEAD (e.g., AES-GCM) combines encryption and integrity checks.

Note - In RSA (TLS 1.2) , the CertificateVerify message (sent after the server's certificate) is used to prove ownership of the private key by signing a hash of the handshake messages. In RSA (TLS 1.2) the server may send the client a CertificateVerify message which is a signed hash of the handshake messages (up to that point) using the private key of the server, proving (to the client) the server’s ownership of the private key (authentication).

  • The server computes a hash (e.g., SHA-256) of all previous handshake messages.

  • It signs this hash with its private RSA key (e.g., using RSA-PSS or RSA-PKCS#1).

  • The client verifies the signature using the server’s public key (from the certificate).

When Hashing is Used in the TLS protocol (TLS Key Exchange and Hashing)

Key Exchange Type

Hashing in Key Exchange Itself?

Where Hashing is Used

Explicit Authentication (CertificateVerify)?

RSA (TLS 1.2)

✗ No (raw RSA encryption for key transport)

✔ Certificate signatures (e.g., RSA-SHA256). ✔ PRF (HMAC-SHA256 for key derivation). ✔ Optional: CertificateVerify signs handshake hash (SHA-256 + RSA).

Optional but recommended: Server sends CertificateVerify (signed hash of handshake) to prove private key ownership.

ECDHE (TLS 1.2)

✔ Yes (hash used to sign ephemeral ECDHE public key)

✔ ServerKeyExchange signature (e.g., ECDSA-SHA256). ✔ PRF (HMAC-SHA256 for keys).

Not required. Server’s signature on ECDHE params provides implicit authentication.

ECDHE (TLS 1.3)

✔ Yes (hash used in handshake signature)

✔ ServerHello signature (covers entire handshake context). ✔ HKDF (SHA-256/384 for key derivation).

Mandatory. CertificateVerify signs all handshake messages (SHA-256 + RSA/ECDSA).

Hashing for signing handshake messages happens in both TLS 1.2 and TLS 1.3.

In TLS 1.2:

  • Occurs in the ServerKeyExchange message (for ECDHE cipher suites) or is omitted (for static RSA key exchange).

  • Trigger: The server signs its ephemeral ECDHE public key + handshake hash (e.g., RSA in TLS 1.2 using SHA-256) to prove authenticity.

In TLS 1.3:

  • Occurs in the CertificateVerify step, after ServerHello/KeyShare but before deriving the session key.

  • Trigger: The server signs a SHA-256 hash of all prior handshake messages to prove private key ownership.

Visual TLS 1.2 Handshake Snippet with key hashing actions highlighted

ClientHello  
  ↓  
ServerHello  
  ↓  
Certificate               // CA’s signature (RSA+SHA-256/ECDSA)  
  ↓  
ServerKeyExchange        // ⭐ Only for ECDHE: Signed ECDHE pubkey + SHA-256 hash of handshake  
  ↓  
ServerHelloDone  
  ↓  
ClientKeyExchange        // Pre-master secret (RSA-encrypted or ECDHE shared secret)  
  ↓  
ChangeCipherSpec         // Switch to encrypted mode  
  ↓  
Finished (HMAC-SHA-256)  // First encrypted message, verifies handshake integrity

Key Differences from TLS 1.3

  1. ServerKeyExchange (TLS 1.2):

    • ECDHE Only: Signs ephemeral public key + SHA-256 hash of handshake messages.

    • RSA Key Exchange: Omits this step entirely (no handshake signing).

  2. CertificateVerify:

    • TLS 1.2 relies on ServerKeyExchange (for ECDHE) or implicit RSA encryption (no explicit signing).

  3. Finished Uses HMAC-SHA-256:

    • TLS 1.2 always uses HMAC for the Finished message, while TLS 1.3 uses AEAD.

Detailed Breakdown (TLS 1.3 Handshake)

  1. ClientHello → ServerHello

    • Agree on cipher suite (e.g., ECDHE_RSA_WITH_AES_128_GCM_SHA256).

  2. Key Exchange (ServerHello + KeyShare)

    • Server sends its ephemeral ECDHE public key (no signing yet).

  3. Server Authentication Phase

    • Certificate: Server sends its digital certificate (signed by CA using RSA+SHA-256/ECDSA).

    • CertificateVerify:

      • Hashing role: The server hashes all previous handshake messages (up to this point) with SHA-256.

      • Signing: Signs this hash with its private key (RSA/ECDSA) to prove ownership.

      • This is the explicit "signing of handshake messages" step.

  4. Final Key Derivation

    • Client and server derive the session key (master secret) using:

      • ECDHE shared secret + nonces + PRF (SHA-256).

  5. Encrypted Data Exchange (Integrity via AEAD)

    • TLS 1.3 uses AEAD (e.g., AES-GCM), which handles encryption + integrity without separate hashing.

Visual TLS 1.3 Handshake (Simplified)

ClientHello  
  ↓ (Includes KeyShare: Client’s ECDHE pubkey + supported groups)  
ServerHello + KeyShare (Server’s ECDHE pubkey)  
  ↓ (Negotiated cipher suite + "hello" messages hashed for keys)  
EncryptedExtensions  
  ↓ (Optional server config, e.g., ALPN)  
Certificate  
  ↓ (Server’s cert, signed by CA with RSA/ECDSA + SHA-256)  
CertificateVerify  
  ↓ (Server signs hash of handshake with its private key)  
Finished (encrypted)  
  ↓ (HMAC over handshake transcript, using derived key)  
[Application Data]

TLS 1.2 vs. TLS 1.3: Key Differences in Hashing and Handshake Signing (comparing handshake message signing, key exchange, and integrity mechanisms):

Step

TLS 1.2

TLS 1.3

Key Exchange

ServerKeyExchange (ECDHE only) or RSA-encrypted

KeyShare (ECDHE always, no RSA)

Handshake Signing

ECDHE signs in ServerKeyExchange

Always signs in CertificateVerify

Integrity Check

HMAC-SHA-256 in Finished

AEAD (e.g., AES-GCM) in all messages

All hashing roles (signing, PRF, integrity) for both versions

Action

TLS 1.2

TLS 1.3

Hashing for Signing Handshake Messages

✔️ ECDHE only: In ServerKeyExchange (signs ECDHE pubkey + handshake hash). ❌ RSA key exchange: No signing of handshake messages (optional CertificateVerify).

✔️ Always in CertificateVerify (signs hash of all prior handshake messages).

Hashing for Key Derivation (PRF)

✔️ SHA-256 (or negotiated hash) for deriving master_secret.

✔️ SHA-256 (or HKDF) for deriving master_secret.

Hashing for Data Integrity

✔️ HMAC-SHA-256 (for cipher suites without AEAD).

✔️ AEAD (e.g., AES-GCM) handles integrity without explicit hashing.

How TLS uses hashing for fingerprint verification, MACs, and digital signatures (providing integrity, authentication, and non-repudiation):

TLS Hashing Application

Security Parameter

Explanation

Fingerprint Verification

Authentication

Public key certificates (e.g., server’s certificate) are hashed to produce fingerprints. Clients verify these against trusted stores to authenticate the server.

Message Authentication Codes (MAC)

Data Integrity

TLS uses hash-based MACs (HMAC) or authenticated encryption (AEAD) to ensure transmitted data is unaltered. The hash ensures any tampering is detectable.

Digital Signatures

Non-Repudiation

TLS uses hashing (e.g., SHA-256) in digital signatures (e.g., RSA/ECDSA). The sender signs a hash of the message, proving their identity and preventing denial of sending.

I. Fingerprint Verification

How the server authentication works in TLS:

  1. Certificate Issuance (Pre-TLS):

    • The server's operator generates a key pair (public + private key) and submits a Certificate Signing Request (CSR) to a Certificate Authority (CA).

    • The CA validates the server's identity (e.g., verifying domain ownership for HTTPS).

    • The CA creates the server's certificate, which includes:

      • Server's public key

      • Server's identity (e.g., domain name)

      • Issuer (CA) info

      • Validity period

      • Other metadata (extensions)

    • The CA hashes the certificate's contents (e.g., SHA-256) → produces a fingerprint.

    • The CA encrypts this fingerprint with its private key → creates the digital signature.

    • The signature is appended to the certificate, which is now "signed" and sent to the server.

  2. During TLS Handshake (Authentication):

    • The server sends its signed certificate to the client in the Server Hello.

    • The client: a. Validates the certificate chain: Checks if the certificate is issued by a trusted CA (traversing the chain up to a root CA in its trust store). b. Decrypts the signature: Uses the CA's public key (from the CA's own certificate) to decrypt the signature → extracts the original fingerprint. c. Recomputes the fingerprint: Hashes the certificate's contents (excluding the signature) using the same hash algorithm the CA used. d. Compares fingerprints: Checks if the decrypted fingerprint matches the recomputed fingerprint.

  3. Authentication Outcomes:

    • Match: The certificate is authentic (not tampered with) and was signed by the trusted CA.

      • The client now trusts the server's public key in the certificate.

      • Proceeds with key exchange (e.g., generating a premaster secret encrypted with the server's public key).

    • Mismatch: The certificate is invalid (possibly tampered with or corrupted) → Handshake fails.

  4. Additional Checks (Beyond the Signature):

    • The client also verifies:

      • The certificate's validity period (not expired/not yet valid).

      • The server's identity (e.g., domain name matches the certificate's Subject or SAN).

      • The certificate hasn't been revoked (via CRL or OCSP, though modern TLS often uses OCSP stapling).

Why This Works:

  • Integrity: If an attacker altered the certificate (e.g., changed the public key), the recomputed fingerprint wouldn't match the decrypted one.

  • Authenticity: Only the CA could have created a valid signature (requires the CA's private key, which is kept secret).

  • Trust: The client implicitly trusts CAs in its trust store. If the CA is compromised, authentication fails.

Example Flow:

  1. CA signs example.com's certificate with CA_private_key.

  2. Client receives example.com's certificate, decrypts the signature with CA_public_key (from CA's root certificate).

  3. If the decrypted fingerprint matches the certificate's contents, the server is authenticated.

This ensures the client is communicating with the genuine server (not an impostor) before establishing encrypted communication.

How Fingerprints Are Generated (Example)

  • A command like OpenSSL can generate a cert’s fingerprint:

    sh

    openssl x509 -noout -fingerprint -sha256 -in server.crt

    Output:

    text

    SHA256 Fingerprint=3A:1B:...:9F

  • Browsers display fingerprints in certificate details (Chrome/Firefox show SHA-1 and SHA-256 hashes).

Why Hashing is Used for Fingerprints

  • Unique identifier: A hash (like SHA-256) condenses the cert into a fixed-length, unique value.

  • Tamper detection: Any change in the cert alters the fingerprint drastically.

  • Efficiency: Comparing hashes is faster than comparing entire certs.

II. Message Authentication Codes (MAC)

During encrypted data exchange:

  • TLS 1.2 uses HMAC (Hash-based MAC) to verify message integrity. The sender and receiver compute a hash of the data + shared secret. Mismatches indicate tampering.

  • TLS 1.3 replaces HMAC with AEAD (e.g., AES-GCM), which integrates encryption + integrity checks.

  • HMAC uses hashes (SHA-256, SHA-384) combined with a secret key.

Recall, integrity protection in TLS happens at two layers, during the TLS handshake (authentication & key exchange), and during encrypted data exchange.

Integrity Protection in TLS: Two Layers

TLS ensures message integrity at two different stages with different mechanisms:

A. During the Handshake (Authentication & Key Exchange)

  • Mechanism: Digital signatures (e.g., RSA, ECDSA)

  • Purpose: Verify the server’s identity and ensure handshake messages are untampered Handshake Phase (authentication and integrity).

  • How it works:

    • The server’s certificate is signed by a CA (as previously explained).

    • The ServerKeyExchange (in some cipher suites) and CertificateVerify (in TLS 1.3) messages are also signed to prove possession of the private key.

    • Not HMAC or AEAD yet—these are only used after the handshake.

B. During Encrypted Data Exchange (Record Layer Integrity)

  • Mechanism:

    • TLS 1.2: HMAC (Hash-based MAC)

    • TLS 1.3: AEAD (Authenticated Encryption with Associated Data, e.g., AES-GCM, ChaCha20-Poly1305)

  • Purpose: Ensure that encrypted application data (HTTP, etc.) is not modified in transit.

HMAC in TLS 1.2 (Legacy Approach)

  • How it works:

    • After the handshake, both client and server derive session keys (e.g., client_write_MAC_key, server_write_MAC_key).

    • For each encrypted record (e.g., an HTTPS request), the sender:

      1. Computes HMAC(message, MAC_key) using SHA-256/SHA-384.

      2. Appends the MAC to the encrypted data.

    • The receiver recomputes the HMAC and checks for a match.

  • Why HMAC?

    • Prevents tampering even if encryption is broken (e.g., if an attacker flips ciphertext bits, the HMAC won’t match).

Example (TLS 1.2):

Encrypted_Record = AES-CBC(plaintext) + HMAC-SHA256(plaintext, MAC_key)

AEAD in TLS 1.3 (Modern Approach)

  • How it works:

    • AEAD (e.g., AES-GCM, ChaCha20-Poly1305) combines encryption + integrity in one step.

    • Instead of HMAC, the cipher itself generates an authentication tag (like a built-in MAC).

    • The receiver decrypts and checks the tag in a single operation.

  • Why AEAD?

    • More efficient (no separate MAC computation).

    • Stronger security (resistant to certain attacks like padding oracle exploits).

Example (TLS 1.3):

Encrypted_Record = AES-GCM(plaintext)  # Includes auth tag

Key Differences Summarized

Feature
TLS 1.2 (HMAC)
TLS 1.3 (AEAD)

Integrity Mechanism

HMAC (SHA-256, etc.) appended to ciphertext

Built-in authentication tag (e.g., GCM tag)

Encryption

Separate (e.g., AES-CBC) + HMAC

Combined (e.g., AES-GCM encrypts + authenticates)

Performance

Slightly slower (extra MAC step)

Faster (single crypto operation)

Security

Good, but vulnerable to padding attacks

Stronger (resists more attacks)

III. Digital Signatures

  • Used in TLS handshakes (e.g., server’s CertificateVerify message). The sender hashes the handshake messages, then signs the hash with their private key. This provided integrity and authentication checks.

  • Ensures non-repudiation: The sender cannot later deny sending the message, as only they possess the private key.

Summary:

  • Hashing underpins all three mechanisms:

    • Fingerprints (authentication) rely on irreversible hashes of certificates.

    • MACs (integrity) use hashing (+ secret keys) to detect tampering.

    • Digital signatures (non-repudiation) sign hashes to bind messages to identities.

How SSL/TLS uses asymmetric encryption

SSL/TLS uses asymmetric encryption (public-key cryptography) for secure key exchange, digital signatures, and certificate authentication. During the handshake, the server shares its public key via a digital certificate, which the client verifies using a trusted Certificate Authority (CA). The client then generates a pre-master secret, encrypts it with the server’s public key, and sends it to the server, which decrypts it with its private key. This establishes a shared secret while ensuring confidentiality and authentication. Asymmetric encryption is computationally expensive, so it is only used for initial setup before switching to symmetric encryption for bulk data transfer.

Role of Asymmetric Encryption in SSL/TLS

  • Purpose: Secure key exchange and authentication (digital signatures and certificate authentication)

  • Common algorithms (RSA, ECC, DH)

  • How TLS uses asymmetric crypto for:

    • Key exchange (in the TLS handshake)

    • Digital signatures

    • Certificate authentication (server authentication)

Key Exchange (TLS 1.2 vs. TLS 1.3)

In TLS 1.2, asymmetric encryption (public-key crypto) is used in two ways for key exchange:

  1. Direct Key Exchange (RSA-based)

    • The client encrypts a pre-master secret with the server’s public key (from its certificate).

    • Only the server (with its private key) can decrypt it.

    • Used in RSA key exchange, but vulnerable if the server’s private key is compromised (no forward secrecy).

  2. Ephemeral Diffie-Hellman (DHE/ECDHE)

    • Asymmetric crypto is used only for authentication (via digital signatures).

    • The actual key exchange happens via ephemeral (temporary) DH/ECDH, ensuring forward secrecy.

In TLS 1.3, asymmetric encryption is used more efficiently:

  • Only Ephemeral Diffie-Hellman (ECDHE) is allowed (forward secrecy is mandatory).

  • The server’s public key (from its certificate) is used just to sign the DH parameters (not encrypt them).

  • The handshake is faster because fewer steps rely on asymmetric crypto.

Key Difference:

  • TLS 1.2: Supports both RSA key exchange (no forward secrecy) and ephemeral DH.

  • TLS 1.3: Only ephemeral DH, with asymmetric crypto limited to authentication (signatures).

This makes TLS 1.3 both more secure (always forward-secret) and faster (fewer round trips).

Digital Signatures

  • Purpose: Verify the integrity and authenticity of data.

  • How it works in SSL/TLS:

    • The server (and optionally the client) signs a piece of data (e.g., a handshake message) with its private key.

    • The recipient verifies the signature using the sender’s public key to ensure the message was not tampered with and truly came from the claimed sender.

  • Example: During the TLS handshake, the server signs the ServerKeyExchange message (in some key exchange methods like ECDHE) to prove it owns the private key matching its certificate.

Certificate Authentication

  • Purpose: Bind an entity (e.g., a server) to its public key, verified by a trusted third party (CA).

  • How it works in SSL/TLS:

    • A Certificate Authority (CA) signs the server’s certificate (which contains the server’s public key) using the CA’s private key.

    • The client checks the certificate’s signature against the CA’s public key (from its trust store) to ensure the certificate is valid and unaltered.

  • Example: When you connect to https://example.com, your browser checks if the server’s certificate was issued and signed by a trusted CA.

Key Differences:

Feature
Digital Signatures
Certificate Authentication

Purpose

Verify message integrity & sender authenticity

Verify server identity & public key binding

Signed Data

Handshake messages (e.g., ServerKeyExchange)

The server’s certificate (public key + metadata)

Signer

Server (or client)

Certificate Authority (CA)

Verification By

Peer (client/server)

Client (via CA’s public key)

Why Both Are Needed:

  • Certificate Authentication ensures you’re talking to the right entity (e.g., example.com and not an impostor).

  • Digital Signatures ensure that the handshake messages exchanged weren’t modified in transit.

Analogy:

  • Certificate Auth = Checking a government-issued ID to confirm someone’s identity.

  • Digital Signature = That person signing a document in front of you to prove they’re the one acting.

How SSL/TLS uses symmetric encryption

Once the handshake is complete, SSL/TLS switches to symmetric encryption (e.g., AES or ChaCha20) for encrypting actual application data. Symmetric encryption is used to encrypt the actual data transmitted between a client (e.g., a web browser) and a server (e.g., a website). Both parties derive the same session keys from the pre-master secret to encrypt and decrypt transmitted data efficiently. Symmetric encryption is faster than asymmetric encryption and provides confidentiality for the bulk of the communication. The keys are ephemeral, generated per session, and never reused, mitigating risks from key compromise. Integrity is further enforced using HMAC or AEAD (Authenticated Encryption with Additional Data) modes like AES-GCM.

Role of Symmetric Encryption in SSL/TLS

  • Purpose: Confidentiality of bulk data

  • Common algorithms: AES (128/256-bit), ChaCha20

  • How TLS Uses Symmetric Encryption:

    1. Bulk Data Encryption:

      • Encrypts all application data (web pages, files, etc.) after the handshake

      • Processes millions of bits efficiently with minimal overhead

    2. Session Keys:

      • Unique keys generated for each session via the handshake

      • Typically 128-256 bit keys (e.g., AES-256-GCM in TLS 1.3)

    3. Performance Advantage:

      • 100-1,000x faster than asymmetric crypto for data transfer

      • Enables high-speed secure communication (e.g., video streaming, large downloads)

    4. Cipher Modes:

      • Authenticated Encryption (AEAD): Combines encryption + integrity (e.g., AES-GCM)

      • CBC mode (older TLS versions) with HMAC for integrity

  • Key characteristics:

    • Fast processing (optimized for hardware/software)

    • Suitable for large amounts of data

    • Minimal latency impact on user experience

    • Perfect for protecting the actual content of communications

Key takeaways

  • SSL/TLS are cryptographic protocols that provide encryption, authentication, and data integrity for secure communication over a network

  • SSL/TLS uses hashing for fingerprint verification, Message Authentication Codes (MAC), and digital signatures

  • SSL/TLS uses asymmetric encryption for secure key exchange, digital signatures, and certificate authentication

  • SSL/TLS uses asymmetric encryption to encrypt the actual data transmitted between a client and a server

References

Ed Harmoush. (n.d.). How SSL & TLS use Cryptographic tools to secure your data - Practical TLS. Practical Networking. https://www.youtube.com/watch?v=aCDgFH1i2B0

PreviousThe SSL/TLS key exchange and derivation processNextReplay attacks and anti-replay methods

Last updated