CSEC 701 SSL Cryptographic Computation

IPsec headers

contain info on the VPN link and the packet, network layer protocol header on top of another network layer protocol (IP), AH & ESP

IPsec modes

method of transportation of user data, transport & tunnel mode

IPsec IKE

internet key exchange, mutual authentication, establish shared symmetric key, two phases

authentication header

IPsec header, data integrity, origin authentication, anti-replay, NO encryption

encapsulated security payload

IPsec header, confidentiality, integrity, optional authentications, HAS encryption

transport mode

between two hosts: one IP header, then TCP/UDP header

tunnel mode

applied to an IP tunnel, outer IP header: IPsec processing destination; inner IP header: ultimate packet destination 

IKE

ISAKAMP+Oakley; protocol that produces security keys and other protocols, mutual authentication+session key establishment(long-term key), key management framework and key exchange protocol (DH)

ISAKAMP

establishes cryptographic keys and security associates

Oakley

a key agreement protocol, uses DH algorithm to create master key, and a key that is specific to each session

IKE phase 1

secure, authenticated session is established, mutual authentication, creates session keys for encrypting IKE phase 2 messages (expesnive)

IKE phase 2

the security services and details for an SA are negotiated, can occur multiple times, establishes IPsec SA (simple)

SSL architecture

SSL handshake protocol, SSL change cipher spec protocol, SSL alert protocl, applications; SSL record protocol

SSL handshake phase 1

Negotiation of the session ID, key exchange algorithm, MAC algorithm, encryption algorithm, and exchange of initial random numbers

SSL handshake phase 2

Server may send its certificate and key
exchange message, and it may request the client
to send a certificate. Server signals end of hello
phase.

SSL handshake phase 3

Client sends certificate if requested and may
send an explicit certificate verification message.
Client always sends its key exchange message.

SSL handshake phase 4

Change cipher spec and finish handshake

phase 1 client hello message

client version, client random, session id(zero or old id), cipher suites (list of cryptographic options)

phase 1 server hello message

server version, server random, session id(chosen by server) , cipher suite(single selected)

cipher suite

key exchange algorithm + cipherSpec

key exchange method

RSA, fixed DH, ephemeral DH, anonymous DH, fortezza

cipherspec

CiberAlgorithm, MACalgorithm, CipherType, IsExportable, HashSize, Key Material, & IV Size

session

defines a set of cryptographic security parameters which can be shared among multiple connections

connection

one mouse click, every connection is associated with one session, connections of the same session share the session state

SSL key derivation steps

1. premaster secret

2. master secret

3. key material

4. encryption keys

premaster secret

created by client, used to seed calculation of encryption parameters, 2 bytes SSL + 46 random bytes, sent encrypted to server using servers public key; at phase 3 after client key exchange

master secret

generated by both parties from premaster secret and random values generated by both client and server, one-time 48 byte value generated for session; MD5 ( PreMasterSecret || SHA(“A” || PreMasterSecret || CleintHello.random || ServerHello.random)) ||

key material

generated from the master secret and shared random values, changed for each connection; MD%( MasterSecret || SHA(“A” || MasterSecret || CleintHello.random || ServerHello.random)) ||

encryption keys

extracted from the key material

cryptographic parameters

the key material is divided into six 128-bit keys

in SSL, 48-byte pre-master secret is directly used to derive the key material?

False

in SSL, the key material is changed for different connections under one session?

True

in SSL, digital certificate is exchanged on every click?

False?

consequences of multiple domain names

responds with server hello and digital certificate, but which certificate? interferes with load balancing and sends error message 

unique IP for each domain name

waste of IP addresses

multi-domain certificates

impractical to use in a shared hosting

SNI

server name indication, extension to TLS by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process

SNI privacy issues

NOT encrypted, so eavesdropper can see which site is being requested, exploited by security software, easier than IP address based filtering

ECH

encrypted client hello, enables encryption of the whole client hello message which is sent during the early stage of TLS negotiation, encrypts the payload with a public key,

encrypted SNI

encrypts the SNI rather than the whole hello client, a public key is attached to the DNS record, being phased out

ECH & ESNI adoption

only compatible with TLS 1.3, low adoption rates

TLS 1.2 problem

