460 likes | 829 Views
IE MS5710 Transport Level Security. 12 March 20 13 Prof. CHAN Yuen-Yan, Rosanna Department of Information Engineering The Chinese University of Hong Kong. Web Security. Web now widely used by business, government, individuals but Internet & Web are vulnerable have a variety of threats
E N D
IEMS5710Transport Level Security 12 March 2013 Prof. CHAN Yuen-Yan, Rosanna Department of Information Engineering The Chinese University of Hong Kong
Web Security Web now widely used by business, government, individuals but Internet & Web are vulnerable have a variety of threats integrity confidentiality denial of service authentication need added security mechanisms IEMS5710 - Lecture 8
Threats, Security Requirements, and Countermeasures • Network Security Threats • Eavesdropping, man-in-the-middle, client and server imposters • Denial of Service attacks • Viruses, worms, and other malicious code • Network Security Requirements • Privacy, Integrity, Authentication, Non-Repudiation, Availability • Countermeasures • Communication channel security • Border security IEMS5710 - Lecture 8
Eavesdropping • Information transmitted over network can be observed and recorded by eavesdroppers (using a packet sniffer) • Information can be replayed in attempts to access server • Requirements: privacy, authentication, non-repudiation replay Request Server Client Response IEMS5710 - Lecture 8
Client Imposter • Imposters attempt to gain unauthorized access to server • Ex. bank account or database of personal records • For example, in IP spoofing imposter sends packets with false source IP address Server Client Imposter IEMS5710 - Lecture 8
Server Imposter Client Server Imposter • An imposter impersonates a legitimate server to gain sensitive information from a client • E.g. bank account number and associated user password IEMS5710 - Lecture 8
Man-in-the-Middle Attack • An imposter manages to place itself as man in the middle • convincing the server that it is legitimate client • convincing legitimate client that it is legitimate server • gathering sensitive information and possibly hijacking session Man in the middle Client Server IEMS5710 - Lecture 8
Web Traffic Security Approaches IEMS5710 - Lecture 8
Bob Alice Authentication using Public Key Cryptography • Transmitter identifies itself • Verifier (Bob) sends a nonce (number used only once) encoded using the sender’s public key in a challenge message • Prover (Alice) uses its private key to recover the nonce, and it returns the unencrypted nonce • Only the holder of the private key can find the nonce Alice to Bob, “let’s talk” EK1(r) r IEMS5710 - Lecture 8
Cryptographic Checksums and Hashes CrytoChk Message Message • Transmitter calculates a fixed number of bits (crypto checksum/hash) that depends on secret key K: HK(P) • Receiver recalculates hash from received message & compares to received hash P P Crypto Checksum Calculator HK(P) K IEMS5710 - Lecture 8
SSL (Secure Socket Layer) Provide authentication, confidentiality, and integrity transport layer security service originally developed by Netscape version 3 designed with public input subsequently became Internet standard known as TLS (Transport Layer Security) uses TCP to provide a reliable end-to-end service SSL has two layers of protocols IEMS5710 - Lecture 8
SSL/TLS • Secure Sockets Layer (SSL) developed by Netscape Communications • Operates on top of TCP • Provides secure connections • HTTP, FTP, telnet, … • Electronic ordering & payment; e-mail • SSL 3.0 submitted to IETF for standardization • TLS standardized by IETF (RFC 2246) • Slight differences with SSL 3.0 IEMS5710 - Lecture 8
SSL Architecture IEMS5710 - Lecture 8
SSL – Cipher Suite List IEMS5710 - Lecture 8
SSL – Cryptographic Secrets • SSL needs six cryptographic secrets • Client authentication key • Server authentication key • Client encryption key • Server encryption key • Client initiation vector • Server initiation vector • SSL requires that the keys for one direction (e.g. client server) be different from those for the other direction (e.g. server client) • If there is an attack in one direction, the other direction is not affected • These parameters are generated by using a negotiation protocol IEMS5710 - Lecture 8
SSL – Cryptographic Secrets • The client and server exchange two random numbers • The client and server exchange one premaster secret by using the key exchange algorithm • A 48-byte master secret is created from a hash of the premaster secret • The master secret is then being used to create variable-length secrets The six cryptographic secrets IEMS5710 - Lecture 8
SSL – Sessions and Connections • There are two levels of connectivity: session and connection • A session lasts longer than a connection • An SSL connection can be established and broken several times during a session • Some security parameters are created during the session establishment and are in effect until the session is terminated • E.g. the cipher suite and master key • Some are created for each connection • E.g. the six secrets IEMS5710 - Lecture 8
SSL – Four Protocols • SSL defines four protocols in two layers • The Record Protocol is the carrier, which carries messages from three other protocols as well as the data coming from the application layer • The Handshake Protocol is the core protocol (describe next) • The ChangeCipherSpec Protocol is used for signaling the readiness of cryptographic secrets • The Alert Protocol is used to report abnormal conditions IEMS5710 - Lecture 8
SSL Record Protocol Services confidentiality using symmetric encryption with a shared secret key defined by Handshake Protocol AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128 message is compressed before encryption message integrity using a MAC with shared secret key similar to HMAC but with different padding IEMS5710 - Lecture 8
SSL Record Protocol Operation IEMS5710 - Lecture 8
SSL Change Cipher Spec Protocol The ChangeCipherSpec Protocol is used for signaling the readiness of cryptographic secrets a single message causes pending state to become current hence updating the cipher suite in use IEMS5710 - Lecture 8
SSL Alert Protocol The Alert Protocol is used to report abnormal conditions conveys SSL-related alerts to peer entity severity warning or fatal specific alert fatal: unexpected message, bad record mac, decompression failure, handshake failure, illegal parameter warning: close notify, no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired, certificate unknown compressed & encrypted like all SSL data IEMS5710 - Lecture 8
SSL Handshake Protocol • The SSL Handshake Protocol is responsible for: • Provides security parameters for the Record Protocol • Establishes a cipher set • Provides keys and security parameters • Authenticates the server to the client (for SSL with client-authentication: authenticate the client to the server) IEMS5710 - Lecture 8
SSL Handshake Protocol allows server & client to: authenticate each other to negotiate encryption & MAC algorithms to negotiate cryptographic keys to be used comprises a series of messages in phases Establish Security Capabilities Server Authentication and Key Exchange Client Authentication and Key Exchange Finish IEMS5710 - Lecture 8
SSL Handshake Protocol IEMS5710 - Lecture 8
Cryptographic Computations IEMS5710 - Lecture 8 • master secret creation • a one-time 48-byte value • generated using secure key exchange (RSA / Diffie-Hellman) and then hashing info • generation of cryptographic parameters • client write MAC secret, a server write MAC secret, a client write key, a server write key, a client write IV, and a server write IV • generated by hashing master secret
TLS (Transport Layer Security) IETF standard RFC 2246 similar to SSLv3 with minor differences uses HMAC for MAC a pseudo-random function expands secrets based on HMAC using SHA-1 or MD5 has additional alert codes some changes in supported ciphers changes in certificate types & negotiations changes in crypto computations & padding IEMS5710 - Lecture 8
Client Server ClientHello ServerHello Certificate* ServerHelloDone ServerKeyExchange* TLS Handshake Process TLS Record protocol initially specifies no compression or encryption Request connection Includes: Version #; Time & date; Session ID (if resuming); Ciphersuite (combinations of key exchange, encryption, MAC, compression) Send ServerHello if there is acceptable Ciphersuite combination; else, send failure alert & close connection. * Optional messages ServerHello includes: Version #; Random number; Session ID ; Ciphersuite & compression selections New CipherSpec pending Server Certificate May contain public key Server part of key exchange: Diffie-Hellman, gx;; RSA, public key Compute shared key Server part of handshake done IEMS5710 - Lecture 8
Client Server ClientKeyExchange [ChangeCipherSpec] Finished Handshake Protocol continued Client’s part of key agreement: Diffie-Hellman gy; RSA, random #s Compute shared key Change Cipher protocol message notifies server that subsequent records protected under new CipherSpec & keys Server changes CipherSpec Verify CipherSpec Hash using new CipherSpec; allows server to verify change in Cipherspec IEMS5710 - Lecture 8
Client Server [ChangeCipherSpec] Finished Application Data Handshake Protocol completion Notify client that subsequent records protected under new CipherSpec & keys Client changes CipherSpec Client verifies new CipherSpec Hash using new CipherSpec; • TLS Record protocol encapsulates application-layer messages • Privacy through secret key cryptography • Reliability through MAC • Fragmentation of application messages into blocks for compression/encryption • Decompression/Decryption/Verification/Reassembly IEMS5710 - Lecture 8
Client Server Certificate* ClientKeyExchange CertificateVerify* ClientHello [ChangeCipherSpec] ServerHello ServerKeyExchange* Finished [ChangeCipherSpec] Certificate* Finished CertificateRequest ServerHelloDone Application Data TLS Handshake with Client Authentication Server requests certificate if client needs to be authenticated If server finds certificate unacceptable; server can send fatal failure alert message & close connection Client sends suitable certificate Client prepares digital signature based on messages sent using its private key Server verifies client has private key IEMS5710 - Lecture 8
HTTPS IEMS5710 - Lecture 8 • HTTPS (HTTP over SSL) • combination of HTTP & SSL/TLS to secure communications between browser & server • documented in RFC2818 • no fundamental change using either SSL or TLS • use https:// URL rather than http:// • and port 443 rather than 80 • encrypts • URL, document contents, form data, cookies, HTTP headers
HTTPS Use IEMS5710 - Lecture 8 • connection initiation • TLS handshake then HTTP request(s) • connection closure • have “Connection: close” in HTTP record • TLS level exchange close_notify alerts • can then close TCP connection • must handle TCP close before alert exchange sent or completed
Secure Shell (SSH) IEMS5710 - Lecture 8 • 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 • SSH2 fixes a number of security flaws • documented in RFCs 4250 through 4254 • SSH clients & servers are widely available • method of choice for remote login
SSH Protocol Stack IEMS5710 - Lecture 8
SSH Transport Layer Protocol IEMS5710 - Lecture 8 • server authentication occurs at transport layer, based on server/host key pair(s) • server authentication requires clients to know host keys in advance • packet exchange • establish TCP connection • can then exchange data • identification string exchange, algorithm negotiation, key exchange, end of key exchange, service request • using specified packet format
SSH User Authentication Protocol IEMS5710 - Lecture 8 • authenticates client to server • three message types: • SSH_MSG_USERAUTH_REQUEST • SSH_MSG_USERAUTH_FAILURE • SSH_MSG_USERAUTH_SUCCESS • authentication methods used • public-key, password, host-based
SSH Connection Protocol IEMS5710 - Lecture 8 • runs on SSH Transport Layer Protocol • assumes secure authentication connection • used for multiple logical channels • SSH communications use separate channels • either side can open with unique id number • flow controlled • have three stages: • opening a channel, data transfer, closing a channel • four types: • session, x11, forwarded-tcpip, direct-tcpip.
SSH Connection Protocol Exchange IEMS5710 - Lecture 8
References • William Stallings, Cryptography and Network Security Principles and Practices, 5/e, Pearson • Chapter 16 IEMS5710 - Lecture 8