Transport layer

From Wikipedia, the free encyclopedia

(Redirected from Transport Layer)

In the Open Systems Interconnection (OSI) communications model, the

Transport layer ensures the reliable arrival of messages and provides error
checking mechanisms and data flow controls. The Transport layer provides
services for both "connection-mode" transmissions and for "connectionlessmode" transmissions. For connection-mode transmissions, a transmission
may be sent or arrive in the form ofpackets that need to be reconstructed into
a complete message at the other end.
The Transmission Control Protocol portion of TCP/IP is a program that can be
mapped to the Transport layer.

Internet protocol suite

Application layer

BGP
DHCP
DHCPv6
DNS
FTP
HTTP
IMAP
IRC
LDAP
MGCP
NNTP
NTP
POP
ONC/RPC
RTP
RTSP
RIP
SIP
SMTP
SNMP
SOCKS
SSH
Telnet
TLS/SSL
XMPP
more...

Transport layer
TCP
UDP
DCCP
SCTP
RSVP
more...
Internet layer
IP
IPv4
IPv6
ICMP
ICMPv6
ECN
IGMP
IPsec
more...
Link layer
ARP/InARP
NDP
OSPF
Tunnels
L2TP
PPP
MAC
Ethernet
DSL
ISDN
FDDI
DOCSIS
more...

V
T
E

In computer networking, a transport layer provides end-to-end or host-to-host communication

services for applications within a layered architecture of network components and protocols. [1] The
transport layer provides services such as connection-orienteddata stream support, reliability, flow
control, and multiplexing.
Transport layer implementations are contained in both the TCP/IP model (RFC 1122),[2] which is the
foundation of the Internet, and the Open Systems Interconnection (OSI) model of general
networking, however, the definitions of details of the transport layer are different in these models. In
the Open Systems Interconnection model the transport layer is most often referred to as Layer 4.
The best-known transport protocol is the Transmission Control Protocol (TCP). It lent its name to the
title of the entire Internet Protocol Suite, TCP/IP. It is used for connection-oriented transmissions,
whereas the connectionless User Datagram Protocol (UDP) is used for simpler messaging
transmissions. TCP is the more complex protocol, due to its stateful design incorporating reliable
transmission and data stream services. Other prominent protocols in this group are the Datagram
Congestion Control Protocol(DCCP) and the Stream Control Transmission Protocol (SCTP).

OSI model
by layer
7. Application[show]
6. Presentation[show]
5. Session[show]
4. Transport[show]
3. Network[show]
2. Data link[show]
1. Physical[show]

V
T
E

Contents
[hide]

1 Services

2 Analysis

3 Protocols

4 Comparison of transport layer protocols

5 Comparison of OSI transport protocols

6 References

7 External links

Services[edit]
Transport layer services are conveyed to an application via a programming interface to the transport
layer protocols. The services may include the following features:

Connection-oriented communication: It is normally easier for an application to interpret a

connection as a data stream rather than having to deal with the underlying connection-less
models, such as the datagram model of the User Datagram Protocol (UDP) and of the Internet
Protocol (IP).

Same order delivery: The network layer doesn't generally guarantee that packets of data will
arrive in the same order that they were sent, but often this is a desirable feature. This is usually

done through the use of segment numbering, with the receiver passing them to the application in
order. This can cause head-of-line blocking.

Reliability: Packets may be lost during transport due to network congestion and errors. By
means of an error detection code, such as a checksum, the transport protocol may check that
the data is not corrupted, and verify correct receipt by sending an ACK or NACK message to the
sender. Automatic repeat request schemes may be used to retransmit lost or corrupted data.

Flow control: The rate of data transmission between two nodes must sometimes be
managed to prevent a fast sender from transmitting more data than can be supported by the
receiving data buffer, causing a buffer overrun. This can also be used to improve efficiency by
reducing buffer underrun.

Congestion avoidance: Congestion control can control traffic entry into a telecommunications
network, so as to avoid congestive collapse by attempting to avoid oversubscription of any of the
processing or link capabilities of the intermediate nodes and networks and taking resource
reducing steps, such as reducing the rate of sendingpackets. For example, automatic repeat
requests may keep the network in a congested state; this situation can be avoided by adding
congestion avoidance to the flow control, including slow-start. This keeps the bandwidth
consumption at a low level in the beginning of the transmission, or after packet retransmission.

Multiplexing: Ports can provide multiple endpoints on a single node. For example, the name
on a postal address is a kind of multiplexing, and distinguishes between different recipients of
the same location. Computer applications will each listen for information on their own ports,
which enables the use of more than one network service at the same time. It is part of the
transport layer in the TCP/IP model, but of the session layer in the OSI model.

Analysis[edit]
The transport layer is responsible for delivering data to the appropriate application process on the
host computers. This involves statistical multiplexing of data from different application processes, i.e.
forming data packets, and adding source and destination port numbers in the header of each
transport layer data packet. Together with the source and destination IP address, the port numbers
constitutes a network socket, i.e. an identification address of the process-to-process communication.
In the OSI model, this function is supported by the session layer.
Some transport layer protocols, for example TCP, but not UDP, support virtual circuits, i.e.
provide connection oriented communication over an underlying packet orienteddatagram network. A
byte-stream is delivered while hiding the packet mode communication for the application processes.
This involves connection establishment, dividing of the data stream into packets called segments,
segment numbering and reordering of out-of order data.
Finally, some transport layer protocols, for example TCP, but not UDP, provide end-to-end reliable
communication, i.e. error recovery by means of error detecting code andautomatic repeat
request (ARQ) protocol. The ARQ protocol also provides flow control, which may be combined
with congestion avoidance.
UDP is a very simple protocol, and does not provide virtual circuits, nor reliable communication,
delegating these functions to the application program. UDP packets are calleddatagrams, rather
than segments.
TCP is used for many protocols, including HTTP web browsing and email transfer. UDP may be
used for multicasting and broadcasting, since retransmissions are not possible to a large amount of
hosts. UDP typically gives higher throughput and shorter latency, and is therefore often used for real-

