Cryptography and Network Security 1 Csc 8222 Network Security Web and Transport-level Security...

Cryptography and Network Security 1

Csc 8222 Network Security

Web and Transport-level Security

WenZhan Song

Web security

See the top 10 security issues in web applications: http://www.slideshare.net/devnology/the-top-10-security-issues-in-web-applications


http://www.slideshare.net/devnology/the-top-10-security-issues-in-web-applications




Introduction

Introduction Presentation of SSL

• The inner workings of SSL• Attacks on SSL

HTTPS vs S-HTTP• Comparison with SSL/TLS• Attacks on S-HTTP

Other aspects of Web security• TLS• IPSec, Kerberos, SET

Conclusion


Web Security

Web now widely used by business, government, individuals

but Internet & Web are vulnerable have a variety of threats

integrity confidentiality denial of service authentication

need added security mechanisms


SSL (Secure Socket Layer)

transport layer security service originally developed by Netscape version 3 designed with public input subsequently became Internet standard

known as TLS (Transport Layer Security) uses TCP to provide a reliable end-to-

end service

Network Security

SSL: Secure Sockets Layerwidely deployed security

protocol supported by almost all browsers, web

servers https billions $/year over SSL

original design: Netscape, 1993

variation -TLS: transport layer security, RFC 2246

provides confidentiality integrity authentication

original goals: Web e-commerce transactions encryption (especially credit-

card numbers) Web-server authentication optional client authentication minimum hassle in doing

business with new merchantavailable to all TCP

applications secure socket interface

Network Security

SSL and TCP/IP

Application

TCP

IP

Normal Application

Application

SSL

TCP

IP

Application with SSL

• SSL provides application programming interface (API)to applications• C and Java SSL libraries/classes readily available•SSL has two layers of protocols


SSL Architecture


SSL Architecture

SSL session an association between client & server created by the Handshake Protocol define a set of cryptographic parameters may be shared by multiple SSL connections

SSL connection a transient, peer-to-peer, communications link associated with 1 SSL session

Network Security

handshake: ClientHello

handshake: ServerHello

handshake: Certificate

handshake: ServerHelloDone

handshake: ClientKeyExchangeChangeCipherSpec

handshake: Finished

ChangeCipherSpec

handshake: Finished

application_data

application_data

Alert: warning, close_notify

SSL Architecture

TCP Fin follow

Everythinghenceforth

is encrypted


SSL Record Protocol

confidentiality using symmetric encryption with a shared secret key

defined by Handshake Protocol IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-

40, RC4-128 message is compressed before encryption

message integrity using a MAC with shared secret key similar to HMAC but with different padding

Network Security

SSL Record Protocol

data

data fragment

data fragment

MAC MAC

encrypteddata and MAC

encrypteddata and MAC

recordheader

recordheader

record header: content type; version; length MAC: includes sequence number, MAC key Mx

fragment: each SSL fragment 214 bytes (~16 Kbytes)

fragment and compress

Network Security

Toy SSL: a simple secure channel

handshake: Alice and Bob use their certificates, private keys to authenticate each other and exchange shared secret

key derivation: Alice and Bob use shared secret to derive set of keys

data transfer: data to be transferred is broken up into series of records

connection closure: special messages to securely close connection

Network Security

Toy: A simple handshake

MS = master secret EMS = encrypted master secret

hello

certificate

KB+(MS) = EMS

Network Security

Toy: Key derivation

Considered bad to use same key for more than one cryptographic operation use different keys for message authentication code (MAC) and

encryption

four keys: Kc = encryption key for data sent from client to server

Mc = MAC key for data sent from client to server

Ks = encryption key for data sent from server to client

Ms = MAC key for data sent from server to client

keys derived from key derivation function (KDF) takes master secret and (possibly) some additional random data

and creates the keys

Network Security

Toy: Data Records why not encrypt data in constant stream as we

write it to TCP? where would we put the MAC? If at end, no message integrity

