Chapter 6 - Transport-Level Security

Class: CSCE-465-63860

Table 6.1 A Comparison of Threats on the Web

Note:

• Note we add TLS in the transport layer, that is the default way to protect this layer
• Then we add Kerberos in the Application layer

Transport Layer Security (TLS)

• One of the most widely used security services
• TLS is an Internet standard that evolved from a commercial protocol known as Secure Sockets Layer (SSL – by Netscape Corporation)
• TLS is a general purpose service implemented as a set of protocols that rely on TCP
  • TLS could be provided as part of the underlying protocol suite and therefore be transparent to applications
  • Alternatively, TLS can be embedded in specific packages

SSL/TLS Protocol Stack

Notes:

• TLS is also called SSL (first it was SSL, now it is TLS)
• Available by default in most OSs
• Note the protocols of the top serve different specific purposes

TLS Architecture

Two important TLS concepts are:

• TLS connection
  • A TCP based transport service
  • For TLS such connections are peer-to-peer relationships like TCP
  • Every connection is associated with a session
  • More connections associated with same session
• TLS session
  • An association between a client and a server
  • Created by the Handshake Protocol
  • Define a set of cryptographic security parameters shared among more connections
  • Are used to avoid the expensive negotiation of new security parameters for each connection

A session state is defined by the following 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

A connection state is defined by the following parameters:

• Server and client random
  • Byte sequences that are chosen by the server and client for each connection
• Server write MAC secret
  • The secret key used in MAC operations on data sent by the server
• Client write MAC secret
  • The secret key used in MAC operations on data sent by the client
• Server write key
  • The secret encryption key for data encrypted by the server and decrypted by the client
• Client write key
  • The symmetric encryption key for data encrypted by the client and decrypted by the server
• Initialization vectors
  • 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 Handshake Protocol
  • The final ciphertext block from each record is preserved for use as the IV with the following record
• Sequence numbers
  • 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$

Notes:

• A session is a long term trust relationship between a client and a server computer
  • More expensive operations happen here
  • Some protocols allow for compression
  • Cipher specification: tells which encryption algorithms have been used for this session
    • Symmetric encryption algorithms, hashing algorithms, etc.
  • Every time we create a new connection, our session master secret will be used
• A connection is a physical TCP connection from the client to the server computer
  • Cheaper to set up
  • Relies on TCP sequence numbers
  • If someone wants to break TCP, it would be easier because there is not security included by TCP

The TLS Record Protocol

The TLS Record Protocol provides two services for TLS connections

• Confidentiality
  • The Handshake Protocol defines shared secret keys used for conventional encryption of TLS payloads
• Message integrity
  • The Handshake Protocol also defines shared secret keys used to form message authentication codes (MACs)

Record Details:

• Being split up into smaller fragments in the case that TCP receives more than 16KB (fragments are at most 16KB)
• Compressed optionally
• Header added at the end

TLS Record Format

• Header contains the version number of TLS, content type (e.g. HTTP, SMTP, etc.)
• Major version = 3
  • Because the version numbering has continued from the old SSL protocol
  • Today we are at something like 3.4
• MAC sizes are wrong, we don't have 20 bytes MAC anymore

TLS Record Protocol Payload

• Handshake Protocol
• Change Cipher Spec Protocol
• Alert Protocol

TLS Handshake Protocol Message Types

Handshake Protocol Action

Handshake Phase I

• Client tells
  • Version limitations
  • Random number (timestamp + 2 bytes)
  • Session ID (<>0 means resume)
  • Cipher limitations (prioritized order)
  • Compression limitations (prioritized order)
• Server tells same stuff
  • Have chosen version and cipher, etc.
• Possible key exchange methods
  • RSA or ECDHE (Elliptic Curve Diffie-Hellman)
  • ECDSA (Elliptic Curve Digital Signature Algorithm) or RSA for signature
  • Fixed Diffie-Hellman (based on public keys)
  • Ephemeral Diffie-Hellman (based on secrets)
  • Anonymous Diffie-Hellman (dangerous…)
  • Fortezza
• We look at TLS 1.2 and everything in grey is from older versions

Notes:

• Client tells:
  • If the session ID number is not 0, it means we want to use a session that already existed
  • Cipher limitations constrained by the cipher spec found in the TLS session (telling the server what ciphers can be used)
