The document explains how SSL/TLS works, detailing encryption algorithms, digital certificates, and the role of certificate authorities in ensuring secure communications. It outlines the processes for creating and verifying digital signatures, which validate the integrity and authenticity of messages. The document further describes the client-server handshake in SSL/TLS, emphasizing the exchange of certificates and the establishment of shared symmetric keys for secure data transmission.

1. HOW SSL/TLS (HTTPS) WORKS
Saptarshi Basu

2. BACKGROUND
HIGH AVAILABILITY
LOAD BALANCER
Encryption algorithms –
Asymmetric, Symmetric,
Hashing
Digital certificate
Certificate authority
Chain certificate
Certificates in Java
Digital signature
Background
concepts

3. Encryption
algorithms
Symmetric
Asymmetric
Hashing

4. Same key for
encryption &
decryption
Faster than
asymmetric
algorithm
Eg. RSA
Message
encrypted by
public key can be
decrypted by
private key
Slower than
symmetric
algorithm
Eg. AES, DES
Converts data to
irreversible fixed
length hash
Used to check
message
integrity
Eg. MD5, SHA-1
Symmetric Asymmetric Hashing

5. RELATEDCONCEPTS-
BASE64ENCODINGNOT FOR ENCRYPTION
Encodes binary data into ASCII format
1.4 to 1.6 times the original string
Ensures no data is lost or modified by the
underlying protocol during transmission due to
misinterpretation of binary characters

6. • Digital Certificate

7. DIGITAL CERTIFICATE
An electronic document
Issued by a certificate authority
Binds identity details (viz. name etc.) with a
public key
Digitally signed by certificate authority to prove
the authenticity and integrity of the binding
X.509 is the standard to manage digital
certificates

8. Certificate authority

9. CERTIFICATE AUTHORITY (CA)
Root CA has self-signed certificates
Root CA signs next-level intermediate
certificates
Root CA certificates stored in trusted key store
of browsers, operating systems or applications
Intermediate CA may issue other intermediate
CA certificates creating a chain

10. CHAIN CERTIFICATE
Contains the end certificate to the trusted root
CA including all intermediate CAs in the middle
For successful verification of a certificate, the
verifying agent must either
get the chain certificate from the certificate
owner, or,
have the end certificate in its trusted key store

11. JAVA & CERTIFICATES
JRE has a default trust store containing all
trusted Root CA certificates at
$JAVA_HOME/lib/security/cacerts
Java applications store its end certificate and
chain certificates in a separate key store
Key stores and trust stores are managed using
“keytool” which comes with the JRE

12. Digital signature

13. WHAT I DIGITAL SIGNATURE
Used to validate the authenticity and integrity of
a message
Digital signature is created by
- Computing a hash of the message
- Encrypting the hash using the private key
Accompanied by the sender’s certificate which
is in turn signed by the CA

14. SIGNATURE VERIFICATION BY THE RECEIVER
Compute the hash of the message
The computed hash and the decrypted hash
should be the same
Decrypt the signature using the public key
(available in the certificate) of the sender

15. WHAT IT PROVES
Digital
certificate
verification
proves
Digital
signature
verification
proves
Message is not tampered
Message is indeed sent by
the sender
The public key belongs to
the sender

16. SSL/TLS
SSL 3.0 served as the
basis of TLS 1.0
Provides security to
the message during
transit over network
(transport layer
security)

17. SSL / TLS CLIENT SERVER HANDSHAKING - 1
Requests for
secured session
Sends certificate &
chain certificate
Verifies certificate
Generates random
key
Encrypts key with
server public key
Client Server

18. SSL / TLS CLIENT SERVER HANDSHAKING - 2
All subsequent communications between client
and server are encrypted using the shared
symmetric key
Decrypts the client
sent key with its
private key
Client Server