1 / 15

Computer Security

Computer Security. Heartbleed Bug Key Exchange SSH Perfect Forward Secrecy. 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.

wrhodes
Télécharger la présentation

Computer Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Computer Security Heartbleed Bug Key Exchange SSH Perfect Forward Secrecy

  2. 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.

  3. 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

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

  5. 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)*/

  6. 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;

  7. Heartbleed Vulnerability • RSA private keys p, q, p-1, q-1, d can be extracted by the attacker, as can anything else in the right portion of the virtual address space of the process, such as passwords. • 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 an area in physical memory that never has virtual memory mapped to it. • Widely agreed to be a catastrophic security failure. • Moral: check input data carefully before acting!

  8. 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

  9. 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. • Can someone see a problem with this protocol?

  10. ga • gc • Alice • Mallory • Bob • gd • gb • Key1 = gad • Key1 = gcb Person-in-the-middle attack • Mallory gets to listen to everything.

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

  12. 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 phoenix as relayer

  13. 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.

  14. 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

  15. 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”

More Related