Transport Layer Security

from Wikipedia, the free encyclopedia
TLS on the TCP / IP protocol stack
application
HTTPS IMAPS POP3S SMTPS ...
application TLS
transport TCP
Internet IP ( IPv4 , IPv6 )
Network access Ethernet Token
bus
Token
ring
FDDI ...

Transport Layer Security ( TLS , English for Transport Layer Security ), wide known under the previous name Secure Sockets Layer ( SSL ), is a hybrid encryption protocol for secure data transmission in the Internet . The last version of the SSL protocol was version 3.0; then it was further developed and standardized under the new name TLS, starting with version 1.0.

TLS in practice

TLS encryption is currently used primarily with HTTPS . Most current web browsers and web servers prefer TLS 1.3 and TLS 1.2, mostly TLS 1.1 and TLS 1.0 are also supported, but this leads to a security warning. SSLv3 and SSLv2 are deactivated in current browsers, as this protocol version has a number of security gaps, including the Poodle attack . The further development TLS 1.3 is supported by Google Chrome , TLS 1.2 is used in the standard configuration of Internet Explorer, Firefox, Google Chrome, Opera and Apple iOS Safari (status 02/2014).

The German Federal Office for Information Security recommends versions 1.2 and 1.3 when using TLS. Cipher suites with Perfect Forward Secrecy are preferred.

For some time now, more and more website operators have been using Extended Validation TLS certificates (EV-TLS certificates). A field is also displayed in the address line of the browser in which the certificate and domain holder alternates with the certification authority . In addition, depending on the browser and / or add-on used, the address line is (partially) colored green. Internet users should be able to recognize even faster whether the website they are visiting is genuine and be better protected against phishing attempts . From a technical point of view, EV-TLS certificates do not offer any extended protection; the encryption and its strength are identical. Only the owner is verified better and more elaborately.

Since January 2017, the Chrome web browser has been marking websites that collect information without using HTTPS as unsafe. This is expected to lead to a significant increase in the use of HTTPS. In February 2017, HTTPS was activated in 2.57% of all registered German Internet domains as well as in 3.70% of Austrian domains and 9.71% of Swiss domains. An examination of around 40,000 websites of small and medium-sized companies in Baden-Württemberg by the State Commissioner for Data Protection and Freedom of Information in Baden-Württemberg has shown that around 7% of the websites examined are offered via HTTPS. For those websites that are offered via HTTPS, server-side support for TLS 1.0 is still very widespread (99%).

Without a certificate-based authentication, TLS is susceptible to man-in-the-middle attacks : If the man-in-the-middle is active before the key is handed over, it can fool both sides of its keys and thus record all data traffic in plain text and manipulate unnoticed. Because of the lack of trustworthiness of some certification authorities, the security of TLS has been questioned since the beginning of 2010. However, this risk can largely be eliminated by deactivating questionable certification authorities in your own browser.

In connection with a virtual server , for example with HTTP ( for example with the Apache HTTP server via the VHost mechanism), it is fundamentally a disadvantage that only one certificate can be used per combination of IP address and port , since the actual user data of the protocol above (and thus the name of the VHost) were not yet transmitted at the time of the TLS handshake. This problem was corrected with the TLS extension Server Name Indication (SNI) in June 2003 by the RFC 3546 . The required server name is sent when the connection is established. The original extension was described for TLS 1.0, due to the compatibility of the individual TLS versions with one another, SNI is also implemented for TLS 1.1 and TLS 1.2 in accordance with the recommendation.