• Server tells:
  • Sends back the same format but now the list has been reduces to a specific version and a specific cipher that has been chosen by the server
    • IT is the server that finally decides on version number and ciphers

Handshake Phase II

• Server tells
  • Its certificate, perhaps a chain (or none)
  • Parameters for key generation (none if RSA or Fixed DHE)
  • If client certificate (and type) is required (not if Anomynous DHE)
• Certificate type can be
  • RSA or DSS for signature
  • ECDSA for signature
  • RSA or DSS for Fixed DHE (auth. only)
  • RSA or DSS for Emphemeral DHE
  • Fortezza

Notes:

• Server answers:
  • Server sends a certificate to the client
  • The server can require a certificate from the client
    • I none, that would mean the user has no certificate installed in their browsers
    • RSA certificate containing RSA public key
    • Elliptic Curve (ECDSA) with public key

Handshake Phase III

• Client tells
  • Certificate, perhaps a chain if needed
  • Parameters for key generation (none if Fixed DHE)
  • Optionally SHA256 of master secret and handshake messages
  • Optional certificate verification (MD5 or SHA-1 of master secret and all handshake messages) encrypted with client key
• Calculation of master secret
  • ”pre-master secret” 6 times
  • Client random 3 times
  • Server random 3 times
  • Public key of peer & own private key

Notes:

• Client answers with certificate if it was asked for one
• IN the old days (first SSL versions) there was something called downgrade attack.
  • It is possible to read plaintext messages
  • In the Hello message you will found the list of ciphers
  • The downgrade was simply modifying this list and choosing the oldest cipher suite that we could break (the weakest one)
  • The server is most likely to accept that and then provides us with he weakest possible state
• The master secret is calculated in quite difficult ways
  • pre-master secret is used 6 times, then we use our random values from the very first handshake.
  • All of this is put together and used with HMAC to produce a pseudorandom sequence to produce public/private keys

Handshake Phase IV

