Transcript Transport-level Security

Csc 8222 Network Security
Web and Transport-level Security
WenZhan Song
Cryptography and Network Security
1
Web security
 See the top 10 security issues in web
applications:
http://www.slideshare.net/devnology/thetop-10-security-issues-in-web-applications
Cryptography and Network Security
2
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
 Transport security
• TLS
• SSH, SET
 Conclusion
•
Cryptography and Network Security
3
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
4
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
Cryptography and Network Security
5
SSL: Secure Sockets Layer
 widely 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
Network Security
 original goals:
 Web e-commerce transactions
 encryption (especially creditcard numbers)
 Web-server authentication
 optional client authentication
 minimum hassle in doing
business with new merchant
 available to all TCP
applications
 secure
socket interface
SSL and TCP/IP
Application
Application
SSL
TCP
TCP
IP
IP
Normal Application
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
Network Security
SSL Architecture
Cryptography and Network Security
8
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

Cryptography and Network Security
9
SSL
Architecture
Everything
henceforth
is encrypted
TCP Fin follow
Network Security
SSL Record Protocol
 confidentiality
using symmetric encryption with a shared secret key
defined by Handshake Protocol
 IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC440, RC4-128
 message is compressed before encryption

 message integrity
using a MAC with shared secret key
 similar to HMAC but with different padding

Cryptography and Network Security
11
SSL Record Protocol
data
fragment and compress
data
fragment
record
header
data
fragment
MAC
encrypted
data and MAC
record
header
MAC
encrypted
data and MAC
record header: content type; version; length
MAC: includes sequence number, MAC key Mx
fragment: each SSL fragment 214 bytes (~16 Kbytes)
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
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
Network Security
data
MAC
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
Network Security
data
MAC
Toy SSL: summary
encrypted
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

Network Security
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