In the Tor network , TLS certificates are of particular importance for connections to the Internet, since an unencrypted connection using a man-in-the-middle attack there by the computer establishing the connection to the Internet (referred to as " exit node ”) would be very easy. However, since a connection between two endpoints in the Tor network is encrypted, the encrypted transmission of data within the network can be considered of secondary importance, provided one trusts the routing of the connections. Here the main feature of TLS encryption is the authenticity of the other side.

In addition to HTTPS as an encrypted variant of HTTP , other known use cases for TLS are, for example:

Versions

version Publishing year Remarks
Older version; no longer supported: SSL 1.0 1994
Older version; no longer supported: SSL 2.0 1995 Use not permitted since March 2011.
Older version; no longer supported: SSL 3.0 1996 Use not permitted since June 2015.
Older version; still supported: TLS 1.0 1999 Support is running out. No longer complies with the Payment Card Industry Data Security Standard (PCI DSS) in payment transactions as of June 30, 2018 .
Older version; still supported: TLS 1.1 2006 Support is running out. Since TLS 1.1 uses the non- collision-resistant hash function SHA-1 for creating the signature, the BSI advises against its use.
Older version; still supported: TLS 1.2 2008
Current version: TLS 1.3 2018 RFC 8446 , also contains new requirements for TLS 1.2
Legend: Older version; no longer supported Older version; still supported Current version Current preliminary version Future version

history

  • In 1994, nine months after the first release of Mosaic , the first popular web browser , Netscape Communications completed the first version of SSL (1.0).
  • Five months later the next version SSL 2.0 was published together with a new edition of the Netscape Navigator.
  • In late 1995, Microsoft released the first version of its Internet Explorer web browser . Shortly thereafter, the first version of its SSL counterpart, PCT 1.0 (Private Communication Technology), also became known. PCT had several advantages over SSL 2.0 that were later incorporated into SSL 3.0.
  • When SSL was set as the standard by the IETF in RFC 2246 , it was renamed Transport Layer Security (TLS) in January 1999 . The differences between SSL 3.0 and TLS 1.0 are only minor. But the renaming resulted in version confusion. TLS 1.0 reports in the header as version SSL 3.1.
  • TLS was later extended by further RFCs :
    • RFC 2712 - Addition of Kerberos Cipher Suites to Transport Layer Security (TLS).
    • RFC 2817 - Upgrading to TLS Within HTTP / 1.1 explains the use of the upgrade mechanism in HTTP / 1.1 to initialize Transport Layer Security (TLS) over an existing TCP connection. This makes it possible to use the same “well-known” TCP ports (80 and 443) for both insecure and secure HTTP traffic.
    • RFC 2818 - HTTP Over TLS separates secure from unsecure traffic through separate server TCP ports.
    • RFC 3268 - Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) uses the extensibility of TLS and adds the symmetrical encryption algorithms ( RC2 , RC4 , International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES) and Triple DES ) the Advanced Encryption Standard (AES).
    • RFC 3546 - Transport Layer Security (TLS) Extensions introduces the concept of extensions, which means that optional data fields or headers can be transmitted especially during the initial negotiation. One of these extensions is Server Name Indication .
  • In April 2006, version 1.1 of TLS was standardized in RFC 4346, making RFC 2246 obsolete. In TLS 1.1, minor security improvements have been made and ambiguities have been eliminated.
  • In August 2008, version 1.2 of TLS appeared with RFC 5246 , which made RFC 4346 obsolete. The definition of MD5 / SHA-1 in the pseudo random function (PRF) and signed elements has been replaced by more flexible solutions in which the hash algorithms can be specified.
  • In February 2015, RFC 7465 was published banning RC4 for encryption.
  • In May 2015, recommendations for the secure use of TLS and DTLS were published with RFC 7525 . Accordingly, SSLv2, SSLv3, RC4 and other encryption algorithms that are restricted to a key length of less than 112 bits due to export restrictions should not be used. The use of 3DES for encryption and RSA for key exchange with static parameters is not recommended. We recommend cipher suites that use Ephemeral Diffie-Hellman combined with RSA for key exchange , which offers forward secrecy (against subsequent subsequent decryption), for encryption AES in Galois / Counter mode with 128 or 256 bit key length and the hash function SHA-256 or SHA -384 for the pseudo-random function of TLS.
  • In August 2018, TLS version 1.3 was published in RFC 8446 , which has been developed since 2014.
  • In October 2018, the manufacturers of the Firefox, Chrome, Edge and Safari browsers stated that they would no longer support the outdated TLS 1.0 and 1.1 protocols starting in March 2020. In Google Chrome 84, support for TLS 1.0 and 1.1 has therefore been removed.

functionality

The client establishes a connection to the server. The server authenticates itself to the client with a certificate . The client checks the trustworthiness of the X.509 certificate and whether the server name matches the certificate. Optionally, the client can also authenticate itself to the server with its own certificate. Then either the client sends the server a secret random number encrypted with the server's public key , or the two parties use the Diffie-Hellman key exchange to calculate a shared secret. A cryptographic key is then derived from the secret. This key is then used to encrypt all messages on the connection with a symmetrical encryption method and to protect the message integrity and authenticity with a message authentication code .

TLS protocols in the protocol stack

