EEC 688/788 Secure and Dependable Computing

EEC 688/788 Secure and Dependable Computing
Lecture 5 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University

Outline Reminder: Secure communication protocols
Lab on secure shell: Monday 9/23 Lab on secure computing in Java: Wed 9/25 Secure communication protocols Application level protocols: SSH, Kerberos, PGP, S/MIME Transport level protocols: SSL/TLS Network level protocols: IPsec

EEC688/788: Secure & Dependable Computing
SSH: Secure Shell SSH, the Secure Shell, 2nd Edition By Daniel J. Barrett, Robert G. Byrnes, Richard E. Silverman 4/24/2017 EEC688/788: Secure & Dependable Computing

Secure Shell Overview Secure Shell (SSH) is a secure remote virtual terminal application Provides encrypted communication between untrusted hosts over an insecure network Intended to replace insecure programs such as rlogin, rsh, etc. Includes capability to securely transfer file such as scp sftp Includes ability to forward X11 connections and TCP ports securely Two versions: SSH1 and SSH2 Assumes eavesdroppers can hear all communications between hosts Provides different methods of authentication Encrypts data exchanged between hosts 4/24/2017 EEC688/788: Secure & Dependable Computing

Architecture of an SSH System
4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Transport Protocol
SSH Protocol Suite Application software (e.g., ssh, sshd, scp, sftp, sftp-server) SSH Authentication Protocol Client authentication publickey password … SSH Connection Protocol Channel multiplexing Pseudo-terminals TCP port and X forwarding Authentication agent forwarding SSH File Transfer Protocol Remote filesystem access File transfer SSH Transport Protocol Algorithm negotiation Session key exchange Session id Sever authentication Privacy, integrity, data compression TCP 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Transport Layer Protocol
Provides server authentication, confidentiality, and integrity services It may also provide compression Runs on top of any reliable transport layer (e.g., TCP) All packets that follow the version string exchange is sent using the Binary Packet Protocol Client Server TCP connection setup SSH version string exchange SSH key exchange (includes algorithm negotiation) SSH data exchange termination of the TCP connection 4/24/2017 EEC688/788: Secure & Dependable Computing

Binary Packet Protocol
packet length: length of the packet not including the MAC and the packet length field padding length: length of padding payload: might be compressed max uncompressed payload size is 32768 random padding: 4 – 255 bytes total length of packet not including the MAC must be multiple of max(8, cipher block size) MAC: message authentication code MAC(key, sequence_number || unencrypted_packet) packet length (4) padding length (1) payload (may be compressed) total length of packet not including the MAC must be multiple of max(8, cipher block size) even if a stream cipher is used Sequence number is used to guard against replay attack random padding MAC 4/24/2017 EEC688/788: Secure & Dependable Computing

Supported Algorithms Encryption: 3DES, Blowfish, Twofish, AES, Serpent, IDEA, CAST in CBC Arcfour (“believed” to be compatible with the “unpublished” RC4) none (not recommended) Integrity: HMAC with MD5 or SHA-1, none (not recommended) Key exchange: Diffie-Hellman with SHA-1 Public key: RSA, DSS (digital signature standard) Compression: none, zlib 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Key Exchange Diffie-Hellman public key exchange algorithm must be supported by all SSH2 implementation Public key exchange algorithm: provides a shared secret between two parties over an insecure link without sharing any prior secret SSH key exchange algorithm has two outputs: A shared secret K: can not be determined by either party alone An exchange hash H: It should be unique to each session, and computed in such a way that neither side can force a particular value of hash 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Key Exchange Client Server I_C (KEXINIT) V_S: Server’s version string V_C: Client’s version string I_S (KEXINIT) Generate x (1 < x < (p-1)/2) and compute e = gx mod p min || n || max p || g Compute: f = gy mod p K = ey mod p H = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || p || g ||e || f || K) Proceed to the next two slides, then come back here when discussion the man-in-the-middle-attack The key to prevent “man-in-the-middle” attack is the use of public host key K_S Trudy can’t use her public host key, because it will expose her identity Trudy can’t use the server’s public host key, because she can’t produce the signature min || n || max: (minimal acceptable, preferred, maximal acceptable) group size in bits the client will accept p: server choose a group size within the proposed bound K_S: Server’s public host key I_C: Client’s KEXINIT message I_S: Server’s KEXINIT message KEXINIT messages have been exchanged during algorithm negotiation e Verifies that KS really is host key KS || f || s K = fx mod p H = hash(V_C || V_S || … ) and verifies the signature s on H s = signature on H with its private host key 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Key Exchange min || n || max: (minimal acceptable, preferred, maximal acceptable) group size in bits the client will accept V_S: Server’s version string V_C: Client’s version string KS: Server’s public host key I_C: Client’s KEXINIT message I_S: Server’s KEXINIT message 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Key Exchange Claim: SSH Key Exchange does not suffer from “man-in-the-middle” attack The goal of a “man in the middle” attack is to gain access to confidential information Naive key exchange suffers from this attack Intruder can establish secrete key with both Alice and Bob Not so for SSH key exchange What if Trudy simply pass msg #1 to Bob? – She won’t know x picked by Alice 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Key Exchange Key exchange ends by each side sending an SSH_MSG_NEWKEYS message This message is sent with the old keys and algorithms. All messages sent after this message MUST use the new keys and algorithms When this message is received, the new keys and algorithms MUST be taken into use for receiving 4/24/2017 EEC688/788: Secure & Dependable Computing

