1. Applied Cryptography Spring 2015 SSL/TLS standards

2. SSL/TLS

4. What is SSL / TLS? Transport Layer Security protocol, ver 1.0 –De facto standard for Internet security –“The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications” –In practice, used to protect information transmitted between browsers and Web servers Based on Secure Sockets Layers protocol, ver 3.0 –Same protocol design, different algorithms Deployed in nearly every web browser

5. History of the Protocol The SSL protocol was originally developed by Netscape. Version 1.0 was never publicly released. Version 2.0 was released in 1994 but "contained a number of security flaws which ultimately led to the design of SSL version 3.0", which was released in 1996. This later served as the basis for TLS version 1.0, an IETF standard protocol first defined in RFC 2246 in January 1999.

6. History of the Protocol SSL 1.0 –Internal Netscape design, early 1994? –Lost in the mists of time SSL 2.0 –Published by Netscape, November 1994 –Badly broken SSL 3.0 –Designed by Netscape and Paul Kocher, November 1996 TLS 1.0 –Internet standard based on SSL 3.0, January 1999 –Not interoperable with SSL 3.0 TLS 1.1 –Update of TLS 1.0, April 2006 –Basically added protection to some attacks (IV, padding) TLS 1.2 –August 2008 (refined 2011 – no SSL 2.0 compatibility) –AES support, replacement of MD5/SHA1 with SHA256

7. Flaws of SSL v2 Identical cryptographic keys are used for message authentication and encryption. SSL v2 has a weak MAC construction that uses the MD5 hash function with a secret prefix, making it vulnerable to length extension attacks. SSL v2 does not have any protection for the handshake, meaning a man-in- the-middle downgrade attack can go undetected. SSL v2 uses the TCP connection close to indicate the end of data. This means that truncation attacks are possible: the attacker simply forges a TCP FIN, leaving the recipient unaware of an illegitimate end of data message (SSL v3 fixes this problem by having an explicit closure alert). SSL v2 assumes a single service, and a fixed domain certificate, which clashes with the standard feature of virtual hosting in webservers. This means that most websites are practically impaired from using SSL..

8. TLS 1.0 – BEAST attack On September 23, 2011 researchers Thai Duong and Juliano Rizzo demonstrated a "proof of concept" called BEAST ("Browser Exploit Against SSL/TLS") using a Java applet to violate same origin policy constraints, for a long-known Cipher block chaining (CBC) vulnerability in TLS 1.0. Practical exploits had not been previously demonstrated for this vulnerability, which was originally discovered by Phillip Rogaway in 2002. Mozilla updated the development versions of their NSS libraries to mitigate BEAST-like attacks. NSS is used by Mozilla Firefox and Google Chrome to implement SSL. Some web servers that have a broken implementation of the SSL specification may stop working as a result. Microsoft released Security Bulletin MS12-006 on January 10, 2012, which fixed the BEAST vulnerability by changing the way that the Windows Secure Channel (SChannel) component transmits encrypted network packets.

9. TLS 1.0 – BEAST attack CBC chaining (above) IV for each block depends from previous encrypted value, so there is a practical attack provided that there is a reliable “oracle” reporting padding errors. As it seems attack can be used to recover information from encrypted cookies. TLS 1.1+ uses “explicit IV” for each block.

10. Sending of messages

11. Receiving of messages

12. Network security

13. SSL/TLS

14. Secure HTTP S-HTTP was developed by Allan Schiffman and Eric Rescorla around 1993. Seems to be used just in some "experimental" browser versions...

15. IPSEC

16. Kerberos

17. A third-party authentication protocol designed for TCP/IP networks. Developed at MIT. Not in public domain, but in principle it is possible to obtain it for free.

18. SSL/TLS Some modifications of HTTP still required though - HTTPS (Hypertext Transfer Protocol Secure )

19. Kerberos A third-party authentication protocol designed for TCP/IP networks Developed at MIT Uses Needham-Schroeder’s trusted third party protocol Not in public domain, but in principle it is possible to obtain it for free

20. Network security

21. TLS Basics TLS consists of two protocols Handshake protocol –Use public-key cryptography to establish a shared secret key between the client and the server Record protocol –Use the secret key established in the handshake protocol to protect communication between the client and the server

22. TLS Example

23. TLS architecure HANDLES COMMUNICATION WITH THE APPLICATION Protocols INITIALIZES COMMUNCATION BETWEEN CLIENT & SERVER INITIALIZES SECURE COMMUNICATION HANDLES DATA COMPRESSION ERROR HANDLING