In the OSI model , TLS is arranged in layer 5 (the session layer). In the TCP / IP model, TLS is located above the transport layer (for example TCP ) and below application protocols such as HTTP or SMTP . In the specifications this is then referred to as "HTTP over TLS", for example. However, if both protocols are to be considered together, an “S” for Secure is usually appended to the protocol of the application layer (for example HTTP S ). TLS works transparently so that it can easily be used to provide secure connections to protocols without their own security mechanisms. It can also be expanded to ensure flexibility and future security for the encryption technology used.

The TLS protocol consists of two layers:

TLS handshake protocol TLS Change Cipher Spec. Protocol TLS Alert Protocol TLS Application Data Protocol
TLS Record Protocol

TLS Record Protocol

The TLS Record Protocol is the lower of the two layers and is used to secure the connection. It is based directly on the transport layer and offers two different services that can be used individually or jointly:

In addition, the data to be backed up is fragmented in blocks of a maximum of 16,384 (2 14 ) bytes and reassembled at the recipient. The standard stipulates that the block size does not exceed this value, unless the block is compressed or encrypted - then the block size may be 1024 bytes (with compression) or 2048 bytes (with encryption) larger. The data can also be compressed before the encryption and before the calculation of the cryptographic checksum. The compression procedure, like the cryptographic key, is negotiated using the TLS handshake protocol.

The structure of a TLS record message is as follows: Content Type (1 byte: Change Cipher Spec = 20, Alert = 21, Handshake = 22, Application Data = 23) | Protocol version major (1 byte) | Protocol version minor (1 byte) | Length (1 short or two bytes)

TLS handshake protocol

TLS handshake with two-way authentication using certificates and RSA key exchange

The TLS Handshake Protocol is based on the TLS Record Protocol and fulfills the following functions even before the first bits of the application data stream have been exchanged:

  • Identification and authentication of communication partners on the basis of asymmetric encryption methods and public key cryptography . This step is optionally a two-way authentication (in this case mutual TLS is sometimes used ), but usually only the server authenticates itself to the client .
  • Negotiating cryptographic algorithms and keys to be used. TLS also supports unencrypted transmission.

The handshake itself can be divided into four phases :

  1. The client sends a client_hello to the server, and the server replies to the client with a server_hello . The parameters of the messages are:
    • the version (the highest TLS protocol version supported by the client)
    • a 32 byte long random information (4 byte timestamp + 28 byte long random number) which is later used to create the pre-master secret (it protects against replay attacks )
    • a session ID
    • the cipher suite to be used (algorithms for key exchange, encryption and authentication)
    • Optionally, the desired FQDN for Server Name Indication support
  2. The server identifies itself to the client. The X.509v 3 certificate is also transmitted to the client here, which the client then verifies. If this is unsuccessful, the client breaks the connection. In addition, the server can optionally request a certificate for client authentication via CertificateRequest . This phase can only be omitted if an anonymous cipher suite is used without authentication.
  3. Here the client uses a certificate to identify itself to the server, provided that the server has sent a CertificateRequest . If the client does not have a certificate, it replies with an empty certificate list. The server certificate received previously contains the public key of the server. If a cipher suite with RSA key exchange is used (see figure), the pre-master secret generated by the client is encrypted with this public key and can be decrypted again by the server with the private key known only to it. Alternatively, the Diffie-Hellman key exchange can also be used here to generate a common pre-master secret . If the Diffie-Hellman secrets of the server and client are freshly and randomly negotiated during the handshake, the requirements for Perfect Forward Secrecy are met.
  4. This phase completes the handshake. From the existing secret pre-master that can master secret can be derived that a one-time session key ( English session key ) represents. Keys, which are used to encrypt and decrypt the data and for the integrity check, are derived from the master secret . The messages that the communication partners now send to each other are only transmitted in encrypted form.

TLS Change Cipher Spec Protocol

The Change Cipher Spec Protocol only consists of a single message. This message is one byte in size and has the content 1. With this message, the sender informs the recipient that he is switching to the cipher suite negotiated in the handshake protocol in the active session . A major reason for defining a separate protocol for this message is that TLS implementations can combine several messages of a protocol in one record (i.e. a TLS data unit). This is undesirable for the “Change Cipher Spec” message. Because records from different protocols cannot be combined, the problem is solved by defining a separate protocol.

TLS Alert Protocol

The Alert Protocol distinguishes around two dozen different messages. One of them announces the end of the session (close_notify). Others relate, for example, to the protocol syntax or the validity of the certificates used. A distinction is made between warnings and errors, with the latter terminating the connection immediately.

