SSL/TLS 101

21

Click here to load reader

Transcript of SSL/TLS 101

Page 1: SSL/TLS 101

SSL/TLS 10123 December 2015

Chul-Woong Yang 양철웅[email protected]

Page 2: SSL/TLS 101

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

Page 3: SSL/TLS 101

SSL and TLS• SSL and TLS are the name of protocol, which imple-

ments 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

Page 4: SSL/TLS 101

OSI Model Layer# OSI Layer Description Example protocols7 Application Application data HTTP, SMTP, IMAP6 Presentation Data representation, conversion, encryption SSL/TLS5 Session Management of multiple connection -4 Transport Reliable delivery of packets and streams TCP, UDP3 Network Routing and delivery of datagrams between

network nodesIP, IPSec

2 Data link Reliable local data connection (LAN) Ethernet1 Physical Direct physical data connection (cables) CAT5

[BPST] p3

Page 5: SSL/TLS 101

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

Page 6: SSL/TLS 101

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. (In-

tegrity)• 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

Page 7: SSL/TLS 101

Step 1: Protect Against Eavesdrop-pers• 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

Page 8: SSL/TLS 101

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

Page 9: SSL/TLS 101

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.

Page 10: SSL/TLS 101

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 dec-

imal digits)• Very slow practical use is only for key exchange, not for data encryp-

tion

Page 11: SSL/TLS 101

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 af-

terwards• 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

Page 12: SSL/TLS 101

Elliptic Curve Cryptography• TLS 1.2 introduced support for Elliptic-Curve Cryptogra-

phy (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

Page 13: SSL/TLS 101

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

Page 14: SSL/TLS 101

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

Page 15: SSL/TLS 101

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

Page 16: SSL/TLS 101

HMAC (Hash-based Message Au-thentication 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

Page 17: SSL/TLS 101

Digital Signature Algorithms (DSA)• Federal Information Processing Standard (FIPS) for digi-

tal 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 stan-

dard• ECDSA• DSA with elliptic curve cryptography• Smaller signature

Page 18: SSL/TLS 101

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

Page 19: SSL/TLS 101

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 certifi-

cates (CRL)• The client should checks it periodically• Key: serial ID

• Should be unique within a CA

Page 20: SSL/TLS 101

X.509• International Telecommuni-

cation Union (ITU) defines and maintains SSL/TLS cer-tificate format in a series of documents• X.509 : Information technol-

ogy - Open Systems Inter-connection - The Directory: Public-key and attribute cer-tificate 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 }

Page 21: SSL/TLS 101

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