time multimedia communication where packet loss occasionally can be accepted, for example IP-TV
and IP-telephony, and for online computer games.
In many non-IP-based networks, for example X.25, Frame Relay and ATM, the connection-oriented
communication is implemented at network layer or data link layer rather than the transport layer. In
X.25, in telephone network modems and in wireless communication systems, reliable node-to-node
communication is implemented at lower protocol layers.
The OSI connection-mode transport layer protocol specification defines five classes of transport
protocols: TP0, providing the least error recovery, to TP4, which is designed for less reliable
networks.

Protocols[edit]
This list shows some protocols that are commonly placed in the transport layers of TCP/IP,
OSI, NetWare's IPX/SPX, AppleTalk, and Fibre Channel.

ATP, AppleTalk Transaction Protocol

CUDP, Cyclic UDP

DCCP, Datagram Congestion Control Protocol

FCP, Fibre Channel Protocol

IL, IL Protocol

MTCP, Multipath TCP

RDP, Reliable Datagram Protocol

RUDP, Reliable User Datagram Protocol

SCTP, Stream Control Transmission Protocol

SPX, Sequenced Packet Exchange

SST, Structured Stream Transport

TCP, Transmission Control Protocol

UDP, User Datagram Protocol

UDP Lite

TP, Micro Transport Protocol

Comparison of transport layer protocols[edit]

UDP

UDP
Lite

Packet header size

8 bytes

8 bytes

Transport layer packet

entity

Datagra
m

Datagram Segment

Feature Name

TCP

2060
bytes

Multipath
TCP

SCTP

5090 bytes

12 bytes

12 or 16
bytes

Segment

Datagra
m

Datagram

DCCP

RUDP

Datagra
m

Connection oriented

No

No

Yes

Yes

Yes

Yes

Yes

Reliable transport

No

No

Yes

Yes

Yes

No

Yes

Unreliable transport

Yes

Yes

No

No

Yes

Yes

Yes

Preserve message
boundary

Yes

Yes

No

No

Yes

Yes

Yes

Ordered delivery

No

No

Yes

Yes

Yes

No

Yes

Unordered delivery

Yes

Yes

No

No

Yes

Yes

Yes

Data checksum

Optional

Yes

Yes

Yes

Yes

Yes

Optional

Checksum size (bits)

16

16

16

16

32

16

16

Partial checksum

No

Yes

No

No

No

Yes

No

Path MTU

No

No

Yes

Yes

Yes

Yes

Unsure

Flow control

No

No

Yes

Yes

Yes

No

Yes

Congestion control

No

No

Yes

Yes

Yes

Yes

Unsure

Explicit Congestion
Notification

No

No

Yes

Yes

Yes

Yes

Multiple streams

No

No

No

Yes

Yes

No

No

Multi-homing

No

No

No

Yes

Yes

No

No

Bundling / Nagle

No

No

Yes

Yes

Yes

No

Unsure

Comparison of OSI transport protocols[edit]

ISO/IEC 8073/ITU-T Recommendation X.224, "Information Technology - Open Systems
Interconnection - Protocol for providing the connection-mode transport service", defines five classes
of connection-mode transport protocols designated class 0 (TP0) to class 4 (TP4). Class 0 contains
no error recovery, and was designed for use on network layers that provide error-free connections.
Class 4 is closest to TCP, although TCP contains functions, such as the graceful close, which OSI
assigns to the session layer. All OSI connection-mode protocol classes provide expedited data and
preservation of record boundaries. Detailed characteristics of the classes are shown in the following
table:[3]
Service

TP0 TP1 TP2 TP3 TP4

Connection oriented network

Yes Yes Yes Yes Yes

Connectionless network

No

No

Concatenation and separation

No

Yes Yes Yes Yes

Segmentation and reassembly

Yes Yes Yes Yes Yes

Error Recovery

No

Yes

No

Yes Yes

Reinitiate connection (if an excessive number of PDUs are unacknowledged)

No

Yes

No

Yes

No

No

Yes

No

multiplexing and demultiplexing over a single virtual circuit

No

No

Yes Yes Yes

Explicit flow control

No

No

Yes Yes Yes

Retransmission on timeout

No

No

No

No

Reliable Transport Service

No

Yes

No

Yes Yes

Yes

There is also a connectionless transport protocol, specified by ISO/IEC 8602/ITU-T

Recommendation X.234.[4]

References[edit]
1.

Jump up^

Transport Layer Protocol

The transport layer is the fourth layer of the OSI reference model. It provides
transparent transfer of data between end systems using the services of the network
layer (e.g. IP) below to move PDUs of data between the two communicating systems.
The transport service is said to perform "peer to peer" communication, with the
remote (peer) transport entity. The data communicated by the transport layer
is encapsulated in a transport layer PDU and sent in a network layer SDU. The
network layer nodes (i.e. Intermediate Systems (IS)) transfer the transport PDU intact,
without decoding or modifying the content of the PDU. In this way, only the peer
transport entities actually communicate using the PDUs of the transport protocol.

Two End Systems connected by an Intermediate System (in this case a router) The
figure shows the various protocol layers drawn with reference to the OSI reference
model
The transport layer relieves the upper layers from any concern with providing reliable
and cost effective data transfer. It provides end-to-end control and information transfer
with the quality of service needed by the application program. It is the first true endto-end layer, implemented in all End Systems (ES).
The Internet Protocol (IP) Stack provides a set of transport layer protocols:
The User Datagram Protocol (UDP)

