SSL/TLS 101 provides an overview of SSL and TLS including: 1) SSL and TLS are cryptographic protocols that provide security for internet communications like HTTPS and HTTP/2. They provide confidentiality, integrity, and authentication. 2) Key concepts of SSL/TLS include symmetric encryption for confidentiality, public key cryptography for key exchange, digital signatures for authentication, and X.509 certificates issued by certificate authorities to verify identities. 3) The document reviews the history and versions of SSL/TLS, how the core requirements of confidentiality, integrity and authentication are achieved, and references for further reading on implementing SSL/TLS.

1. SSL/TLS 101
23 December 2015
Chul-Woong Yang 양철웅
cwyang@aranetworks.com

2. Agenda
• SSL and TLS
• Protection against Eavesdroppers
• Secure Key Exchange
• Authentication
• X.509 Certificates
• Reference

3. SSL and TLS
• SSL and TLS are the name of protocol, which implements
cryptography
• SSL: Secure Socket Layer
• TLS: Transport Layer Security, a new name for SSL
• Internet depends on HTTP, HTTPS, HTTP/2
• HTTPS and HTTP/2 depends on SSL/TLS for secure
transmission
• So, Internet depends on SSL/TLS

4. OSI Model Layer
# OSI Layer Description Example protocols
7 Application Application data HTTP, SMTP, IMAP
6 Presentation Data representation, conversion, encryption SSL/TLS
5 Session Management of multiple connection -
4 Transport Reliable delivery of packets and streams TCP, UDP
3 Network Routing and delivery of datagrams between
network nodes
IP, IPSec
2 Data link Reliable local data connection (LAN) Ethernet
1 Physical Direct physical data connection (cables) CAT5
[BPST] p3

5. Protocol History
• SSLv1: N/A
• SSLv2: November 1994, deployed into Netscape Navigator 1.1
• Serious cryptographic weakness
• SSLv3: Late 1995
• IETF TLS working group formed: May 1996
• TLSv1: January 1999, RFC2246
• Minor improvement from SSLv3
• Name changed for Microsoft
• TLS extension: June 2003
• TLSv1.1: April 2006
• TLSv1.2: August 2008

6. Core Requirements
• When Alice receives a message from Bob:
• Only Alice, no eavesdropper, can decrypt the message (Confidentiality)
• The received message is the exact message sent from Bob. Not tampered.
(Integrity)
• Truncation attack
• “BOMB THE BUILDING AT 2:00 IF ENEMY DOES NOT SURRENDER”
•  “BOMB THE BUILDING AT 2:00”
• Tampering
• “Transfer $100 to Alice”
•  “Transfer $100 to Bob”
• Alice is sure that the message come from Bob, no one else. (Authenticity)
• Man-In-The-Middle attack

7. Step 1: Protect Against Eavesdroppers
• Symmetric encryption (private/shared key)
• Algorithms are based on bit shifting and XORing
• Stream ciphers: RC4
• Block ciphers: DES, AES
• DES: Breaks input into 8-byte blocks and scrambles them in using 8-
byte keys (only 56 bit is used)
• weak
• 3DES: Use 56 * 3 = 168 bit key on 8 byte blocks
• Very slow in SW implementation
• AES: Defined for 128-, 192-, and 256-bit keys.
• Fast in SW/HW implementation
• RC4: Use 40 bits and 128 bits keys
• Straightforward to crack

8. Step 2: Secure Key Exchange
• Q)How can exchange a shared key over an insecure medium,
on which eavesdroppers can see the key?
• A) Public-key cryptography
• Public key can decrypt messages encrypted with private key
• Private key can decrypt messages encrypted with public key
• Algorithms are based on BIGNUM manipulation
• Most common algorithm: RSA
• Ron Rivest, Adi Shamir, and Leonard Adleman

9. RSA
• Three numbers: e, d, n
• (m^e)^d % n = m
• m = message
• d = private key
• (e, n) = public key
• d cannot be computed from (e, d) – computationally infeasible
• Break a message into blocks of length n or less and encrypt them
• Alice sends message m encrypted with Bob’s public key (e, n)
• C has sent to Bob. C = (m^e) % n
• Bob reclaims m = (C^d) % n
• Though Eve can eavesdrop C, she cannot decrypt C into m
without d.

10. RSA
• (m^e)^d % n = m
• Public key: (e=3, n=55) then
• d= 27
• n and d have to be enormous
• 512 (weak), 1024, 2048 bit number
• Should do numerical operation for 2048 bit number (617 decimal
digits)
• Very slow  practical use is only for key exchange, not for data encryption

