{"id":32603,"date":"2019-10-31T21:47:55","date_gmt":"2019-10-31T18:47:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya\/"},"modified":"2019-10-31T21:47:55","modified_gmt":"2019-10-31T18:47:55","slug":"potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","title":{"rendered":"Microsoft has seen signs of the end of the Intel processor shortage.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Half of websites use HTTPS<\/a><\/noindex>, and their number is steadily increasing. The protocol reduces the risk of traffic interception but does not eliminate attack attempts altogether. We will discuss some of them \u2014 POODLE, BEAST, DROWN, and others \u2014 and ways to protect against them in our article.<\/p>\n

\"Microsoft <\/a><\/noindex><\/a><\/noindex>
\n\/ Flickr \/ Sven Graeme<\/a><\/noindex> \/ CC BY-SA<\/i><\/p>\n

POODLE<\/h2>\n

\nThe attack was first reported POODLE<\/a><\/noindex> in 2014. The vulnerability in the SSL 3.0 protocol was discovered by information security expert Bodo M\u00f6ller and colleagues from Google.<\/p>\n

Its essence is as follows: a hacker forces the client to connect using SSL 3.0 by mimicking connection drops. Then, they search for special marker messages in the encrypted CBC<\/a><\/noindex>-mode traffic. Through a series of forged requests, the attacker gains the ability to reconstruct the content of the data of interest, such as cookies.<\/p>\n

SSL 3.0 is an outdated protocol. However, the issue of its security is still relevant. Clients use it to avoid compatibility problems with servers. According to some data, almost 7% of the 100,000 most popular websites still support SSL 3.0<\/a><\/noindex>. There are also modifications<\/a><\/noindex> of POODLE targeting more modern TLS 1.0 and TLS 1.1. This year, data has emerged<\/a><\/noindex> new attacks Zombie POODLE and GOLDENDOODLE, which bypass the protection of TLS 1.2 (they are still related to CBC encryption).<\/p>\n

How to protect yourself.<\/b> In the case of the original POODLE, it's necessary to disable support for SSL 3.0. However, this comes with the risk of compatibility issues. An alternative solution could be the TLS_FALLBACK_SCSV mechanism \u2014 it ensures that data exchange over SSL 3.0 will only occur with older systems. Attackers will no longer be able to initiate a protocol downgrade. To protect against Zombie POODLE and GOLDENDOODLE, one must disable CBC support in applications based on TLS 1.2. A radical solution would be to switch to TLS 1.3 \u2014 this new version of the protocol does not use CBC encryption. Instead, more resilient AES and ChaCha20 are used.<\/p>\n

BEAST<\/h2>\n

\nOne of the earliest attacks on SSL and TLS 1.0, discovered in 2011. Like POODLE, BEAST use<\/a><\/noindex> Features of CBC encryption. Attackers deploy a JavaScript agent or Java applet on the client machine that intercepts messages during data transmission over TLS or SSL. Since attackers are aware of the contents of the \"forged\" packets, they can use them to decrypt the initialization vector and read other messages to the server, such as authentication cookie files.<\/p>\n

As of today, the BEAST vulnerability still affects a range of network tools<\/a><\/noindex>: proxy servers and applications used to secure local internet gateways.<\/p>\n

How to protect yourself.<\/b> The attacker needs to regularly send requests to decrypt data. In VMware recommend<\/a><\/noindex> reduce the SSLSessionCacheTimeout from five minutes (the default recommendation) to 30 seconds. This approach complicates the attackers' plans, although it will have some negative impact on performance. Additionally, it is important to understand that soon the BEAST vulnerability may become obsolete by itself \u2014 starting from 2020, major browsers will stop<\/a><\/noindex> supporting TLS 1.0 and 1.1. In any case, these protocols are used by less than 1.5% of all browser users.<\/p>\n

DROWN<\/h2>\n

\nis a cross-protocol attack that exploits flaws in the implementation of SSLv2 with 40-bit RSA keys. An attacker listens to hundreds of the target's TLS connections and sends special packets to the server using SSLv2 with the same private key. By employing Bleichenbacher's attack<\/a><\/noindex>, a hacker can decrypt one of approximately a thousand client's TLS sessions.<\/p>\n

DROWN was first disclosed in 2016 \u2014 at that time it was affecting a third of servers<\/a><\/noindex> in the world. To this day, it has not lost relevance. Of the 150,000 most popular sites, 2% still support<\/a><\/noindex> use SSLv2 and vulnerable encryption mechanisms.<\/p>\n

How to protect yourself.<\/b> It is necessary to apply the patches provided by cryptographic library developers that disable SSLv2 support. For example, two such patches were released for OpenSSL (in 2016, these were updates<\/a><\/noindex> 1.0.1s and 1.0.2g). Updates and instructions to disable the vulnerable protocol have also been published in Red Hat<\/a><\/noindex>, Apache<\/a><\/noindex>, Debian<\/a><\/noindex>.<\/p>\n

\"The resource may be vulnerable to DROWN if its keys are used by a third-party server with SSLv2, such as a mail server,\" notes the head of development of the IaaS provider 1cloud.ru<\/a><\/noindex> Sergey Belkin. \u2014 This situation arises when multiple servers share a common SSL certificate. In this case, SSLv2 support must be disabled on all machines.<\/i><\/p><\/blockquote>\n

\nYou can check if your system needs an update using a special utility<\/a><\/noindex> \u2014 it was developed by security experts who discovered DROWN. More recommendations related to protection against this type of attack can be found in the post on the OpenSSL website<\/a><\/noindex>.<\/p>\n

Heartbleed<\/h2>\n

\nOne of the most significant vulnerabilities in software \u2014 Heartbleed<\/a><\/noindex>was discovered in 2014 in the OpenSSL library. At the time of the error announcement, the number of vulnerable websites was estimated at half a million<\/a><\/noindex> \u2014 about 17% of secured resources on the web.<\/p>\n

The attack is implemented through a small Heartbeat module of the TLS extension. The TLS protocol requires that data be transmitted continuously. In the event of prolonged inactivity, a disconnection occurs, and the connection must be re-established. To address the problem, servers and clients artificially 'noise' the channel (RFC 6520, p.5<\/a><\/noindex>), transmitting a packet of random length. If it was larger than the maximum packet size, vulnerable versions of OpenSSL would read memory beyond the allocated buffer. This area could contain any data, including private encryption keys and information about other connections.<\/p>\n

The vulnerability was present in all versions of the library between 1.0.1 and 1.0.1f inclusive, as well as in several operating systems \u2014 Ubuntu up to 12.04.4, CentOS older than 6.5, OpenBSD 5.3, and others. A complete list is available on the Heartbleed website<\/a><\/noindex>. Although patches against this vulnerability were released almost immediately after its discovery, the problem remains relevant to this day. Even as of 2017, nearly 200,000 sites<\/a><\/noindex>, were still vulnerable to Heartbleed.<\/p>\n

How to protect yourself.<\/b> It is necessary to update OpenSSL<\/a><\/noindex> to version 1.0.1g or higher. You can also manually disable Heartbeat requests using the DOPENSSL_NO_HEARTBEATS option. After the update, security experts recommend<\/a><\/noindex> should reissue SSL certificates. Replacement is needed in case the encryption key data has been compromised by hackers.<\/p>\n

Certificate Replacement<\/h2>\n

\nA managed node with a legitimate SSL certificate is set up between the user and the server, actively intercepting traffic. This node presents itself as a legitimate server, providing a valid certificate, and allows for a MITM attack.<\/p>\n

According to a study<\/a><\/noindex> According to commands from Mozilla, Google, and several universities, approximately 11% of secure connections on the internet are being monitored. This is a result of suspicious root certificates being installed on users' computers.<\/p>\n

How to protect yourself.<\/b> Use the services of reliable SSL providers<\/a><\/noindex>. You can check the 'quality' of certificates using the service Certificate Transparency<\/a><\/noindex> (CT). Cloud providers can also help with detecting monitoring; already today, some large companies offer specialized tools for monitoring TLS connections.<\/p>\n

Another means of protection will be the new the standard<\/a><\/noindex> ACME, which automates the acquisition of SSL certificates. It will also add additional mechanisms for verifying the ownership of the website. You can read more about it in one of our previous articles<\/a><\/noindex>.<\/p>\n

\"Microsoft
\n\/ Flickr \/ Yuri Samoilov<\/a><\/noindex> \/ CC BY<\/i><\/p>\n

The Prospects of HTTPS<\/h2>\n

\nDespite a number of vulnerabilities, IT giants and cybersecurity experts are confident in the future of the protocol. For the active implementation of HTTPS, is<\/a><\/noindex> the creator of the WWW, Tim Berners-Lee. According to him, over time, TLS will become more secure, significantly enhancing the safety of connections. Berners-Lee even suggested that in the future,<\/a><\/noindex> client certificates for identity authentication will emerge. They will help improve server protection against intruders.<\/p>\n

The development of SSL\/TLS technology is also planned to be enhanced with machine learning\u2014intelligent algorithms will be responsible for filtering malicious traffic. In HTTPS connections, administrators have no means to know the contents of encrypted messages, including discovering requests from malware. Today, neural networks are already capable of filtering potentially dangerous packets with 90% accuracy. (slide 23 of the presentation<\/a><\/noindex>).<\/p>\n

Conclusions<\/h2>\n

\nAttacks on HTTPS are mostly related not to issues in the protocol itself, but to the support of outdated encryption mechanisms. The IT industry is gradually moving away from previous generation protocols and is offering new tools for vulnerability detection. In the future, these tools will become increasingly intelligent.<\/p>\n

Additional resources on the topic:<\/h5>\n

<\/p>\n