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

Index Web Security Considerations SSL TLS HTTPS SSH

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

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)

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

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

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)

SSL Protocol Structure

SSL Connection and Session 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

SSL Session States Parameters (detail not required) 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

SSL Connection States Parameters (detail not required) 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 264 - 1 Sequence numbers 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

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)

Detailed formula and contents are NOT required.

SSL Record Format

(Detail of these two protocols are not required) 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 1st byte is alert level: warning (1) or fatal (2), the 2nd byte is alert type

SSL 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

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

Phase 2: Server authentication and key exchange Server sends its certificate: one or chain of X.509 certificates; 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 Server sends a server_request message Certificate type and a list of CAs Server sends a server_hello_done message

Phase 3: Client authentication and key exchange (formula is Not required) Client first verify server’s certificate and parameters Received. If all good  If server requests a certificate, client sends a certificate message 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 Client sends a certificate_verify message

Phase 4: Finish (formula is Not required) Client sends a change_cipher_spec message 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 …

Two Cryptographic Items in Handshake process (formula is Not required) The creation of a shared master secret key by key exchange Generation of cryptographic parameters from master secret;

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

Generation of cryptographic parameters from master secret (formula is Not required) 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

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 (detail is Not required) Version number MAC TLS use HMAC algorithm (page 179) TLS MAC encompasses all fields in SSLv3 MAC calculation, PLUS TLSCompressed.version

Transport Layer Security (TLS) (detail is Not required) 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

HTTPS HTTPS: combination of HTTP and SSL HTTPS encrypts: 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

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

HTTPS Connection Closure A HTTP client or server can indicates the closing of a connection by including: connection: close in HTTP 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

Start Ethereal

Capture packets when open a web page (http)

Check the packets (TCP 3-way handshake)

Clear text in http packets

Now access https web page (secure log in page)

Although I didn’t enter the correct username and password, Ethereal capture the packets of sending username and password.

https set up Client accesses a URL with https Server sends back its certificate (public key encrypted by CA) Client validates certificate, generates a symmetric session key, encrypts by server’s public key and sends back Server gets session key, communication begins…

The encrypted packets captured by Ethereal

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.

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)

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

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.

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,

SSH key exchange steps Step 1: ID string exchange Step 2: Algorithm negotiation Step 3: key exchange Spec allows for alternative methods, but only two version of DH key exchange are specified As result two sides share a master key K D-H key exchange (revisit) the server has been authenticated to the client Server sign its half of DH exchange Step 4 Service request The client requests either user authentication or connection protocol Key generation: 6 keys used in following SSH are generated from result of step 3 (details are not required)

SSH User Authentication Protocol (detail is Not required) Message exchange Client sends request Server checks if user name is valid  valid or NOT Server returns result of step 2 and a list of authentication methods 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

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

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) Open a channel Data transfer Close a channel

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

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.

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.

Port Forwarding