1. SCSC 555 Adv Computer Security Chapter 6 Transport layer Security Dr. Frank Li

2. Index Web Security Considerations SSL TLS HTTPS SSH

3. Web Security Considerations Web are extremely vulnerable  Is a client/server application running over the Internet and TCP/IP Intranet  Characteristics of Web usage: Web servers are easy to configure and manage, and Web contents is easy to develop. However, the underlying software is complex and may hide potential security flaws. A Web server can be exploited as a launching pad into entire network Untrained users are common clients for Web-based service, may not aware of security risks

4. Web Security Threats Group threats in terms of:  passive and active attacks can you give some examples of each type?  Location of threats: Web server, Web browser (part III of this book) network traffic A comparison of threats on the Web Threats, consequences and countermeasures (next slide Table 6.1)

6. Location of Security Facilities Use IPSec  A general-purpose solution  Transparent to ends users and applications  Filtering capacity – only selected traffic need IPSec processing and overhead SSL/TLS  Can be provided as part of underlying protocol suite  Can be embedded in specific package. Can you name any applications with embedded SSL? Application-specific security service

7. SSL Defined in RFC5246 A general-purpose service as a set of protocol rely on TCP  Implemented as part of underlying protocol suite OR  embedded in specific package

8. SSL Not a single protocol but two layers of protocols  SSL record protocol – provides basic security service to various higher layer protocols  Three higher-layer protocols the handshake protocol The change cipher spec protocol The alert protocol (Figure 6.2 next slide)

9. SSL Protocol Structure

10. SSL Connection and Session SSL Connection  Is a transport the provides a suitable type of service  Is transient  is associated with one session SSL Session  Is an association between a client and a server  Created by the handshake protocol  Defines a set of security parameters, can be shared among multiple connection  Are used to avoid the expensive negotiation of new security parameters for each connection

11. SSL Session States During the handshake protocol  Pending read and write states  At conclusion of the handshake protocol Pending read  red Pending write  write Once a session is established  operating sate for both read and write

12. SSL Session States Parameters Session identifier An arbitrary byte sequence chosen by the server to identify an active or resumable session state Peer certificate An X509.v3 certificate of the peer; this element of the state may be null Compression method The algorithm used to compress data prior to encryption Cipher spec Specifies the bulk data encryption algorithm and a hash algorithm used for MAC calculation; also defines cryptographic attributes such as the hash_size Master secret 48-byte secret shared between the client and the server Is resumable A flag indicating whether the session can be used to initiate new connections

13. SSL Connection States Parameters Byte sequences that are chosen by the server and client for each connection Server and client random The secret key used in MAC operations on data sent by the server Server write MAC secret The secret key used in MAC operations on data sent by the client Client write MAC secret The secret encryption key for data encrypted by the server and decrypted by the client Server write key The symmetric encryption key for data encrypted by the client and decrypted by the server Client write key When a block cipher in CBC mode is used, an initialization vector (IV) is maintained for each key This field is first initialized by the SSL Handshake Protocol The final ciphertext block from each record is preserved for use as the IV with the following record Initialization vectors Each party maintains separate sequence numbers for transmitted and received messages for each connection When a party sends or receives a change cipher spec message, the appropriate sequence number is set to zero Sequence numbers may not exceed 2 64 - 1 Sequence numbers

14. SSL Record Protocol Provides two services for SSL connection  Confidentiality: define a shared secret key to encrypt SSL payload  Message integrity: define a shared secret key to form MAC (Figure 6.3 SSL Record Protocol next slide)

16. SSL Record Format

17. Three SSL-Specific Protocols figure 6.5 Change Cipher Spec Protocol  Cause the pending state to be copied into current state  Single byte with value 1 Alert Protocol  Convey SSL related alerts to the peer entity  Two bytes: the 1 st byte is alert level: warning (1) or fatal (2), the 2 nd byte is alert type

