1 Giuseppe Bianchi Lecture 4: Lecture 4: Transport Layer Security Transport Layer Security (secure Socket Layer) (secure Socket Layer) Recommended reading: Thomas, SSS and TLS essentials (old but very well written) Giuseppe Bianchi SSL/TLS: SSL/TLS: layered layered view view IPsec TCP/UDP HTTP SMTP …… Network layer security IP TCP/UDP HTTP SMTP …… Transport layer security SSL / TLS https SSL/TLS: operates on top of TCP , but below application layer (can be considered as top sublayer for L4) SSL/TLS: it is NOT a security enhancement of TCP!
24
Embed
Lecture 4: Transport Layer Security (secure Socket Layer)kodu.ut.ee/~b04866/tls.pdf · 1 Giuseppe Bianchi Lecture 4: Transport Layer Security (secure Socket Layer) Recommended reading:
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
Giuseppe Bianchi
Lecture 4:Lecture 4:
Transport Layer SecurityTransport Layer Security(secure Socket Layer)(secure Socket Layer)
Recommended reading: Thomas, SSS and TLS essentials (old but very well written)
Giuseppe Bianchi
SSL/TLS: SSL/TLS: layeredlayered viewview
IPsec
TCP/UDP
HTTP SMTP ……
Network layer security
IP
TCP/UDP
HTTP SMTP ……
Transport layer security
SSL / TLS
https
SSL/TLS: operates on top of TCP, but below application layer
(can be considered as top sublayer for L4)
SSL/TLS: it is NOT a security enhancement of TCP!
2
Giuseppe Bianchi
HistoryHistory of SSL/TLSof SSL/TLS
� TLS 1.0 specification in RFC 2246
� More recent RFC specification: TLS 1.1, RFC 4346, April 2006
� Even more recent: TLS 1.2, Internet Draft, March 2007
� Basically SSL with minor modification
� Also referred to as SSL v3.1
� However NOT backward compatible with SSL 3.0
� Not necessarily limited to Internet transport!
� Devised for point-to-point relationships in general
� E.g. EAP-TLS (RFC 2716)� TLS mechanisms employed for authentication and integrity protection over L2 EAP
1994 1995
SSL v2
Integrated in
netscape 1.1
Badly broken!
SSL v1
by Netscape
never released
1996
SSL v3
Redesigned
from scratch
by Netscape
1996-1999
TLS v1
IETF SSL design
(versus Netscape)
SSL v3.1
Public Domain implementation
available @ www.openssl.org
Giuseppe Bianchi
GoalsGoals
�Establish a session
�Agree on algorithms
�Share secrets
�Perform authentication
�Transfer application data
�Communication privacy
�Symmetric encryption
�Data integrity
�Keyed Message Authentication Code (HMAC)
3
Giuseppe Bianchi
SessionSession vsvs ConnectionConnection
�Connection:
�Transport service
�TLS provides encryption and integrity
�TLS Record Protocol
�Session:
�Association between Client and Server�Authentication and exchange of security
parameters
�May include several connections�Heavy work: done once at the beginning
�Designed for HTTPv1.0;
�TLS Handshake Protocol
Giuseppe Bianchi
TLS TLS protocolprotocol stackstack
TLS Record Protocol
TCP
Handshake
Protocol
Establishes
session &
Initializes
communicaton
Alert
Protocol
Error Handling
Data transfer
Change
Cipher
Spec
Application
on TLS
start cipher
HTTP, etc
Minor modification
of apps may be
necessary (e.g.
see RFC 2817/2818
for
- HTTPS #443
- HTTPv1.1 ext
Trivial protocols!
Possibly
special app port#
4
Giuseppe Bianchi
SupportSupport of of applicationsapplications
� Typical approach: reserve a special port number forSSL/TLS mediated application
� Example: �port 80 = HTTP over TCP
�Port 443 = HTTP over SSL/TLS (HTTPS)
� SSL/TLS common application port numbers
� ssmtp 465
� spop3 995
� imaps 991
� telnets 992
�…
� Alternative approach: slightly modify application toreuse traditional port number
� Various problems with a certificate (corrupted, signatures did not verify, unsupported, revoked, expired, other unspecified issues which render it unacceptable�Warning or Fatal, depends on the implementation
See RFC2246 for all alerts and detailed description
If fatal, terminate and do not allow resumption with same security parameters (clear all!)
23
Giuseppe Bianchi
TruncationTruncation attackattack
TCP TLS
TCP FIN
An attacker may end connection at any time by sending a TCP FIN
Part of the intended information exchange is lost
How can Server and Client distinguish this from a transaction that “normally” completes?
Giuseppe Bianchi
SolutionSolution: : CloseClose NotifyNotify
�Issued by any party
�Close Notify = Alert (warning level)
�Informs that no more data will be transmitted
�A connection that ends abruptly without a Close Notify may be a truncation attack
Close Notify
Close Notify
Application Data
A remark: note the weakness of TLS against TCP DOS attacks in general!
24
Giuseppe Bianchi
Conclusive Conclusive remarksremarks
�Performance drawbacks:
�Increased overhead and latency!�Mostly for encryption overhead and handshake overhead
�Computational overhead may kill server performance�Up to two orders of magnitude
» ref: Transport Layer Security: how much does it really costs? Infocom 99
�TLS does NOT protect TCP
�How to protect non SSL/TLS-aware applications?
�Tools available to protect a generic TCP connection�stunnel = TCP over TLS over TCP
» www.stunnel.org
» Crazy (tcp tunneled over tcp), but as last resort…
�DOS attacks to TCP remains a significant issue (no protection at all)
Giuseppe Bianchi
DTLSDTLS
�Recently specified
�RFC 4347 – Datagram TLS – April 2006�TLS over UDP
�DTLS design goal:�Be as most as possible similar to TLS!
�DTLS vs TLS�TLS assumes orderly delivery
» DTLS: Sequence number explicitly added in record header
�TLS assumes reliable delivery» Timeouts added to manage datagram loss
�TLS may generate large fragments up to 16384B» DTLS includes fragmentation capabilities to fit into single UDP