Chapt2-Transport Level Security-SSL, TLS
Chapt2-Transport Level Security-SSL, TLS
1/28
Web Security Considerations
❏ World Wide Web (WWW) is fundamentally a client/server
application running over the Internet and TCP/IP intranets
❏ The following characteristics of Web usage suggest the
need for tailored security tools:
❏ Web servers are relatively easy to configure and manage
❏ Web content is increasingly easy to develop
❏ Underlying software is extraordinarily complex
❏ May hide many potential security flaws
❏ Web server can be exploited as a launching pad into the
corporation’s or agency’s entire computer complex
❏ Casual and untrained (in security matters) users are
common clients for Web-based services
❏ Such users are not necessarily aware of the security risks that
exist and do not have the tools or knowledge to take effective
countermeasures
# Once the Web server is subverted, an attacker may be able to gain access to data and systems
not part of the Web itself but connected to the server at the local site.
2/28
Types of Security Threats on the Web
3/28
One way to group these threats is in terms of passive and active attacks.
Another way to classify Web security threats is in terms of the location of the
threat: Web server, Web browser, and network traffic between browser and server.
Issues of server and browser security fall into the category of computer system
security;
the issue of system security is also applicable to Web system security. Issues of
traffic security fall into the category of
network security.
TCP/IP Protocol Stack
There are various Web security approaches that have been considered are similar in the services they provide
and, to some extent, in the mechanisms that they use, but they differ with respect to their scope of
applicability and their relative location within the TCP/IP protocol stack.
5/28
Secure Sockets Layer(SSL)/ Transport
Layer Security(TLS)
❏ SSL/TLS protocols are dominant for providing security at the
transport layer.
❏ TLS is actually an IETF version of SSL.
❏ Protocol goals include server and client authentication, data
confidentiality, and data integrity.
❏ Application-layer client/server programs, such as HTTP can
encapsulate their data in SSL packets (HTTPS).
● If the server and client are capable of running SSL (or TLS) programs,
then the client can use https://... instead of http://...
● e.g., credit card numbers can be safely transferred via the Internet
for online shoppers.
6/28
SSL Algorithms
❏ Key Exchange Algorithms (like DH_RSA, DH_RSA, Fortezza…):
client and server need six cryptographic secrets created by
pre-master secret.
❏ Encryption/Decryption Algorithms (like RC4, RC2, DES…): client
and server need to agree to a set of encryption and decryption
algorithms.
❏ Hash Algorithms (MD5 and SHA): several hash algorithms have
been defined to provide message integrity (message
authentication).
❏ Cipher Suite: combination of key exchange, encryption and hash
algorithms defines a cipher suite for each SSL session.
9/28
Calculation of the Key Materials from
Master Secret
10/28
Extraction of cryptographic secrets
from Key Materials
11/28
Summary of Cryptographic Parameter
Generation
12/28
Sessions and Connections
❏ Session is association between client and server.
● the two parties have common info such as session identifier,
certificate authenticating each of them (if necessary), compression
method (if needed), cipher suite, master secret.
❏ Connection is established to exchange data between client and server.
● two entities exchange random numbers and create, using the master
secret, keys and parameters needed for authentication and privacy.
❏ Session can consist of many connections.
❏ Connection between two parties can be terminated and reestablished
within the same session.
❏ Session can be terminated or suspended and resumed.
13/28
SSL Protocols
❏ Handshake Protocol provides security parameters for Record.
● establishes cipher set, provides keys and parameters.
● authenticates server to client and vice versa if needed.
❏ ChangeCipherSpec Protocol used for signaling the readiness of
cryptographic secrets.
❏ Alert Protocol for reporting errors and abnormal conditions.
● uses only one message that describes the problem and its level
(warning or fatal).
❏ Record Protocol carries messages from other protocols and data
from application layer and forwards messages as payloads to
transport layer (TCP).
14/28
SSL Handshake
Protocol Messages
● After Phase I, the client and server know the version of SSL,
the cryptographic algorithms, the compression method, and the
two random numbers for key generation.
16/28
Handshake Protocol Action Phases
❏ Phase II: Server Authentication and Key Exchange
● Server sends its certificate: the certificate contains the server’s public
key. The client will use this key to authenticate the server and to
encrypt the premaster secret.
● Server Key Exchange: this is an optional step in which the server creates
and sends a temporary key to the client. This key can be used by the
client to encrypt the Client Key Exchange message later in the process
● Client Certificate Request: this is an optional step in which the server
request certificates from client.
● Server Hello Done: this message indicates that the server is finished and
awaiting a response from the client.
18/28
Handshake Protocol Action Phases
❏ Phase IV: Finalizing and Finishing
• Client Change Cipher Spec: this message notifies the server that all
messages that follow the Client Finished message will be encrypted using
the keys and algorithms just negotiated (slides 21-22).
• Server Change Cipher Spec: this message notifies the client that the
server will begin encrypting messages with the keys just negotiated
(slides 21-22).
• Finished: this message is a hash of the entire conversation to provide
further authentication of the client or of the server.
• In Phase IV, the client and server send messages to change cipher
specifications and to finish the Handshake Protocol.
❏
19/28
Handshake Protocol Message Types
Table
Table
Each message has three fields: 17.2 SSL
17.2 TLSHandshake
HandshakeProtocol
ProtocolMessage
MessageTypes
Types
• Type (1 byte): Indicates one of ten messages.
• Length (3 bytes): The length of the message in bytes.
• Content (# 0 bytes): The parameters associated with this message;
20/28
ChangeCipherSpec Protocol
❏ SSL mandates that parties cannot use parameters or secrets
● Each state holds two sets of values: read (inbound) and write
(outbound).
21/28
ChangeCipherSpec Protocol
22/28
Processing done by the record protocol
❏ The record protocol carries messages from the upper layer (Handshake Protocol,
ChangeCipherSpec Protocol, Alert Protocol, or application layer).
❏ SSL provides several services on data received from the application layer:
• Fragmentation: the data is fragmented into blocks of 214 bytes or less
• Compression: each fragment is optionally compressed using a lossless compression method
negotiated bet client and server
• Message Integrity: uses a keyed-hash function to create a Message Authentication Code
(MAC) which is added to the compressed message using the negotiated hash algorithm.
• Confidentiality: compressed fragment and MAC are encrypted using symmetric-key
cryptography ( negotiated encryption algorithm).
• Framing: a header is added to the encrypted payload.
23/28
Heartbeat & HTTPS Protocols
24/28
Heartbeat Protocol
❏ Generates a periodic signal by hardware or software to indicate normal
operation or to synchronize other parts of a system
❏ Typically used to monitor the availability of a protocol entity
❏ Defined in 2012 in RFC 6250 (Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS) Heartbeat Extentsion)
❏ Runs on top of the TLS Record Protocol
❏ Consists of two messages
❏ heartbeat_request
❏ heartbeat_response
❏ The use of the Heartbeat protocol is established during Phase 1 of the
Handshake protocol
❏ The heartbeat serves two purposes
❏ assures the sender that the recipient is still alive
❏ generates activity across the connection during idle periods, which avoids
closure by a firewall that does not tolerate idle connections
25/28
HTTPS (HTTP over SSL)
❏ HTTPS refers to the combination of HTTP and SSL to implement
secure communication bet Web browser and Web server
❏ 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
❏ No fundamental change in using HTTP over either SSL or TLS
and both implementations referred to HTTPS
❏ When HTTPS is used, the following elements of the
communication are encrypted:
❏ URL of requested document
❏ Contents of document
❏ Contents of browser forms
❏ Cookies sent from browser to server and from server to
browser
❏ Contents of HTTP header
26/28
Connection Initiation
❏ For HTTPS, agent acting as HTTP client and as TLS client
● 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
Normal HTTP behavior, including retained connections, should be followed.
27/28
Connection Closure
❏ HTTP client or server can indicate the closing of a connection
by including the line Connection: close in an HTTP record
This indicates that the connection will be closed after this record is delivered.
28/28
Summary
● Web security considerations
○ Web security threats
○ Web traffic security approaches