18. SSL Handshake Protocol Handshake Protocol  Allow the server and the client to authenticate each other and to negotiate an encryption and MAC algorithm and keys  Three fields: Type (1 byte), Length (3 bytes), Contents (>= 0 bytes) Handshake consists of a series of messages (Figure 6.6)  Phase 1: establish security capabilities  Phase 2: Server authentication and key exchange  Phase 3: client authentication and key exchange  Phase 4: finish

20. SSL Handshake Protocol Phase 1: establish security capabilities  The client initiates a logical connection “client_hello” Parameters: version, random, session ID, cipher suite, compression method Details of cipher suite: key exchanged method, cipher spec “server hello”  Convention

21. Phase 2: Server authentication and key exchange 1. Server sends its certificate: one or chain of X.509 certificates; 2. Server sends a server_key_exchange message;  E.g. 1 anonymous DH (figure 3.12)  E.g 2 RSA key exchange (figure 3.10)  Signature in this message: parameters and 2 nonces 3. Server sends a server_request message  Certificate type and a list of CAs 4. Server sends a server_hello_done message

22. Phase 3: Client authentication and key exchange Client first verify server’s certificate and parameters Received. If all good  1. If server requests a certificate, client sends a certificate message 2. Client sends a client_key_exchange message  E.g. 1 RSA: 48-byte pre-master secret, encrypted with server’s public key or RSA key  E.g. 2 anonymous DH  E.g. 3 Fixed DH 3. Client sends a certificate_verify message

23. Phase 4: Finish 1. Client sends a change_cipher_spec message 2. Client sends a finished message  Verify the key exchange and authentication process were successful Server sends a change_cipher_spec message Server send a finished message --- handshake is complete --- Begin to exchange App-level data …

24. Two Cryptographic Items in Handshake process The creation of a shared master secret key by key exchange Generation of cryptographic parameters from master secret;

25. The creation of a shared master secret key by key exchange Shared master secret is one-time 48-byte for this session by secret key exchange 1. Pre_master_secret is exchanged 2. Master-secret is calculated by both parties;  E.g. 1 RSA (page 178)  E.g. 2 DH (page 178)

26. Generation of cryptographic parameters from master secret Cipher spec requires parameters:  a client write MAC secret,  a server write MAC secret,  a client write key,  a server write key,  a client write IV,  a server write IV, The parameters are calculated from the master secret based on formula, example page 178  Pseudorandom seed and salt  The result secure bytes are used for all parameters

27. Transport Layer Security (TLS) TLS is IETF standardization initiative to produce a standard version of SSL  In RFC 5246  Similar to SSLv3 The differences to SSLv3:  Version number  MAC TLS use HMAC algorithm (page 179) TLS MAC encompasses all fields in SSLv3 MAC calculation, PLUS TLSCompressed.version

28. Transport Layer Security (TLS) The differences to SSLv3 (con’d)  Use a different Pseudorandom function: PRF is based on data expansion function To make use of a relatively small shared secret to generate longer blocks of data for parameters  Additional alert codes  Cipher Suites  Client certificate types  Cryptographic computations  Padding

29. HTTPS HTTPS: combination of HTTP and SSL  Defined in RFC 2818  Implement secure communication between web server and web client (browser)  HTTP uses port 80 vs HTTS uses port 443 HTTPS encrypts:  URL of requested document  Contents of document  Contents of browser forms  Cookies  Contents of HTTP header

30. HTTPS Connection Initiation The client (Web browser) acts as both HTTP client and TLS client  Client initiates a connection to the server and sends clientHello message  Three levels of awareness of a connection in HTTPS HTTP level TLS/SSL level TCP level

31. HTTPS Connection Closure A HTTP client or server can indicates the closing of a connection by including: connection: close in HEEP record  close TLS connection Use the TLS alert protocol to send close_notify alert; May close the connection without waiting for the peer to send its closure alert HTTP client must be able to cope with a situation in which underly TCP connection is terminated without a prior close_notify  Close underlying TCP connection