24. TLS Handshake Protocol Two parties: client and server Negotiate version of the protocol and the set of cryptographic algorithms to be used –Interoperability between different implementations of the protocol Authenticate client and server (optional) –Use digital certificates to learn each other’s public keys and verify each other’s identity Use public keys to establish a shared secret

25. Handshake Phases Hello messages Certificate and Key Exchange messages Change CipherSpec and Finished messages

26. SSL messages

28. TLS architecure HANDLES COMMUNICATION WITH THE APPLICATION Protocols INITIALIZES COMMUNCATION BETWEEN CLIENT & SERVER INITIALIZES SECURE COMMUNICATION HANDLES DATA COMPRESSION ERROR HANDLING

29. Record layer

31. TLS Record layer

32. TLS architecure HANDLES COMMUNICATION WITH THE APPLICATION Protocols INITIALIZES COMMUNCATION BETWEEN CLIENT & SERVER INITIALIZES SECURE COMMUNICATION HANDLES DATA COMPRESSION ERROR HANDLING

33. TLS Handshake protocol

34. TLS Alert protocol

35. TLS ChangeCipherSpec protocol

36. TLS Application protocol MAC - optional in SSL, required in TLS MD5/SHA-1 based HMAC

37. HMAC ipad = 0x36 opad = 0x5c K is 64 bytes long (padded to the right with 0-s) Supported by SSL3.0, “enforced” in TLS1.0

38. SSL – establishing communications

39. SSL Messages OFFER CIPHER SUITE MENU TO SERVER SELECT A CIPHER SUITE SEND CERTIFICATE AND CHAIN TO CA ROOT CLIENT SIDE SERVER SIDE SEND PUBLIC KEY TO ENCRYPT SYMM KEY SERVER NEGOTIATION FINISHED SEND ENCRYPTED SYMMETRIC KEY SOURCE: THOMAS, SSL AND TLS ESSENTIALS ACTIVATE ENCRYPTION CLIENT PORTION DONE ( SERVER CHECKS OPTIONS ) ACTIVATESERVER ENCRYPTION SERVER PORTION DONE ( CLIENT CHECKS OPTIONS ) NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION

40. SSL – establishing communications

43. Client Hello

45. Client Hello/Cypher suites

47. Client Hello Cypher suites

48. Time requirements of public key algorithms

49. RC4 Ron Rivest (RSA Security) 1987 Widely used in SSL, WEP etc 104-bit RC4 used in WEP can be cracked in less than a minute for i=0,…,N-1 S[i]=i j=0 for i=0…N-1 j=j+S[i]+Key[i mod l] Swap[S[i], S[j]] i=i+1 j=j+S[i] Swap(S[i],S[j]) Output z =S[S[i]+S[j]]

50. RC4 Easy computation –Fast –Can use large bit blocks and keys Stream based encryption Key can be made to change at regular intervals using fancy programming Implementation in Popular languages (C, perl) well documented. Vulnerable to brute force attacks Require a large data structure Proven Breakable by researchers at ATT and Rice Univ. (August, 2001) –“One hour of brute force computation to break standard WEP” Once Key is broken all messages are easily readable.

51. RC2 RC2 is a block cipher designed by Ron Rivest in 1987. RC2 is a 64-bit block cipher with a variable size key. Its 18 rounds are arranged as a source-heavy Feistel network, with 16 rounds of one type (MIXING) punctuated by two rounds of another type (MASHING). A MIXING round consists of four applications of the MIX transformation (shown in the diagram). RC2 is vulnerable to related-key attack using 2 34 chosen plaintexts.

52. Fortezza The Fortezza card is becoming wider in use in Government and Military applications due to the fact that the cards are interchangeable within the many types of equipment that support Fortezza. Likewise, this means that the parties that program the Fortezza cards are able to program the cards and ship them out so organizations may use them in whatever equipment they need to use it for. This simplifies the process of rekeying equipment for Crypto changes: instead of requiring an expensive Fill device, a technician is able to put a new Fortezza card in the device's PCMCIA slot.

53. Skipjack Skipjack was proposed as the encryption algorithm in a US government-sponsored scheme of key escrow, and the cipher was provided for use in the Clipper chip, implemented in tamperproof hardware. Skipjack is used only for encryption, the key escrow is achieved through the use of a separate mechanism known as the Law Enforcement Access Field (LEAF). The design was initially secret, and was regarded with considerable suspicion by many in the public cryptography community for that reason. It was declassified on 24 June 1998.

