1 / 28

Security at the Transport Layer Lecture 6

Security at the Transport Layer Lecture 6. SSL/TLS. SSL was developed by Phil Karlton & Netscape. The standards community wanted their own version free from any patents/restrictions Thus was born TLS, which is very similar to SSL

corine
Download Presentation

Security at the Transport Layer Lecture 6

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. Security at the Transport LayerLecture 6

  2. SSL/TLS • SSL was developed by Phil Karlton & Netscape. • The standards community wanted their own version free from any patents/restrictions • Thus was born TLS, which is very similar to SSL • IETF changed the name to avoid showing bias – and add a few things • E.g: TLS defines additional alert codes • TLS MAC covers compression version field in addition to what SSL MAC covers • TLS v1.0 is very similar to SSL v3.1 Information and Nework Security

  3. SSL HTTP NNTP FTP Telnet Etc. Other Apps SSL/TLS TCP/IP Information and Nework Security

  4. Digital certificates and the CA • Public key cryptography avoids the problem of key distributions but it has its weakness: the public key is public and anyone can forge a public key announcement • Solution: public-key certificate: • <a public key and user ID of the key owner>, the whole thing, is signed by a trusted third party (TTP) • The TTP is a certificate authority (CA) • A user can present her public key to the CA in a secure manner and obtain a certificate • The user can then publish her public key • Anyone needs this user’s public key can obtain the certificate and verify that it is valid by the way of the attached trusted signature Information and Nework Security

  5. Client/Server Mutual Authentication • Establish trust with intended recipients • Signed Digital Certificates • Server authenticates Client (optional) • Client authenticates Server Information and Nework Security

  6. Secure Sockets Layer (SSL) • SSL is designed to run in user-level process – no need to change the OS (not like IPSec that runs in superuser-level process) • SSL uses TCP only (not UDP), hence it is simple and it does not have to worry about timing out and retransmitting lost data (TCP does that for SSL) • Applications based on TCP needs to change (even minimum) to work with SSL Information and Nework Security

  7. Secure Sockets Layer (SSL) • The primary goal of the SSL Protocol is • To provide privacy and reliability between two communicating applications. • Allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery (Many applications at Application Layer are based on client/server model) Information and Nework Security

  8. SSL – Secure Client/Server Communication • SSL Server authentication allows clients to confirm a server’s identity • SSL client authentication allows server to confirm a client’s identity (optional) • SSL provides confidentiality and integrity • Sent information is encrypted • Integrity check is carried out to detect tampering Information and Nework Security

  9. SSL – Secure Client/Server Communication • To allow Secure Client/Server Communication to happen using SSL: • The peer's identity can be authenticated using certificates [basically using asymmetric (private key cryptography like DES), and public key, cryptography (e.g., RSA, DSS, etc.)]. • Encryption is used after an initial handshake to define a secret key. Secret key cryptography is used for data encryption (e.g., DES, RC4, etc.) • Integrity check is done using a keyed MAC: Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations. Information and Nework Security

  10. SSL Main Functions • Negotiates and employs essential functions for secure transactions • Mutual Authentication • Data Encryption • Data Integrity Information and Nework Security

  11. SSL Structure Application Layer (http – imap – etc) } ChangeCipher Alert Handshake SSL/TLS Record Layer TCP/IP Information and Nework Security

  12. Cipher Suite • For public-key, secret key encryption and certificate verification we need • public-key algorithm • Secret key encryption algorithm • message digest (hash) algorithm (MD5, SHA-1, etc) • This collection is called a cipher suite • SSL supports many different cipher suites • Client and server must decide on which one to use • The client offers a choice; the server picks one Information and Nework Security

  13. SSL Protocols • SSL consists of two protocol layers (The Record Layer and its above layer which consists of ChangeCipherSpec protocol , Alert protocol and Handshake protocol.) • The SSL record protocol: • takes an application message to be transmitted, • fragments the data into manageable blocks, • optionally compresses the data, • applies MAC, • encrypts, • adds a header and transmits the resulting unit in TCP segment Information and Nework Security

  14. SSL Other Protocols • The Handshake protocol negotiates all options of the session (most important) • The handshake protocol involves using SSL record protocol to exchange a series of messages between an SSL-enabled server and an SSL-enabled client • The ChangeCipherSpec protocol indicates the channel is ready for secure communications • The Alert protocol indicates errors or other caution conditions have occurred in the connection Information and Nework Security

  15. The ChangecipherspecStructure • The change cipher spec message is sent by both the client and server to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec; Information and Nework Security

  16. Alert Message Structure • The Alert protocol specifies and conveys the status of transmitted messages struct { AlertLevel level; AlertDescription description; } Alert; Information and Nework Security

  17. Handshake Protocol • The TLS Handshake Protocol involves the following steps: • Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption. • Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret. • Exchange certificates and cryptographic information to allow the client and server to authenticate themselves. • Generate a master secret from the premaster secret and exchanged random values. • Provide security parameters to the record layer. • Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker. Information and Nework Security

  18. ClientHello Message Structure struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites; CompressionMethod_list compression_methods; } ClientHello; Information and Nework Security

  19. ServerHello Message Structure struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod_list compression_method; } ServerHello; Information and Nework Security

  20. Message Flow of full Handshake Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data * Indicates optional or situation-dependent messages that are not always sent. Borrowed from rft2246 Information and Nework Security

  21. Client/Server Server new thread s1 to serve client1 client1 message main thread message new thread s2 to serve client2 client2 Information and Nework Security

  22. Client/Server Socket Connection Client A Newly returned socket #1 accept Original socket #2 Newly returned socket Client B Server Information and Nework Security

  23. Client/Server with TCP and Socket Client must contact server • server process must first be running • server must have created socket (door) that welcomes client’s contact Client contacts server by: • creating client-local TCP socket • specifying IP address, port number of server process • When client creates socket: client TCP establishes connection to server TCP • When contacted by client, server TCP creates new socket for server process to communicate with client • allows server to talk with multiple clients Information and Nework Security

  24. TCP socket programming flow Client socket() Server well-known port bind() socket() listen() connect() accept() Connection establishment TCP three-way handshake write() Block until connection from client Data (request) read() Process requests write() Data (reply) read() read() End-of-file notification close() close() Information and Nework Security

  25. SSL Applications – Simple Demo /*We can use SSL to build secure Internet application The purpose of this simple program is to show you how to connect to a secure website using SSL and Java Secure Socket Extension */ //TestSSL.java class public class TestSSL { public static void main(String [] args) { try { new java.net.URL("https://" + args[0] + "/").getContent(); } catch (Exception exception) { exception.printStackTrace();} } } /* you can compile this application on sng: javac TestSSL.java And run it with the security option (load HTTPS protocol handler) : java –Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol –Djavax.net.debug=ssl TestSSL sng.its.monash.edu.au */ Information and Nework Security

  26. SSL-based Client (skeleton) import javax.net.ssl.*; public class SecureChatClient { SSLSocket socket; public SecureChatClient() { try { SSLSocketFactory sslFact = (SSLSocketFactory)SSLSocketFactory.getDefault(); socket = (SSLSocket)sslFact.createSocket(“serverhost",5002); /* more code for input/ouput */   } } public static void main(String[] args) { new SecureChatClient(); } } Information and Nework Security

  27. SSL-based Server (skeleton) import javax.net.ssl.*;import java.security.*; public class SecureChatServer { SSLServerSocket ssocket;SSLSocket clientSocket; public SecureChatServer() { Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");   try { SSLServerSocketFactory sslSrvFact = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault(); ssocket = (SSLServerSocket)sslSrvFact.createServerSocket(5002); clientSocket = (SSLSocket)ssocket.accept(); …} } public static void main(String[] args) { new SecureChatServer(); } } Information and Nework Security

  28. SSL/TLS and IPSec • SSL/TLS is useful for building Secure Network and Internet Applications • Both IPSec and SSL are useful for building VPN • SSL/TLS can be used to provide peer entity authentication such as authentication between client and server of Client/Server software applications. IPSec is used to provide security between hosts and networks • IPSec can be used to enhance the security of the whole network when used with firewalls or routers. SSL/TLS is designed to provide security mainly for Client/Server applications Information and Nework Security

More Related