41. Secure Shell (SSH) SSH is a protocol for secure network communication  SSH1 is designed to replace Telnet  security issues with Telnet Sends all data in clear text. Host between sender and receiver can see what the traffic is.  SSH provides secure remote access, and allows other protocols to ride on top of it  Transmission can be compressed.

42. History of SSH Created by Tatu Ylönen in July 1995, a student of Helsinki University of Technology  SSH1  Founded SSH Communications Security, Ltd  SSH 2 fixes a number of security flaws in SSH1 (RFC4250 – 4256) SSH is organized as three protocols, run on top of TCP  SSH protocol stack (next slide)

44. Functions of SSH protocol stack Transport layer protocol  Provides server authentication, data confidentiality and integrity User authentication protocol  Authenticates the user to the server Connection protocol  Multiplex multiple logic communication channels over a single underlying SSH connection

45. SSH Transport layer protocol Server authentication is based on the server’s public/private key pair  Host Keys: one host may have many, or many hosts could share one  Client must have the server’s public key in advance!  Two alternative trust models defined in RFC4251 The client has a local DB associates each host name with public key The host name to key association is certified by CA. The client only knows CA’s public key and can verify all host keys certified by CA.

46. SSH Package exchange Package exchange of SSH Transport Layer Protocol  First, client establish TCP connection to the server  Then starts SSH key exchange steps (next slide)  The client and server exchange data (packets) Packet format (after next slide) pktl, pdl, payload (may be compressed), random padding, MAC,

47. SSH key exchange steps

49. SSH User Authentication Protocol Message exchange 1. Client sends request 2. Server checks if user name is valid  valid or NOT 3. Server returns result of step 2 and a list of authentication methods 4. Client selects one of authentication method in step 3 and reply its choice A sequence of exchange to perform authentication 5. Based on authentication result, go to step 3 Or 6 when all required authentication methods succeeds, server sends a success message

50. Authentication methods in SSH User Authentication Protocol Public key  Client sends message to server. The message contains signature (message encrypted by client’s private key) and client’s public key  Server verify if the key is acceptable and if the signature is valid Password  Client sends a password encrypted by Transport layer protocol Hostbased  Client sends a signature created with private key of client host  Server verifies the identity of client host, and then believes the client host already authenticate that client

51. SSH Connection Protocol SSH connection protocol runs on the top of SSH Transport layer protocol  Secure authentication connection is called tunnel  Each side may open a channel, and each side associates a unique channel number. SSH Connection Protocol steps (next slide) 1. Open a channel 2. Data transfer 3. Close a channel

52. Three Main Functions of SSH Secure Command Shell Port Forwarding Secure file transfer

53. Secure Command Shell Allow you to edit files. View the contents of directories. Custom based applications. Create user accounts. Change permissions. Anything can be done from command prompt can be done remotely and securely.

54. Port Forwarding A Powerful Tool.  provide security to TCP/IP applications including e- mail, sales and customer contact databases, and in- house applications.  allows data from normally unsecured TCP/IP applications to be secured.

55. Port Forwarding

56. Secure File Transfer Secure File Transfer Protocol (SFTP) is a subsystem of the Secure Shell protocol. Separate protocol layered over the Secure Shell protocol to handle file transfers.

57. SFTP SFTP encrypts both the username/password and the data being transferred.  Uses the same port as the Secure Shell server, eliminating the need to open another port on the firewall or router.  Using SFTP also avoids the network address translation (NAT) issues that can often be a problem with regular FTP. An ideal use of SFTP is to fortify a server or servers outside the firewall or router accessible by remote users and/or partners (sometimes referred to as a secure extranet or DMZ).

59. Secure File Transfer Protocol one of the safest ways to make specific data available to customers, partners and remote employees without exposing other critical company information to the public network. effectively restricts access to authorized users and encrypts usernames, passwords and files sent to or from them.