Cryptography and Network Security
25
General purpose
1.Handshake
`
2. Data transmission
 Two step process:
• Handshake : exchange private keys using a public key encryption
algorithm
• Data transmission: exchange the required data using a private key
encryption
Cryptography and Network Security
26
SSL
Handshake
Protocol
Cryptography and Network Security
27
Table 6.2 SSL Handshake Protocol Message Types
SSL Handshake
1.
2.
3.
4.
5.
6.
client sends list of algorithms it supports, along
with client nonce
server chooses algorithms from list; sends back:
choice + certificate + server nonce
client verifies certificate, extracts server’s
public key, generates pre_master_secret,
encrypts with server’s public key, sends to
server
client and server independently compute
encryption and MAC keys from
pre_master_secret and nonces
client sends a MAC of all the handshake messages
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
Network Security
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
33
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
34
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
•
Can be avoided by randomly delaying the computations
•
Can be used on servers that accept small key sizes: 40 bits for symmetric
encryptions and 512 for the asymmetric one.
•
•
•
 Timing attack
 Brute force
Cryptography and Network Security
35
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
36
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
37
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.)
Cryptography and Network Security
38
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
For HTTPS, the agent acting as
the HTTP client also acts as the
TLS client
• The client initiates a connection to the server
on the appropriate port and then sends the
TLS ClientHello to begin the TLS handshake
• When the TLS handshake has finished, the
client may then initiate the first HTTP
request
• All HTTP data is to be sent as TLS application
data
There are three levels of awareness of
a connection in HTTPS:
• At the HTTP level, an HTTP client requests a
connection to an HTTP server by sending a
connection request to the next lowest layer
• Typically the next lowest layer is TCP, but it
may also be TLS/SSL
• At the level of TLS, a session is established
between a TLS client and a TLS server
• This session can support one or more
connections at any time
• A TLS request to establish a connection begins
with the establishment of a TCP connection
between the TCP entity on the client side and
the TCP entity on the server side
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
A
B
C
D
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
Security on the WWW
Cryptography and Network Security
42
A
B
C
D
C- Secure-HTTP
Location of S-HTTP
Secure-HTTP
Message encryption and
signature
Application Layer:
HTTP message
Transmission Control Protocol
(TCP)
HTTP-specific message
encryption
 Can possibly be used
over a secure channel
 Designed to be
compatible with HTTP
for handling at lower
layers

Internet Protocol
(IP)
Security on the WWW
Cryptography and Network Security
43
A
B
C
D
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
Security on the WWW
Cryptography and Network Security
44
A
B
C
D
C- Secure-HTTP
S-HTTP vs. HTTPS: functionalities
Security Service
S-HTTP
HTTPS
Privacy
Public or private cryptosystem
Encryption of the complete HTTP
transaction
Symmetric key cryptosystem
Complete 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
Security on the WWW
Cryptography and Network Security
45
A
B
C
D
C- Secure-HTTP
S-HTTP vs. HTTPS: proxy traversal
Proxy traversal: SSL connection
OR
cleartext
SSL tunnel
External
secure server
SSL tunnel
SSL-aware proxy
Enterprise environment
Proxy traversal: S-HTTP messaging
Encrypted data
Authentication
External
secure server
Security on the WWW
S-HTTP-aware proxy
Enterprise environment
Cryptography and Network Security
46
A
B
C
D
C- Secure-HTTP
S-HTTP inner working
 Message-based encryption
 Superset of HTTP: “outer” envelope
 Specific headers added
S-HTTP message
S-HTTP headers
HTTP payload headers:
Security-Scheme, Encryption-Identity,
Certificate-Info… + regular HTTP headers
Request:
Secure*Secure-HTTP/1.2
Response:
Secure-HTTP/1.2 200 OK
HTTP message body
Security on the WWW
Cryptography and Network Security
47
A
B
C
D
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 SHTTP
Security on the WWW
Cryptography and Network Security
48
A
B
C
D
D- Other protocols
HTTP Basic Authentication
HTTP has an authentication scheme as part of its original
protocol.
• 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.
Security on the WWW
Cryptography and Network Security
49
Secure Shell (SSH)
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
SSH2 fixes a number of
security flaws in the
original scheme
• Is documented as a
proposed standard in
IETF RFCs 4250 through
4256
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 email
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 trust models:
• The client has a local database that associates each host
name with the corresponding public host key
• The host name-to-key association is certified by a trusted
certification authority (CA); the client only knows the CA
root key and can verify the validity of all host keys certified
by accepted CAs
Table 6.3
SSH
Transport
Layer
Cryptographic
Algorithms
* = Required
** = Recommended
Authentication
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 and, if so, it checks whether the signature is
correct
Password
• The client sends a message containing a plaintext password, which is
protected by encryption by the Transport Layer Protocol
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
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
• 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 channel
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, a system
command, or some built-in subsystem
• Once a session channel is opened, subsequent requests are used to start the remote
program
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
Forwarded-tcpip
• Remote port forwarding
Direct-tcpip
• Local port forwarding
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 numbers
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
62
SET Components
Cryptography and Network Security
63
SET Transaction
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
customer opens account
customer receives a certificate
merchants have their own certificates
customer places an order
merchant is verified
order and payment are sent
merchant requests payment authorization
merchant confirms order
merchant provides goods or service
merchant requests payment
Cryptography and Network Security
64
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
65
Purchase Request – Customer
Cryptography and Network Security
66
Purchase Request – Merchant
Cryptography and Network Security
67
Purchase Request – Merchant
1.
2.
3.
4.
verifies cardholder certificates using CA sigs
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
processes order and forwards the payment
information to the payment gateway for
authorization (described later)
sends a purchase response to cardholder
Cryptography and Network Security
68
Payment Gateway Authorization
1.
2.
3.
4.
5.
6.
7.
8.
verifies all certificates
decrypts digital envelope of authorization block to obtain
symmetric key & then decrypts authorization block
verifies merchant's signature on authorization block
decrypts digital envelope of payment block to obtain
symmetric key & then decrypts payment block
verifies dual signature on payment block
verifies that transaction ID received from merchant
matches that in PI received (indirectly) from customer
requests & receives an authorization from issuer
sends authorization response back to merchant
Cryptography and Network Security
69
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
Cryptography and Network Security
70
Summary
• Web security considerations
• Web security threats
• Web traffic security approaches
• Secure sockets layer
•
•
•
•
•
•
SSL architecture
SSL record protocol
Change cipher spec protocol
Alert protocol
Handshake protocol
Cryptographic computations
• HTTPS
• Connection initiation
• Connection closure
• Transport layer security
Version number
Message authentication code
Pseudorandom function
Alert codes
Cipher suites
Client certificate types
Certificate_verify and finished
messages
• Cryptographic computations
• Padding
•
•
•
•
•
•
•
•
•
•
•
Secure shell (SSH)
Transport layer protocol
User authentication protocol
Communication protocol
• SET secure credit card
payment protocols