Transport-level and Web Security (SSL / TLS, SSH) Chapter 17 of

Transport-level and Web Security (SSL / TLS, SSH) Chapter 17 of Stallings 1

Web Security HTTP is not a secure protocol – simple and stateless client/server application running over TCP/IP Added security measures needed – we will see SSL (Secure Socket Layer) and TLS (Transport Layer Security) – HTTPS Secure HTTP protocol Actually SSL support is provided for several other TCP/IP applications as well – POP3, SMTP, FTP, News, . 2

Web Security Threats and Countermeasures – Integrity data modification, insertion – Confidentiality eavesdropping on the network – can be prevented by encryption theft from server machine – SSL may solve to some extent, but on-site security measures still needed – Authentication impersonation, data forgery we will see some cryptographic techniques Scope of SSL / TLS – cryptographic checksums (HMAC) – Denial of service, hacked web servers 3

Where to provide security? Long-lasting have seen discussion, no ultimate answer this lecture have seen and will see 4

SSL (Secure Socket Layer) originally developed by Netscape version 3 designed with public input subsequently Internet standardization effort started at IETF – TLS (Transport Layer Security) working group established – TLS can be viewed as SSL v3.1 and compatible with SSL v3 Our book completely switched to TLS – But they are not that different anyway 5

TLS Protocol Stack makes use of TCP (reliable end to end data transfer) any upper layer protocol adds security features – reliable and secure end to end data transfer TLS is not a single protocol – two-layers of protocols 6

Two TLS concepts TLS session – an association between client and server – define a set of cryptographic parameters created by the Handshake Protocol – may be shared by multiple TLS connections TLS connection – a transient, peer-to-peer, secure communication link – associated with (derived from) a TLS session – A session is used several times to create connections Session vs. Connection – Sessions are used to avoid expensive negotiation for crypto parameters for each connection Both are characterized by several parameters – that define a session state or connection state 7

Session state parameters Session identifier – chosen by server Peer certificate – certificate of the peer entity (server’s if the entity is client, client’s if the entity is server) – may be null (which is the likely case for server) Compression method (to be deprecated in TLS v1.3) – algorithm used for compression Cipher Spec – bulk data encryption algorithm (AES, etc.) - may be null (rarely) – hash algorithm used in MAC calculation (MD5 or SHA-1 or SHA-2) Master Secret – 48-bytes secret shared between client and server Is resumable – a flag that is set if the session can be used later for new connections 8

Connection State Parameters Random numbers – server and client exchange – used as nonces during key exchange MAC secret – secret key used for MAC operations – Separate for server and client conventional encryption keys – Separate for server and client initialization vector – if CBC mode is used 9

TLS Record Protocol serves to TLS connections – uses connection parameters provides confidentiality and integrity also fragments (into 214 bytes chunks) optionally compresses data (in practice, no compression and this is deprecated in the last version of TLS) confidentiality – AES, IDEA, DES, 3DES, RC4, etc. message integrity – using HMAC with shared secret key – In SSL, the method was similar to HMAC but pads were concatenated rather than XORed 10

TLS Record Protocol TLS header fields content type (higher layer protocol) – change cipher spec, alert, handshake, application data version compressed length (or plaintext length if no compression) of the fragment 11

Change Cipher Spec Protocol very simple protocol the new state established by the handshake protocol is a pending state – that is, it is not yet valid change cipher spec protocol (actually a single command exchanged between client and server) makes this pending state the current one – connection parameters change after that will see its use in the handshake protocol Record Protocol Payload 12

Alert Protocol Record Protocol Payload conveys TLS-alerts to peer entity secured using the record protocol (if any) – and with current connection state parameters each message is two bytes – one byte for level (severity) warning (connection may resume) or fatal (connection is terminated) – one byte for the alert code unexpected message, bad record MAC, decompression failure handshake failure (no common ground), illegal parameters (inconsistent or unrecognized parameters) no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired, certificate unknown 13

Handshake Protocol The most complex part of TLS Allows server and client: – – – – to authenticate each other to negotiate encryption and MAC algorithms to create cryptographic keys to be used in general, to establish a session and then a connection handshake is done before any data is transmitted – so cannot assume a secure record protocol 14

