View
234
Download
1
Category
Tags:
Preview:
Citation preview
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
Cryptography and Network Security 2
Cryptography and Network Security 3
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
Cryptography and Network Security 4
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
Cryptography and Network Security 5
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
Cryptography and Network Security 8
SSL Architecture
Cryptography and Network Security 9
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
Cryptography and Network Security 11
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
Cryptography and Network Security 25
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
Cryptography and Network Security 26
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
Cryptography and Network Security 27
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
Cryptography and Network Security 33
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
Cryptography and Network Security 34
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
Cryptography and Network Security 35
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.
Cryptography and Network Security 36
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
Cryptography and Network Security 37
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.
Cryptography and Network Security 38
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
Cryptography and Network Security 43Security on the WWW
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
Cryptography and Network Security 44Security on the WWW
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
Cryptography and Network Security 45Security on the WWW
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
Cryptography and Network Security 46Security on the WWW
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
Cryptography and Network Security 47Security on the WWW
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
Cryptography and Network Security 48Security on the WWW
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
Cryptography and Network Security 49Security on the WWW
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
Cryptography and Network Security 62
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
Cryptography and Network Security 63
SET Components
Cryptography and Network Security 64
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
Cryptography and Network Security 65
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
Cryptography and Network Security 66
Purchase Request – Customer
Cryptography and Network Security 67
Purchase Request – Merchant
Cryptography and Network Security 68
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
Cryptography and Network Security 69
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
Cryptography and Network Security 70
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
Recommended