Computer Security Heartbleed Bug Tutorial on Creating Certificates SSH Perfect Forward Secrecy Kerberos

OpenSSL “Heartbleed” Bug Announced April, 2014. (But bad code checked in December 31, 2011!) Exploits a programming mistake in the OpenSSL implementation of the TLS “heartbeat hello’’ extension. Heartbeat protocol is used to keep a TLS connection alive without continuously transferring data. One endpoint (e.g., a Web browser) sends a HeartbeatRequest message containing a payload to the other endpoint (e.g. a Web server). The server then sends back a HeartbeatReply message containing the same payload. “Buffer over-read” error caused by a failure to check for an invalid read-length parameter.

From RFC 6520 Heartbeat Request and Response Messages The Heartbeat protocol messages consist of their type and an arbitrary payload and padding. struct { HeartbeatMessageType type; uint16 payload_length; opaque payload[HeartbeatMessage.payload_length]; opaque padding[padding_length]; } HeartbeatMessage; The total length of a HeartbeatMessage MUST NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066]. type: The message type, either heartbeat_request or heartbeat_response. payload_length: The length of the payload. payload: The payload consists of arbitrary content. padding: The padding is random content that MUST be ignored by the receiver. Problem: no check that payload_length matches the actual length of the payload

Illustration From http://www.theregister.co.uk/2014/04/09/heartbleed_explained/

Broken OpenSSL Code struct ssl3_record_st { /* generic struct used to store message */ unsigned int length; /* How many bytes available */ /* ignore */ unsigned int off; /* ignore */ unsigned char *data; /* pointer to the record data */ /* ignore */ … } SSL3_RECORD; /* Read type and payload length first */ hbtype = *p++; /* message type goes in hbtype, p now points to length */ n2s(p, payload); /* copies length into variable payload, adds 2 to p */ pl = p; /* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; /* set type to response */ s2n(payload, bp); /* write payload (length) to memory, add 2 to p */ memcpy(bp, pl, payload);/*copy payload bytes from memory (up to 64K)*/

The Fix hbtype = *p++; n2s(p, payload); if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /* silently discard per RFC 6520 sec. 4 */ pl = p;

Heartbleed Vulnerability Can extract private information stored in the virtual address space of the process, including private keys, p, q, p-1, q-1, d. All Web sites using OpenSSL (e.g., using Apache, nginx servers) should have their certificates revoked, and new certificates issued. Akamai was informed before the bug was announced publicly and released a patch, but (oops!) there was a bug in that too. Akamai patch: move private keys to a “secure heap” area in virtual memory that is not near to the normal heap. Widely agreed to be a catastrophic security failure. Moral: check input data carefully before acting!

Acting as Your own Certificate Authority (CA) 1. a. Create public/private root keys for CA b. Create self-signed root certificate 2. a. Create public/private intermediate keys b. Create intermediate certificate signing request (CSR) c. Sign intermediate certificate 3. a. Create public/private key for domain www.example.com b. Create CSR for domain c. Sign certificate for domain using intermediate private key Might do this when setting up secure web sites within a corporate intranet. CPS 290

Create Files and Directories index.txt stores database of certificates created serial holds serial number of next certificate CPS 290

Create Configuration File Strict policy requires organization names in parent and child certificates to match, e.g., when used in intranet. CPS 290

Create Root Public/Private Keys Private key is encrypted using pass phrase as key to AES256 algorithm. CPS 290

Create Root Certificate -x509 indicates self-signed certificate sha256 algorithm used to create message digest (hash) of certificate, which is then (self) signed CPS 290

Examine the Root Certificate who signed it CPS 290

redundant to specify Signature Algorithm again signed hash of everything above CPS 290

CPS 290

Create Public/Private Intermediate Keys CPS 290

Create Intermediate CSR sha256 digest (hash) of applicant information signed with root private key – can check that it can be decoded with root public key CPS 290

Sign Intermediate Certificate CPS 290

Examine Signed Intermediate Certificate CPS 290

CPS 290

CPS 290

Verify Signed Certificate Using Root Certificate After signing the intermediate certificate, hide the root certificate’s private key somewhere very secure (e.g., off-line). Use intermediate certificate with short validity period to sign other certificates. CPS 290

