Introduction to SSL and 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