(Best Effort Service)

The Lighweight User Datagram Protocol (UDP-Lite)

(Best Effort Service)

The Transmission Control Protocol (TCP)

(Reliable Service) (Options)

(Cong

The Datagram Congestion Control Protocol (DCCP)

(Reliable Service) (Options)

(Cong

The Stream Control Transport Protocol (SCTP)

(Reliable Service) (Options) (Threads)

(Cong

SCTP-PR

(Partially Reliable) (Options) (Threads) (Cong

Gorry Fairhurst - Date: 1/11/2009 EG3567

Transport Layer Security

From Wikipedia, the free encyclopedia

Internet protocol suite

Application layer

BGP
DHCP
DHCPv6
DNS
FTP
HTTP
IMAP
IRC
LDAP
MGCP
NNTP
NTP
POP
ONC/RPC
RTP
RTSP
RIP
SIP
SMTP
SNMP
SOCKS
SSH
Telnet
TLS/SSL
XMPP
more...

Transport layer

TCP
UDP
DCCP
SCTP
RSVP
more...
Internet layer

IP
IPv4
IPv6
ICMP
ICMPv6
ECN
IGMP
IPsec
more...
Link layer

ARP/InARP
NDP
OSPF
Tunnels
L2TP
PPP
MAC
Ethernet
DSL
ISDN
FDDI
DOCSIS
more...

V
T
E

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL),
are cryptographic protocols designed to provide communication security over the Internet.[1] They
use X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with
whom they are communicating, and to exchange a symmetric key. This session key is then used to
encrypt data flowing between the parties. This allows for data/message confidentiality, and message
authentication codes for message integrity and as a by-product, message authentication. Several
versions of the protocols are in widespread use in applications such as web browsing, electronic
mail, Internet faxing, instant messaging, and voice-over-IP (VoIP). An important property in this
context isforward secrecy, so the short-term session key cannot be derived from the long-term
asymmetric secret key.[2]

As a consequence of choosing X.509 certificates, certificate authorities and a public key

infrastructure are necessary to verify the relation between a certificate and its owner, as well as to
generate, sign, and administer the validity of certificates. While this can be more beneficial than
verifying the identities via a web of trust, the 2013 mass surveillance disclosures made it more
widely known that certificate authorities are a weak point from a security standpoint, allowing man-inthe-middle attacks (MITM).[3][4]
In the Internet Protocol Suite, TLS and SSL encrypt the data of network connections in
the application layer. In OSI modelequivalences, TLS/SSL is initialized at layer 5 (session layer) and
works at layer 6 (the presentation layer).[citation needed] The session layer has a handshake using an
asymmetric cipher in order to establish cipher settings and a shared key for that session; then the
presentation layer encrypts the rest of the communication using a symmetric cipher and that session
key. In both models, TLS and SSL work on behalf of the underlying transport layer, whose segments
carry encrypted data.
TLS is an Internet Engineering Task Force (IETF) standards track protocol, first defined in 1999 and
last updated in RFC 5246 (August 2008) and RFC 6176 (March 2011). It is based on the earlier SSL
specifications (1994, 1995, 1996) developed by Netscape Communications[5] for adding
the HTTPS protocol to their Navigator web browser.
Contents
[hide]

1 Description

2 History and development

o

2.1 Secure Network Programming API

2.2 SSL 1.0, 2.0 and 3.0

2.3 TLS 1.0

2.4 TLS 1.1

2.5 TLS 1.2

3 Applications and adoption

o

3.1 Websites

3.2 Key exchange or key agreement

3.3 Cipher

3.4 Web browsers

3.5 Libraries

3.6 Other uses

4 Security
o

4.1 SSL 2.0

4.2 SSL 3.0

4.3 TLS

4.4 Attacks against TLS/SSL

4.4.1 Renegotiation attack

4.4.2 Version rollback attacks

4.4.3 BEAST attack

4.4.4 CRIME and BREACH attacks

4.4.5 Padding attacks

4.4.6 RC4 attacks

4.4.7 Truncation attack

4.4.8 Heartbleed Bug

4.4.9 Survey of websites

4.5 Forward secrecy

4.6 Avoiding Triple-DES CBC

4.7 Dealing with MITM attacks

4.7.1 Certificate pinning

4.7.2 Perspectives Project

5 Protocol details
5.1 TLS handshake

5.1.1 Basic TLS handshake

5.1.2 Client-authenticated TLS handshake

5.1.3 Resumed TLS handshake

5.1.3.1 Session IDs

5.1.3.2 Session tickets

5.2 TLS record

5.2.1 Handshake protocol

5.2.2 Alert protocol

5.2.3 ChangeCipherSpec protocol

5.2.4 Application protocol

6 Support for name-based virtual servers

7 Standards

8 See also

9 References

10 Further reading

11 External links

Description[edit]
The TLS protocol allows client-server applications to communicate across a network in a way
designed to prevent eavesdropping and tampering.
Since protocols can operate either with or without TLS (or SSL), it is necessary for the client to
indicate to the server the setup of a TLS connection. There are two main ways of achieving this. One
option is to use a different port number for TLS connections (for example port 443 for HTTPS). The
other is for the client to request that the server switch the connection to TLS using a protocol-specific
mechanism (for example STARTTLS for mail and news protocols).
Once the client and server have agreed to use TLS, they negotiate a stateful connection by using
a handshaking procedure.[6] During this handshake, the client and server agree on various
parameters used to establish the connection's security:
1. The client sends the server the client's SSL version number, cipher settings, session-specific
data, and other information that the server needs to communicate with the client using SSL.

2. The server sends the client the server's SSL version number, cipher settings, sessionspecific data, and other information that the client needs to communicate with the server
over SSL. The server also sends its own certificate, and if the client is requesting a server
resource that requires client authentication, the server requests the client's certificate.
3. The client uses the information sent by the server to authenticate the servere.g., in the
case of a web browser connecting to a web server, the browser checks whether the
received certificate's subject name actually matches the name of the server being contacted,
whether the issuer of the certificate is a trusted certificate authority, whether the certificate
has expired, and, ideally, whether the certificate has been revoked.[7] If the server cannot be
authenticated, the user is warned of the problem and informed that an encrypted and
authenticated connection cannot be established. If the server can be successfully
authenticated, the client proceeds to the next step.
4. Using all data generated in the handshake thus far, the client (with the cooperation of the
server, depending on the cipher in use) creates the pre-master secret for the session,
encrypts it with the server's public key (obtained from the server's certificate, sent in step 2),
and then sends the encrypted pre-master secret to the server.
5. If the server has requested client authentication (an optional step in the handshake), the
client also signs another piece of data that is unique to this handshake and known by both
the client and server. In this case, the client sends both the signed data and the client's own
certificate to the server along with the encrypted pre-master secret.
6. If the server has requested client authentication, the server attempts to authenticate the
client. If the client cannot be authenticated, the session ends. If the client can be
successfully authenticated, the server uses its private key to decrypt the pre-master secret,
and then performs a series of steps (which the client also performs, starting from the same
pre-master secret) to generate the master secret.
7. Both the client and the server use the master secret to generate the session keys, which are
symmetric keys used to encrypt and decrypt information exchanged during the SSL session
and to verify its integrity (that is, to detect any changes in the data between the time it was
sent and the time it is received over the SSL connection).
8. The client sends a message to the server informing it that future messages from the client
will be encrypted with the session key. It then sends a separate (encrypted) message
indicating that the client portion of the handshake is finished.
9. The server sends a message to the client informing it that future messages from the server
will be encrypted with the session key. It then sends a separate (encrypted) message
indicating that the server portion of the handshake is finished.
The SSL handshake is now complete and the session begins. The client and the server use the
session keys to encrypt and decrypt the data they send to each other and to validate its integrity.
This is the normal operation condition of the secure channel. At any time, due to internal or external
stimulus (either automation or user intervention), either side may renegotiate the connection, in
which case, the process repeats itself.[8]

This concludes the handshake and begins the secured connection, which is encrypted and
decrypted with the key material until the connection closes.
If any one of the above steps fails, the TLS handshake fails and the connection is not created.
In step 3, the client must check a chain of "signatures" from a "root of trust" built into, or added to,
the client. The client must also check that none of these have been revoked; this is not often
implemented correctly,[citation needed] but is a requirement of any public-key authentication system. If the
particular signer beginning this server's chain is trusted, and all signatures in the chain remain
trusted, then the Certificate (thus the server) is trusted.

History and development[edit]

Secure Network Programming API[edit]
Early research efforts towards transport layer security included the Secure Network Programming
(SNP) application programming interface (API), which in 1993 explored the approach of having a
secure transport layer API closely resembling Berkeley sockets, to facilitate retrofitting preexisting
network applications with security measures.[9]

SSL 1.0, 2.0 and 3.0[edit]

The SSL protocol was originally developed by Netscape.[10] Version 1.0 was never publicly released;
version 2.0 was released in February 1995 but "contained a number of security flaws which
ultimately led to the design of SSL version 3.0."[11] SSL version 3.0, released in 1996, was a complete
redesign of the protocol produced by Paul Kocherworking with Netscape engineers Phil Karlton and
Alan Freier. Newer versions of SSL/TLS are based on SSL 3.0. The 1996 draft of SSL 3.0 was
published by IETF as a historical document in RFC 6101.
The basic algorithm was written by Dr. Taher Elgamal. As the Chief Scientist of Netscape, Taher was
recognized as the "father of SSL".[12][13]

TLS 1.0[edit]
TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0. As stated
in the RFC, "the differences between this protocol and SSL 3.0 are not dramatic, but they are
significant to preclude interoperability between TLS 1.0 and SSL 3.0." TLS 1.0 does include a means
by which a TLS implementation can downgrade the connection to SSL 3.0, thus weakening security.
[14]:12

TLS 1.1[edit]
TLS 1.1 was defined in RFC 4346 in April 2006.[15] It is an update from TLS version 1.0. Significant
differences in this version include:

Added protection against Cipher block chaining (CBC) attacks.

The implicit Initialization Vector (IV) was replaced with an explicit IV.

Change in handling of padding errors.

Support for IANA registration of parameters.[14]:2

TLS 1.2[edit]
TLS 1.2 was defined in RFC 5246 in August 2008. It is based on the earlier TLS 1.1 specification.
Major differences include:

The MD5-SHA-1 combination in the pseudorandom function (PRF) was replaced with SHA256, with an option to use cipher suite specified PRFs.

The MD5-SHA-1 combination in the Finished message hash was replaced with SHA-256,
with an option to use cipher suite specific hash algorithms. However the size of the hash in the
finished message is still truncated to 96-bits.

The MD5-SHA-1 combination in the digitally signed element was replaced with a
single hash negotiated during handshake, defaults to SHA-1.

Enhancement in the client's and server's ability to specify which hash and signature
algorithms they will accept.

Expansion of support for authenticated encryption ciphers, used mainly for Galois/Counter
Mode (GCM) and CCM mode of Advanced Encryption Standard encryption.

TLS Extensions definition and Advanced Encryption Standard cipher suites were added.[14]:2

All TLS versions were further refined in RFC 6176 in March 2011 removing their backward
compatibility with SSL such that TLS sessions will never negotiate the use of Secure Sockets Layer
(SSL) version 2.0.

Applications and adoption[edit]

In applications design, TLS is usually implemented on top of any of the Transport Layer protocols,
encapsulating the application-specific protocols such as HTTP, FTP, SMTP,NNTP and XMPP.
Historically it has been used primarily with reliable transport protocols such as the Transmission
Control Protocol (TCP). However, it has also been implemented with datagram-oriented transport
protocols, such as the User Datagram Protocol (UDP) and the Datagram Congestion Control
Protocol (DCCP), usage which has been standardized independently using the term Datagram
Transport Layer Security (DTLS).

Websites[edit]

A prominent use of TLS is for securing World Wide Web traffic between the website and
the browser carried by HTTP to form HTTPS. Notable applications are electronic
commerce and asset management.

Website protocol support

Protocol
version

Website
support[16]

Security[16][17]

SSL 2.0

21.1% (0.3%)

Insecure

SSL 3.0

98.7% (0.2%)

Depends on cipher[n 1] and client mitigations[n 2]

TLS 1.0

99.3% (+0.1%)

Depends on cipher[n 1] and client mitigations[n 2]

TLS 1.1

36.0% (+2.0%)

Depends on cipher[n 1] and client mitigations[n 2]

TLS 1.2

38.5% (+1.5%)

Depends on cipher[n 1] and client mitigations[n 2]

Notes
1.

^ Jump up to:a b c d see #Cipher table below

2.

^ Jump up to:a b c d see #Web browsers and #Attacks against TLS/SSL sections

Key exchange or key agreement[edit]

See also: Cipher suite
Before a client and server can begin to exchange information protected by TLS, they must securely
exchange or agree upon an encryption key and a cipher to use when encrypting data (see Cipher).
Among the methods used for key exchange/agreement are: public and private keys generated
with RSA (denoted TLS_RSA in the TLS handshake protocol), Diffie-Hellman (denoted TLS_DH in
the TLS handshake protocol), ephemeral Diffie-Hellman (denoted TLS_DHE in the handshake
protocol), Elliptic Curve Diffie-Hellman (denoted TLS_ECDH), ephemeral Elliptic Curve DiffieHellman (TLS_ECDHE), anonymous Diffie-Hellman (TLS_DH_anon), [18] and PSK (TLS_PSK).[19]
The TLS_DH_anon key agreement method does not authenticate the server or the user and hence
is rarely used. Only TLS_DHE and TLS_ECDHE provide forward secrecy.

Public key certificates used during exchange/agreement also vary in the size of the public/private
encryption keys used during the exchange and hence the robustness of the security provided. In
July 2013, Google announced that it would no longer use 1024 bit public keys and would switch
instead to 2048 bit keys to increase the security of the TLS encryption it provides to its users. [20]

Cipher[edit]
See also: Cipher suite, Block cipher and Cipher security summary
Cipher security against publicly known feasible attacks

Cipher

Type

Algorithm

Protocol version

Stren
gth
(bits)

SS
L
2.0

SSL
3.0
[note 1]
[note 2]

TLS
1.0
[note 1]
[note 3]

[note 3]

Block cipher
with
mode of
operation

AES CBC[note 4]

AES GCM[21][note 5]

128,
256

AES CCM[22][note 5]

CAMELLIA CBC[23][note
4]

CAMELLIA GCM[24]
[note 5]

128,
256

TL
S
1.1

TL
S
1.2

[note

[note

1]

1]

Depend
s on
Secur Secur
mitigati
e
e
ons

N/A

N/A

N/A

N/A

N/A

N/A

Secur
e

N/A

N/A

N/A

N/A

Secur
e

N/A

N/A

N/A

N/A

Depend
s on
Secur Secur
mitigati
e
e
ons

N/A

N/A

Secur
e

Cipher security against publicly known feasible attacks

Cipher

Type

Algorithm

Protocol version

Stren
gth
(bits)

SS
L
2.0

SSL
3.0
[note 1]
[note 2]

TLS
1.0
[note 1]
[note 3]

[note 3]

SEED CBC[25][note 4]

128

ARIA CBC[26][note 4]

IDEA CBC[note 4][note 6]

128

3DES EDE CBC[note 4] 112[note 7]

DES CBC[note 4][note 6]

56

TL
S
1.2

[note

[note

1]

1]

N/A

Depend
s on
Secur Secur
mitigati
e
e
ons

N/A

N/A

Depend
s on
Secur Secur
mitigati
e
e
ons

N/A

N/A

N/A

128,
256
ARIA GCM[26][note 5]

TL
S
1.1

N/A

N/A

Depend Depend
Insecu
s on
s on
Secur
re
mitigati mitigati
e
ons
ons

Secur
e

N/A

Low
Low
strength strength
,
,
Low
Low
Insecu
Depend Depend streng streng
re
s on
s on
th
th
mitigati mitigati
ons
ons

Insecu Insecure Insecure Insecu

N/A

Cipher security against publicly known feasible attacks

Cipher

Type

Algorithm

Protocol version

Stren
gth
(bits)

SS
L
2.0

SSL
3.0
[note 1]
[note 2]

TLS
1.0
[note 1]
[note 3]

[note 3]

re

TL
S
1.1

TL
S
1.2

[note

[note

1]

1]

re

40[note 8]

Insecu
Insecure Insecure
re

N/A

N/A

RC2 CBC[note 4]

40[note 8]

Insecu
Insecure Insecure
re

N/A

N/A

CHACHA20+POLY1
305[30][note 5]

256

N/A

Secur
e

Stream
cipher

128

N/A

N/A

N/A

Insecu
Insecu Insecu
Insecure Insecure
re
re
re

RC4[note 9]
40[note 8]

Insecu
Insecure Insecure
re

N/A

N/A

no
authenticati
on[note 10]

Several

40-256

N/A

Insecure Insecure

Insecu Insecu
re
re

no
encryption

NULL

N/A

Insecure Insecure

Insecu Insecu
re
re

Notes

1.

^ Jump up to:a b c d RFC 5746 must be implemented in order to fix a renegotiation flaw
that would otherwise break this protocol.

2.

Jump up^ If libraries implement fixes listed in RFC 5746, this will violate the SSL 3.0
specification, which the IETF cannot change unlike TLS. Fortunately, most current libraries
implement the fix and disregard the violation that this causes.

3.

^ Jump up to:a b the BEAST attack breaks all block ciphers (CBC ciphers) used in SSL
3.0 and TLS 1.0 unless mitigated by the client. See #Web browsers.

4.

^ Jump up to:a b c d e f g h CBC ciphers can be attacked with the Lucky 13 attack if the
library is not written carefully to eliminate timing side channels.
^ Jump up to:a b c d e AEAD ciphers (such as GCM and CCM) can be used in only TLS

5.
1.2.
6.

^ Jump up to:a b IDEA and DES have been removed from TLS 1.2.[27]

7.

Jump up^ Triple DES provides only 112 bits of security,[28] which is below the
recommended minimum of 128 bits.[29]

8.

^ Jump up to:a b c 40 bits strength of cipher suites were designed to operate at reduced
key lengths in order to comply with US regulations about the export of cryptographic software
containing certain strong encryption algorithms (see Export of cryptography from the United
States). These weak suites are forbidden in TLS 1.1 and later.

9.
10.

Jump up^ the RC4 attacks weaken or break RC4 used in SSL/TLS
Jump up^ Anonymous key exchange with DiffieHellman (DH_anon) and Elliptic curve
DiffieHellman (ECDH_anon) are insecure because of Man-in-the-middle attack.

Web browsers[edit]
Further information: Comparison of web browsers
As of July 2014, the latest version of all major web browsers support SSL 3.0, TLS 1.0, 1.1, and 1.2
enabled by default and mitigations against known attacks have been implemented. However, there
are still problems on several version of browsers which are not the latest but still supported.

support TLS 1.1 and 1.2 but disabled by default: Mozilla Firefox ESR 24, Internet Explorer 8
10 for Windows 7 and IE 10 for Win 8, Opera 12 (with Presto engine)

not support TLS 1.1 and 1.2: Internet Explorer 79 for Windows Vista, Safari 6 for Mac OS X
10.7 and 10.8

mitigations against known attacks have not been implemented: Safari 6 for Mac OS X 10.7

Browser support for TLS/SSL

Brow
ser

Vers
ion

Platfo
rms

Disabled
by
default

09

Google
Chrom
e

1021

[notes 3]
[notes 4]

2229

Android,
iOS,
Linux,
Mac OS
X,
Windows

30[notes
5]

Browse Versio
r
n

Mozilla
Firefox

1, 1.5

[notes 4]
[notes 6]

27

SSL
2.0
(insec
ure)

Platfor
ms

[39]

No

S
S
L
3.
0

Yes

Yes

TLS
1.0

Yes

Yes

TLS
1.1

No

No

Vulnerab
ilities
Fixed[notes

tes 1]

2]

No

No,
discontinued

No

No

unknown,
assume No,
discontinued

No[40][41]

since
v26

unknown,
assume No,
discontinued

Yes

Yes

No

No

Yes

Yes

No

Yes

Yes

Yes

SSL 2.0
SSL
(insecur
3.0
e)

TLS
1.0

TLS
1.1

TLS 1.2

SHA- Vulnerabili
2[notes
ties
1]
Fixed[notes 2]

No

No

since
No,
1.5 discontinued

No

No

Yes

No

No

Yes

Android,
Yes[4
Yes[44]
Yes[44]
4]
Firefox
OS,
Linux,
Mac OS Disabled
X,
by
Yes
Yes
Windows default[44]

Yes

[40]

TLS
1.2

SH
A2[no

[42][43]

Yes[41][42]
[43]

No,
discontinued

[45]

822
ESR 10,

No[45]

Yes

Yes

unknown,
assume No,

Browser support for TLS/SSL

Brow
ser

Vers
ion

Platfo
rms

SSL
2.0
(insec
ure)

S
S
L
3.
0

TLS
1.0

TLS
1.1

TLS
1.2

SH
A2[no

Vulnerab
ilities
Fixed[notes

tes 1]

2]

17

discontinued

23

No

Yes

Yes

Disabl
ed by
default

No

Yes

[35]

unknown,
discontinued

2426
No

Yes

Yes

Disabl Disabled
ed by
by
default default[37]

Yes
Yes (latest
ESR)

ESR 24

27[notes

No

5]

Browse Versio
r
n

Interne
t
Explore
r

[notes 7]

4-6

Platfor
ms

Windows
3.1, 95,
NT
3.1[notes 8]

Windows
3.1, 95,

Yes[46]

Yes[48][47]

unknown,
assume No,
discontinued

Yes

Yes

SSL 2.0
SSL
(insecur
3.0
e)

TLS
1.0

TLS
1.1

TLS 1.2

No

No

No

No

No,
discontinued

No

No

No

No

No,
discontinued

Disabl
ed by

No

No

No

Yes

Yes

Yes

No

Yes[5
2]

Yes

[47]

Yes

Yes

SHA- Vulnerabili
2[notes
ties
1]
Fixed[notes 2]

No,
discontinued

Browser support for TLS/SSL

Brow
ser

Vers
ion

Platfo
rms

SSL
2.0
(insec
ure)

S
S
L
3.
0

98, ME
Windows
NT 3.x, 4
Windows
2000[notes

TLS
1.0

TLS
1.1

TLS
1.2

SH
A2[no

Vulnerab
ilities
Fixed[notes

tes 1]

2]

(latest for
Win 3.1, 95,
98, ME
Windows NT
3.x, 4,
Windows
2000)

default
[52]

8]

Yes

Yes

Disabl
ed by
default

No

No

with
SP3

Yes,
discontinued

Yes,
discontinued
(latest for
Win XP)

Windows
XP[notes 8]
Disabled
by
Yes
default[53]

7, 8

79

Windows
Vista

Disabled
by
default

810

Windows
7

Disabled
by
default

10

Windows Disabled
8
by
default

Yes

Yes[53]

No

No

with
SP3

Yes

No

No

Yes

Yes (latest
for Win
Vista)

Yes

Yes

Yes

(latest for
Win 8)

Yes

Yes

Yes

Yes

Disabl
Disabled
ed by
by
default
[54]
default
[54]

Disabl Disabled
ed by
by
default default

Browser support for TLS/SSL

Brow
ser

Vers
ion

Platfo
rms

Windows
7
11
Windows
8.1

Browse Versio
r
n

Opera
[notes 9]

57

[notes 10]

Platfor
ms

Android,
iOS,[citation

SSL
2.0
(insec
ure)

Disabled
by
default

S
S
L
3.
0

TLS
1.0

TLS
1.1

tes 1]

2]

SSL 2.0
SSL
(insecur
3.0
e)

TLS
1.0

TLS
1.1

TLS 1.2

Yes[58]

No

No

No

No,
discontinued

No

No

No,
discontinued

No

Yes

No,
discontinued

8]