Technologies for Protecting Private Keys 1) Hardware device that performs cryptographic operations for the processor. Private key cannot be read from the device. 2) Secure multiparty computation: multiple servers must collaborate to perform cryptographic operations. No one server can learn anything about the private key unless all collude. CPS 290

Create Public/Private Keys for Domain CPS 290

Create CSR for Domain www.example.com CPS 290

Sign Certificate for Domain CPS 290

SSH Applications Secure Shell (SSH): Replacement for insecure telnet, rlogin, rsh, rexec, which sent plaintext passwords over the network!

SSH Applications Port forwarding (email example): Log in to linux.cs.duke.edu. Forward anything received locally (phoenix) on port 25 to linux.cs.duke.edu on port25. Useful if “phoenix” is not a trusted email relayer but “linux” is. “phoenix” email program configured to use localhost as relayer

SSH v2 Authentication Server has a permanent “host” public-private key pair (RSA or DSA) . Public key typically NOT signed by a certificate authority. Client warns if public host key changes. User can authenticate by sending password to server or using a public-private key pair. User’s private key has optional passphrase. If so, the private key is encrypted using the passphrase as an AES encryption key and stored on the client’s machine. If using keys, client signs a block of data including session ID, user name, and user’s public key with user’s private key; server authenticates with user’s public key. Advantage of using public/private key authentication: if server is compromised, only client’s public key is compromised.

Diffie-Hellman Key Exchange A group (G,*) and a primitive element (generator) g is made public. Alice picks a random a, and sends ga mod p to Bob Bob picks a random b and sends gb mod p to Alice Both compute the shared key gab mod p Note this is easy for Alice or Bob to compute, but assuming discrete logs are hard is hard for anyone else to compute.

SSH v2 Session Encryption Diffie-Hellman is used to exchange session key. Server selects g and p (group size) and sends to client. Client and server create DH private keys a and b. Client sends public DH key ga. Server sends public DH key gb and signs hash of DH shared secret gab and 12 other values with its private “host” key. Client verifies signed shared secret using public key. Symmetric encryption using 3DES, Blowfish, AES, or Arcfour begins. CPS 290

Why Combine RSA and Diffie-Hellman? Why doesn’t the client just send a symmetric key to the server, encrypted with the server’s public key? Because if the server’s private key is later compromised, previous communications encrypted with the public key can be decrypted, revealing the symmetric key. Then all communications encrypted with the symmetric key can also be decrypted! To prevent this attack, Diffie-Hellman ensures that the symmetric key is never transmitted, even in encrypted form, and the client and server discard the symmetric key gab after the session is over. RSA is used for authentication to prevent the man-in-the-middle attack. SSL/TLS provides this option too: DHE_RSA key exchange “Perfect forward secrecy”

Kerberos A key-serving system based on Private-Keys (DES). Assumptions Built on top of TCP/IP networks Many “clients” (typically users, but perhaps software) Many “servers” (e.g. file servers, compute servers, print servers, …) User machines and servers are potentially insecure without compromising the whole system A kerberos server must be secure. CPS 290

Ticket Granting Server Kerberos (kinit) Kerberos Authentication Server Ticket Granting Server (TGS) 2 1 3 4 Service Server (S) Client (C) 5 Request ticket-granting-ticket (TGT) <TGT> Request server-ticket (ST) <ST> Request service CPS 290

Kerberos V Message Formats C = client S = server K = key or session key T = timestamp V = time range TGS = Ticket Granting Service A = Net Address Ticket Granting Ticket: TC,TGS = TGS,{C,A,V,KC,TGS}KTGS Server Ticket: TC,S = S, {C,A,V,KC,S}KS Authenticator: AC,TGS = {C,T}KC,TGS Authenticator: AC,S = {C,T}KC,S Client to Kerberos: C,TGS Kerberos to Client: {KC,TGS}KC, TC,TGS Client to TGS: TC,TGS , S, AC,TGS TGS to Client: {KC,S}KC,TGS, TC,S Client to Server: AC,S, TC,S Possibly repeat CPS 290

Kerberos Notes All machines have to have synchronized clocks Must not be able to reuse authenticators Servers should store all previous and valid tickets Help prevent replays Client keys are typically a one-way hash of the client’s password + salt. Clients do not store these keys. Kerberos 5 uses cipher block chaining (CBC) for encryption - Kerberos 4 was insecure in part because it used a nonstandard propagating CBC (PCPC) CPS 290