The structure of an error message is as follows: AlertLevel (1 byte: Warning = 1, Fatal = 2) | AlertDescription (1 byte: close_notify = 0, […], no_renegotiation = 100).

The following serious error types are defined in the specification of TLS:

unexpected_message Inappropriate message was received.
bad_record_mac An incorrect MAC was received.
decompression_failure Decompression algorithm received incorrect data.
handshake_failure Sender was unable to edit an acceptable set of security parameters.
illegal_parameter A field in the handshake message was out of range or conflicted with other fields.

The following warnings are defined in the specification of TLS:

close_notify Informs recipients that the sender will not send any further messages on this connection. Must be sent as the last message by every partner in a connection.
no_certificate Can be sent in response to a certificate request if the appropriate certificate is not available. (Removed in TLS 1.0)
bad_certificate Received certificate was incomplete or incorrect.
unsupported_certificate The type of the receiving certificate is not supported.
certificate_revoked Certificate was recalled by the signer.
certificate_expired Certificate has expired.
certificate_unknown Other, unspecified reasons occurred while the certificate was being edited that resulted in the certificate being marked as invalid.

The following warnings have been added to the specification of TLS 1.0:

decryption_failed Decryption failed.
record_overflow
unknown_ca Unknown or untrustworthy CA.
access_denied Access denied.
decode_error Decoding error.
decrypt_error Decryption failure.
export_restriction Export restriction.
protocol_version Outdated version of TLS / SSL.
insufficient_security Insufficient security.
internal_error Internal error.
user_canceled Cancellation by user.
no_renegotiation

TLS Application Data Protocol

The application data is transported via the Record Protocol, broken down into parts, compressed and, depending on the current status of the session, also encrypted. In terms of content, they are not interpreted in more detail by TLS.

Calculation of the master secret

In earlier protocol versions , the master secret is calculated from the pre-master secret with the help of the hash functions SHA-1 and MD5 , in TLS 1.2 with the help of a pseudo-random function specified by a cipher suite . The random numbers from phase 1 of the handshake are also included in this calculation. Using both hash functions should ensure that the master secret is still protected in the event that one of the functions is deemed to have been compromised. In TLS 1.2 this approach is replaced by the flexible interchangeability of the function.

safety

A number of attacks are known to undermine security guarantees on both SSL and TLS. The following list represents some of the known attacks.

Padding Oracle attacks

The cryptologist Serge Vaudenay discovered in 2002 that a man-in-the-middle attacker can obtain information from the padding of a message encrypted with the Cipher Block Chaining Mode (CBC) that can be used to decrypt the message. Through targeted manipulation of an encrypted message, the attacker learns whether the server is reporting a valid padding and thus part of the plaintext has been correctly guessed.

As a protective measure, the server should discard invalid messages without revealing whether the padding or message authenticity was invalid. However, an attacker can also derive this information by analyzing the response times (timing attack). SSL, TLS up to version 1.2 and DTLS are affected, provided a cipher suite with CBC is used. Cipher suites with authenticated encryption are not affected.

In October 2014, security researchers demonstrated the POODLE attack ( Padding Oracle On Downgraded Legacy Encryption ), with which an attacker forces a version downgrade of a TLS connection in order to carry out a Padding Oracle attack against SSL 3.0. For compatibility reasons, SSL 3.0 was still supported by web browsers and other implementations, despite security weaknesses known at the time. Subsequently, the Internet Engineering Task Force marked SSL 3.0 as outdated and specified a method to protect against downgrade attacks on TLS.

BEAST

SSL 3.0 and TLS 1.0 use a predictable initialization vector in CBC mode. An attacker can use a chosen plaintext attack to determine unknown parts of the plaintext. One attack scenario is the stealing of HTTP cookies , which are transmitted in encrypted form. To do this, the attacker must lure the attack victim to a malicious website that repeatedly triggers HTTP requests to a foreign domain, with the web browser automatically sending the HTTP cookies set for the domain. The attacker can guess the cookie character by character due to the partly self-selected content of the HTTP requests and by listening to the encrypted TLS messages.

The basics of the attack were described in 2004 and first demonstrated in practice in 2011 under the name BEAST ( Browser Exploit Against SSL / TLS ). TLS version 1.1 and higher are not affected as each message is encrypted with a pseudo-random initialization vector.

Compression attacks

