Secure Socket Layer (TLS) Carlo U. Nicola, SGI FHNW With extracts from publications of : William Stallings.

Transcription

1 Secure Socket Layer (TLS) Carlo U. Nicola, SGI FHNW With extracts from publications of : William Stallings.

2 Crypto building blocks AS HS13 2

3 Abstraction: The secure channel 1., run a key-exchange protocol that establishes an, between and. 2. This is used together with a cryptographic functions to protect the and/or of the transmitted data. AS HS13 3

4 The real secure channel Network layer Physical layer Data link LLC = Logical Link Control MAC = Media Access Control AS HS13 4

5 SSL as a playground for crypto tools We will study the SSL protocol and in the meantime recapitulate (or relearn) some important concepts like: 1. Hash function, hash value (MD5 (deprecated), SHA-XXX) 2. Symmetric encryption key (AES) 3. Asymmetric encryption key (RSA) 4. Digital signature 5. X.509 certificates AS HS13 5

6 Where security hides in the TCP/IP protocol stack AS HS13 6

7 SSL functionality AS HS13 7

8 The differnt parts of the SSL protocol AS HS13 8

9 SSL(TLS) over TCP over IP AS HS13 9

10 SSL characteristics! Netscape Secure Socket Layer;! Layered between the application and TCP;! Server authenticated with public keys (X509);! Can authenticate client (rare);! Privacy enforced by encryption;! Integrity enforced by MACs;! Works with any TCP application (but mainly http): Service port AS HS13 10

11 SSL(TLS) protocols SSL provides end to end security, based on a communication protocol. The different protocols implemented by SSL: 1. Handshake 2. Record 3. Change cipher specifications 4. Alert services The record protocol specifies how the data are encrypted. AS HS13 11

12 Handshake protocol The most complex and unsecure part of SSL: a) Allows the server and client (optional) to authenticate each other. b) Negotiate encryption, MAC (Message Authentication Code) algorithm and cryptographic keys. c) Used before any application data are transmitted. AS HS13 12

13 Handshake protocol action: the palatable version. Client : Hello, here is a list of cipher suites I can use. Server: Hello, here is the cipher suite I chose from your list. And here's an X.509v3 certificate that contains my public RSA key. Client : [Scrutinises the certificate, checks to make sure it's signed by a known certificate authority.] Okay, thanks. Here's the pre-master secret, encrypted with your public key. The next thing I say to you will be encrypted with the session key. Client : [Encrypted] I'm done with the handshake. Server: [Decrypts the pre-master secret using private key, then generates the session key.] The next thing I send will be encrypted. Server: [Encrypted] I'm done with the handshake too. AS HS13 13

14 SSL protocol basic handshake features (i) The client initiates the connection to the server and tells the server which SSL cipher suites the client supports. (ii) The server responds with the cipher suites that it supports. (iii) The server sends the client a certificate that should authenticate it. (iv) The server initiate a session key exchange algorithm, based in part on the information contained in the certificate it has just sent, and sends the necessary key exchange information to the client. (v) The client completes the key exchange algorithm and sends the necessary key exchange information to the server. Along the way, it verifies the certificate. (vi) Based on the type of key exchange algorithm (that in turn is based on the type of key in the server s certificate), the client selects an appropriate cipher suite and tells the server which suite it wishes to use. (vii) The server makes a final decision as to which cipher suite to use. AS HS13 14

15 Handshake protocol crypto details Negotiate cryptographic specifications: -- includes session id and nonce (random number) -- key exchange -- RSA, Diffie-Hellmann, Fortezza (IBM proprietary alg.) -- cipher -- RC2, RC4, DES, 3DES, DES40, IDEA, Fortezza, AES -- hash -- MD5, SHA-1 Authenticate server (optionally and rarely the client): -- server sends its public key certificate -- or anonymous DH (option) -- client verifies server certificates with CA certificate Establish session key/iv (Initial Vectors): -- optional client authentication -- client sends premaster secret encrypted with server's pub key -- client/server calculate master secret, keys, IVs Send change cipher message. Send encrypted finish message. AS HS13 15

16 Handshake protocol global view AS HS13 16

