久しぶりです！ジャスティンです！

ハッキングのリスクが段々上がってきますので、気を付けてください。特に東京オリンピックの事前は危なくなる可能性もありますので。
元の記事はこちらです：
https://www.zdnet.com/article/new-tls-encryption-busting-attack-also-impacts-the-newer-tls-1-3/

さまざまな大学の研究者のチームは、新しいTLSバージョンが強制的ダウングレードでインターネット通信に傍受やデータ漏洩の弱点を発見しました。
 
2018年8月にリリースされたTLSプロトコルの新しいバージョン、TLS 1.3、は、安全であると考えられていました。 TLSプロトコルはインターネット通信にセキュリティを提供する暗号化プロトコルです。
 
TLSは、TSLレコード·プロトコルとTSLハンドシェイク·プロトコルの2つの部分にまとめられています。 レコード·プロトコルは、ハンドシェイク·プロトコルで作成された「キー」を使用してデータを保護します。 ハンドシェイク·プロトコルは、安全なセッションを作成、または再開するキー交換を認証して実行します。
 
攻撃者が悪用するのは、このハンドシェイクの操作中です。 ダウングレード攻撃は基本的にハンドシェイクを傍受し、クライアントとサーバー両側が以前のバージョンのプロトコルを使用する要求を行うようにデータ改竄を行います。 古いシステムとの互換性用に、TLSクライアントとサーバーは弱いアルゴリズムを使用する古いバージョンのプロトコルをサポートします。

TLS 1.3がリリースされたとき、ダウングレード攻撃に対する2つの保護対策が含まれていました。 まずは、クライアントとサーバーの両側がセッション中に前回のハンドシェイクのすべてのMACを含む「finished」メッセージを送信する必要があります。サーバーとクライアントの両側がデータが改ざんされていないことを確認するためのものです。

次は、「ServerHello.random」にメッセージにコードを埋め込み、古いプロトコルが使用されているときにそれが使用されることを示します。

TLS 1.3対応サーバーがクライアントから「TLS 1.2以下しか受け入れられないです」というメッセージを受信した場合は、「DOWNGRD」コードを「ServerHello.random」に追加してメッセージを送り返します。TLS 1.3対応可能のクライアントの場合は 、サーバにTLS 1.3使用をサーバに要求します。 ただし、TLS 1.2以下のみをサポートするというメッセージを受信した場合は、「ServerHello.random」に「DOWNGRD」というコードが含まれているかどうかを確認します。「ServerHello.random」にそのコードが含まれている場合は、途中に通信の間に誰かが入ってきと判断し、通信を終了します。
 
ハッカーが「ServerHello.random」から「DOWNGRD」を削除しても、最初の鍵交換プロセスでは「ServerHello.random」が使用されていますので、アクセスが不可能になります。

この形式のダウングレード攻撃は、1998年に初めて発見されたスイスの暗号作成者にちなんで名付けられた、「Bleichenbacher Oracle Attack」として呼ばれています。以前のバージョンのTLSにも、Bleichenbacher攻撃のバリエーションが問題でありましたが、対策を含めながら更新続けました。 RSAアルゴリズムを置き換えるよりも、RSA復号化キーを推測することを難しくするための対策を追加しました。
 
 
ところが、今月世界中の研究者の集団のチームが、最新のTLS 1.3で使用されていたRSAアルゴリズムのクラック方法を発見しました。 彼らは、「この攻撃は、TLS実装のRSA鍵交換を破るために、これらの実装のキャッシュアクセスタイミングを介したサイドチャネルリークを利用している」と報告しました。
 
TLS規格（RFC 5246）で定義されている対策はありますが、ハードウェアやソフトウェアの業者はこの規格に準拠していませんでした。対策の不適切な実装のせいで、脆弱なサーバー、ファイアウォール、VPN、およびコードライブラリがかなりあります。
 
RSAアルゴリズムは不完全なものであり、新しいアルゴリズムの導入が勧められて来ていましたが、経済的などな理由で変換されていませんでした。しかし、ネットで一番使われてる暗号がTLSのRSAなのでとても危険になってきています。
 
調査の結果は、9つのTSL実装したシステムをテストして、OpenSSL、Amazon s2n、MbedTLS、Apple CoreTLS、Mozilla NSS、WolfSSL、とGnuTLSが上記の攻撃に弱点があることを確認しました。 9つのなかでたった2つだけ、BearSSLとGoogleのBoringSSLが安全であることが判明した。こちらの バグはCVEに記録されています：CVE-2018-12404、CVE-2018-19608、CVE-2018-16868、CVE-2018-16869、およびCVE-2018-16870。  
Researchers Discover a New Form of Downgrade Attack that Exploits TLS 1.3 Encryption
 
A team of researchers from various universities found the new TLS version is vulnerable to forced downgrade and allowing interception and data breaches over internet communication.
 
The new version of the TLS protocol, TLS 1.3, was released in August of 2018 which was considered to be secure. TLS protocols in general are cryptographic protocols which provide security for internet communication.
 
TLS boils down to two parts, a TSL record protocol and a TSL handshake protocol. The record protocol protects data using keys created in the handshake protocol. The handshake protocol authenticates and performs a key exchange which creates or resumes a secure sessions.
 
It is during this handshake process that an attacker exploits. The downgrade attack essentially intercepts the handshake and change the data to look like both the client and the server are sending request to use a earlier version of the protocol. For the sake of compatibility for older systems, TLS clients and servers usually support older versions of the protocol which use weaker algorithms.
 
When the TLS 1.3 was released, it included two protection measures against downgrade attacks. First It required that both the client and the server send a “finished” messaged that contains all the MAC of the previous handshakes during a session, which allows both the server and the client to make sure that the data has not been tampered with.
 
Second, it embeds code into the “ServerHello.random” message to indicate that is used when older protocols are in use.
 
If a TLS 1.3 capable server receives a message from the client that they can only accept TLS 1.2 or lower, it will send a message back in the “ServerHello.random” with the appended code “DOWNGRD.” If a client is TLS 1.3 capable, it will ask the server to use TLS 1.3. But if it receives a message that it only support TLS 1.2, it will check the “ServerHello.random” to see if it contains the code “DOWNGRD.”  If the “ServerHello.random” does contain the code, then it will conclude that there is someone in the middle and will shut down the communication.
 
Even if a hacker removes “DOWNGRD” from “ServerHello.random”, it will still not be able to gain access since the “ServerHello.random” is used during the first key exchange process.
 
This form of downgrade attack is known as a Bleichenbacher oracle attack, named after the Swiss cryptographer who first discovered it back in 1998. In the previous versions of the TLS, the Bleichenbacher attack variations continued to be a problem because the authors of TLS, rather than replacing the RSA algorithm, added countermeasures to make it harder and harder to guess the RSA decryption key.
 
Although the countermeasures where defined in the TLS standard (RFC 5246), hardware and software manufacturers failed to follow the standard to the T. Improper implementation of the countermeasures lead to vulnerable servers, firewalls, VPNs, and code libraries.
 
Earlier this month, a team consisting of researchers from around the world, found another way to break the RSA algorithm used in the latest TLS 1.3. They stated, “The attack leverages a side-channel leak via cache access timings of these implementations in order to break the RSA key exchanges of TLS implementations.”
 
In their investigation, they tested nine different TSL implementations and found the following to be vulnerable: OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL, and GnuTLS. Of the nine, only two, BearSSL and Google’s BoringSSL was found to be safe. The bugs have been logged in the CVE: CVE-2018-12404, CVE-2018-19608, CVE-2018-16868, CVE-2018-16869, and CVE-2018-16870.