Output from Key Exchange
The key exchange produces two values: A shared secret K, and An exchange hash H Session identifier: the exchange hash H from the first key exchange Once computed, the session identifier is not changed, even if keys are later re-exchanged 4/24/2017 EEC688/788: Secure & Dependable Computing

Output from Key Exchange
Encryption keys are computed as HASH of a known value and K as follows: Initial IV client to server: HASH(K || H || "A" || session_id) Initial IV server to client: HASH(K || H || "B" || session_id) Encryption key client to server: HASH(K || H || "C" || session_id) Encryption key server to client: HASH(K || H || "D" || session_id) Integrity key client to server: HASH(K || H || "E" || session_id) Integrity key server to client: HASH(K || H || "F" || session_id) Recall the guideline for good authentication protocols? Different keys are used to encrypt traffic from different direction 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Server Authentication
Based on the server’s public host key KS The client must check that KS is really the host key of the server Client has a local database that associates each host name with the corresponding public host key The host name – key association can be certified by a trusted CA and the server provides the necessary certificates or the client obtains them from elsewhere Common practice Accept host key without check when connecting the first time to the server, and save the host key in the local database Check against the saved key on all future connections to the same server 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Authentication Protocol
The protocol assumes that the underlying transport protocol provides integrity and confidentiality (e.g., SSH Transport Layer Protocol) The protocol has access to the session ID Three authentication methods are supported publickey password hostbased Key exchange: client authenticates the server Now it is turn for the server to authenticate the client 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Authentication Protocol
Client Server Userauth_request Userauth_request: username, service, “publickey", Public key alg name Public key signature signature is: session identifier, Userauth_request encrypted with private key Userauth_success or failure request service if userauth_success Server checks whether the supplied key is acceptable for authentication, and if so, it checks whether the signature is correct 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Connection Protocol
Multiplexes the secure tunnel provided by the SSH Transport Layer and User Authentication Protocols into several logical channels These logical channels can be used for a wide range of purposes Secure interactive shell sessions Remote execution of commands Forwarded TCP/IP connections Forwarded X11 connections 4/24/2017 EEC688/788: Secure & Dependable Computing

A Debugging Run of SSH <=TCP connection setup
bash-3.00$ ssh -v -l wenbing dcs.csuohio.edu OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 debug1: Connecting to dcs.csuohio.edu [ ] port 22. debug1: Connection established. debug1: identity file /home/wenbing/.ssh/identity type -1 debug1: identity file /home/wenbing/.ssh/id_rsa type 1 debug1: identity file /home/wenbing/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.1 debug1: match: OpenSSH_4.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received <=TCP connection setup <= SSH version string exchange <= start of key exchange 4/24/2017 EEC688/788: Secure & Dependable Computing

A Debugging Run of SSH <= algorithm negotiation
debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'dcs.csuohio.edu' is known and matches the RSA host key. debug1: Found key in /home/wenbing/.ssh/known_hosts:2 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received <= DH key exchange <= server authentication <= end of key exchange 4/24/2017 EEC688/788: Secure & Dependable Computing