The use of the optional compression of user data opens up a class of attacks that allow parts of the plaintext to be guessed. The attack scenario is similar to that of the BEAST attack : the attacker carries out a chosen plain text attack and observes the encrypted TLS messages in the network. The compression method removes redundancies from the user data, so that the plain text to be encrypted and thus also the ciphertext becomes shorter. If the attacker has guessed part of the unknown plaintext, for example a character from an HTTP cookie, he learns this from the difference in length of an encrypted TLS message.

The attack was published in 2012 by the creators of the BEAST attack under the name CRIME ( Compression Ratio Info-leak Made Easy ). In addition to SSL and TLS, the SPDY protocol is also affected. The use of compression is not recommended as a protective measure. TLS 1.3 or higher no longer supports compression. The SPDY successor HTTP / 2 uses a simplified compression format ( HPACK ), which compresses less efficiently than Deflate , but is more difficult to attack.

TIME and BREACH are improved variants of the attack. TIME ( Timing Info-leak Made Easy ) derives the size of an encrypted TLS message from the response time without having to listen to the network traffic. Both attacks allow guessing of TLS-encrypted content if TLS compression is switched off and HTTP compression is used instead . Since TLS cannot fundamentally prevent compression attacks, application-specific protective measures must be used, for example not using compression at all.

Downgrade to export encryption

As a result of the export restrictions on cryptography from the United States , numerous exportable cipher suites that only use short keys are specified in TLS. Despite known security weaknesses, some of these were or are still supported by implementations. The TLS handshake is actually intended to prevent a man-in-the-middle attacker from forcing a downgrade to an unsolicited cipher suite by authenticating the handshake messages. The security of the authentication also depends on the negotiated cipher suite, so that the attacker can break the key.

In the FREAK attack ( Factoring RSA Export Keys ) published in 2015, a downgrade to RSA-based cipher suites with 512-bit export keys took place. The attack assumes an implementation error in which the client uses the 512-bit key instead of the longer key from the server certificate. The bug related to OpenSSL and SecureTransport (Apple), among others.

Shortly thereafter, a team of researchers published the Logjam attack, which enables the Diffie-Hellman key exchange to be downgraded to 512-bit residual class groups. The reason is the support of exportable cipher suites with ephemeral Diffie-Hellman. In contrast to FREAK, there is a weakness in the protocol in TLS that can be exploited without implementation errors. The Logjam attack can be carried out with high performance in practice, since a large part of the computing work to break the key can be carried out before the connection is established. The computational effort required during the actual key exchange takes about 70 seconds. As a protective measure, servers should switch off support for exportable cipher suites and use groups of at least 2048 bits. Clients should discard groups that are less than 1024 bits.

Implementation error

In addition to security weaknesses in the protocol, TLS implementations are affected by security-relevant implementation errors on a recurring basis. One of the most serious bugs was the Heartbleed bug discovered in OpenSSL in 2014 .

Public and deliberate breach of encryption

A social attack on the TLS standard was started via the ETSI , in which a version of the standard that can be encrypted and therefore has to be regarded as broken is to find its way into general communication processes.

The attackers derive a justification for their attack on the encryption from the fact that there must be opportunities in business, especially in the financial industry, as well as in authorities, to gain a higher-level insight into encrypted communication without those involved being aware of it. Many professionals and organizations such as B. the EFF warn very clearly against the use of this procedure due to the possible collateral damage.

The attempt to introduce this defective encryption into the TLS family as “eTLS” (“Enterprise TLS”) was fought off by naming rights to TLS. which is why the process will be renamed ETS.

Since ETS / eTLS is recognized as a CVE by TLS, ETS / eTLS can also be described as (deliberately) incorrect implementation of TLS.

As a result, the Technical Committee CYBER of ETSI 2019 received the negative BigBrotherAward :

"For his efforts to define the 'Enterprise Transport Security' protocol (ETS) as part of the new technical standard for encryption on the Internet and thus to equip secure connections with a predetermined breaking point"

- Frank Rosengart : laudation at the BigBrotherAwards

Advantages and disadvantages

The advantage of the TLS protocol is the ability to implement any higher protocol based on the TLS protocol. This guarantees independence from applications and systems.

The disadvantage of TLS-encrypted transmission is that the connection setup on the server side is computationally intensive and therefore slower. The encryption itself requires little computing time , depending on the algorithm used .

Encrypted data can hardly be compressed by compression at lower layers ( e.g. at the PPTP level).

