scsc 555 adv computer security
DESCRIPTION
SCSC 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 - PowerPoint PPT PresentationTRANSCRIPT
SCSC 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 WebThreats, 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
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
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
SSL Session States Parameters
Session identifierAn arbitrary byte sequence chosen by the server to identify an active or resumable
session state
Peer certificateAn X509.v3 certificate of the peer; this element
of the state may be null
Compression methodThe algorithm used to compress data prior to
encryption
Cipher specSpecifies 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
• 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 264 - 1
Sequence numbers
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)
SSL Record Format
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 1st byte is alert level: warning (1) or fatal (2), the 2nd byte is alert type
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
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 exchange1. 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
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
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 …
Two Cryptographic Items in Handshake process
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 Shared master secret is one-time 48-byte for this
session by secret key exchange1. 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)
Generation of cryptographic parameters from master secretCipher 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: 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)
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
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 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
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
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
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)1. Open a channel
2. Data transfer
3. 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
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.
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).
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.
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.
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.
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.
Security Benefits User Authentication Host Authentication Data Encryption Data Integrity
User Authentication
• User Identity• System verifies that access is only given to intended
users and denied to anyone else.
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.
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
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.
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)
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.
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.
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.
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.