• Both parties send
  • Confirmation of cipher specification (agreement about starting secure communication)
  • A message including both MD5 and SHA-1 of master secret and all handshake messages (confirmation of TLS version, etc.) (for TLS 1.2 it is SHA256 of master secret and handshake messages

Cryptographic Computations

• Items of interest:
  • The creation of a shared master secret by means of the key exchange for the session
    • The shared master secret is a one-time 48-byte value generated for this session by means of secure key exchange
• The generation of cryptographic parameters from the master secret for each connection
  • CipherSpecs require a 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 which are generated from the master secret in that order
    • These parameters are generated from the master secret by hashing the master secret into a sequence of secure bytes of sufficient length for all needed parameters

Heartbeat Protocol

• A heartbeat is a periodic signal generated by hardware or software to indicate normal operation or to synchronize other parts of a system
• A heartbeat protocol is typically used to monitor the availability of a protocol entity and was added to TLS 1.2
• The heartbeat protocol runs on top of the TLS Record Protocol
  • Consists of two message types: heartbeat request and heartbeat response
• The heartbeat serves two purposes:
  • It assures the sender that the recipient is still alive, even though there may not have been any activity over the underlying TCP connection
  • It generates activity across the connection during idle periods, which avoids closure by a firewall that does not tolerate idle connection

Notes:

• Invented in order to be able to detect DDoS Attacks.
• Instead we can recognize very fast if the TCP connection was left

TLS Attacks

Attack categories

• Attacks on the handshake protocol
• Attacks on the record and application data protocols
• Attacks on the PKI
• Other attacks, e.g., attack on implementation!
  • Could be vulnerabilities, errors, bugs in the code that could be utilized by an attacker

Notes:

• As far as we know, there are no current attacks for TLS 1.2
• If you look for TLS 1.1 you will find some attacks.

TLS Version 1.3

• Shorter and simplified 1-RTT handshake (faster)
• Removes RSA & DH static key exchange (removes everything insecure)
• Supports only Perfect Forward Secrecy (PFS) methods
• A few other details

Notes:

• 0-RTT also possible, but insecure
  • Round Trip Time handshake
• me algorithms have been removed -> static key exchange
• PFS: If someone breaks a key, it won't be able to use that knowledge to break other keys in the past or in the future
• It is actually insecure
  • Not used for internet connections
  • Can be attacked by a replay attack

SSL/TLS Versions

• GCM = Galois/Counter Mode
• CCM = Counter with Cipher block chaining MAC

Notes:

• No = not implemented
• Yes = implemented
• Red = Insecure
• With TLS 1.3, ciphers have been cut down to only 3, which are the ones that support forward secrecy.
  • Why 3 options? Why not only 1?
  • What is left is considered to be what is equally secure
    • Kind of a negotiation among experts from different companies

Notes:

• Considered to be very secure algorithms

HTTPs (HTTP over TLS)

• Refers to the combination of HTTP and TLS to implement secure communication between a Web browser and a Web server
• User of a Web browser will see URL addresses that begin with https://
• If HTTPS is specified, port 443 is used, which invokes TLS
• Documented in RFC 2818, HTTP Over TLS
  • There is no fundamental change in using HTTP over TLS and both implementations are referred to as HTTPS
• When HTTPS is used, the following elements of the communication are encrypted:
  • URL of the requested document (with parameters)
  • Contents of the document
  • Contents of browser forms
  • Cookies sent from browser to server and from server to browser
  • Contents of HTTP header

Connection Closure

• An HTTP client or server can indicate the closing of a connection by including the line Connection: close in an HTTP record
• The closure of an HTTPS connection requires that TLS close the connection with the peer TLS entity on the remote side, which will involve closing the underlying TCP connection
• TLS implementations must initiate an exchange of closure alerts before closing a connection
  • A TLS implementation may, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an “incomplete close” (bad implementation)
• An unannounced TCP closure could be evidence of some sort of attack so the HTTPS client (and server) should issue some sort of security warning when this occurs

Website Client Auth.

• Website uses HTTPS
• Basically three options available
  • HTTP basic authentication (asking for username + password)
    • Seldom used today (cannot be integrated in website design)
  • HTTP form authentication (asking for whatever you like)
    • OAuth using this
  • Client-side authentication with X509v3 certificate at client-side (for TLS handshake giving mTLS)
    • Could be internal website or community website requiring high level of security
• Afterwards session variables handle access rights (cookie being a key element in order to identify authenticated client)
  • Cookie must be unforgeable (encrypted by server)
  • Often JWT (Javascript Web Token) used

Secure Shell (SSH)

• A protocol for secure network communications designed to be relatively simple and inexpensive to implement
• The initial version, SSH1 was focused on providing a secure remote logon facility to replace TELNET and other remote logon schemes that provided no security
• SSH also provides a more general client/server capability and can be used for such network functions as file transfer and e-mail
• SSH2 fixes a number of security flaws in the original scheme
  • Is documented as a proposed standard in IETF RFCs 4250 through 4256
• SSH client and server applications are widely available for most operating systems
  • Has become the method of choice for remote login and X tunneling
  • Is rapidly becoming one of the most pervasive applications for encryption technology outside of embedded systems

Transport Layer Protocol

• Server authentication occurs at the transport layer, based on the server possessing a public/private key pair
• A server may have multiple host keys using multiple different asymmetric encryption algorithms
• Multiple hosts may share the same host key!
• The server host key is used during key exchange to authenticate the identity of the host
• RFC 4251 dictates two alternative server trust models:
  1. The client has a local database that associates each host name with the corresponding public host key
  2. The host name-to-key association is certified by a trusted certification authority (CA); the client knows the CA root key and can verify the validity of all host keys certified by accepted CAs

Notes:

• The problem with this is that we don't want to store the same key in different devices, if one of those gets hacked, then they all get hacked
• The other option is to rely on CA, and use it to verify public keys

Notes:

• Sends something over SSH
• Optional compression
• Add sequence number
• Encryption
• Message Authentication Code (MAC) is aggregated

SSH Transport Layer Cryptographic Algorithms

Notes:

• Cyber block chaining is not as secure a it used to be
• OpenSSH is a really good option and more often being used instead of ssh.
  • Includes larger keys and SHA-256
  • But it is actually running at the Application Layer, which is why some experts claim is actually less secure than SSH.

Client Auth. Methods

• Publickey
  • The client sends a message to the server that contains the client’s public key, with the message signed by the client’s private key
  • When the server receives this message, it checks whether the supplied key is acceptable for authentication (stored in its database) and, if so, it checks whether the signature is correc
• Password
  • The client sends a message containing a plaintext password, which is protected by encryption by the Transport Layer Protoc
• Hostbased
  • Authentication is performed on the client’s host rather than the client itself
  • This method works by having the client send a signature created with the private key of the client host
  • Rather than directly verifying the user’s identity, the SSH server verifies the identity of the client host

Notes:

• If you log in from a PC that is using host based auth against an SSH server, then it is not you being authenticated, it is the PC being authenticated, which means anyone logged on that PC would be able to access the SSH server
  • There coul dbe a lot of people sharing the same authentication principle
  • Is like sharing the same certificate among many people
  • It is clearly a security issue

Connection Protocol

• The SSH Connection Protocol runs on top of the SSH Transport Layer Protocol and assumes that a secure authentication connection is in use
  • The secure authentication connection, referred to as a tunnel, is used by the Connection Protocol to multiplex a number of logical channels
• Channel mechanism (to get a data connection)
  • All types of communication using SSH are supported using separate channels
  • Either side may open a channel
  • For each channel, each side associates a unique channel number
  • Channels are flow controlled using a window mechanism
  • No data may be sent to a channel until a message is received to indicate that window space is available
  • The life of a channel progresses through three stages: opening a channel, data transfer, and closing a channe

Notes:

• With TLS it is possible to create several more connections (called channels)

Channel Types

Four channel types are recognized in the SSH Connection Protocol specification

• Session
  • The remote execution of a program
  • The program may be a shell, an application such as file transfer or e-mail client, a system command, or some built-in subsystem
  • Once a session channel is opened, subsequent requests are used to start the remote program, provide inputs and receive outpu
• X11
  • Refers to the X Window System, a computer software system and network protocol that provides a graphical user interface (GUI) for networked computers
  • X allows applications to run on a network server but to be displayed on a desktop machine (thin client)
• Forwarded-tcpip
  • Remote port forwarding (when service is hidden behind firewall or NAT)
• Direct-tcpip
  • Local port forwarding (when service is available directly)

Notes:

• The only thing you can do with an open session is to create channels, to actually start sending data you have to had created a channel
• X Windows are remote windows systems supported by linux and unix where you can open a window in one computer which is called a thin client, where a full client is running remotely on another computer
  • All applications today probably support X11
  • Application window that shows up where the client is sitting, but the full application is running remotely
• Forwarded-tcpip and Direct-tcpip are general channels that we can always use
• Direct-tcpip = local port forwarding
  • Using a local port (e.g. 80) for connecting to a web server on another host somewhere else
  • It will become a secret connection by means of encryption and MAC provided by SSH
• Forwarded-tcpip
  • Used in the case that the remote service is not accessible
  • The remote site can export the services using forwarded-tcpip
  • The remote side will decide a port that can be used for this, we at the client side will use this port to access this service
    • (a channel will be created) - encrypting all the traffic between the both sides

Port Forwarding

• One of the most useful features of SSH
• Provides the ability to convert any insecure TCP connection into a secure SSH connection (also referred to as SSH tunneling)
• Incoming TCP traffic is delivered to the appropriate application on the basis of the port number (a port is an identifier of a user of TCP)
• An application may employ multiple port number

Notes:

• An unsecure TCP connection is being secure by covering it under a secure SSH Tunnel (Channel)
• Considered to be the most powerful part of SSH
  • Means that any kind of service communication can be secure even if they are using an unsecure protocol
• Is it possible to verify that your connection is being secured by an SSH tunnel?
  • Yes, you can verify if an active SSH tunnel is running and securing your connection using local network tools and command-line utilities.
  • You can type a command on the client side
• To set up this tunnel
  • You need to type a command on the server side and another command on the client side

Summary

• Transport Layer Security
  • TLS architecture
  • TLS record protocol
  • Change cipher spec protocol
  • Alert protocol
  • Handshake protocol
  • Cryptographic computations
  • Heartbeat protocol
  • SSL/TLS attacks
  • TLSv1.3
• Web security considerations
  • Web security threats
  • Web traffic security approaches
• HTTPS
  • Connection initiation
  • Connection closure
• Secure shell (SSH)
  • Transport layer protocol
  • User authentication protocol
  • Communication protocol