TLS only encrypts communication between two stations. Scenarios are conceivable in service-oriented architectures in which a message is sent via several stations. If each station is only allowed to read part of the message, TLS is not sufficient because each station can decrypt all of the data in the message. This creates security gaps at every station that cannot decrypt data intended for it.

Implementations

The best-known program libraries that implement Transport Layer Security include:

See also

literature

  • Eric Rescorla: SSL and TLS. Designing and building secure systems. Addison-Wesley, New York NY a. a. 2001, ISBN 0-201-61598-3 .
  • Roland Bless et al. a .: Secure network communication. Basics, protocols and architectures. Springer Verlag, Berlin a. a. 2005, ISBN 3-540-21845-9 , ( X.systems.press ).
  • Claudia Eckert : IT security. Concepts - Procedures - Protocols. 6th revised edition. Oldenbourg, Munich a. a. 2009, ISBN 978-3-486-58999-3 .

Web links

Individual evidence

  1. a b Christopher Wood: Deprecation of Legacy TLS 1.0 and 1.1 Versions. In: WebKit. October 15, 2018, accessed August 18, 2020 .
  2. a b Martin Thomson: Removing Old Versions of TLS. Retrieved August 18, 2020 (American English).
  3. a b TLS 1.0 and TLS 1.1 - Chrome Platform Status. Retrieved August 18, 2020 .
  4. Firefox cannot establish a secure connection because the website is using an older, insecure version of the SSL protocol. Retrieved January 19, 2016 .
  5. SSLv2 insecure - should be disabled by default. Retrieved January 19, 2016 .
  6. On SSL 2 and older protocols. Retrieved January 19, 2016 .
  7. Firefox 27 encrypted with TLS 1.2. Retrieved January 19, 2016 .
  8. TR-02102-2 Cryptographic procedures: Recommendations and key lengths. Federal Office for Information Security , February 22, 2019, accessed on March 6, 2020 .
  9. German Internet statistics reflecte.de. (No longer available online.) Archived from the original on February 14, 2017 ; accessed on February 22, 2017 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / www.reflecte.de
  10. ^ Austrian internet statistics reflecte.at. (No longer available online.) Archived from the original on February 14, 2017 ; accessed on February 22, 2017 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / www.reflecte.at
  11. Swiss Internet Statistics avidom.ch. (No longer available online.) Archived from the original on February 14, 2017 ; accessed on February 22, 2017 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / www.avidom.ch
  12. Ronald Petrlic, Klaus Manny: How secure is access to websites on the Internet? In: Data protection and data security - DuD . tape 41 , no. 2 , February 3, 2017, ISSN  1614-0702 , p. 88-92 , doi : 10.1007 / s11623-017-0734-y .
  13. EFF doubts SSL's security against eavesdropping. Retrieved January 19, 2016 .
  14. New Research Suggests That Governments May Fake SSL Certificates. Retrieved January 19, 2016 .
  15. Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL. (PDF) (No longer available online.) Archived from the original on February 16, 2016 ; accessed on January 19, 2016 (English). Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / files.cloudprivacy.net
  16. Law Enforcement Appliance SUBVERTS SSL. Retrieved January 19, 2016 .
  17. ^ S. Turner, T. Polk:  RFC 6176 . (English).
  18. ^ R. Barnes, M. Thomson, A. Pironti, A. Langley:  RFC 7568 . (English).
  19. Are You Ready for June 30, 2018? Saying goodbye to SSL / early TLS. In: PCI Security Standards Council, LLC. Accessed July 19, 2018 .
  20. TR-02102-2 Cryptographic procedures: Recommendations and key lengths. (PDF; 829 kB) January 2019, p. 7 , accessed on January 15, 2020 : “Since TLS 1.1 uses the hash function SHA-1 as a component for creating the signature (and does not support the SHA-2 family), the Use of TLS 1.1 no longer recommended. "
  21. ^ [TLS] Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard. Retrieved March 31, 2018 (draft-ietf-tls-tls13-28.txt).
  22. a b RFC 8446 . - The Transport Layer Security (TLS) Protocol Version 1.3 . August 2018. (English).
  23. RFC 7465 . - Prohibiting RC4 cipher suites . February 2015. (English).
  24. Jürgen Schmidt: IETF prohibits RC4 encryption in TLS. Heise Security, February 20, 2015, accessed February 20, 2015 .
  25. RFC 7525 . - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) . May 2015. (English).
  26. Jürgen Schmidt: IETF specifies guidelines for the use of encryption. Heise Security, May 8, 2015, accessed May 10, 2015 .
  27. ^ Joshua Davies: Implementing SSL / TLS Using Cryptography and PKI. John Wiley and Sons, Indianapolis 2011, p. 344.
  28. a b Schwenk, Jörg (2010): Security and cryptography in the Internet. From secure e-mail to IP encryption , published by Vieweg + Teubner Verlag / GWV Fachverlage GmbH, Wiesbaden. ISBN 978-3-8348-0814-1 .
  29. RFC 7457 . - Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) . February 2015. (English).
  30. Serge Vaudenay: Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS… In: Advances in Cryptology - EUROCRYPT 2002 (=  Lecture Notes in Computer Science ). tape 2332 . Springer, Berlin / Heidelberg 2002, p. 535-545 , doi : 10.1145 / 586110.586125 ( iacr.org [PDF]).
  31. Nadhem J. AlFardan, Kenneth G. Paterson: Lucky Thirteen: Breaking the TLS and DTLS Record Protocols . In: IEEE Symposium on Security and Privacy . IEEE, 2013, pp. 526-540 , doi : 10.1109 / SP.2013.42 ( ieee-security.org [PDF]).
  32. RFC 7568 . - Deprecating Secure Sockets Layer version 3.0 . June 2015. (English).
  33. RFC 7507 . - TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks . April 2015. (English).
  34. ^ Gregory V. Bard: The Vulnerability of SSL to Chosen Plaintext Attack . In: Cryptology ePrint Archive . 2004, doi : 10.1145 / 586110.586125 ( iacr.org [PDF]).
  35. ^ Thai Duong, Juliano Rizzo: Here Come The Ninjas. (PDF) May 13, 2011, accessed January 10, 2016 .
  36. Juliano Rizzo, Thai Duong: Browser Exploit Against SSL / TLS. October 3, 2011, accessed January 10, 2016 .
  37. ^ Juliano Rizzo, Thai Duong: The CRIME attack. (PDF) 2012, accessed on January 11, 2016 (presentation at the Ekoparty 2012.).
  38. RFC 7541 . - HPACK: Header Compression for HTTP / 2 . May 2015. (English).
  39. Tal Be'ery, Amichai Shulman: A Perfect CRIME? Only TIME Will Tell. (PDF) 2013, accessed on January 11, 2016 .
  40. Cipher Suites with "RSA_EXPORT" in the name.
  41. Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfredo Pironti, Pierre-Yves Strub, Jean Karim Zinzindohoue: A Messy State of the Union: Taming the Composite State Machines of TLS . In: IEEE Symposium on Security and Privacy . IEEE, 2015, p. 535–552 , doi : 10.1109 / SP.2015.39 ( research.microsoft.com [PDF]).
  42. Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfredo Pironti, Pierre-Yves Strub, Jean Karim Zinzindohoue: A messy state of the union: Taming the Composite State Machines of TLS. (PDF) 2015, accessed on January 11, 2016 (presentation slides).
  43. Cipher Suites with "DHE_EXPORT" in the name.
  44. David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, Paul Zimmermann: Imperfect Forward Secrecy : How Diffie-Hellman Fails in Practice . In: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security . ACM, New York 2015, pp. 5–17 , doi : 10.1145 / 2810103.2813707 ( weakdh.org [PDF]).
  45. TLS standardization: Authorities and banks want to undermine encryption . Heise Online; accessed on March 2, 2019
  46. ETS Isn't TLS and You Shouldn't Use It . EFF, accessed March 2, 2019
  47. ETSI TS 103 523-3: CYBER; Middlebox Security Protocol; Part 3: Profile for enterprise network and data center access control (PDF) Technical specification of the ETSI; accessed March 2, 2019
  48. ^ IETF to ETSI: Stay away from TLS . Heise Online; accessed on February 3, 2019
  49. CVE-2019-9191 The ETSI Enterprise Transport Security (ETS, formerly known as eTLS) protocol does not provide per-session forward secrecy . nist.gov; accessed on March 2, 2019
  50. Frank Rosengart: Laudation technology: “Technical Committee CYBER” of the European Institute for Telecommunications Standards (ETSI). In: bigbrotherawards.de. June 8, 2019, accessed June 21, 2019 .
  51. Google is developing its own SSL library on heise online