Transport Layer Security Security: History
View Latest Version
Please note this is an old version of this entry, which may differ significantly from the current revision.
Subjects: Others
Contributor:
HandWiki

This article discusses the security of the Transport Layer Security (TLS) internet protocol.

  • tls
  • security

1. SSL 2.0

SSL 2.0 was flawed in a variety of ways:[1]

  • Identical cryptographic keys were used for message authentication and encryption. (In SSL 3.0, MAC secrets may be larger than encryption keys, so messages can remain tamper-resistant even if encryption keys are broken.[2])
  • SSL 2.0 had a weak MAC construction that used the MD5 hash function with a secret prefix, making it vulnerable to length extension attacks.
  • SSL 2.0 did not have any protection for the handshake, meaning a man-in-the-middle downgrade attack could go undetected.
  • SSL 2.0 used the TCP connection close to indicate the end of data. This meant that truncation attacks were possible: the attacker simply forges a TCP FIN, leaving the recipient unaware of an illegitimate end of data message (SSL 3.0 fixed this problem by having an explicit closure alert).
  • SSL 2.0 assumed a single service and a fixed domain certificate, which clashed with the standard feature of virtual hosting in Web servers. This means that most websites were practically impaired from using SSL.

SSL 2.0 was disabled by default, beginning with Internet Explorer 7,[3] Mozilla Firefox 2,[4] Opera 9.5,[5] and Safari. Support for SSL 2.0 (and weak 40-bit and 56-bit ciphers) was removed completely from Opera as of version 10.[6][7]

2. SSL 3.0

SSL 3.0 improved upon SSL 2.0 by adding SHA-1–based ciphers and support for certificate authentication.

From a security standpoint, SSL 3.0 should be considered less desirable than TLS 1.0. The SSL 3.0 cipher suites have a weaker key derivation process; half of the master key that is established is fully dependent on the MD5 hash function, which is not resistant to collisions and is, therefore, not considered secure. Under TLS 1.0, the master key that is established depends on both MD5 and SHA-1 so its derivation process is not currently considered weak. It is for this reason that SSL 3.0 implementations cannot be validated under FIPS 140-2.[8]