17 Handshake protocol gritty details (1) Client Server of client of server Handshake: (offer of supported cipher clusters, represented as two-byte codes; the client is offering different combinations of signing algorithms, digest algorithms, and so on) (4 bytes GMT + 28 bytes random) 3. version (first time through client leaves this blank) (the only one defined is null...) Handshake: (contains essentially the same fields as the message. Server fills in, for uses we'll see shortly. What's in are the algorithms the client and server will actually use--i.e., the server decides) Handshake:Certificate (here's my X.509 certificate; see the example below) Handshake: AS HS13 17

18 Handshake protocol gritty details (2) Client Handshake: (client selects (= two bytes designating version + 46 of random bytes, encrypts with sender's public key (having verified the server's certificate and extracted the key) and sends; each side now turns the into the, and then to turn the into a set of session keys; see below for further details) (my next message will use the encryptions we agreed on) Handshake: 1. the client now sends a digest of all its previous messages so the server can verify the integrity of the messages received; the point is to prevent the possibility of an attacker injecting bogus handshake messages 2. in the case of SSLv3, the contents of the Finished message are an MD5 hash followed by a SHA-1 hash; here's how the MD5 hash is produced: Server (my next message will use the encryptions we agreed on) Handshake: (here's a digest of what I just said) AS HS13 18