leakage of the pre-master or master secret, allowing an attacker to create key blocks for all connections in past and future

perfect forward secrecy

assurance that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised, it protects past session against future compromises, not offered by TLS 1.2, generates unique session key for every session

ephemeral key

different key is used for each connection, offered by DHE & ECDHE

DH

1. agree on prime and generator

2. generate a private key

3. generate a public key

4. exchange public key

5. calculate shared secret key

none can do authentication so must be paired with other algorithm

X.509 digital certificate 

public key is contained in the certificate, (RSA or DH), CA signs the certificate with RSA

TLS 1.2 uses RSA

to encrypt the initial communication with servers public key, & authenticate the sender with CA’s public key

cipher suite algorithms

key exchange algorithms, authentication/digital signature algorithms, bulk encryption algorithms, message authentication code algorithms

key exchnage in TLS 1.3

uses RSA only for authentication, uses DHE key exchange protocol

TLS 1.2

defined in 2008, TLS extension defined, AES cipher suites added, supports 37 cipher suites

TLS 1.3

in 2018, removed support for older encryption standards, removed support for weaker and lesser used elliptical curves, removed compression, supports inly 5 cipher suites

TLS 1.3 improvements

simplified handshake by removing RSA, relying only on DH

limitations of HTTP/2

recovery from packet loss stalls all object transmissions

HTTP/3

quick UDP internet connections QUIC, replaces TLS and TCP, implements reliable transport in application library

QUIC initial connection

client connects a server over TCP port 443 and does TLS handshaking, can be done in TLS 1.2 or below, server responds to the clients HTTP request

QUIC discovery

in the server HTTP respons eheaders, it includes an Alt-Svc header

QUIC subsequent connections

the client caches this information, simultaneously attempts to connect using QUIC over UDP port 443, maintains a fallback to the traditional TCP/TLS connection

security processing in QUIC

very first TCP?TLS connection is only for discovery, when the session is established the entire X.509 exchange/verification occurs again over QUIC

QUIC

TLS 1.3 is mandatory, HTTP/3 cannot work without QUIC, it replaces TCP with UDP while providing built-in encryption

SSLstrip

man in the middle attack, works on both SSL and TLS by transparently converting the secure HTTPS connection into a plain HTTP connection, removing the transport layer encryption protections

HTTP strict transport security

an IETF standard and a mechanism to enforce rules to prevent browsers from downgrading security; created in response to a series of attack profiles

rlogin

TCP port 513, only to unix host, info is unencrypted, BSD package incldues rcp and rsh

telnet

TCP port 23, can make interactive raw TCP sessions, no encryption or authentication, telnet daemons

risks of remote access protocols 

data travels in cleartext format, intermediate hosts can hijack sessions, authentication based on IP address and reusable passwords

secure shell SSH

replaces rlogin, telnet, and rsh, secure encrypted communication between two untrusted hosts over an insecure network, provides security at application layer (port 22)

SSH-2 architecture

applications, SSH user authentication protocol and connection protocol, SSH transport layer protocol, TCP

SSH transport layer protocol tasks

sets up secure channel between client and server; server authentication, encryption, integrity verification, and compression

SSH transport layer protocol steps

1. TCP connection setup

2. SSH version string exchange

3. exchange lists of supported algorithms

4. initial key exchange

5. server authentication (fingerprint & certficate)

SSH key exchange

gives a shared secret key K and a hash H

best effort

accept host key without check when connecting the first time to the server, save the host key in the local database, and check against the saved key on all future connections ot same server

higher level protocol services on top of SSH transport

SSH user authentication protocol, SSH connection protocol, filr etransfer

SSH user authentication protocol

authenticates the client-side user to the server, relies on data privacy and integrity provided by transport layer, CLIENT driven

SSH connection protocol

multiplexes the encrypted tunnel into several logical channels

protections by SSH

interceptions of cleartext passwords by intermediate hosts, manipulation of data by people in control of intermediate hosst (MITM), IP spoofing, IP source routing, DNS spoofing

SFTP

SSH secure file transfer protocol, driven by commands similar to FTP, provides general file system access

SCP

replaces RCP but data is encrypted, only file transfer no authentication, generally faster than SFTP

SSH is a replacement for what

in SSH, if the host key is not pre-populated at the client, can a connection be made with the server