In October 2014, the vulnerability in the design of SSL 3.0 was reported, which makes CBC mode of operation with SSL 3.0 vulnerable to the padding attack (see #POODLE attack).

3. TLS

TLS has a variety of security measures:

  • Protection against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite.
  • Numbering subsequent Application records with a sequence number and using this sequence number in the message authentication codes (MACs).
  • Using a message digest enhanced with a key (so only a key-holder can check the MAC). The HMAC construction used by most TLS cipher suites is specified in RFC 2104 (SSL 3.0 used a different hash-based MAC).
  • The message that ends the handshake ("Finished") sends a hash of all the exchanged handshake messages seen by both parties.
  • The pseudorandom function splits the input data in half and processes each one with a different hashing algorithm (MD5 and SHA-1), then XORs them together to create the MAC. This provides protection even if one of these algorithms is found to be vulnerable.

4. Attacks Against TLS/SSL

Significant attacks against TLS/SSL are listed below.

In February 2015, IETF issued an informational RFC[9] summarizing the various known attacks against TLS/SSL.

4.1. Renegotiation Attack

A vulnerability of the renegotiation procedure was discovered in August 2009 that can lead to plaintext injection attacks against SSL 3.0 and all current versions of TLS.[10] For example, it allows an attacker who can hijack an https connection to splice their own requests into the beginning of the conversation the client has with the web server. The attacker can't actually decrypt the client–server communication, so it is different from a typical man-in-the-middle attack. A short-term fix is for web servers to stop allowing renegotiation, which typically will not require other changes unless client certificate authentication is used. To fix the vulnerability, a renegotiation indication extension was proposed for TLS. It will require the client and server to include and verify information about previous handshakes in any renegotiation handshakes.[11] This extension has become a proposed standard and has been assigned the number RFC 5746. The RFC has been implemented by several libraries.[12][13][14]

4.2. Downgrade Attacks: FREAK Attack and Logjam Attack

A protocol downgrade attack (also called a version rollback attack) tricks a web server into negotiating connections with previous versions of TLS (such as SSLv2) that have long since been abandoned as insecure.

Previous modifications to the original protocols, like False Start[15] (adopted and enabled by Google Chrome[16]) or Snap Start, reportedly introduced limited TLS protocol downgrade attacks[17] or allowed modifications to the cipher suite list sent by the client to the server. In doing so, an attacker might succeed in influencing the cipher suite selection in an attempt to downgrade the cipher suite negotiated to use either a weaker symmetric encryption algorithm or a weaker key exchange.[18] A paper presented at an ACM conference on computer and communications security in 2012 demonstrated that the False Start extension was at risk: in certain circumstances it could allow an attacker to recover the encryption keys offline and to access the encrypted data.[19]

Encryption downgrade attacks can force servers and clients to negotiate a connection using cryptographically weak keys. In 2014, a man-in-the-middle attack called FREAK was discovered affecting the OpenSSL stack, the default Android web browser, and some Safari browsers.[20] The attack involved tricking servers into negotiating a TLS connection using cryptographically weak 512 bit encryption keys.

Logjam is a security exploit discovered in May 2015 that exploits the option of using legacy "export-grade" 512-bit Diffie–Hellman groups dating back to the 1990s.[21] It forces susceptible servers to downgrade to cryptographically weak 512-bit Diffie–Hellman groups. An attacker can then deduce the keys the client and server determine using the Diffie–Hellman key exchange.

4.3. Cross-Protocol Attacks: DROWN

The DROWN attack is an exploit that attacks servers supporting contemporary SSL/TLS protocol suites by exploiting their support for the obsolete, insecure, SSLv2 protocol to leverage an attack on connections using up-to-date protocols that would otherwise be secure.[22][23] DROWN exploits a vulnerability in the protocols used and the configuration of the server, rather than any specific implementation error. Full details of DROWN were announced in March 2016, together with a patch for the exploit. At that time, more than 81,000 of the top 1 million most popular websites were among the TLS protected websites that were vulnerable to the DROWN attack.[23]

4.4. BEAST Attack

On September 23, 2011 researchers Thai Duong and Juliano Rizzo demonstrated a proof of concept called BEAST (Browser Exploit Against SSL/TLS)[24] using a Java applet to violate same origin policy constraints, for a long-known cipher block chaining (CBC) vulnerability in TLS 1.0:[25][26] an attacker observing 2 consecutive ciphertext blocks C0, C1 can test if the plaintext block P1 is equal to x by choosing the next plaintext block P2 = x [math]\displaystyle{ \oplus }[/math] C0 [math]\displaystyle{ \oplus }[/math] C1; as per CBC operation, C2 = E(C1 [math]\displaystyle{ \oplus }[/math] P2) = E(C1 [math]\displaystyle{ \oplus }[/math] x [math]\displaystyle{ \oplus }[/math] C0 [math]\displaystyle{ \oplus }[/math] C1) = E(C0 [math]\displaystyle{ \oplus }[/math] x), which will be equal to C1 if x = P1. Practical exploits had not been previously demonstrated for this vulnerability, which was originally discovered by Phillip Rogaway[27] in 2002. The vulnerability of the attack had been fixed with TLS 1.1 in 2006, but TLS 1.1 had not seen wide adoption prior to this attack demonstration.

RC4 as a stream cipher is immune to BEAST attack. Therefore, RC4 was widely used as a way to mitigate BEAST attack on the server side. However, in 2013, researchers found more weaknesses in RC4. Thereafter enabling RC4 on server side was no longer recommended.[28]

Chrome and Firefox themselves are not vulnerable to BEAST attack,[29][30] however, Mozilla updated their NSS libraries to mitigate BEAST-like attacks. NSS is used by Mozilla Firefox and Google Chrome to implement SSL. Some web servers that have a broken implementation of the SSL specification may stop working as a result.[31]

Microsoft released Security Bulletin MS12-006 on January 10, 2012, which fixed the BEAST vulnerability by changing the way that the Windows Secure Channel (SChannel) component transmits encrypted network packets from the server end.[32] Users of Internet Explorer (prior to version 11) that run on older versions of Windows (Windows 7, Windows 8 and Windows Server 2008 R2) can restrict use of TLS to 1.1 or higher.

Apple fixed BEAST vulnerability by implementing 1/n-1 splitTemplate:Explain-wrap and turning it on by default in OS X Mavericks, released on October 22, 2013.[33]

4.5. CRIME and BREACH Attacks

The authors of the BEAST attack are also the creators of the later CRIME attack, which can allow an attacker to recover the content of web cookies when data compression is used along with TLS.[34][35] When used to recover the content of secret authentication cookies, it allows an attacker to perform session hijacking on an authenticated web session.

While the CRIME attack was presented as a general attack that could work effectively against a large number of protocols, including but not limited to TLS, and application-layer protocols such as SPDY or HTTP, only exploits against TLS and SPDY were demonstrated and largely mitigated in browsers and servers. The CRIME exploit against HTTP compression has not been mitigated at all, even though the authors of CRIME have warned that this vulnerability might be even more widespread than SPDY and TLS compression combined. In 2013 a new instance of the CRIME attack against HTTP compression, dubbed BREACH, was announced. Based on the CRIME attack a BREACH attack can extract login tokens, email addresses or other sensitive information from TLS encrypted web traffic in as little as 30 seconds (depending on the number of bytes to be extracted), provided the attacker tricks the victim into visiting a malicious web link or is able to inject content into valid pages the user is visiting (ex: a wireless network under the control of the attacker).[36] All versions of TLS and SSL are at risk from BREACH regardless of the encryption algorithm or cipher used.[37] Unlike previous instances of CRIME, which can be successfully defended against by turning off TLS compression or SPDY header compression, BREACH exploits HTTP compression which cannot realistically be turned off, as virtually all web servers rely upon it to improve data transmission speeds for users.[36] This is a known limitation of TLS as it is susceptible to chosen-plaintext attack against the application-layer data it was meant to protect.

4.6. Timing Attacks on Padding

Earlier TLS versions were vulnerable against the padding oracle attack discovered in 2002. A novel variant, called the Lucky Thirteen attack, was published in 2013.

Some experts[38] also recommended avoiding Triple-DES CBC. Since the last supported ciphers developed to support any program using Windows XP's SSL/TLS library like Internet Explorer on Windows XP are RC4 and Triple-DES, and since RC4 is now deprecated (see discussion of RC4 attacks), this makes it difficult to support any version of SSL for any program using this library on XP.

A fix was released as the Encrypt-then-MAC extension to the TLS specification, released as RFC 7366.[39] The Lucky Thirteen attack can be mitigated in TLS 1.2 by using only AES_GCM ciphers; AES_CBC remains vulnerable.

4.7. POODLE attack

On October 14, 2014, Google researchers published a vulnerability in the design of SSL 3.0, which makes CBC mode of operation with SSL 3.0 vulnerable to a padding attack (CVE-2014-3566). They named this attack POODLE (Padding Oracle On Downgraded Legacy Encryption). On average, attackers only need to make 256 SSL 3.0 requests to reveal one byte of encrypted messages.[40]

Although this vulnerability only exists in SSL 3.0 and most clients and servers support TLS 1.0 and above, all major browsers voluntarily downgrade to SSL 3.0 if the handshakes with newer versions of TLS fail unless they provide the option for a user or administrator to disable SSL 3.0 and the user or administrator does so. Therefore, the man-in-the-middle can first conduct a version rollback attack and then exploit this vulnerability.[40]

In general, graceful security degradation for the sake of interoperability is difficult to carry out in a way that cannot be exploited. This is challenging especially in domains where fragmentation is high.[41]

On December 8, 2014, a variant of POODLE was announced that impacts TLS implementations that do not properly enforce padding byte requirements.[42]

4.8. RC4 Attacks

Despite the existence of attacks on RC4 that broke its security, cipher suites in SSL and TLS that were based on RC4 were still considered secure prior to 2013 based on the way in which they were used in SSL and TLS. In 2011, the RC4 suite was actually recommended as a work around for the BEAST attack.[43] New forms of attack disclosed in March 2013 conclusively demonstrated the feasibility of breaking RC4 in TLS, suggesting it was not a good workaround for BEAST.[44] An attack scenario was proposed by AlFardan, Bernstein, Paterson, Poettering and Schuldt that used newly discovered statistical biases in the RC4 key table[45] to recover parts of the plaintext with a large number of TLS encryptions.[46][47] An attack on RC4 in TLS and SSL that requires 13 × 220 encryptions to break RC4 was unveiled on 8 July 2013 and later described as "feasible" in the accompanying presentation at a USENIX Security Symposium in August 2013.[48][49] In July 2015, subsequent improvements in the attack make it increasingly practical to defeat the security of RC4-encrypted TLS.[50]

As many modern browsers have been designed to defeat BEAST attacks (except Safari for Mac OS X 10.7 or earlier, for iOS 6 or earlier, and for Windows; see #Web browsers), RC4 is no longer a good choice for TLS 1.0. The CBC ciphers which were affected by the BEAST attack in the past have become a more popular choice for protection.[38] Mozilla and Microsoft recommend disabling RC4 where possible.[51][52] RFC 7465 prohibits the use of RC4 cipher suites in all versions of TLS.

On September 1, 2015, Microsoft, Google and Mozilla announced that RC4 cipher suites would be disabled by default in their browsers (Microsoft Edge, Internet Explorer 11 on Windows 7/8.1/10, Firefox, and Chrome) in early 2016.[53][54][55]

4.9. Truncation Attack

A TLS (logout) truncation attack blocks a victim's account logout requests so that the user unknowingly remains logged into a web service. When the request to sign out is sent, the attacker injects an unencrypted TCP FIN message (no more data from sender) to close the connection. The server therefore doesn't receive the logout request and is unaware of the abnormal termination.[56]

Published in July 2013,[57][58] the attack causes web services such as Gmail and Hotmail to display a page that informs the user that they have successfully signed-out, while ensuring that the user's browser maintains authorization with the service, allowing an attacker with subsequent access to the browser to access and take over control of the user's logged-in account. The attack does not rely on installing malware on the victim's computer; attackers need only place themselves between the victim and the web server (e.g., by setting up a rogue wireless hotspot).[56] This vulnerability also requires access to the victim's computer. Another possibility is when using FTP the data connection can have a false FIN in the data stream, and if the protocol rules for exchanging close_notify alerts is not adhered to a file can be truncated.

4.10. Unholy PAC Attack

This attack, discovered in mid-2016, exploits weaknesses in the Web Proxy Autodiscovery Protocol (WPAD) to expose the URL that a web user is attempting to reach via a TLS-enabled web link.[59] Disclosure of a URL can violate a user's privacy, not only because of the website accessed, but also because URLs are sometimes used to authenticate users. Document sharing services, such as those offered by Google and Dropbox, also work by sending a user a security token that's included in the URL. An attacker who obtains such URLs may be able to gain full access to a victim's account or data.

The exploit works against almost all browsers and operating systems.

4.11. Sweet32 Attack

The Sweet32 attack breaks all 64-bit block ciphers used in CBC mode as used in TLS by exploiting a birthday attack and either a man-in-the-middle attack or injection of a malicious JavaScript into a web page. The purpose of the man-in-the-middle attack or the JavaScript injection is to allow the attacker to capture enough traffic to mount a birthday attack.[60]

4.12. Implementation Errors: Heartbleed Bug, BERserk Attack, Cloudflare Bug

The Heartbleed bug is a serious vulnerability specific to the implementation of SSL/TLS in the popular OpenSSL cryptographic software library, affecting versions 1.0.1 to 1.0.1f. This weakness, reported in April 2014, allows attackers to steal private keys from servers that should normally be protected.[61] The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret private keys associated with the public certificates used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.[62] The vulnerability is caused by a buffer over-read bug in the OpenSSL software, rather than a defect in the SSL or TLS protocol specification.

In September 2014, a variant of Daniel Bleichenbacher's PKCS#1 v1.5 RSA Signature Forgery vulnerability[63] was announced by Intel Security Advanced Threat Research. This attack, dubbed BERserk, is a result of incomplete ASN.1 length decoding of public key signatures in some SSL implementations, and allows a man-in-the-middle attack by forging a public key signature.[64]

In February 2015, after media reported the hidden pre-installation of Superfish adware on some Lenovo notebooks,[65] a researcher found a trusted root certificate on affected Lenovo machines to be insecure, as the keys could easily be accessed using the company name, Komodia, as a passphrase.[66] The Komodia library was designed to intercept client-side TLS/SSL traffic for parental control and surveillance, but it was also used in numerous adware programs, including Superfish, that were often surreptitiously installed unbeknownst to the computer user. In turn, these potentially unwanted programs installed the corrupt root certificate, allowing attackers to completely control web traffic and confirm false websites as authentic.

In May 2016, it was reported that dozens of Danish HTTPS-protected websites belonging to Visa Inc. were vulnerable to attacks allowing hackers to inject malicious code and forged content into the browsers of visitors.[67] The attacks worked because the TLS implementation used on the affected servers incorrectly reused random numbers (nonces) that are intended be used only once, ensuring that each TLS handshake is unique.[67]

In February 2017, an implementation error caused by a single mistyped character in code used to parse HTML created a buffer overflow error on Cloudflare servers. Similar in its effects to the Heartbleed bug discovered in 2014, this overflow error, widely known as Cloudbleed, allowed unauthorized third parties to read data in the memory of programs running on the servers—data that should otherwise have been protected by TLS.[68]

4.13. Survey of Websites Vulnerable to Attacks

(As of May 2019), Trustworthy Internet Movement estimate the ratio of websites that are vulnerable to TLS attacks.[69]

Survey of the TLS vulnerabilities of the most popular websites
Attacks Security
Insecure Depends Secure Other
Renegotiation attack 0.4%
support insecure renegotiation		 0.4%
support both		 98.3%
support secure renegotiation		 1.2%
no support
RC4 attacks 1.3%
support RC4 suites used with modern browsers		 12.6%
support some RC4 suites		 86.1%
no support		 N/A
TLS Compression (CRIME attack) 0.1%
vulnerable		 N/A N/A N/A
Heartbleed <0.1%
vulnerable		 N/A N/A N/A
ChangeCipherSpec injection attack 0.2%
vulnerable and exploitable		 1.3%
vulnerable, not exploitable		 96.8%
not vulnerable		 1.8%
unknown
POODLE attack against TLS
(Original POODLE against SSL 3.0 is not included)		 0.3%
vulnerable and exploitable		 N/A 98.3%
not vulnerable		 1.4%
unknown
Protocol downgrade 11.7%
Downgrade defence not supported		 N/A 72.0%
Downgrade defence supported		 16.3%
unknown

5. Forward Secrecy

Forward secrecy is a property of cryptographic systems which ensures that a session key derived from a set of public and private keys will not be compromised if one of the private keys is compromised in the future.[70] Without forward secrecy, if the server's private key is compromised, not only will all future TLS-encrypted sessions using that server certificate be compromised, but also any past sessions that used it as well (provided of course that these past sessions were intercepted and stored at the time of transmission).[71] An implementation of TLS can provide forward secrecy by requiring the use of ephemeral Diffie–Hellman key exchange to establish session keys, and some notable TLS implementations do so exclusively: e.g., Gmail and other Google HTTPS services that use OpenSSL.[72] However, many clients and servers supporting TLS (including browsers and web servers) are not configured to implement such restrictions.[73][74] In practice, unless a web service uses Diffie–Hellman key exchange to implement forward secrecy, all of the encrypted web traffic to and from that service can be decrypted by a third party if it obtains the server's master (private) key; e.g., by means of a court order.[75]

Even where Diffie–Hellman key exchange is implemented, server-side session management mechanisms can impact forward secrecy. The use of TLS session tickets (a TLS extension) causes the session to be protected by AES128-CBC-SHA256 regardless of any other negotiated TLS parameters, including forward secrecy ciphersuites, and the long-lived TLS session ticket keys defeat the attempt to implement forward secrecy.[76][77][78] Stanford University research in 2014 also found that of 473,802 TLS servers surveyed, 82.9% of the servers deploying ephemeral Diffie–Hellman (DHE) key exchange to support forward secrecy were using weak Diffie–Hellman parameters. These weak parameter choices could potentially compromise the effectiveness of the forward secrecy that the servers sought to provide.[79]

Since late 2011, Google has provided forward secrecy with TLS by default to users of its Gmail service, along with Google Docs and encrypted search, among other services.[80] Since November 2013, Twitter has provided forward secrecy with TLS to users of its service.[81] (As of May 2019), about 80% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to most web browsers.[69]

6. TLS Interception

TLS interception (or HTTPS interception if applied particularly to that protocol) is the practice of intercepting an encrypted data stream in order to decrypt it, read and possibly manipulate it, and then re-encrypt it and send the data on its way again. This is done by way of a "transparent proxy": the interception software terminates the incoming TLS connection, inspects the HTTP plaintext, and then creates a new TLS connection to the destination.[82]

TLS / HTTPS interception is used as an information security measure by network operators in order to be able to scan for and protect against the intrusion of malicious content into the network, such as computer viruses and other malware.[82] Such content could otherwise not be detected as long as it is protected by encryption, which is increasingly the case as a result of the routine use of HTTPS and other secure protocols.

A significant drawback of TLS / HTTPS interception is that it introduces new security risks of its own. Because it provides a point where network traffic is available unencrypted, attackers have an incentive to attack this point in particular in order to gain access to otherwise secure content. The interception also allows the network operator, or persons who gain access to its interception system, to perform man-in-the-middle attacks against network users. A 2017 study found that "HTTPS interception has become startlingly widespread, and that interception products as a class have a dramatically negative impact on connection security".[82]

The content is sourced from: https://handwiki.org/wiki/Transport_Layer_Security_Security

References

  1. Joris Claessens; Valentin Dem; Danny De Cock; Bart Preneel; Joos Vandewalle (2002). "On the Security of Today's Online Electronic Banking Systems". Computers & Security 21 (3): 253–265. doi:10.1016/S0167-4048(02)00312-7.  https://dx.doi.org/10.1016%2FS0167-4048%2802%2900312-7
  2. null
  3. Lawrence, Eric (2005-10-22). "IEBlog: Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2". MSDN Blogs. Archived from the original on 2013-04-17. https://www.webcitation.org/6FwL2ooJz?url=http://blogs.msdn.com/b/ie/archive/2005/10/22/483795.aspx. Retrieved 2007-11-25. 
  4. "Bugzilla@Mozilla — Bug 236933 – Disable SSL2 and other weak ciphers". Mozilla Corporation. https://bugzilla.mozilla.org/show_bug.cgi?id=236933. Retrieved 2007-11-25. 
  5. "Opera 9.5 for Windows Changelog" at Opera.com: "Disabled SSL v2 and weak ciphers." http://www.opera.com/docs/changelogs/windows/950/
  6. "Opera 10 for Windows changelog" at Opera.com: "Removed support for SSL v2 and weak ciphers" http://www.opera.com/docs/changelogs/windows/1000/
  7. Pettersen, Yngve (2007-04-30). "10 years of SSL in Opera — Implementer's notes". Opera Software. Archived from the original on October 12, 2007. https://web.archive.org/web/20071012205124/http://my.opera.com/yngve/blog/2007/04/30/10-years-of-ssl-in-opera. Retrieved 2007-11-25. 
  8. National Institute of Standards and Technology (December 2010). "Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program". Archived from the original on November 6, 2010. https://web.archive.org/web/20101106130105/http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf. 
  9. "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)". Archived from the original on 2016-03-04. https://web.archive.org/web/20160304201813/https://tools.ietf.org/html/rfc7457. 
  10. "CVE – CVE-2009-3555". Archived from the original on 2016-01-04. https://web.archive.org/web/20160104234608/http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555. 
  11. Eric Rescorla (2009-11-05). "Understanding the TLS Renegotiation Attack". Educated Guesswork. Archived from the original on 2012-02-09. https://www.webcitation.org/65JSTKRCA?url=http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html. Retrieved 2009-11-27. 
  12. "SSL_CTX_set_options SECURE_RENEGOTIATION". OpenSSL Docs. 2010-02-25. Archived from the original on 2010-11-26. https://web.archive.org/web/20101126121933/http://openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION. Retrieved 2010-11-18. 
  13. "GnuTLS 2.10.0 released". GnuTLS release notes. 2010-06-25. Archived from the original on 2012-02-09. https://www.webcitation.org/65JSUYEDA?url=http://article.gmane.org/gmane.network.gnutls.general/2046. Retrieved 2011-07-24. 
  14. "NSS 3.12.6 release notes". NSS release notes. 2010-03-03. Archived from the original on March 6, 2012. https://web.archive.org/web/20120306184633/https://developer.mozilla.org/NSS_3.12.6_release_notes. Retrieved 2011-07-24. 
  15. A. Langley; N. Modadugu (2010-06-02). "Transport Layer Security (TLS) False Start". Internet Engineering Task Force. IETF. Archived from the original on 2013-09-05. https://web.archive.org/web/20130905215608/http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00. Retrieved 2013-07-31. 
  16. Gruener, Wolfgang. "False Start: Google Proposes Faster Web, Chrome Supports It Already". Archived from the original on 2010-10-07. https://web.archive.org/web/20101007061707/http://www.conceivablytech.com/3299/products/false-start-google-proposes-faster-web-chrome-supports-it-already/. Retrieved 2011-03-09. 
  17. Smith, Brian. "Limited rollback attacks in False Start and Snap Start". Archived from the original on 2011-05-04. https://web.archive.org/web/20110504014418/http://www.ietf.org/mail-archive/web/tls/current/msg06933.html. Retrieved 2011-03-09. 
  18. Dimcev, Adrian. "False Start". Random SSL/TLS 101. Archived from the original on 2011-05-04. https://web.archive.org/web/20110504060256/http://www.carbonwind.net/blog/post/Random-SSLTLS-101-False-Start.aspx. Retrieved 2011-03-09. 
  19. Mavrogiannopoulos, Nikos; Vercautern, Frederik; Velichkov, Vesselin; Preneel, Bart (2012). A cross-protocol attack on the TLS protocol. Proceedings of the 2012 ACM conference on Computer and communications security. pp. 62–72. ISBN 978-1-4503-1651-4. https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf. 
  20. "SMACK: State Machine AttaCKs". Archived from the original on 2015-03-12. https://web.archive.org/web/20150312074827/https://www.smacktls.com/. 
  21. Goodin, Dan (2015-05-20). "HTTPS-crippling attack threatens tens of thousands of Web and mail servers". Ars Technica. Archived from the original on 2017-05-19. https://web.archive.org/web/20170519130937/https://arstechnica.com/security/2015/05/https-crippling-attack-threatens-tens-of-thousands-of-web-and-mail-servers/. 
  22. Leyden, John (1 March 2016). "One-third of all HTTPS websites open to DROWN attack". Archived from the original on 1 March 2016. https://web.archive.org/web/20160301215536/http://www.theregister.co.uk/2016/03/01/drown_tls_protocol_flaw/. 
  23. "More than 11 million HTTPS websites imperiled by new decryption attack". Archived from the original on 2016-03-01. https://web.archive.org/web/20160301191108/http://arstechnica.com/security/2016/03/more-than-13-million-https-websites-imperiled-by-new-decryption-attack/. 
  24. "Here Come The ⊕ Ninjas". 2011-05-13. Archived from the original on 2014-06-03. https://web.archive.org/web/20140603102506/https://bug665814.bugzilla.mozilla.org/attachment.cgi?id=540839. 
  25. Dan Goodin (2011-09-19). "Hackers break SSL encryption used by millions of sites". Archived from the original on 2012-02-09. https://www.webcitation.org/65JSSbOus?url=http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/. 
  26. "Y Combinator comments on the issue". 2011-09-20. Archived from the original on 2013-04-17. https://www.webcitation.org/6FwL5WZ8b?url=https://news.ycombinator.com/item?id=3015498. 
  27. "Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures". 2004-05-20. Archived from the original on 2012-06-30. https://web.archive.org/web/20120630143111/http://www.openssl.org/~bodo/tls-cbc.txt. 
  28. Ristic, Ivan (Sep 10, 2013). "Is BEAST Still a Threat?". Archived from the original on 12 October 2014. https://web.archive.org/web/20141012121824/https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat. Retrieved 8 October 2014. 
  29. "Chrome Stable Release". Chrome Releases. 2011-10-25. Archived from the original on 2015-02-20. https://web.archive.org/web/20150220020306/http://googlechromereleases.blogspot.jp/2011/10/chrome-stable-release.html. Retrieved 2015-02-01. 
  30. "Attack against TLS-protected communications". Mozilla Security Blog. Mozilla. 2011-09-27. Archived from the original on 2015-03-04. https://web.archive.org/web/20150304221307/https://blog.mozilla.org/security/2011/09/27/attack-against-tls-protected-communications/. Retrieved 2015-02-01. 
  31. Brian Smith (2011-09-30). "(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets -76)". https://bugzilla.mozilla.org/show_bug.cgi?id=665814. 
  32. "Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)". 2012-01-10. Archived from the original on 2014-08-15. https://web.archive.org/web/20140815234322/https://technet.microsoft.com/library/security/ms12-006. 
  33. Ristic, Ivan (Oct 31, 2013). "Apple Enabled BEAST Mitigations in OS X 10.9 Mavericks". Archived from the original on 12 October 2014. https://web.archive.org/web/20141012122536/https://community.qualys.com/blogs/securitylabs/2013/10/31/apple-enabled-beast-mitigations-in-os-x-109-mavericks. Retrieved 8 October 2014. 
  34. Dan Goodin (2012-09-13). "Crack in Internet's foundation of trust allows HTTPS session hijacking". Archived from the original on 2013-08-01. https://web.archive.org/web/20130801104610/http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/. Retrieved 2013-07-31. 
  35. Dennis Fisher (September 13, 2012). "CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions". ThreatPost. Archived from the original on September 15, 2012. https://web.archive.org/web/20120915224635/http://threatpost.com/en_us/blogs/crime-attack-uses-compression-ratio-tls-requests-side-channel-hijack-secure-sessions-091312. Retrieved 2012-09-13. 
  36. Goodin, Dan (1 August 2013). "Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages". Ars Technica. Condé Nast. Archived from the original on 3 August 2013. https://web.archive.org/web/20130803181144/http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/. Retrieved 2 August 2013. 
  37. Leyden, John (2 August 2013). "Step into the BREACH: New attack developed to read encrypted web data". The Register. Archived from the original on 5 August 2013. https://web.archive.org/web/20130805233414/http://www.theregister.co.uk/2013/08/02/breach_crypto_attack/. Retrieved 2 August 2013. 
  38. Qualys SSL Labs. "SSL/TLS Deployment Best Practices". Archived from the original on 4 July 2015. https://web.archive.org/web/20150704101956/https://www.ssllabs.com/projects/best-practices/index.html. Retrieved 2 June 2015. 
  39. P. Gutmann (September 2014). "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". Archived from the original on 2015-05-12. https://web.archive.org/web/20150512214100/https://tools.ietf.org/html/rfc7366. 
  40. "This POODLE Bites: Exploiting The SSL 3.0 Fallback". Archived from the original on 2014-10-14. https://web.archive.org/web/20141014224443/https://www.openssl.org/~bodo/ssl-poodle.pdf. Retrieved 2014-10-15. 
  41. Hagai Bar-El. "Poodle flaw and IoT". Archived from the original on 16 March 2015. https://web.archive.org/web/20150316030953/https://www.hbarel.com/analysis/eng/poodle-flaw-and-iot. Retrieved 15 October 2014. 
  42. Langley, Adam (December 8, 2014). "The POODLE bites again". Archived from the original on December 8, 2014. https://web.archive.org/web/20141208200653/https://www.imperialviolet.org/2014/12/08/poodleagain.html. Retrieved 2014-12-08. 
  43. security – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune – Server Fault http://serverfault.com/questions/315042/
  44. ivanr. "RC4 in TLS is Broken: Now What?". Qualsys Security Labs. Archived from the original on 2013-08-27. https://web.archive.org/web/20130827044512/https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what. Retrieved 2013-07-30. 
  45. Pouyan Sepehrdad; Serge Vaudenay; Martin Vuagnoux (2011). Discovery and Exploitation of New Biases in RC4. 6544. 74–91. doi:10.1007/978-3-642-19574-7_5. ISBN 978-3-642-19573-0.  https://dx.doi.org/10.1007%2F978-3-642-19574-7_5
  46. Green, Matthew. "Attack of the week: RC4 is kind of broken in TLS". Cryptography Engineering. Archived from the original on March 14, 2013. https://web.archive.org/web/20130314214026/http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html. Retrieved March 12, 2013. 
  47. Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt. "On the Security of RC4 in TLS". Royal Holloway University of London. Archived from the original on March 15, 2013. https://web.archive.org/web/20130315084623/http://www.isg.rhul.ac.uk/tls/. Retrieved March 13, 2013. 
  48. AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (8 July 2013). On the Security of RC4 in TLS and WPA. Archived from the original on 22 September 2013. https://web.archive.org/web/20130922170155/http://www.isg.rhul.ac.uk/tls/RC4biases.pdf. Retrieved 2 September 2013. 
  49. AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (15 August 2013). "On the Security of RC4 in TLS" (PDF). 22nd USENIX Security Symposium. p. 51. Archived from the original on 22 September 2013. https://web.archive.org/web/20130922133950/https://www.usenix.org/sites/default/files/conference/protected-files/alfardan_sec13_slides.pdf. Retrieved 2 September 2013. "Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical" 
  50. Goodin, Dan. "Once-theoretical crypto attack against HTTPS now verges on practicality". Conde Nast. Archived from the original on 16 July 2015. https://web.archive.org/web/20150716084138/http://arstechnica.com/security/2015/07/once-theoretical-crypto-attack-against-https-now-verges-on-practicality/. Retrieved 16 July 2015. 
  51. "Mozilla Security Server Side TLS Recommended Configurations". Mozilla. Archived from the original on 2015-01-03. https://web.archive.org/web/20150103093047/https://wiki.mozilla.org/Security/Server_Side_TLS. Retrieved 2015-01-03. 
  52. "Security Advisory 2868725: Recommendation to disable RC4". Microsoft. 2013-11-12. Archived from the original on 2013-11-18. https://web.archive.org/web/20131118081816/http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx. Retrieved 2013-12-04. 
  53. "Ending support for the RC4 cipher in Microsoft Edge and Internet Explorer 11". Microsoft Edge Team. September 1, 2015. Archived from the original on September 2, 2015. https://web.archive.org/web/20150902054341/http://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11/. 
  54. Langley, Adam (Sep 1, 2015). "Intent to deprecate: RC4". https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ. 
  55. Barnes, Richard (Sep 1, 2015). "Intent to ship: RC4 disabled by default in Firefox 44". Archived from the original on 2011-01-22. http://arquivo.pt/wayback/20110122130054/https://groups.google.com/forum/#!topic/mozilla.dev.platform/JIEFcrGhqSM/discussion. 
  56. John Leyden (1 August 2013). "Gmail, Outlook.com and e-voting 'pwned' on stage in crypto-dodge hack". The Register. Archived from the original on 1 August 2013. https://web.archive.org/web/20130801193054/http://www.theregister.co.uk/2013/08/01/gmail_hotmail_hijacking/. Retrieved 1 August 2013. 
  57. "BlackHat USA Briefings". Black Hat 2013. Archived from the original on 30 July 2013. https://web.archive.org/web/20130730124037/http://www.blackhat.com/us-13/briefings.html#Smyth. Retrieved 1 August 2013. 
  58. Smyth, Ben; Pironti, Alfredo (2013). "Truncating TLS Connections to Violate Beliefs in Web Applications". 7th USENIX Workshop on Offensive Technologies. Archived from the original on 6 November 2015. https://web.archive.org/web/20151106110117/https://hal.inria.fr/hal-01102013. Retrieved 15 February 2016. 
  59. Goodin, Dan. "New attack bypasses HTTPS protection on Macs, Windows, and Linux". Condé Nast. Archived from the original on 27 July 2016. https://web.archive.org/web/20160727160434/http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/. Retrieved 28 July 2016. 
  60. Goodin, Dan (August 24, 2016). "HTTPS and OpenVPN face new attack that can decrypt secret cookies". Ars Technica. Archived from the original on August 24, 2016. https://web.archive.org/web/20160824181630/http://arstechnica.com/security/2016/08/new-attack-can-pluck-secrets-from-1-of-https-traffic-affects-top-sites/. 
  61. "Why is it called the 'Heartbleed Bug'?". The Washington Post. 2014-04-09. Archived from the original on 2014-10-09. https://web.archive.org/web/20141009063758/http://www.washingtonpost.com/blogs/style-blog/wp/2014/04/09/why-is-it-called-the-heartbleed-bug/. 
  62. "Heartbleed Bug vulnerability [9 April 2014"]. Comodo Group. Archived from the original on 5 July 2014. https://web.archive.org/web/20140705212748/https://blogs.comodo.com/e-commerce/heartbleed-bug-comodo-urges-openssl-users-to-apply-patch/. 
  63. Bleichenbacher, Daniel (August 2006). "Bleichenbacher's RSA signature forgery based on implementation error". Archived from the original on 2014-12-16. https://web.archive.org/web/20141216203704/http://www.imc.org/ietf-openpgp/mail-archive/msg06063.html. 
  64. "BERserk". Intel Security: Advanced Threat Research. September 2014. Archived from the original on 2015-01-12. https://web.archive.org/web/20150112153121/http://www.intelsecurity.com/advanced-threat-research/. 
  65. Goodin, Dan (February 19, 2015). "Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections". Archived from the original on September 12, 2017. https://web.archive.org/web/20170912103610/https://arstechnica.com/information-technology/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/. Retrieved December 10, 2017. 
  66. Valsorda, Filippo (2015-02-20). "Komodia/Superfish SSL validation is broken". Filippo.io. Archived from the original on 2015-02-24. https://web.archive.org/web/20150224112141/https://blog.filippo.io/komodia-superfish-ssl-validation-is-broken/. 
  67. Goodin, Dan. ""Forbidden attack" makes dozens of HTTPS Visa sites vulnerable to tampering". Archived from the original on 26 May 2016. https://web.archive.org/web/20160526175713/http://arstechnica.com/security/2016/05/faulty-https-settings-leave-dozens-of-visa-sites-vulnerable-to-forgery-attacks/. Retrieved 26 May 2016. 
  68. Clark Estes, Adam. "Everything You Need to Know About Cloudbleed, the Latest Internet Security Disaster". Archived from the original on 2017-02-25. https://web.archive.org/web/20170225013516/http://gizmodo.com/everything-you-need-to-know-about-cloudbleed-the-lates-1792710616. Retrieved 2017-02-24. 
  69. As of May 3, 2019. "SSL Pulse: Survey of the SSL Implementation of the Most Popular Websites". https://www.ssllabs.com/ssl-pulse/. Retrieved 2019-05-09. 
  70. Diffie, Whitfield; van Oorschot, Paul C; Wiener, Michael J. (June 1992). "Authentication and Authenticated Key Exchanges". Designs, Codes and Cryptography 2 (2): 107–125. doi:10.1007/BF00124891. Archived from the original on 2008-03-13. https://web.archive.org/web/20080313081157/http://citeseer.ist.psu.edu/diffie92authentication.html. Retrieved 2008-02-11. 
  71. Discussion on the TLS mailing list in October 2007 http://www1.ietf.org/mail-archive/web/tls/current/msg02134.html
  72. "Protecting data for the long term with forward secrecy". Archived from the original on 2013-05-06. https://web.archive.org/web/20130506184654/http://googleonlinesecurity.blogspot.com.au/2011/11/protecting-data-for-long-term-with.html. Retrieved 2012-11-05. 
  73. Bernat, Vincent. "SSL/TLS & Perfect Forward Secrecy". Archived from the original on 2012-08-27. https://web.archive.org/web/20120827064047/http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html. Retrieved 2012-11-05. 
  74. "SSL Labs: Deploying Forward Secrecy". Qualys.com. 2013-06-25. Archived from the original on 2013-06-26. https://web.archive.org/web/20130626193314/https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy. Retrieved 2013-07-10. 
  75. Ristic, Ivan (2013-08-05). "SSL Labs: Deploying Forward Secrecy". Qualsys. Archived from the original on 2013-09-20. https://web.archive.org/web/20130920150259/https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy. Retrieved 2013-08-31. 
  76. Langley, Adam (27 June 2013). "How to botch TLS forward secrecy". Archived from the original on 8 August 2013. https://web.archive.org/web/20130808221614/https://www.imperialviolet.org/2013/06/27/botchingpfs.html. 
  77. Daignière, Florent. "TLS "Secrets": Whitepaper presenting the security implications of the deployment of session tickets (RFC 5077) as implemented in OpenSSL". Matta Consulting Limited. Archived from the original on 6 August 2013. https://web.archive.org/web/20130806233112/https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf. Retrieved 7 August 2013. 
  78. Daignière, Florent. "TLS "Secrets": What everyone forgot to tell you...". Matta Consulting Limited. Archived from the original on 5 August 2013. https://web.archive.org/web/20130805134805/https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-Slides.pdf. Retrieved 7 August 2013. 
  79. L.S. Huang; S. Adhikarla; D. Boneh; C. Jackson (2014). "An Experimental Study of TLS Forward Secrecy Deployments". IEEE Internet Computing 18 (6): 43–51. doi:10.1109/MIC.2014.86. Archived from the original on 20 September 2015. https://web.archive.org/web/20150920011317/http://crypto.stanford.edu/~dabo/pubs/abstracts/websec_ecc.html. Retrieved 16 October 2015. 
  80. "Protecting data for the long term with forward secrecy". Archived from the original on 2014-02-12. https://web.archive.org/web/20140212214518/http://googleonlinesecurity.blogspot.com.au/2011/11/protecting-data-for-long-term-with.html. Retrieved 2014-03-07. 
  81. Hoffman-Andrews, Jacob. "Forward Secrecy at Twitter". Twitter. Archived from the original on 2014-02-16. https://web.archive.org/web/20140216041202/https://blog.twitter.com/2013/forward-secrecy-at-twitter-0. Retrieved 2014-03-07. 
  82. Durumeric, Zakir; Ma, Zane; Springall, Drew; Barnes, Richard; Sullivan, Nick; Bursztein, Elie; Bailey, Michael; Halderman, J. Alex et al. (5 September 2017). "The Security Impact of HTTPS Interception". NDSS Symposium. doi:10.14722/ndss.2017.23456. https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/security-impact-https-interception/. 
More
©Text is available under the terms and conditions of the Creative Commons-Attribution ShareAlike (CC BY-SA) license; additional terms may apply. By using this site, you agree to the Terms and Conditions and Privacy Policy.
This entry is offline, you can click here to edit this entry!
ScholarVision Creations
Feedback