until all data processed. E.g., with instant messaging, how can we do integrity check over

all bytes sent before displaying? instead, break stream in series of records

Each record carries a MAC Receiver can act on each record as it arrives

issue: in record, receiver needs to distinguish MAC from data want to use variable-length records

length data MAC

Network Security

Toy: Sequence Numbers

attacker can capture and replay record or re-order records

solution: put sequence number into MAC: MAC = MAC(Mx, sequence||data)

Note: no sequence number field

attacker could still replay all of the records use random nonce

Network Security

Toy: Control information

truncation attack: attacker forges TCP connection close segment One or both sides thinks there is less data than there

actually is.

solution: record types, with one type for closure type 0 for data; type 1 for closure

MAC = MAC(Mx, sequence||type||data)

length type data MAC

Network Security

Toy SSL: summary

hello

certificate, nonce

KB+(MS) = EMS

type 0, seq 1, datatype 0, seq 2, data

type 0, seq 1, data

type 0, seq 3, datatype 1, seq 4, close

type 1, seq 2, close

encr

ypte

d

bob.com

Network Security

Toy SSL isn’t complete

how long are fields? which encryption protocols? want negotiation?

allow client and server to support different encryption algorithms

allow client and server to choose together specific algorithm before data transfer

Network Security

SSL Cipher Suite cipher suite

public-key algorithm symmetric encryption algorithm MAC algorithm

SSL supports several cipher suites

negotiation: client, server agree on cipher suite client offers choice server picks one

Common SSL symmetric ciphers DES – Data Encryption

Standard: block 3DES – Triple strength: block RC2 – Rivest Cipher 2: block RC4 – Rivest Cipher 4: stream

SSL Public key encryption RSA


SSL Handshake Protocol

allows server & client to: authenticate each other to negotiate encryption & MAC algorithms to negotiate cryptographic keys to be used

comprises a series of messages in phases Establish Security Capabilities Server Authentication and Key Exchange Client Authentication and Key Exchange Finish


General purpose

Two step process:• Handshake : exchange private keys using a public key encryption

algorithm• Data transmission: exchange the required data using a private key

encryption

