transport sec
TRANSCRIPT
![Page 1: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/1.jpg)
Transport-level and Web Security (SSL / TLS, SSH)
Chapter 17 of Stallings
![Page 2: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/2.jpg)
Web Security HTTP is not a secure protocol
– simple and stateless client/server application running over TCP/IP
Added security measures needed– we will see SSL (Secure Socket Layer) and TLS
(Transport Layer Security)– HTTPS
• Secure HTTP protocol
Actually SSL support is provided for several other TCP/IP applications as well– POP3, SMTP, FTP, News, ...
![Page 3: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/3.jpg)
Web Security Threats and Countermeasures
– Integrity• data modification, insertion
– cryptographic checksums (HMAC)
– Confidentiality• eavesdropping on the net
– can be prevented by encryption
• theft from server machine– SSL may solve to some extent, but on-site
security measures still needed
– Authentication• impersonation, data forgery• we will see some cryptographic techniques
– Denial of service, hacked web servers
Sco
pe o
f SS
L / TLS
![Page 4: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/4.jpg)
Where to provide security?
Long-lasting discussion, no ultimate answer
have seen this lecture have seen and will see
![Page 5: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/5.jpg)
SSL (Secure Socket Layer)
originally developed by Netscape version 3 designed with public input subsequently Internet standardization
effort started at IETF– TLS (Transport Layer Security) working
group established– TLS can be viewed as SSL v3.1 and
compatible with SSL v3
![Page 6: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/6.jpg)
SSL Protocol Stack
adds security features– reliable and secure
end to end data transfer
SSL is not a single protocol– two-layers of protocols
• makes use of TCP (reliable end to end data transfer)
any upper layer protocol
![Page 7: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/7.jpg)
Two SSL concepts SSL session
– an association between client and server– define a set of cryptographic parameters created by
the Handshake Protocol– may be shared by multiple SSL connections
SSL connection– a transient, peer-to-peer, secure communication link– associated with (derived from) a SSL session– A session is used several times to create connections
Session vs. Connection– Sessions are used to avoid expensive negotiation for
crypto parameters for each connection Both are characterized by several parameters
– that define a session state or connection state
![Page 8: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/8.jpg)
Session state parameters Session identifier
– chosen by server Peer certificate
– certificate of the peer entity (server’s if the entity is client, client’s if the entity is server)
– may be null (which is the likely case for server) Compression method
– algorithm used for compression Cipher Spec
– bulk data encryption algorithm (AES, etc.) - may be null (rarely)– hash algorithm used in MAC calculation (MD5 or SHA-1 or SHA-2)
Master Secret – 48-bytes secret shared between client and server
Is resumable– a flag that is set if the session can be used later for new connections
![Page 9: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/9.jpg)
Connection State Parameters
Random numbers– server and client exchange– used as nonces during key exchange
MAC secret– secret key used for MAC operations
conventional encryption key initialization vector
– if CBC mode is used
![Page 10: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/10.jpg)
SSL Record Protocol serves to SSL connections
– uses connection parameters provides confidentiality and integrity also fragments (into 214 bytes chunks) and optionally
compresses data (in practice, no compression) confidentiality
– AES, IDEA, DES, 3DES, RC4, etc. message integrity
– using a MAC with shared secret key– similar to HMAC but pads are concatenated rather
than XORed
![Page 11: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/11.jpg)
SSL Record Protocol
header fields content type (higher layer protocol)
– change_cipher_spec, alert, handshake, application data version compressed length (or plaintext length if no compression) of the fragment
![Page 12: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/12.jpg)
Change Cipher Spec Protocol very simple protocol the new state established by the
handshake protocol is a pending state– that is, it is not yet valid
change cipher spec protocol (actually a single command exchanged between client and server) makes this pending state the current one– connection parameters change
will see its use in handshake protocol Record Protocol
Payload
![Page 13: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/13.jpg)
Alert Protocol conveys SSL-related alerts to peer entity secured using the record protocol (if any)
– and with current connection state parameters each message is two bytes
– one byte for level (severity)• warning (connection may resume) or fatal (connection is terminated)
– one byte for the alert code• unexpected message, bad record MAC, decompression failure• handshake failure (no common ground), illegal parameters
(inconsistent or unrecognized parameters)• no certificate, bad certificate, unsupported certificate, certificate
revoked, certificate expired, certificate unknown
Record Protocol Payload
![Page 14: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/14.jpg)
Handshake Protocol The most complex part of SSL Allows server and client:
– to authenticate each other– to negotiate encryption and MAC algorithms– to create cryptographic keys to be used– in general, to establish a session and then a
connection
handshake is done before any data is transmitted– so cannot assume a secure record protocol
![Page 15: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/15.jpg)
Handshake Protocol a series of messages in 4 phases
1. Establish Security Capabilities
2. Server Authentication and Key Exchange
3. Client Authentication and Key Exchange
4. Finish Handshake message format Message types
![Page 16: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/16.jpg)
Handshake Protocol
![Page 17: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/17.jpg)
Handshake Phase 1 – Establish Security Capabilities
Client Hello (a list of client’s preferences)– version: highest SSL version supported by client– client’s random
• also includes a timestamp• are used during key exchange to prevent replay attacks
– session ID• nonzero means client wants to use an existing session state for a
new connection state (abbreviated handshake); zero means new connection on a new session
– compression methods supported by client– Cipher Suite
• a list that contains the combination of crypto algorithms supported by the client in the order of preference
• each entry is a key exchange algorithm and a cipher spec
![Page 18: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/18.jpg)
Handshake Phase 1 – Establish Security Capabilities
Server Hello (response to client’s requests)– version: version proposed by client if also supported
by server; otherwise highest supported by server– server’s random
• same structure as client’s, but independent of client’s random
– session ID• if client offered one and it is also supported by server, then
the same ID (abbreviated handshake)• otherwise a new ID assigned by server
– compression methods chosen from the client’s list– Cipher Suite selected from the client’s list
![Page 19: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/19.jpg)
Key exchange methods How the conventional encryption and MAC keys
are exchanged?– actually first pre-master secret is exchanged– master secret is derived from pre-master
secret• At this point session is created
– other keys are derived from the master secret• At this point connection is created
![Page 20: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/20.jpg)
Key exchange methods – cont’d Rephrase question: how is the pre-master secret
exchanged?– RSA
• server provides its RSA certificate (that has the server’s public key), client encrypts the pre-master secret and sends it
– Fixed Diffie-Hellman (DH)• Server and client DH parameters are fixed and sent in
certificates
– Ephemeral DH• server and client certificates contain RSA or DSS public keys• server creates DH parameters (used one-time) and signs by its
private key. For client, see later.
– Anonymous DH• no certificates, no authentication, just send out DH parameters• vulnerable to man-in-the-middle-attacks
![Page 21: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/21.jpg)
Some Cipher Specs Fields
Cipher algorithm and key size– RC4, RC2, DES, 3DES, DES40 (40-bit DES),
IDEA, AES, etc. Hash algorithm for MAC
– MD5 or SHA-1 Cipher type
– stream or block IV size
– size of the init. vector for CBC mode
![Page 22: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/22.jpg)
Handshake Phase 2: Server Auth. and Key Exchange
Certificate is needed except for anon-DH (anon-DH is not used most of the time)– Certificate is the basis for server authentication– if fixed DH, then certificate contains enough information for key
exchange (so server key exchange message is not needed)
![Page 23: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/23.jpg)
Handshake Phase 2: Server Auth. and Key Exchange
Server Key Exchange– not needed for
• fixed DH and RSA key exchange
– message content depends on the key exchange method agreed
• Anon-DH– message contains public DH parameters and server’s DH
public key
• Ephemeral DH– same as anon-DH plus a signature on them
– Signatures contain random values (that are exchanged in hello phase) to resist against replay attacks
![Page 24: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/24.jpg)
Handshake Phase 2: Server Auth. and Key Exchange
Certificate Request Message– although not common in practice, server may
request client to send its certificate • to authenticate the client
– two fields: certificate type and acceptable CAs• a list of them
– Certificate types• fixed DH (certificate may be signed with RSA or DSS)• ephemeral DH (certificate may contain RSA or DSS key)• signature only (not used for key exchange but for auth.)
– Certificate may contain RSA or DSS key
Server Hello Done message– server is finished and will wait for client’s response
![Page 25: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/25.jpg)
Handshake Phase 3: Client Auth. and Key Exchange
Upon receipt of server hello done– client checks the server certificate and server hello parameters– after that client starts sending its own messages
Client’s Certificate – is sent if requested and available
![Page 26: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/26.jpg)
Handshake Phase 3: Client Auth. and Key Exchange
Client Key exchange message– content depends on the key exchange method agreed– RSA
• 48-byte pre-master secret is encrypted using server’s RSA key (obtained at phase 2)
– fixed-DH• client DH parameters are in client certificate, so key exchange
message is null
– Anon or ephemeral DH• Client DH parameters and DH public key are sent• no signature even for ephemeral DH
– no client authentication and authenticated key exchange so far (only key exchange)
![Page 27: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/27.jpg)
Handshake Phase 3: Client Auth. and Key Exchange
Certificate Verify message– in client key exchange message, the client is not
authenticated• anyone could send the key exchange message
– a method for authentication is the certificate verify message• client shows ownership of private key that corresponds to the public
key in client certificate by signing a hash that contains the master secret and handshake messages
• except for fixed DH that does not contain a signature key
– what about authentication for fixed DH case?• no real authentication but the attacker cannot produce the pre-
master and master secrets since it does not know the DH private key (so there is a kind of an implied auth.)
![Page 28: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/28.jpg)
Handshake Phase 4: Finish At the end of Phase 3, both client and server can
calculate keys Phase 4 is wrap-up phase
Change cipher spec messages– to make the pending cipher spec the current one
![Page 29: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/29.jpg)
Handshake Phase 4: Finish
Finished message– a MAC on exchanged handshake messages using
the master secret– to verify that handshake is successful and both
parties have the same master secret– client’s finished is verified by server and vice versa– the connection state of the record protocol that
encrypts and MACs the finished message is the new one
• so this is also verification of all the keys that are recently created
![Page 30: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/30.jpg)
Master Secret Creation Master Secret
– 48-byte value generated for a session two stage creation
– pre-master secret is exchanged during handshake• using RSA (client creates, encrypts and sends, server decrypts) or DH
(both calculates the same secret)
– master secret is calculated using pre-master secret and random nonces
master_secret = MD5(pre_master_secret || SHA('A' || pre_master_secret ||
ClientHello.random || ServerHello.random)) || MD5(pre_master_secret || SHA('BB' || pre_master_secret ||
ClientHello.random || ServerHello.random)) || MD5(pre_master_secret || SHA('CCC' || pre_master_secret ||
ClientHello.random || ServerHello.random))
![Page 31: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/31.jpg)
Generation of cryptographic parameters
encryption keys, MAC secrets, IV are to be generated from a key block obtained from the master secret
key_block = MD5(master_secret || SHA('A' || master_secret ||
ServerHello.random || ClientHello.random)) || MD5(master_secret || SHA('BB' || master_secret ||
ServerHello.random || ClientHello.random)) || MD5(master_secret || SHA('CCC' || master_secret ||
ServerHello.random || ClientHello.random)) || [...] until enough output has been
generated. This is actually a kind of a PRNG
![Page 32: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/32.jpg)
Abbreviated Handshake We have said that a particular SSL session can serve
to different SSL connections– Abbreviated handshake is the mechanism for that
During phase-1 if both parties agree on using an existing session ID, then that means they run abbreviated handshake– that session’s master secret (which is already stored) and
new random nonces exchanged during phase-1 are directly used for the generation of the keys
• Thus, phase 2 and 3 are skipped (that is why it is abbreviated)• Phase 4 is the same as full handshake
![Page 33: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/33.jpg)
TLS (Transport Layer Security)
TLS is a proposed Internet Standard (RFC 5246)– similar to SSL v3, some differences are given here
Version number– record format is the same, but the major version 3,
minor version 3 (v3.3) MAC
– TLS uses HMAC with pads XORed (unlike SSL where pads are appended)
additional alert codes
![Page 34: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/34.jpg)
TLS (Transport Layer Security) Same cipher suites of SSL except Fortezza
– actually it is not common in SSL v3 either No ephemeral client certificates in TLS
– since signature-only certificates are used for that purpose
some changes in certificate verify and finished message calculations
a different Pseudorandom function (PRF) based on HMAC– master secret and key block calculations use PRF in
TLS
![Page 35: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/35.jpg)
HTTPS HTTPS (HTTP over SSL/TLS)
– combination of HTTP & SSL/TLS to secure communications between browser & web server
• documented in RFC2818• no fundamental change using either SSL or TLS; both
are referred as HTTPS use https:// URL rather than http://
– use port 443 rather than 80 encrypts
– URL, document contents, form data, cookies, HTTP headers
![Page 36: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/36.jpg)
HTTPS Connection Initiation
SSL/TLS handshake is first done– HTTP client (browser) acts as SSL/TLS
client After the handshake HTTP request(s)
are sent– Actually all HTTP data should be sent
through SSL/TLS record protocol
![Page 37: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/37.jpg)
HTTPS Connection Closure
connection closure– have “Connection: close” in HTTP headers
• which normally causes to close the TCP connection• but there is SSL/TLS protocols between HTTP and
TCP• thus, SSL/TLS should control connection closure at
TCP level
– SSL/TLS level exchange close_notify alerts– can then close TCP connection
![Page 38: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/38.jpg)
Secure Shell (SSH) protocol for secure network communications
– designed to be simple & inexpensive
SSH1 provided secure remote logon facility– replace TELNET & other insecure schemes– also has more general client/server capability
• Can be used for FTP, for example
SSH2 was documented in RFCs 4250 through 4254
SSH clients & servers are widely available (even in OSs)
![Page 39: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/39.jpg)
SSH Protocol Stack
Also provides forward secrecy
![Page 40: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/40.jpg)
SSH Transport Layer Protocol Server authentication
– PKC operation using the host key pair (public/private)
– A server may have different host keys
– Clients should know the public host keys of the server• May keep in a database• May obtain in a cerificate• Or just use it without any guarantee (the mostly used
method) but vulnerable to MitM attacks
Packet exchange– establish TCP connection
– can then exchange data• identification string exchange, algorithm negotiation, key
exchange, end of key exchange, service request
– using specified packet format
![Page 41: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/41.jpg)
Identification string exchange– To know which SSH version,
which SSH implementation Algorithm Negotitation
– For the crypto algorithms (key exchange, encryption, MAC) and compression algo.
– A list in the order of preference of the client
– For each category, the algorithm chosen is the first algorithm on the client's list that is also supported by the server.
SSH Transport Layer Protocol Packet Exchanges
![Page 42: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/42.jpg)
SSH Transport Layer Protocol Packet Exchanges
key exchange– Only two exchanges– Diffie-Hellman based – Also signed by the server (host private key)– As a result (i) two sides now share a
master key K. (ii) the server has been authenticated to the client.
Then, encryption, MAC keys and IV are derived from the master key
End of key exchange– To signal the end of key exchange process– Encrypted and MACed using the new keys
Service Request: to initiate either user authentication or connection protocol
![Page 43: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/43.jpg)
SSH Transport Layer Protocol Packet Formation
![Page 44: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/44.jpg)
SSH User Authentication Protocol Authentication of client to server First client and server agree on an authentication
method– Then a sequence of exchanges to perform that method
– Several authentication methods may be performed one after another
authentication methods– public-key
• Client signs a message and server verifies
– password
• Client sends pasword which is encrypted and MACed using the keys agreed
![Page 45: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/45.jpg)
SSH Connection Protocol runs on SSH Transport Layer Protocol assumes secure authentication connection
– which is called tunnel used for multiple logical channels
– SSH communications use separate channels– either side can open with unique id number– flow controlled via sliding window mechanism– have three stages:
• opening a channel, data transfer, closing a channel
![Page 46: Transport Sec](https://reader033.vdocument.in/reader033/viewer/2022042702/55cf8f3c550346703b9a45d9/html5/thumbnails/46.jpg)
SSH Connection Protocol Exchange