Yes

Yes[56] (latest
for Win
7,8.1)

Yes

Yes[5

Yes

[55]

Vulnerab
ilities
Fixed[notes

Yes

Yes[58]

Yes

[55]

TLS
1.2

SH
A2[no

SHA- Vulnerabili
2[notes
ties
1]
Fixed[notes 2]

needed]

Linux,
Mac OS
X,
Windows

Yes

Yes

Yes

Disabl
ed by
default
[59]

1012

Disabled
by
Yes
default[60]

No[61]

Yes

Yes

Yes

Disabl
ed by
default

Disabl Disabled
ed by
by
default default[61]

Yes

since
version
11.60+
(latest for
Linux,
withPresto)

Browser support for TLS/SSL

Brow
ser

Vers
ion

Platfo
rms

1416

No

17[notes

Safari

Platfor
ms

S
S
L
3.
0

Yes

TLS
1.0

Yes

TLS
1.1

Yes[62]

Yes

Yes

Yes[63]

SSL 2.0
SSL
(insecur
3.0
e)

TLS
1.0

TLS
1.1

No

5]

Browse Versio
r
n

SSL
2.0
(insec
ure)

TLS
1.2

No[62]

Yes[63]

No[68]

15

Yes

Yes

No

Vulnerab
ilities
Fixed[notes

tes 1]

2]

Yes

unknown,
discontinued

Yes

Yes (latest
for Windows,
OS X,
Android)

TLS 1.2

SHA- Vulnerabili
2[notes
ties
1]
Fixed[notes 2]

No

No,
since discontinued
OS X
(latest for
10.5 OS X 10.0
10.6)

Mac OS X
10.0
10.6

[notes 11]

SH
A2[no

Mac OS X
10.7

No (latest
for OS X
10.7)

Mac OS X
10.7
6

No

Yes

Yes

No

No

Yes
Yes[notes
(latest for
OS X 10.8)

Mac OS X
10.8

Mac OS X
10.9

12]

No

Yes

Yes

Yes[72]

Yes[72]

Yes

Yes[70] (latest
for OS X

Browser support for TLS/SSL

Brow
ser

Vers
ion

Platfo
rms

SSL
2.0
(insec
ure)

S
S
L
3.
0

TLS
1.0

TLS
1.1

TLS
1.2

SH
A2[no

Vulnerab
ilities
Fixed[notes

tes 1]

2]

10.9)

35

5, 6

35

Browse Versio
r
n

iPhone
(i)OS 1
4[notes 13]

iOS 5,
6[notes 13]

iOS 7[notes
13]

Windows

Platfor
ms

No[73]

Yes

Yes

No

No

No,
discontinued
since
(latest for
OS 3
iPhone (i)OS
14)

No

Yes

Yes

Yes[74]

Yes[74]

Yes

No,
discontinued
(latest for
iOS 5, 6)

No

Yes

Yes

Yes

Yes

Yes

Yes[77] (Lates
t for iOS 7)

No

No,
discontinued
(Latest for
Windows)

No

Yes

Yes

No

No

SSL 2.0
SSL
(insecur
3.0
e)

TLS
1.0

TLS
1.1

TLS 1.2

SHA- Vulnerabili
2[notes
ties
1]
Fixed[notes 2]

Version and Platform color

Significance

Grey

Mixed / Unspecified

Red

Former release; no longer supported

Yellow

Former release; still supported

Green

Current supported release[notes 5]

Notes
^ Jump up to:a b c d e f SHA-2 Certificate Compatibility (common SHA-256)

1.

[31]

2.

^ Jump up to:a b c d e f Does the current browser have mitigations or is not vulnerable for
all the known protocol and cipher attacks listed in this page (BEAST, CRIME, BREACH, Lucky
Thirteen, see##Attacks against TLS/SSL). Note actual security depends on other factors such as
negotiated cipher, encryption strength etc (see #Cipher table). Non-current browsers will have
unfixed security issues so are not considered.

3.

Jump up^ Google Chrome (and Chromium) supports TLS 1.0, and TLS 1.1 from version
22 (it was added, then dropped from version 21). TLS 1.2 support has been added, then dropped
from Chrome 29.[32][33][34]

4.

^ Jump up to:a b Uses the TLS implementation provided by NSS. NSS 3.14 supports TLS
1.0 and 1.1 but not 1.2.[35][36] TLS 1.2 has been implemented in NSS 3.15.1.[37][38]

5.

^ Jump up to:a b c d Shown Number e.g "27-" only reflect last version at the time TLS
Support changed. It does not reflect the really latest current version and does not reflect that the
shown version is really still suppored and have latest security patches included.

6.

Jump up^ As of Firefox 22, Firefox supports only TLS 1.0 despite the bundled NSS
supporting TLS 1.1. Since Firefox 23, TLS 1.1 can be enabled, but was not enabled by default
due to issues. Firefox 24 has TLS 1.2 support disabled by default. TLS 1.1 and TLS 1.2 have
been enabled by default in Firefox 27 release.

7.

Jump up^ IE uses the TLS implementation of the Microsoft Windows operating system
provided by the SChannel security support provider. TLS 1.1 and 1.2 are disabled by default until
IE11.[49][50]

8.

^ Jump up to:a b c Windows XP and older only support weak ciphers like 3DES and RC4.
The weak ciphers of these SChannel version are not only used for IE. They are also used for
other Microsoft products running on this OS, e.g like Office.
[51]

9.

Jump up^ Opera 10 added support for TLS 1.2 as of Presto 2.2. Previous support was
for TLS 1.0 and 1.1. TLS 1.1 and 1.2 are disabled by default (except for version 9 [57] that enabled
TLS 1.1 by default).

10.

Jump up^ TLS support of Opera 14 and above is same as that of Chrome, because
Opera has migrated to Chromium backend.

11.

Jump up^ Safari uses the operating system implementation on Mac OS X, Windows (XP,
Vista, 7)[64] with unknown version,[65] Safari 5 is the last version available for Windows. OS X 10.8
on have SecureTransport support for TLS 1.1 and 1.2 [66] Qualys SSL report simulates Safari 5.1.9
connecting with TLS 1.0 not 1.1 or 1.2[67]

12.

Jump up^ In September 2013, Apple implemented BEAST mitigation in OS X

10.8 (Mountain Lion), but it was not turned on by default resulting in Safari still being theoretically
vulnerable to the BEAST attack on that platform.[69][70] BEAST mitigation has been enabled by
default from OS X 10.8.5 updated in February 2014. [71]

13.

^ Jump up to:a b c Mobile Safari and third-party software utilizing the system UIWebView
library use the iOS operating system implementation, which supports TLS 1.2 as of iOS 5.0. [74][75]
[76]

Libraries[edit]
Main article: Comparison of TLS implementations
Most SSL and TLS programming libraries are free and open source software.

Botan, a BSD-licensed cryptographic library written in C++.

Microsoft Windows includes an implementation of SSL and TLS as part of its Secure
Channel package.

OS X includes an implementation of SSL and TLS as part of its Secure Transport package.

Delphi programmers may use a library called Indy which utilizes OpenSSL.

OpenSSL: a free implementation (BSD license with some extensions)

LibreSSL: a fork of OpenSSL by OpenBSD project.

GnuTLS: a free implementation (LGPL licensed)

cryptlib: a portable open source cryptography library (includes TLS/SSL implementation)

JSSE: a Java implementation included in the Java Runtime Environment supports TLS 1.1
and 1.2 from Java 7, although is disabled by default for client, and enabled by default for server.
[78]
Java 8 supports TLS 1.1 and 1.2 enabled on both the client and server by default. [79]

MatrixSSL: a dual licensed implementation

Network Security Services (NSS): FIPS 140 validated open source library

PolarSSL: A tiny SSL library implementation for embedded devices that is designed for ease
of use

a. ^ SSL 2.0 client hello is supported even though SSL 2.0 is not supported or is disabled because
of the backward compatibilities.
b. ^ Secure Transport: SSL 2.0 was discontinued in OS X 10.8. TLS 1.1 and 1.2 are available on
iOS 5.0 and later, and OS X 10.8 and later.[86]

A paper presented at the 2012 ACM conference on computer and communications

security[87] showed that few applications used some of these SSL libraries incorrectly, leading to
vulnerabilities. According to the authors
"the root cause of most of these vulnerabilities is the terrible design of the APIs to the underlying
SSL libraries. Instead of expressing high-level security properties of network tunnels such as
confidentiality and authentication, these APIs expose low-level details of the SSL protocol to
application developers. As a consequence, developers often use SSL APIs incorrectly,
misinterpreting and misunderstanding their manifold parameters, options, side effects, and return
values."

Other uses[edit]
The Simple Mail Transfer Protocol (SMTP) can also be protected by TLS. These applications
use public key certificates to verify the identity of endpoints.
TLS can also be used to tunnel an entire network stack to create a VPN, as is the case
with OpenVPN and OpenConnect. Many vendors now marry TLS's encryption and authentication
capabilities with authorization. There has also been substantial development since the late 1990s in
creating client technology outside of the browser to enable support for client/server applications.
When compared against traditional IPsec VPN technologies, TLS has some inherent advantages in
firewall and NAT traversal that make it easier to administer for large remote-access populations.
TLS is also a standard method to protect Session Initiation Protocol (SIP) application signaling. TLS
can be used to provide authentication and encryption of the SIP signaling associated with VoIP and
other SIP-based applications.[citation needed]