60. Components of Secure Shell SSHD Server: A program that allows incoming SSH connections to a machine, handling authentication, authorization. Clients: A program that connects to SSH servers and makes requests for service Session: An ongoing connection between a client and a server. It begins after the client successfully authenticates to a server and ends when the connection terminates.

61. SSH Architecture The user initiates an SSH connection. SSH attempts to connect to port 22 on the remote host. If successful, SSHD on the machine Remote forks off a child SSHD process. This process will handle the SSH connection between the two machines. The child SSHD now forks off the command received from the original SSH client. The SSHD child process now encrypts every messages that has to be send to the ssh client. The SSH client decrypts the information and sends it to the user application.

62. How Secure Shell Works ? When SSHD is started, it starts listening on port22 for a socket. When a socket get connected the secure shell daemon spawns a child process. Which in turn generates an host key e g. RSA. After key is generated the secure shell daemon is ready for the local client to connect to another secure shell daemon or waits for a connection from remote host.

63. Security Benefits User Authentication Host Authentication Data Encryption Data Integrity

64. User Authentication User Identity System verifies that access is only given to intended users and denied to anyone else.

65. Password Authentication Passwords, in combination with a username, are a popular way to tell another computer that you are who you claim to be. If the username and password given at authentication match the username and password stored on a remote system, you are authenticated and allowed access.

66. Public Key Authentication Most secure Method to authenticate using Secure Shell Public key authentication uses a pair of computer generated keys - one public and one private. Each key is usually between 1024 and 2048 bits in length

67. Public Key Authentication To access an account on a Secure Shell server, a copy of the client's public key must be uploaded to the server. When the client connects to the server it proves that it has the secret, or private counterpart to the public key on that server, and access is granted.

68. Host Authentication A host key is used by a server to prove its identity to a client and by a client to verify a "known" host. – Host keys are described as persistent (they are changed infrequently) and are asymmetric--much like the public/private key pairs discussed above in the Public key section. – If a machine is running only one SSH server, a single host key serves to identify both the machine and the server. – If a machine is running multiple SSH servers, it may either have multiple host keys or use a single key for multiple servers. Host authentication guards against the Man-in-the-Middle attack. (next slide)Man-in-the-Middle attack

69. Host Authentication (cont.)  To access an account on a Secure Shell server, a copy of the client's public key must be uploaded to the server.  When the client connects to the server it proves that it has the secret, or private counterpart to the public key on that server, and access is granted.

71. Data Encryption your data is protected from disclosure to a would-be attacker "sniffing“ on the wire. Ciphers are the mechanism by which Secure Shell encrypts and decrypts data being sent over the wire.  When a client establishes a connection with a Secure Shell server, they must agree which cipher they will use to encrypt and decrypt data. The server generally presents a list of the ciphers it supports, and the client then selects the first cipher in its list that matches one in the server's list.

72. Data Integrity Data integrity guarantees that data sent from one end of a transaction arrives unaltered at the other end.  Even with Secure Shell encryption, the data being sent over the network could still be vulnerable to someone inserting unwanted data into the data stream  Secure Shell version 2 (SSH2) uses Message Authentication Code (MAC) algorithms to greatly improve upon the original Secure Shell's (SSH1) simple 32-bit CRC data integrity checking method.

73. Reasons to use SSH Designed to be a secure replacement for rsh, rlogin, rcp, rdist, and telnet. Strong authentication. Closes several security holes (e.g., IP, routing, and DNS spoofing). Improved privacy. All communications are automatically and transparently encrypted. Arbitrary TCP/IP ports can be redirected through the encrypted channel in both directions The software can be installed and used (with restricted functionality) even without root privileges. Optional compression of all data with gzip (including forwarded X11 and TCP/IP port data), which may result in significant speedups on slow connections.