A Debugging Run of SSH <= client authentication (publickey)
debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/wenbing/.ssh/identity debug1: Offering public key: /home/wenbing/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. Last login: Fri Feb 3 02:00: from adsl dsl.bcvloh.ameritech.net Have a lot of fun... Directory: /home/wenbing <= client authentication (publickey) <= requesting an interactive session 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH in Practice - Basic Use
ssh ssh_server_name ssh –l user_name ssh_server_name ssh ssh_server_name command_to_run ssh –v ssh_server_name The normal terminal use on the first line will open a connection from your machine to the SSH Server. The two ends will exchange identification information (so both know that the other has not been compromised or replaced). At that point, you need to authenticate yourself. The easy way is with a password, but we’ll look at how to use ssh keys and the advantages of doing so. The password you’ll use is the exact same password you’ve been using with telnet in the past; ssh understands how passwords are stored in /etc/shadow * Instead of starting up a terminal session as the first two examples, one can specify a single remote command to run on the remote machine as in the third example. In the last example, the “-v” instructs the local ssh client to be verbose about the login process. Each time you first connect to an SSH server, it will send back its Host Key. At the first connection, you’ll be asked to verify that the the key received is in fact from the host to which you wanted to connect; you can check this by comparing the key to the one stored in the server’s /etc/ssh directory. In future connections, the key received will be compared to the one stored on the client during the first connection; if they differ, ssh will complain loudly because some machine might be impersonating the machine to which you wanted to connect. * You have converted your system over to using shadow passwords, right? To check, does the /etc/passwd contain “:x:” immediately after each username? If not, look at “man pwconv” man page and see for background information. 4/24/2017 EEC688/788: Secure & Dependable Computing

Securely Copying Files
scp scp localfile Can use –r option to recursively copy entire directory Can use –p option to preserve modification and access time Prompts for authentication if needed All traffic encrypted: replaces ftp, rcp The local and remote file specifications are of the form If you're including wildcards, you should include the block in quotes, such as: scp –p /home/wstearns/mailtransfer/ In this example, we're copying all the mail files from the mail machine to the mailtransfer directory on the local machine. If omitted, user, machine, and directory default to local username, local machine, and current directory, respectively. The "-p" preserves ownership and permissions. By specifying remote machines for both the source and destination, files can be copied between two remote machines. 4/24/2017 EEC688/788: Secure & Dependable Computing

Securely Copying Files
sftp: ftp on ssh Multiple commands for file copying and manipulation can be invoked within a single sftp session, whereas scp opens a new session each time it is invoked 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Public Key Based Authentication
Password-based authentication: password stored on server, user supplied password compared to stored version Public key based authentication: private key kept on client, public key stored on server If an attacker gets the public key stored on the server, that public key cannot be used to get back into the server The serious problem with the password approach, whether used with telnet or with ssh, is that the password you need to enter at the client end is stored on the server. Even though it’s stored in an encoded form in /etc/passwd or /etc/shadow, this password can be cracked with brute force once one has access to that file. The difference with the public/private key split is that if an attacker gets the public key stored on the server, that public key cannot be used to get back into the server! Only the private key, kept on the client only, can be used to get into a server with the public key. 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Key Creation General command: ssh-keygen –t rsa –b 1024 –f ~/.ssh/id_rsa Assign a hard-to-guess passphrase to the private key during creation Key can be used for multiple servers To install the public key on the server, transfer the key to the server (using scp or sftp) and add the key entry in the ~/.ssh/authorized_keys file From now on, if you want to connect to the server using ssh/scp/sftp, you will be prompted for the passphrase, instead of password What’s the benefit for using a passphrase w.r.t. password? “man ssh-keygen” will give you the exact syntax for the version of SSH on your machine. Running this command will create two files: ~/.ssh/identity_file (the private key) and ~/.ssh/indentity_file.pub (the public file). The private file is an unreadable binary file; this one should never leave your control. ~/.ssh/identity_file.pub is the public key that needs to be copied over to each server you want to access. The passphrase is a long phrase with lots of varied characters. It’s like a password, but longer and with more strange characters. It encrypts the private key before storing it on the disk; this makes the file useless to someone who manages to steal it from your disk unless they also know the passphrase. If you’re worried that we’ve traded short passwords for a lot of complexity and long passphrases, don’t worry! We’ll see that ssh-agent can let us enter the passphrase once and remember the private key. Also, by putting the public key on many machines, the one private key can give us access to lots of remote machines. 4/24/2017 EEC688/788: Secure & Dependable Computing