`

1.Handshake

2. Data transmission


SSLHandshake Protocol

Table 6.2 SSL Handshake Protocol Message Types

Network Security

SSL Handshake

1. client sends list of algorithms it supports, along with client nonce

2. server chooses algorithms from list; sends back: choice + certificate + server nonce

3. client verifies certificate, extracts server’s public key, generates pre_master_secret, encrypts with server’s public key, sends to server

4. client and server independently compute encryption and MAC keys from pre_master_secret and nonces

5. client sends a MAC of all the handshake messages

6. server sends a MAC of all the handshake messages

Network Security

Key derivation

client nonce, server nonce, and pre-master secret input into pseudo random-number generator. produces master secret

master secret and new nonces input into another random-number generator: “key block” Because of resumption: TBD

key block sliced and diced: client MAC key server MAC key client encryption key server encryption key client initialization vector (IV) server initialization vector (IV)

Network Security

SSL Handshake (cont.)

last 2 steps protect handshake from tampering

client typically offers range of algorithms, some strong, some weak

man-in-the middle could delete stronger algorithms from list

last 2 steps prevent this Last two messages are encrypted

Network Security

SSL Handshake (cont.)

why two random nonces? suppose Trudy sniffs all messages

between Alice & Bob next day, Trudy sets up TCP connection

with Bob, sends exact same sequence of records Bob (Amazon) thinks Alice made two separate orders

for the same thing solution: Bob sends different random nonce for each

connection. This causes encryption keys to be different on the two days

Trudy’s messages will fail Bob’s integrity check


SSL Change Cipher Spec Protocol

one of 3 SSL specific protocols which use the SSL Record protocol

a single message causes pending state to become current hence updating the cipher suite in use


SSL Alert Protocol

conveys SSL-related alerts to peer entity severity

warning or fatal

specific alert unexpected message, bad record mac,

decompression failure, handshake failure, illegal parameter

close notify, no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired, certificate unknown

compressed & encrypted like all SSL data


Attacks on SSL

Certificate Injection Attack• The list of trusted Certificate Authorities is altered• Can be avoided by upgrading the OS or switching to a safer one.

Man in the Middle • Cipher Spec Rollback : regresses the public key encryption algorithms • Version Rollback : regression from SSL 3.0 to weaker SSL 2.0• Algorithm rollback : modify public encryption method• Truncation attack : TCP FIN|RST used to terminate connection

Timing attack• Can be avoided by randomly delaying the computations

Brute force• Can be used on servers that accept small key sizes: 40 bits for symmetric

encryptions and 512 for the asymmetric one.


TLS (Transport Layer Security)

IETF standard RFC 2246 similar to SSLv3 with minor differences

in record format version number uses HMAC for MAC a pseudo-random function expands secrets has additional alert codes some changes in supported ciphers changes in certificate negotiations changes in use of padding


TLS

TLS was developed by IETF to replace SSL version 3.

• Based on SSL version 3, with some changes:

• Replaced FORTEZZA key exchange option with DSS.

• Include the hash method HMAC used by IPSec for authentication in IP headers.

• More differentiation between sub-protocols.

• TLS has mechanisms for backwards compatibility with SSL.


TLS

TLS has about 30 possible cipher ‘suites’, combinations of key exchange, encryption method, and hashing method.

• Key exchange includes: RSA, DSS, Kerberos

• Encryption includes: IDEA(CBC), RC2, RC4, DES, 3DES, and AES

• Hashing: SHA and MD5

(Note: Some of the suites are intentionally weak export versions.)

HTTPS(HTTP over SSL) Refers to the combination of HTTP and SSL to

implement secure communication between a Web browser and a Web server

The HTTPS capability is built into all modern Web browsers

A user of a Web browser will see URL addresses that begin with https:// rather than http://

If HTTPS is specified, port 443 is used, which invokes SSL

Documented in RFC 2818, HTTP Over TLS There is no fundamental change in using HTTP over either SSL or 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 Contents of the document Contents of browser forms Cookies sent from browser to server and from server to browser Contents of HTTP header

Connection Initiation

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”

An unannounced TCP closure could be evidence of some sort of attack so the HTTPS client should issue some sort of security warning when this occurs

Cryptography and Network Security 42Security on the WWW

C- Secure-HTTP

Presentation of S-HTTP

Designed by E. Rescorla and A. Schiffman of EIT to secure HTTP connections

Proposed in 1994 but never used commercially

Not to be confused with HTTPS: encrypts HTTP messages at the application level

ABCD


C- Secure-HTTP

Location of S-HTTPABCD

Internet Protocol(IP)

Transmission Control Protocol (TCP)

Secure-HTTPMessage encryption and

signature

Application Layer:HTTP message

HTTP-specific message encryption

Can possibly be used over a secure channel

Designed to be compatible with HTTP for handling at lower layers


C- Secure-HTTP

S-HTTP vs. SSL/TLS

HTTP-specific vs. general purpose SSL (IMAPS, POPS, LDAPS…)

Burden of encryption not on transmission/reception but rather on message production/unpacking

Similar set of available ciphers, plus added capabilities for signing (DSS, RSA)

Very general specifications, leaving a lot to implement and a potential for incompatible implementations

Only one reference implementation in NCSA Mosaic

ABCD


C- Secure-HTTP

S-HTTP vs. HTTPS: functionalitiesABCD

Security Service S-HTTP HTTPS

Privacy Public or private cryptosystemEncryption of the complete HTTP transaction

Symmetric key cryptosystemComplete communication encryption

Integrity Simple MAC or signing MAC only

Authentication Key management on the keys used, or digital signature

During the initial public key exchange (server auth. mandatory, client auth. optional)

Non-repudiation Digital signature Not provided

S-HTTP can make use of key management Non-repudiation is not provided by SSL (e.g., HTTPS) Signing is optional, but a major attraction to S-HTTP


C- Secure-HTTP

S-HTTP vs. HTTPS: proxy traversalABCD

SSL-aware proxyExternal

secure server Enterprise environment

Proxy traversal: SSL connection

OR

S-HTTP-aware proxyExternal

secure server Enterprise environment

Proxy traversal: S-HTTP messaging

SSL tunnel SSL tunnel

Encrypted data

Authentication

cleartext


C- Secure-HTTP

S-HTTP inner working

Message-based encryption Superset of HTTP: “outer” envelope Specific headers added

ABCD

S-HTTP message

S-HTTP headers

HTTP payload headers:Security-Scheme, Encryption-Identity,Certificate-Info… + regular HTTP headers

HTTP message body

Request:Secure*Secure-HTTP/1.2

Response:Secure-HTTP/1.2 200 OK


C- Secure-HTTP

S-HTTP attacks

Basically the same as on SSL, since the ciphers are the same

Default values more secure in S-HTTP than SSL at the time of proposal (e.g. DES vs. RC4)

S-HTTP generally stronger by design (more resilient to proxy compromising)

More complex and wider specifications create a potential for faulty implementations

No real-world use to field test the actual security of S-HTTP

ABCD


D- Other protocols

HTTP has an authentication scheme as part of its original protocol.

HTTP Basic Authentication

ABCD

• Supported by almost all browsers and web servers.

• Password and username are sent in clear text (base64 encoded) in the HTTP request message.

• Obviously not secure enough for sensitive information.

This scheme is being replaced by the slightly more secure HTTP Digest Authentication, which sends a MD5 hash of the password and other information.

Secure Shell (SSH)Secure Shell (SSH)

Transport Layer Transport Layer ProtocolProtocol

• Server authentication occurs at the transport Server authentication occurs at the transport layer, based on the server possessing a layer, based on the server possessing a public/private key pairpublic/private key pair

• A server may have multiple host keys using A server may have multiple host keys using multiple different asymmetric encryption multiple different asymmetric encryption algorithmsalgorithms

• Multiple hosts may share the same host keyMultiple hosts may share the same host key• The server host key is used during key exchange The server host key is used during key exchange

to authenticate the identity of the hostto authenticate the identity of the host• RFC 4251 dictates two alternative trust models:RFC 4251 dictates two alternative trust models:

• The client has a local database that associates each The client has a local database that associates each host name with the corresponding public host keyhost name with the corresponding public host key

• The host name-to-key association is certified by a The host name-to-key association is certified by a trusted certification authority (CA); the client only trusted certification authority (CA); the client only knows the CA root key and can verify the validity of knows the CA root key and can verify the validity of all host keys certified by accepted CAsall host keys certified by accepted CAs

* = Required** = Recommended

Table 6.3

SSH

Transport

Layer

Cryptographic

Algorithms

Authentication MethodsAuthentication Methods

Connection ProtocolConnection Protocol

• The SSH Connection Protocol runs on top of the SSH The SSH Connection Protocol runs on top of the SSH Transport Layer Protocol and assumes that a secure Transport Layer Protocol and assumes that a secure authentication connection is in useauthentication connection is in use• The secure authentication connection, referred to as a The secure authentication connection, referred to as a

tunnel, tunnel, is used by the Connection Protocol to multiplex a is used by the Connection Protocol to multiplex a number of logical channelsnumber of logical channels

• Channel mechanismChannel mechanism• All types of communication using SSH are supported using All types of communication using SSH are supported using

separate channelsseparate channels• Either side may open a channelEither side may open a channel• For each channel, each side associates a unique channel For each channel, each side associates a unique channel

numbernumber• Channels are flow controlled using a window mechanismChannels are flow controlled using a window mechanism• No data may be sent to a channel until a message is No data may be sent to a channel until a message is

received to indicate that window space is availablereceived to indicate that window space is available• The life of a channel progresses through three stages: The life of a channel progresses through three stages:

opening a channel, data transfer, and closing a channelopening a channel, data transfer, and closing a channel

Channel TypesChannel Types

Four channel types are recognized in the SSH Connection Protocol specification

Port ForwardingPort Forwarding

• One of the most useful features of SSHOne of the most useful features of SSH

• Provides the ability to convert any insecure TCP Provides the ability to convert any insecure TCP connection into a secure SSH connection (also connection into a secure SSH connection (also referred to as SSH tunneling)referred to as SSH tunneling)

• Incoming TCP traffic is delivered to the Incoming TCP traffic is delivered to the appropriate application on the basis of the port appropriate application on the basis of the port number (a port is an identifier of a user of TCP)number (a port is an identifier of a user of TCP)

• An application may employ multiple port An application may employ multiple port numbersnumbers


Secure Electronic Transactions (SET) open encryption & security specification to protect Internet credit card

transactions developed in 1996 by Mastercard, Visa

etc not a payment system rather a set of security protocols &

formats secure communications amongst parties trust from use of X.509v3 certificates privacy by restricted info to those who need it


SET Components


SET Transaction

1. customer opens account2. customer receives a certificate3. merchants have their own certificates4. customer places an order5. merchant is verified6. order and payment are sent7. merchant requests payment authorization8. merchant confirms order9. merchant provides goods or service10. merchant requests payment


Dual Signature

customer creates dual messages order information (OI) for merchant payment information (PI) for bank

neither party needs details of other but must know they are linked use a dual signature for this

signed concatenated hashes of OI & PI


Purchase Request – Customer


Purchase Request – Merchant


Purchase Request – Merchant

1. verifies cardholder certificates using CA sigs2. verifies dual signature using customer's

public signature key to ensure order has not been tampered with in transit & that it was signed using cardholder's private signature key

3. processes order and forwards the payment information to the payment gateway for authorization (described later)

4. sends a purchase response to cardholder


Payment Gateway Authorization1. verifies all certificates2. decrypts digital envelope of authorization block to

obtain symmetric key & then decrypts authorization block

3. verifies merchant's signature on authorization block4. decrypts digital envelope of payment block to obtain

symmetric key & then decrypts payment block5. verifies dual signature on payment block6. verifies that transaction ID received from merchant

matches that in PI received (indirectly) from customer7. requests & receives an authorization from issuer8. sends authorization response back to merchant


Payment Capture

merchant sends payment gateway a payment capture request

gateway checks request then causes funds to be transferred to

merchants account notifies merchant using capture

response

SummarySummary

• Web security considerationsWeb security considerations• Web security threatsWeb security threats• Web traffic security approachesWeb traffic security approaches

• Secure sockets layerSecure sockets layer• SSL architectureSSL architecture• SSL record protocolSSL record protocol• Change cipher spec protocolChange cipher spec protocol• Alert protocolAlert protocol• Handshake protocolHandshake protocol• Cryptographic computationsCryptographic computations

• HTTPSHTTPS• Connection initiationConnection initiation• Connection closureConnection closure

• TransTransport layer securityport layer security• Version numberVersion number• Message authentication codeMessage authentication code• Pseudorandom functionPseudorandom function• Alert codesAlert codes• Cipher suitesCipher suites• Client certificate typesClient certificate types• Certificate_verify and Certificate_verify and

finished messagesfinished messages• Cryptographic computationsCryptographic computations• Padding Padding

• Secure shell (SSH)Secure shell (SSH)• Transport layer protocolTransport layer protocol• User authentication User authentication

protocolprotocol• Communication protocolCommunication protocol

• SET secure credit card SET secure credit card payment protocolspayment protocols

Cryptography and Network Security 1 Csc 8222 Network Security Web and Transport-level Security...

Documents

Transcript of Cryptography and Network Security 1 Csc 8222 Network Security Web and Transport-level Security...