19 Handshake protocol gritty details (3) Client Server (blah blah blah) ApplicationData (yak yak yak) Alert: warning, (the point of which is to prevent truncation attack, i.e., attacker inserting a premature (they can't insert a bogus because of the integrity checks built into SSL)) Alert:, of of AS HS13 19

20 Generating the Master Secret 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 SOURCE: THOMAS, SSL AND TLS ESSENTIALS AS HS13 20

21 Generation of key material JUST LIKE FORMING THE MASTER SECRET EXCEPT THE MASTER SECRET IS USED HERE INSTEAD OF THE PREMASTER SECRET... SOURCE: THOMAS, SSL AND TLS ESSENTIALS AS HS13 21

22 Obtaining keys from the key material SECRET VALUES INCLUDED IN MESSAGE AUTHENTICATION CODES SYMMETRIC KEYS INITIALIZATION VECTORS FOR DES CBC ENCRYPTION SOURCE: THOMAS, SSL AND TLS ESSENTIALS AS HS13 22

23 Record protocol 1. Provides confidentiality and integrity. 2. Fragments message ( 2 14 bytes). 3. Optional compression (default: none). 4. Calculates MAC (Message Authentication Code = integrity). MAC traditionally is based on symmetric block cipher, i.e. MAC = C K (M) where M is the message, MAC a fixed length authenticator, K a secret symmetric key shared between sender and receiver and C(.) a function. 5. Modified H(Hash)MAC to include sequence number (prevent replay attacks). 6. Encrypts both message and MAC (confidentiality+integrity). 7. Propend header. AS HS13 23

24 SSL Record Protocol Operation 2 14 Bytes = 16 KB AS HS13 24

25 SSL Record Format Higher level protocol used 2003: : 1 Length in Bytes of plaintext or compressed fragment AS HS13 25

26 SSL remaining protocols One of 10 messages, e.g.: Always 1: pending state current Parameters Warning (1) or fatal (2) Specifies alert AS HS13 26

27 TLS enhancements: TLS 1.0 (1) RFC 2246 standard for SSLv3.1:! contains only non patented technology (no IBM KEA/FORTEZZA)! standard HMAC functions: H = embedded hash function (for TLS, either MD5 or SHA-1) M = message input to HMAC K+ = secret key padded with zeros until the block length of hash code is reached ipad = (36 in hexadecimal) repeated 64 times (512 bits) opad = (5C in hexadecimal) repeated 64 times (512 bits)! No weak cryptography for export! Good PRF (pseudo random function) for random bit expansion! Newer cryptographic algorithms (SHA-1/2/3, AES, ) AS HS13 27

28 TLS enhancements: TLS 1.0 (2) Differences in the: version number message authentication code pseudorandom function (PRF) alert codes cipher suites client certificate types certificate_verify and finished message cryptographic computations padding Otherwise similar to SSL v3.1. Important: the same record format as the SSL record. Vaudeney (EPFL): TLS/1.0 is unsafe! Production use: TLS 1.1 or better TLS 1.2 AS HS13 28

29 TLS enhancements: TLS 1.1 Defined in RFC 4346 in April Significant differences in this version include: 1. Added protection against Cipher block chaining ( ) attacks. Each block has a new IV field. Random IV via PRF 2. The implicit Initialization Vector ( ) was replaced with an explicit. 3. Change in handling of padding errors. 4. Support for IANA registration of parameters i.e. canonical bites codes for Internet s commands, protocols, algorithms etc. Examples: AS HS13 29

30 TLS enhancements: TLS 1.2 TLS 1.2 was defined in RFC 5246 in August Major differences include: 1. The MD5-SHA-1 combination in the pseudorandom function (PRF) was replaced with SHA-256, with an option to use PRFs specified in the ciphersuite. 2. The same combination in the message hash was replaced with SHA-256, with an option to use hash algorithms specified in the cipher-suite. 3. The same combination in the digitally-signed element was replaced with a single hash negotiated during handshake, defaults to SHA Enhancement in the client's and server's ability to specify which hash and signature algorithms they will accept. 5. Expansion of support for authenticated encryption ciphers, used mainly for Galois/Counter Mode (GCM) and CCM mode of Advanced Encryption Standard encryption. 6. TLS Extensions definition and Advanced Encryption Standard CipherSuites were added. 7. TLS 1.2 was further refined in RFC 6176 in March 2011 redacting its backward compatibility with SSL such that TLS sessions will never negotiate the use of Secure Sockets Layer (SSL) version 2.0. AS HS13 30

31 Words to the wise about applied cryptography 1. Hashing and symmetric key ciphers are fast: use them for session encryption. 2. RSA public key is slow, but it is useful for key exchange and user/server authentication 3. Informal web of trust of PGP (you are in charge) versus CA based (you do not know, who controls it: in fact the NSA controls it (note added in 2013)) 4. A good protocol should: 1. negotiate cryptographic parameters 2. establish shared secret 3. authenticate endpoints 5. Use ssh, pgp liberally as the crypto part of an application. 6. SSL: a transport interface, but you still needs to modify the application (http https, telnet ssltelnet,...) 7. IPsec places cryptography where it belongs: at the network layer. AS HS13 31

32 SSL and Java applications AS HS13 32

33 A fast intro to socket Datagram (dg) = Internet data packet, which consists of:! Header: accounting info (e.g., sequence #, src port and dest port)! Payload: the data itself. Internet data are a stream of dg. Questions: How to split dg? How to reassemble dg? How to track packets arrival? How to parse dg? All this is handled by sockets. A socket is a descriptor that lets an application read/write from/to the network. Socket is a Berkeley Unix innovation that treat network connection as yet another byte stream, e.g., a file. Clients and servers communicate with each other by reading from and writing to socket descriptors. The main difference between file I/O and socket I/O is how the application opens the socket descriptors.! Example: Linux uses the same abstraction for both file I/O and network I/O.! Example: Linux uses regular read and write I/O functions. AS HS13 33

34 Socket basics in Java and do the following: classes : connection between two hosts. Can (i) bind to a port (ii) connect to remote machine (iii) send data (iv) receive data (v) close connection (vi) listen for incoming data (vii) accept connections from remote machines on background port AS HS13 34

35 Normal use of Java class 1. Program create new socket with different constructors (see DS) ; 2. Socket tries connecting to remote host; 3. After the connection is established, local and remote hosts get input and output streams from socket, which are used to send data to each other. Connection is full-duplex (both hosts can send and receive data simultaneously). The protocol (,, ) determines the data's meaning. 4. When done, connection is closed by one or both hosts. AS HS13 35

36 Java SSL software (JSSE) Set of API to construct SSL-Client and SSL-Server sockets. Two important new concepts: trust store and key store. Both are databases that hold certificates. Key store are used to provide credentials; trust store to verify them. Example: (i) Servers use key stores to obtain certificates they present to clients; (ii) Clients use trust stores to obtain root certificates to verify the server s certificate. AS HS13 36

37 Java 1.6 class diagram for SSL-sockets AS HS13 37

38 Providers Java provides abstract classes for the SSL package., and others offer concrete implementations (providers) of these classes. Example: Sun JSSE provider: 1. SSL 2.0 and 3.1, TLS See table for encryption methods 3. Checks for X.509 certificates 4. Certificates tree verification 5. Java Key Store (jks format) 6. Java 4 AES support I recommend strongly to use open source implementations of these classes. A good link: AS HS13 38

39 Set of ciphers after FIPS SSL_RSA_WITH_DES_CBC_SHA (hex number 0009) SSL_RSA_FIPS_WITH_DES_CBC_SHA (hex number FEFE) SSL_RSA_WITH_3DES_EDE_CBC_SHA (hex number 000A) SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (hex number FEFF) SSL_RSA_WITH_AES_128_CBC_SHA (hex number 002F) SSL_RSA_WITH_AES_256_CBC_SHA (hex number 0035) SSL_DHE_RSA_WITH_AES_128_CBC_SHA (hex number 0033) SSL_DHE_RSA_WITH_AES_256_CBC_SHA (hex number 0039) SSL_DHE_RSA_WITH_DES_CBC_SHA (hex number 0015) SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA (hex number 0016) SSL_DHE_DSS_WITH_AES_128_CBC_SHA (hex number 0032) SSL_DHE_DSS_WITH_AES_256_CBC_SHA (hex number 0038) SSL_DHE_DSS_WITH_DES_CBC_SHA (hex number 0012) SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA (hex number 0062) SSL_RSA_EXPORT_WITH_DES40_CBC_SHA (hex number 0008) SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (hex number 0014) SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (hex number 0063) SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (hex number 0011) SSL_DH_anon_WITH_AES_128_CBC_SHA (hex number 0034) SSL_DH_anon_WITH_AES_256_CBC_SHA (hex number 003A) SSL_DH_anon_WITH_DES_CBC_SHA (hex number 001A) SSL_DH_anon_WITH_3DES_EDE_CBC_SHA (hex number 001B) SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA (hex number 0019) AS HS13 39

40 Java 1.5: non blocking The processes the data contained in the buffer, or any handshaking data, to produce SSL/TLS encoded data and places it the network buffer supplied by the application. The application is then responsible for using an appropriate transport (shown on the right) to send the contents of the network buffer to its peer. Upon receiving SSL/TLS encoded data from its peer (via the transport), the application places the data into a network buffer and passes it to. The processes the network buffer's contents to produce handshaking data or application data. AS HS13 40

41 X.509 certificate (1) Every X.509 certificate consists of two sections: (i) data and (ii) signature. The data section includes the following information: 1. The version number of the X.509 standard supported by the certificate. 2. The certificate's serial number. Every certificate issued by a CA has a serial number that is unique to the certificates issued by that CA. 3. Information about the user's public key, including the algorithm used and a representation of the key itself. 4. The DN of the CA that issued the certificate. 5. The period during which the certificate is valid (for example, between 1:00 p.m. on January 1, 2000 and 1:00 p.m. December 31, 2000). 6. The DN of the certificate subject (for example, in a client SSL certificate this would be the user's DN), also called the subject name. 7. Optional certificate extensions, which may provide additional data used by the client or server. For example, the certificate type extension indicates the type of certificate - that is, whether it is a client SSL certificate, a server SSL certificate, a certificate for signing , and so on. Certificate extensions can also be used for a variety of other purposes. AS HS13 41

42 X.509 certificate (2) The signature section includes: 1. The cryptographic algorithm, or cipher, used by the issuing certificate authority (CA) to create its own digital signature. 2. The CA's digital signature, obtained by hashing all of the data in the certificate together and encrypting it with the CA's private key. AS HS13 42

43 Webserver verification of client's certificate AS HS13 43

44 Client verification of server's certificate AS HS13 44

45 Certification path The chain, or path, begins with the certificate of that entity, and each certificate in the chain is signed by the entity identified by the next certificate in the chain. The chain terminates with a root CA certificate. The root CA certificate is always signed by the CA itself. AS HS13 45

46 Certificates and keys administration Look contents of cacerts in: Verisign, Thawte CA Date trust degree given by user MD5-hash of cert AS HS13 46

47 Key pair generation (1) Encryption algorithm Private and public key + autosigned certificate Default name of keystore in $HOME directory. Other options: : Size in bits of key. Default 1024 bits. : Signature algorithm. Default: SHA1withDSA : No of day the certificate is valid. Default 90 days. AS HS13 47

48 Key pair generation (2) AS HS13 48

49 List contents of keystore AS HS13 49

50 Export and trust an autosigned certificate (1) Export: Import it into your trusted : AS HS13 50

51 Export and trust an autosigned certificate (2) Examine it in your trusted : AS HS13 51

52 Preparation for a Verisign certificate You want to get Verisign to authenticate your certificate (it costs money). First step: You get a file formatted with the standard: AS HS13 52

53 A secure Webserver in Java (1) AS HS13 53

54 A secure Webserver in Java (2) AS HS13 54

55 A secure Webserver: the problem The password to is passed in clear text as argument. Pseudo solutions: (i) Use without password but restrict access permissions to it. (ii) Use JCEKS ( ). is now encrypted, but to open it, you need a password. Where is it hidden? Sun proposal: The password to is passed in clear text within the code! AS HS13 55

56 Bibliography Stephen Thomas: SSL and TLS Essentials, John Wiley, RFC on TLS 1.1, 1.2: Analysis of SSL Security: SSL Timing Attack: Vaudenay paper can be found at: AS HS13 56