54. Skipjack

56. KEA

57. Key generation – Diffie-Hellman How to exchange g and p? - “ephemeral mode”: randomly generated and DSS/RSA signed - static: contained within certificate “DH_anon” – does not provide authentication

58. SSL – establishing communications

59. Server Hello

60. SSL – establishing communications

61. Server Key Exchange

62. SSL – establishing communications

63. Client Key Exchange Premaster secret –Created by client; used to “seed” calculation of encryption parameters –2 bytes of SSL version + 46 random bytes –Sent encrypted to server using server’s public key This is where the attack happened in SSLv2: A client can be used to send an oversized master key to an SSLv2 server, enabling denial of service or malicious code execution on the server.

64. CS519, © A.Selcuk Encryption: (PKCS #1 v1.5, RFC 2313) first 0: to guarantee x < n 2: indicates encryption second 0: indicates end of padding Protects against: guessable message attacks (e.g., a yes/no message) cube root problem, for e = 3 broadcast problem, for e = 3 random non-zero octets 0002 00 data 1 byte each 1 byte≥ 8 bytes Client Key Exchange 0301pre-master key 46 bytes

65. CS519, © A.Selcuk Capture c =m e mod n and send messges of the form c’=cs e mod n to the “oracle”. If the oracle confirms that the padding of the first two bytes are correct (probability 1/2 16 ), we know that ms starts with bytes 00,02. It can be shown that with  2 20 appropriately chosen messages s the entire message m can be recovered. The method becomes non-practical if the “oracle” in the same way reacts to the correctness of all 5 bytes of padding (probability 1/2 40 that for random message such padding will be correct). Million message attack [Bleichenbacher, 1998]

66. Building cipher suites

68. Change Cipher Spec & Finished Messages Change Cipher Spec –Switch to newly negotiated algorithms and key material Finished –First message encrypted with new crypto parameters –Digest of negotiated master secret, the ensemble of handshake messages, sender constant –HMAC approach of nested hashing

69. Finished

70. Authentication

71. Certificate

72. Authentication

74. Certificates Sequence of X.509 certificates –Server’s, CA’s, … X.509 Certificate associates public key with identity Certification Authority (CA) creates certificate –Adheres to policies and verifies identity –Signs certificate User of Certificate must ensure it is valid Standard was developed starting from 1988. Standard defined in RFC 5280 (Public Key Infrastructure Certificate)

75. Validating a Certificate Must recognize accepted CA in certificate chain –One CA may issue certificate for another CA Must verify that certificate has not been revoked –CA publishes Certificate Revocation List (CRL)

76. X.509 certificates

79. Sample certificate This picture shows how Internet Explorer shows the contents of a certificate. Note that the CN field contains the host name of the server.

80. Certificate authorities Worldwide, the certificate authority business is fragmented, with national or regional providers dominating their home market. This is because many uses of digital certificates, such as for legally binding digital signatures, are linked to local law, regulations, and accreditation schemes for certificate authorities. However, the market for SSL certificates (used for website security) supports a number of multinational companies. A 2007 market share report from Security Space as of September of that year determined that Symantec (owns VeriSign, Thawte and Geotrust) have a 42.9% share of the certificate authority market, followed by Comodo (26%), GoDaddy (14%), GlobalSign (7.7%). (% updated as of Nov. 2012)

81. Certificate authorities Currently there are at least four providers issuing digital certificates to the public at no cost: CAcert.org - The Root CA is not included in Mozilla and Microsoft CA ring. Comodo "Free SSL Certificates provide full Secure Sockets Layer functionality for 90 days.“ (Options apparently still exist, but information above is likely out of date.)

82. Certificate authorities Currently there are at least four providers issuing digital certificates to the public at no cost: Thawte offers personal e-mail certificates that "can be used indefinitely at no cost"; it isn't stated whether the certificates never expire, or they do expire but can be renewed for free. (Thawte has issued certificates in the past that expire on an annual basis but can be renewed at no charge.) Thawte also offers 21-day free trial SSL certificates. StartCom - Microsoft has not included the Root CA in Explorer ring.

83. Certificate file formats

84. Abstract syntax notation (ASN.1) In telecommunications and computer networking, Abstract Syntax Notation One (ASN.1) is a standard and flexible notation that describes data structures for representing, encoding, transmitting, and decoding data. It provides a set of formal rules for describing the structure of objects that are independent of machine-specific encoding techniques and is a precise, formal notation that removes ambiguities. Eric Recorla: Falls in category of “highly unpleasant things that it is sometimes necessary to know”

85. Abstract syntax notation (ASN.1) TBSCertificate ::= SEQUENCE { version [ 0 ] Version DEFAULT v1(0), serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [ 1 ] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [ 2 ] IMPLICIT UniqueIdentifier OPTIONAL, extensions [ 3 ] Extensions OPTIONAL }

86. Abstract syntax notation (ASN.1) ASN.1 defines the abstract syntax of information but does not restrict the way the information is encoded. Various ASN.1 encoding rules provide the transfer syntax (a concrete representation) of the data values whose abstract syntax is described in ASN.1. The standard ASN.1 encoding rules include: Basic Encoding Rules (BER) Canonical Encoding Rules (CER) Distinguished Encoding Rules (DER) XML Encoding Rules (XER) Packed Encoding Rules (PER) Generic String Encoding Rules (GSER)

87. Abstract syntax notation (ASN.1) myQuestion FooQuestion ::= { trackingNumber 5, question "Anybody there?" } DER: 30 13 02 01 05 1a 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f XER: 5 Anybody there?

88. SSL Encryption Master secret –Generated by both parties from premaster secret and random values generated by both client and server Key material –Generated from the master secret and shared random values Encryption keys –Extracted from the key material

89. Generating the Master Secret SOURCE: THOMAS, SSL AND TLS ESSENTIALS SERVER’S PUBLIC KEY IS SENT BY SERVER IN ServerKeyExchange CLIENT GENERATES THE PREMASTER SECRET ENCRYPTS WITH PUBLIC KEY OF SERVER CLIENT SENDS PREMASTER SECRET IN ClientKeyExchange SENT BY CLIENT IN ClientHello SENT BY SERVER IN ServerHello MASTER SECRET IS 3 MD5 HASHES CONCATENATED TOGETHER = 384 BITS

90. Key generation

92. Generation of Key Material SOURCE: THOMAS, SSL AND TLS ESSENTIALS JUST LIKE FORMING THE MASTER SECRET EXCEPT THE MASTER SECRET IS USED HERE INSTEAD OF THE PREMASTER SECRET...

93. Obtaining Keys from the Key Material SOURCE: THOMAS, SSL AND TLS ESSENTIALS SECRET VALUES INCLUDED IN MESSAGE AUTHENTICATION CODES INITIALIZATION VECTORS FOR DES CBC ENCRYPTION SYMMETRIC KEYS

94. SSL Record Protocol

95. Record Header Three pieces of information –Content type Application data Alert Handshake Change_cipher_spec –Content length Suggests when to start processing –SSL version Redundant check for version agreement

96. Record Protocol (cont’d) Max. record length 2 14 – 1 MAC –Data –Headers –Sequence number To prevent replay and reordering attack Not included in the record

97. Alerts and Closure Alert the other side of exceptions –Different levels –Terminate and session cannot be resumed Closure notify –To prevent truncation attack (sending a TCP FIN before the sender is finished)

98. SSL Sessions Sessions vs. Connections –Multiple connections within a sessions –One negotiation/session Session Resumption –Through session IDs –Clients use server IP address or name as index –Servers use the session IDs provide by the clients –Use of random numbers in resumed session key calculation ensures different keys Session Re-handshake –Client can initiate a new handshake within a session –Use of Server Gated Cryptography (SGC) for added security

99. SSL Overhead 2-10 times slower than a TCP session Where do we lose time –Handshake phase Client does public-key encryption Server does private-key encryption (still public-key cryptography) Usually clients have to wait on servers to finish –Data Transfer phase Symmetric key encryption

100. IPsec - between designated routers U

101. IPsec

102. IPsec – between individual computers U

103. IPsec – transport and tunnel modes U

104. IPsec – what protocols/algorithms does it provide? U AH/ESP looks more like just more like standards for packet formats, not really protocol. Generally support for hashing and symmetric algorithms. IKE – Key Exchange Algorithm (typically Diffie –Hellman scheme, maybe RSA). Doesn’t provide initial authetication(?) Apparently relies on external authentication protocols (X.509 certificates, keys stored on smartcards etc) (???) Any of these will require some kind of PKI.