Handshake Protocol a series of messages in 4 phases 1. Establish Security Capabilities 2. Server Authentication and Key Exchange 3. Client Authentication and Key Exchange 4. Finish Handshake message format Message types 15

Handshake Protocol 16

Handshake Phase 1 – Establish Security Capabilities Client Hello (a list of client’s preferences) – version: highest TLS version supported by client – client’s random also includes a timestamp are used during key exchange to prevent replay attacks – session ID nonzero means client wants to use an existing session state for a new connection state (abbreviated handshake); zero means new connection on a new session – compression methods supported by client – Cipher Suite a list that contains the combination of crypto algorithms supported by the client in the order of preference each entry is a key exchange algorithm and a cipher spec 17

Handshake Phase 1 – Establish Security Capabilities Server Hello (response to client’s requests) – version: version proposed by client if also supported by server; otherwise highest supported by server – server’s random same structure as client’s, but independent of client’s random – session ID if client offered one and it is also supported by server, then the same ID (abbreviated handshake) otherwise a new ID assigned by server – compression methods chosen from the client’s list – Cipher Suite selected from the client’s list 18

Key exchange methods How the conventional encryption and HMAC keys are exchanged? – actually first pre-master secret is exchanged using public key crypto – master secret is derived from pre-master secret At this point session is created – other keys are derived from the master secret At this point connection is created 19

Key exchange methods – cont’d Rephrase question: how is the pre-master secret exchanged? – RSA server provides its RSA certificate (that has the server’s public key), client encrypts the pre-master secret using server's public key and sends it – Fixed Diffie-Hellman (DH) Server and client DH public keys are fixed and sent in certificates – Ephemeral DH server and client certificates contain RSA or DSS public keys server creates DH parameters (used one-time) and signs by its private key. For client, see later. – Anonymous DH no certificates, no authentication, just send out DH parameters vulnerable to man-in-the-middle-attacks 20

Some Cipher Specs Fields Cipher algorithm and key size – RC4, RC2, DES, 3DES, DES40 (40-bit DES), IDEA, AES, etc. Hash algorithm for HMAC – MD5 or SHA-1 or others Cipher type – stream or block IV size – size of the init. vector for CBC mode 21

Handshake Phase 2: Server Auth. and Key Exchange Certificate is needed except for anon-DH (anon-DH is not used most of the time in anyway) – Certificate is the basis for server authentication – if fixed DH, then certificate contains enough information for key exchange (so server key exchange message is not needed) 22

Handshake Phase 2: Server Auth. and Key Exchange Server Key Exchange – not needed for fixed DH and RSA key exchange – message content depends on the key exchange method agreed Anon-DH – message contains public DH parameters and server’s DH public key Ephemeral DH – same as anon-DH plus a signature on them – Signatures contain random values (that are exchanged in hello phase) to resist against replay attacks 23

Handshake Phase 2: Server Auth. and Key Exchange Certificate Request Message – although not common in practice, server may request client to send its certificate to authenticate the client – two fields: certificate type and acceptable CAs a list of them – Certificate types fixed DH (certificate may be signed with RSA or DSS) signature only – Certificate may contain RSA or DSS key – Used for client authentication (see Phase 3) – Also used for signing ephemeral DH parameters Server Hello Done message – server is finished and will wait for client’s response 24

Handshake Phase 3: Client Auth. and Key Exchange Upon receipt of server hello done – client checks the server certificate and server hello parameters – after that client starts sending its own messages Client’s Certificate – is sent if requested and available 25

Handshake Phase 3: Client Auth. and Key Exchange Client Key exchange message – content depends on the key exchange method agreed – RSA 48-byte pre-master secret is encrypted using server’s RSA key (obtained at phase 2) – fixed-DH client DH parameters are in client certificate, so key exchange message is null – Anon or ephemeral DH Client DH parameters and DH public key are sent no signature even for ephemeral DH – no client authentication and authenticated key exchange so far (only key exchange) 26