11. Diffie-Hellman Key Exchange
• Eve has Bob’s private key somehow (compromised key)
• Alice send shared key encrypted with Bob’s public key
• Eve can eavesdrop the message and retrieve the shared key.
• Once Eve has the shared key of Alice and Bob, she can see all their
messages afterwards
• Diffie-Hellman key exchange: Perfect forward secrecy
• Public numbers (g, p) and ephemeral numbers a and b.
• g is usually 2
• a, b, p is large number (512, 1024, 2048 bit)
• Alice chooses a and sends Y(a) = (g^a % p)
• Bob chooses b and send Y(b) = (g^b % p)
• Alice computes Z = Y(b)^a % p = (g ^ ab % p)
• Bob computes Z = Y(a)^b % p = (g ^ ab % p)
• Z is shared key

12. Elliptic Curve Cryptography
• TLS 1.2 introduced support for Elliptic-Curve Cryptography
(ECC) in 2008
• Math
• Why ECC?
• ECC 80 bit private key ~ RSA 512-bit private key
• Public-key operation is O(n), where n is the number of bit in private
key

13. Step 3. Authentication
• Public key cryptography supported by certificates
• Alice receives certificates from Bob
• Alice verify certificates whether it is really from Bob and not
tampered
• Alice has Bob’s public key, then proceeds to key exchange

14. Digital Signature
• RSA: (m^e)^d % n = m
•  (m^d)^e % n = m
• Message encrypted with Alice’s Public Key
• Only Alice can read
• Message encrypted with Alice’s Private Key
• Bob can verify the message is coming from Alice
• Identity proof: role of signature
• Message with message digest encrypted with Alice’s Private key
• Bob can verify the message is coming from Alice, without tampering

15. Message Digest
• MD5 (RFC1321)
• Transform 512 bit blocks to 128 bit hashes and compute the sum.
• Birthday Paradox
• How many people needed to have 50% chance that two of them share the
same birthday?
• 1.1772 * sqrt(n)
• MD5 collisions
• 50% chance to collide: 2.2 * 10^19
• 2005: MD5 collisions are computed in an hour using commodity hardware
• Secure Hash Algorithm (SHA)
• SHA-1: 160-bit
• SHA-2: 224, 256, 384, 512-bit

16. HMAC (Hash-based Message
Authentication Code)
• Replay attack to retrieve original data from MD5 hash
• If domain is not large, compute all set of (message, MD5)
• Ex. Credit card number
• Storage can be reduced using rainbow table
• HMAC (RFC 2104)
• Include secret in the hash: H(m,s), s can be up to 64 byte
• Use SHA
• SSL
• Every SSL records are HMAC’ed before being encrypted to keep
message authenticity

17. Digital Signature Algorithms (DSA)
• Federal Information Processing Standard (FIPS) for digital
signatures
• DSA vs RSA signature
• DSA is faster in signing, but much slower in verifying
• DSA generates smaller signature for same strength
• DSA requires 1024 bits key only to be compatible with standard
• ECDSA
• DSA with elliptic curve cryptography
• Smaller signature

18. Step 4. X.509 Certificates
• Alice receives a certificate from Bob
• How to verify the certificate is from Bob?
• SSL uses a “Trusted Intermediary”
• Trusted intermediary digitally signs Bob’s public key
• Alice must have access to the public key of the trusted intermediary to
verify the signature of Bob’s public key
• If Mallory does MITM and send to Alice her certificate, not Bob’s certificate?
• Other information, like Bob’s name, is included in addition to public key
• Certificate: a holder for public key and other information, which is
signed by trusted intermediary (CA)
• Certificate Authority: a trusted intermediary responsible for signing
certificates

19. Certificate Revocation
• When there is a problem with the certificate?
• Specified cryptography is outdated
•  Validity period
• The private key is compromised
•  Revocation
• CAs are responsible for keeping a list of revoked certificates
(CRL)
• The client should checks it periodically
• Key: serial ID
• Should be unique within a CA

20. X.509
• International
Telecommunication Union (ITU)
defines and maintains SSL/TLS
certificate format in a series of
documents
• X.509 : Information technology -
Open Systems Interconnection -
The Directory: Public-key and
attribute certificate frameworks
• RFC2459: Internet X.509 Public
Key Infrastructure Certificate
and CRL Profile
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version shall be v3
}

21. Reference
• [BPST] Bulletproof SSL and TLS, Ivan Ristic, Feisty Duck
• [IST] Implementing SSL/TLS, Joshua Davies, Wiley