Port Forwarding – Real Server On Remote Machine
I want to listen on port 6666 on this machine; all packets arriving here get sent to proxyserver, port 8888: ssh –L 6666:proxyserver:8888 proxyserver Can be used to tunnel insecure services in a secure manner The “-L” is a shorthand for listen for connections on Local (on this client computer) port (in this example 5110), and when you hear one, send all its packets to the remote machine (mailserver) and feed them into port 110 on mailserver. The above example would be a great way to encrypt the pop download from a remote mail server. Before pressing “Get New Mail”, one starts up the above ssh command. The ssh terminal will sit at a prompt, waiting for a command – let it sit. In the mail software, tell it that your pop mail server is on the machine “localhost” and is listening on port When you press “Get New Mail”, the mail server will talk to port 5110 on the local box. The ssh software, told to listen there, will take all the pop mail requests, encrypt them, and carry them to port 110 on the real mail server. Likewise, it will bring back all the pop responses – your mail messages -, encrypt them, and carry them back to your local mail software. Your mail server doesn’t need to know anything about encryption at all. You can have multiple port forwards on one command line, such as: ssh –L 5110:mailserver:110 –L 5143:mailserver:143 –L 5025:mailserver:25 mailserver , allowing you to transparently encrypt any and all traffic heading to the pop, imap, or smtp mail services on mailserver. As soon as you close the ssh session, the port forwarding stops and you need to connect to the mail server directly as you’ve done in the past. 4/24/2017 EEC688/788: Secure & Dependable Computing

SSH Port Forwarding Client Host SSH Client Client App Server Host SSH Server Server App Port 22 open Port 8888 Port 6666 Client thinks the server is running at localhost and listening at port 6666 Clear msg Encrypted msg 4/24/2017 EEC688/788: Secure & Dependable Computing

Port Forwarding – Real Server On This Machine
All web traffic to my firewall should be redirected to the web server running on port 8000 on my machine instead: ssh –R 80:MyMachine:8080 firewall The “-R” is a shorthand for listen for connections on Remote (on the ssh server computer) port (in this example 80), and when you hear one, pull all its packets back to the local machine (MyMachine) and feed them into port 8000 on MyMachine. The crucial difference here is the fact that ssh listens on the remote machine for incoming tcp connections and carries them back to a server on the local machine. The server that will actually handle the requests needs to be running on the local machine. Please note that port forwarding in ssh only works for TCP ports; that’s why we don’t need to specify a protocol on the command line. If you want to do port forwarding for UDP, you’ll need to look at Network Address Translation (NAT) facilities in the Linux kernel or use a UDP proxy. Remember that that approach loses the encryption that SSH gives for free for TCP. 4/24/2017 EEC688/788: Secure & Dependable Computing