Handshake Phase 3: Client Auth. and Key Exchange Certificate Verify message – client is not authenticated via client key exchange message anyone could send the key exchange message – the method for authentication is via the certificate verify message client shows ownership of private key that corresponds to the public key in client certificate by signing a hash that contains the master secret and handshake messages except for fixed DH that does not contain a signature key – what about authentication for fixed DH case? no real authentication but the attacker cannot produce the premaster and master secrets since it does not know the DH private key (so there is a kind of an implied auth.) 27

Handshake Phase 4: Finish At the end of Phase 3, both client and server can calculate keys Phase 4 is wrap-up phase Change cipher spec messages – to make the pending cipher spec the current one 28

Handshake Phase 4: Finish Finished message – a MAC on exchanged handshake messages using the master secret – to verify that handshake is successful and both parties have the same master secret – client’s finished is verified by server and vice versa – the connection state of the record protocol that encrypts and MACs the finished message is the new one so this is also verification of all the keys that are recently created 29

Master Secret Creation Master Secret – 48-byte value generated for a session two stage creation – pre-master secret is exchanged during handshake if RSA, client creates, encrypts and sends; server decrypts if DH, both calculates the same secret which is the premaster secret – master secret is calculated using pre-master secret and random nonces exchanged during handshake by using a PRF (Pseudo Random Function) Several levels of HMACs until 48 bytes have been generated 30

Generation of cryptographic parameters Encryption keys, MAC secrets, IV are to be generated from a key block obtained from the master secret – again using a PRF based on several levels of HMACs master secret is the key random nonces are also used – variable length output, until enough output has been generated. 31

Abbreviated Handshake We have said that a particular TLS session can serve to different TLS connections – Abbreviated handshake is the mechanism for that During phase-1 if both parties agree on using an existing session ID, then that means they run abbreviated handshake – that session’s master secret (which is already stored) and new random nonces exchanged during phase-1 are directly used for the generation of the keys Thus, phase 2 and 3 are skipped (that is why it is abbreviated) Phase 4 is the same as full handshake 32

Heartbeat Protocol Relatively a new extension of TLS – In 2012 (RFC 6250) In the context of computer networks, a heartbeat is a periodic signal or messages to probe the availability of the other party. Heartbeat protocol runs on top of TLS protocol (part of upper layer of TLS) – Simple periodic request-response pairs sent with a random payload (same payload in both request and response) Helps request-response matching if used over UDP, since UDP is connectionless Two purposes of HeartBeat Protocol – Sender assures that the recipient is still alive – Even if the real communication is idle, it generates traffic such that the firewalls, which do not tolerate idle times, do not cause connection closures 33

Attacks on TLS/SSL Mostly based on implementation related bugs – On handshake and record protocols and the use of crypto during these protocol Certificate related attacks – Fake certificates, fake authorities, certificate validation problems Heartbleed attack (2014) – Due to a bug in the implementation of HeartBeat protocol in OpenSSL (open source crypto lib.) The responder is not sending the received payload but a part of memory that the attacker wants – Has been fixed quickly but the propagation of the patch took some time and several websites got affected 34

TLS Versions TLS 1.0, 1.1, 1.2 are not too much different than each other – Same protocol flow that is just explained – Same basic principles – Main changes are related to adding modern cryptographic suites and modes Using new hash algorithms in HMAC and PRF calculations and other places that use hash Authenticated Encryption modes ECC cipher suites (in another RFC) However, TLS 1.3 changed TLS tremendously 35

TLSv1.3 Recently published: RFC 8446 (August 2018) and widely implemented in new versions of web clients and servers. – The working group at IETF started in 2014 and the standard was pretty much matured by 2017. Primary aim is to improve the security of TLS Lots of features changed (including the protocol flow) Significant changes from version1.2 – TLSv1.3 allows for a “1 round trip time” handshake by changing the order of message sent in establishing a secure connection In two messages, keys are generated and server “finished” is sent. Third message is client “finished” and upper layer protocol data. Yields faster handshake 36