X Windows forwarding ssh –X ssh_server_name Note the uppercase X No need to manually setup the DISPLAY Run the X Windows application in the terminal window. For example, xclock & The screen display shows up on your computer, and any keystrokes and mouse movements are sent back, all encrypted With this arrangement, the application is actually exectuing its instructions on the remote machine’s processor, using the remote machine’s memory, and interacting with the remote machine’s disk; only the keystrokes and mouse movemenents come from the local machine, and all the X screen output comes back to the local machine’s display. This setup is the exact graphical equivalent of running text applications inside the ssh terminal. Because X Windows apps were designed from the start to handle this split between the machine running the code and the machine showing the display, this SSH X Forwarding works even between machines with different processors and Operating Systems. By the way, if this doesn’t work, check for the following message at login time: Warning: Remote host denied X11 forwarding. If you see this, it means that the ssh server configuration file (usually something like /etc/ssh{2}/sshd_config has a line such as X11Forwarding No 4/24/2017 EEC688/788: Secure & Dependable Computing

ssh-agent Other applications can ask ssh-agent to authenticate you automatically Start ssh-agent shell: > ssh-agent bash Add your private key to the agent: > ssh-add You will be prompt for the passphrase If you now ssh to another host, you will not prompt for passphrase until you remove the private key To remove your private key: > ssh-add –d To exit ssh-agent shell > exit ssh-agent has a weird quirk; it needs to start up as a background daemon, but it also needs to tell the applications that need to use it where to ask for keys. It does this by setting environment variables, so it has to start up a shell or X windows. Any applications you start inside that shell or X Windows session can then ask ssh-agent to provide them with an ssh key. In some X Windows setups, one can add the following lines to ~/.xsession to automatically start ssh-agent: eval `ssh-agent` ssh-add When ssh-agent starts up, it doesn’t have any keys in memory; the ssh-add command asks you for the passphrase for a given key, then hands the unlocked key to ssh-agent so it can later hand it out to future ssh sessions. For reference, SSH supports agent forwarding, where you can ssh to Machine1, logging in with a key provided by your client’s ssh-agent, and ssh from Machine1 to Machine2, and have the ssh-agent request sent back to your original client’s ssh-agent as well. This allows you to keep the private key only on the local machine, but jump from machine to machine without having to start fresh sessions directly from the client machine. 4/24/2017 EEC688/788: Secure & Dependable Computing

SSL: The Secure Sockets Layer
SSL (Secure Sockets Layer): a security package for secure communication over Internet Introduced in 1995, Netscape Communications Corp SSL builds a secure connection between two sockets, including Parameter negotiation between client and server Mutual authentication of client and server Secret communication Data integrity protection 4/24/2017 EEC688/788: Secure & Dependable Computing

Secure Sockets Layer Documentation
The SSL Protocol version 3.0 Internet Draft: The TLS Protocol version 1.0 Internet Draft: "HTTP Over TLS" Information RFC: SSL and TLS: Designing and Building Secure Systems by Eric Rescorla. Addison Wesley Professional, 2000 Analysis of the SSL 3.0 Protocol, by David Wagner and Bruce Schneier, 4/24/2017 EEC688/788: Secure & Dependable Computing

HTTPS (Secure HTTP): HTTP over SSL Sometimes it is available at a new port (443) instead of the standard port (80) Layers (and protocols) for home user using HTTPS 4/24/2017 EEC688/788: Secure & Dependable Computing

SSL consists of two main subprotocols: handshake protocol record protocol SSL supports multiple cryptographic algorithms The strongest one uses triple DES with three separate keys for encryption and SHA-1 for message integrity For ordinary e-commerce applications, RC4 is used with a 128-bit key for encryption and MD5 is used for message authentication 4/24/2017 EEC688/788: Secure & Dependable Computing

Application software Application Data SSL Handshake Protocol SSL Change Cipher Spec Protocol SSL Alert Protocol SSL Record Layer Protocol TCP 4/24/2017 EEC688/788: Secure & Dependable Computing

SSL Handshake Protocol
ClientKeyEx Here we assume the RSA is used for authentication and key agreement Client and server negotiating a common ciphersuite acceptable to both parties, exchanging random nonces, and the client sending an encrypted pre master secret. Then each endpoint derives a master secret from the pre master secret and verifies that their protocol runs match by authenticating all messages with the master secret. Assuming that the check succeeds, both generate session keys from the master secret and proceed to send cryptographically-protected application data 4/24/2017 EEC688/788: Secure & Dependable Computing

Message #1: Client hello SSL version; Random structure (timestamp and nonce); Session id; CipherSuites; Compression methods Message #2: Server hello SSL version*; Random structure (timestamp and nonce); Session id; CipherSuite*; Compression method* * selection based on client’s preference by the server 4/24/2017 EEC688/788: Secure & Dependable Computing

Message #3: Server certificate (server key exchange message would be sent if there is no certificate) Message #4: Server hello done To indicate the end of the server hello and associated messages 4/24/2017 EEC688/788: Secure & Dependable Computing

Message #5: ClientKeyExchange - RSA encrypted premaster secret message 48-byte long (version number and random bytes), encrypted using server’s public key 4/24/2017 EEC688/788: Secure & Dependable Computing

Message #6&8: Change cipher spec Sent by both client and server to notify receiving party that subsequent records will be protected under the new CipherSpec and keys The client sends a change cipher spec message following handshake key exchange and certificate verify messages (if any) The server sends one after successfully processing the key exchange message it received from the client a handshake protocol execution can also happen to change cryptographic parameters on a connection that already has some protection in effect 4/24/2017 EEC688/788: Secure & Dependable Computing

The Change cipher spec message is an independent SSL Protocol content type, and is not actually an SSL handshake message This is designed as a performance improvement This message cannot be combined with the finished message (change cipher spec is unencrypted [or encrypted using the previous session key] and the finished message is encrypted using the new session key) a handshake protocol execution can also happen to change cryptographic parameters on a connection that already has some protection in effect 4/24/2017 EEC688/788: Secure & Dependable Computing

Message #7&9: Finished Sent immediately after a change cipher specs msg The finished message is the first protected with the just-negotiated algorithms, keys, and secrets No acknowledgment of the finished message is required; parties may begin sending confidential data immediately after sending the finished message 4/24/2017 EEC688/788: Secure & Dependable Computing

SSL Handshake Protocol Output
Client Random Pre-master Secret Server Random Master Secret Key Block Client MAC Server MAC Client Write Server Write Client IV Server IV 4/24/2017 EEC688/788: Secure & Dependable Computing

Master secret: computed based on the premaster secret and the nonces proposed by the client and the server master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('BB' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('CCC' + pre_master_secret + ClientHello.random + ServerHello.random)); Session keys, MAC secrets, and IVs: the master secret is used as an entropy source, and the random values provide unencrypted salt material and IVs for exportable ciphers 4/24/2017 EEC688/788: Secure & Dependable Computing

To generate the key material, compute key_block = MD5(master_secret + SHA('A' + master_secret + ServerHello.random + ClientHello.random)) + MD5(master_secret + SHA('BB' + master_secret + ServerHello.random + ClientHello.random)) + MD5(master_secret + SHA('CCC' + master_secret + ServerHello.random + ClientHello.random)) + [...]; until enough output has been generated SSL3.0 way of computation, not TLS 4/24/2017 EEC688/788: Secure & Dependable Computing

Then the key_block is partitioned as follows: client_write_MAC_secret[CipherSpec.hash_size] server_write_MAC_secret[CipherSpec.hash_size] client_write_key[CipherSpec.key_material] server_write_key[CipherSPec.key_material] client_write_IV[CipherSpec.IV_size] /* non-export ciphers */ server_write_IV[CipherSpec.IV_size] /* non-export ciphers */ SSL3.0 way of computation, not TLS 4/24/2017 EEC688/788: Secure & Dependable Computing

SSL Record Protocol <= 16 KB each Transmissions also include a sequence number so that missing, altered, or extra messages are detectable. Why? MAC = hash(MAC_write_secret + pad_ hash(MAC_write_secret + pad_1 + seq_num length + content)); 4/24/2017 EEC688/788: Secure & Dependable Computing

SSL and TLS In 1996, Netscape Communications Corp. turned SSL over to IETF for standardization. The result was TLS (Transport Layer Security) It is described in RFC 2246 The changes made to SSL were relatively small, but just enough that SSL version 3 and TLS cannot interoperate The TLS version is also known as SSL version 3.1 4/24/2017 EEC688/788: Secure & Dependable Computing

OpenSSL Hearblead Bug (From: http://heartbleed.com/)
The bug is reported in It exists in the popular OpenSSL library The Heartbleed bug allows anyone on the Internet to read the memory of the systems using the vulnerable versions of the OpenSSL It compromises the private keys used for server’s X.509 certificates, user names and passwords, and the actual content communicated Bug is in the OpenSSL's implementation of the TLS heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server

EEC 688/788 Secure and Dependable Computing

Similar presentations

Presentation on theme: "EEC 688/788 Secure and Dependable Computing"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

EEC 688/788 Secure and Dependable Computing

Similar presentations

Presentation on theme: "EEC 688/788 Secure and Dependable Computing"— Presentation transcript:

Similar presentations

About project

Feedback