TLSv1.3 (cont’d) Significant changes from version1.2 (cont’d) – 0-RTT mode for abbreviated handshake (when there is pre-shared key or by using master secret from previous handshake) 0-RTT means encrypted data is started to be sent together with SSL abbreviated handshake messages. To do so, connection keys are generated using only client’s involvement Has some known security problems (especially vulnerable to some replay attacks) – TLSv1.3 removes support for a number of options and functions; important deleted items are: Compression (actually nobody was using it) Ciphers that do not offer authenticated encryption Static DH key exchange, (static) RSA key exchange Change Cipher Spec Protocol DSS and RC4 support Use of MD5, SHA-1 and SHA-224 hashes with signatures – TLSv1.3 uses Diffie-Hellman or Elleptic Curve Diffie-Hellman for key exchange and does not permit RSA For the sake of Perfect Forward Security (PFS) If an RSA private key is compromised all previous handsakes becomes compromised in RSA key excahnge 37

HTTPS HTTPS (HTTP over TLS) – combination of HTTP & TLS to secure communications between browser & web server documented in RFC2818 Originally it was HTTP over SSL. Actually no fundamental change using either SSL or TLS; both are referred as HTTPS Any TLS version can be used in HTTPS use https:// URL rather than http:// – use port 443 rather than 80 encrypts – URL, document contents, form data, cookies, HTTP headers 38

HTTPS Connection Initiation TLS handshake is first done – HTTP client (browser) acts as TLS client After the handshake HTTP request(s) are sent and then responded by the server – Actually all HTTP data should be sent through TLS record protocol 39

HTTPS Connection Closure connection closure – There exists “Connection: close” item in HTTP headers which normally causes to close the TCP connection but there is TLS protocol between HTTP and TCP and TLS connection should also be closed thus, TLS should control connection closure at TCP level – At TLS level parties exchange close notify alerts – can then close TCP connection 40

Secure Shell (SSH) protocol for secure network communications – designed to be simple & inexpensive SSH1 provided secure remote logon facility – replace TELNET & other insecure schemes – also has more general client/server capability Can be used for FTP, for example SSH2 was documented in RFCs 4250 through 4254 SSH clients & servers are widely available (even in OSs) 41

SSH Protocol Stack Also provides forward secrecy 42

SSH Transport Layer Protocol Server authentication – PKC operation using the host key pair (public/private) – A server may have different host keys – Clients should know the public host keys of the server May keep in a database May obtain in a certificate Or just use it without any guarantee (the mostly used method) but vulnerable to MitM attacks Packet exchange of the protocol – establish TCP connection first – then can exchange data identification string exchange, algorithm negotiation, key exchange, end of key exchange, service request – using specified packet format 43

SSH Transport Layer Protocol Packet Exchanges Identification string exchange – To know which SSH version, which SSH implementation Algorithm Negotiation – For the crypto algorithms (key exchange, encryption, MAC) and compression algo. – A list in the order of preference of the client – For each category, the algorithm chosen is the first algorithm on the client's list that is also supported by the server. 44

SSH Transport Layer Protocol Packet Exchanges key exchange – Only two different Diffie-Hellman based exchange types are defined – Also signed by the server (host private key) – As a result (i) two sides now share a master key K. (ii) the server has been authenticated to the client. Then, encryption, MAC keys and IV are derived from the master key End of key exchange Service Request: to initiate either user authentication or connection protocol Encrypted and MACed – To signal the end of key exchange process – Encrypted and MACed using the new keys 45

SSH Transport Layer Protocol Packet Formation 46

SSH User Authentication Protocol Authentication of client to the server First client and server agree on an authentication method – Then a sequence of exchanges to perform that method – Several authentication methods may be performed one after another authentication methods – public-key Client signs a message and server verifies – password Client sends pasword which is encrypted and MACed using the keys agreed 47

SSH Connection Protocol runs on SSH Transport Layer Protocol assumes secure authentication connection – which is called tunnel used for multiple logical channels – SSH communications use separate channels – either side can open with unique id number – flow controlled via sliding window mechanism – have three stages: opening a channel, data transfer, closing a channel 48

SSH Connection Protocol Exchange 49