Forrester Total Economic Impact™の調査によると、Edwin AIは複合組織において313%の投資対効果（ROI）を実現したことが判明しました。

続きを読む

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

Forrester Total Economic Impact™の調査によると、Edwin AIは複合組織において313%の投資対効果（ROI）を実現したことが判明しました。

続きを読む

HTTP/3とHTTP/2の比較

TLS 1.2と1.3の比較 ― ハンドシェイク、パフォーマンス、その他の改善点

TLS 1.3では、TLS 1.2で長年蓄積されてきたプロトコルの不要な要素が排除されました。具体的には、通信回数の削減、より強力な暗号スイートの使用、そして前方秘匿性の強制などが挙げられます。ここでは、変更点と、このアップグレードがセキュリティとパフォーマンスの両面で重要な理由について解説します。

8〜12分

デントン千倉

クイックダウンロード:

TLS 1.3は、トランスポート層セキュリティプロトコルの大幅な改訂版であり、ハンドシェイクの遅延を2RTTから1RTTに短縮し、TLS 1.2で許可されていた脆弱な暗号スイートを排除し、すべての接続で前方秘匿性を義務付けています。

  • TLS 1.3では、ハンドシェイクの遅延がTLS 1.2の2RTTから1RTTに短縮され、再接続するクライアントに対して0RTTでのセッション再開が可能になるため、遅延に敏感なアプリケーションにおける接続確立時間が大幅に短縮されます。

  • TLS 1.3では、RSA鍵交換を含む、前方秘匿性を提供しないすべての暗号スイートが排除されます。つまり、侵害されたサーバーの秘密鍵を使用して、以前に記録されたセッショントラフィックを復号化することはできません。

  • TLS 1.3では、MD5、SHA-1、RC4、DES、3DESなどの脆弱なアルゴリズムのサポートが削除され、TLS 1.2の設定で後方互換性のためにしばしば残されていた攻撃対象領域が大幅に縮小されました。

  • TLS 1.2はレガシーシステムとの互換性のために依然として必要ですが、最新のインフラストラクチャではTLS 1.3をデフォルトとし、TLS 1.2をフォールバックとして使用し、TLS 1.0と1.1は完全に無効にするべきです。

今日のデジタルで相互接続された世界において、通信のセキュリティとプライバシーは依然として大きな懸念事項です。インターネット上で安全かつ暗号化された接続を提供する最初のプロトコルは、公開鍵暗号方式を用いたSecure Socket Layer（SSL）でした。1999年、SSLはバージョン3にアップグレードされ、Transport Layer Security（TLS）バージョン1.0として標準化されました。現在、これらのプロトコルは、より安全なTLS 1.2および1.3バージョンに置き換えられています。 

トランスポート層セキュリティ（TLS）は、公共インターネット上で行われるすべての通信が安全かつ改ざん不可能であることを保証する標準規格です。TLSは、機密性、認証、完全性、およびリプレイ攻撃からの保護を提供します。 

この記事では、TLS 1.2と1.3の変更点、およびTLS 1.3における改善点について解説します。

TLS 1.2と1.3の違いの概要 

TLS 1.2は2008年にリリースされ、文書化されました。 RFC 5246このアップグレードには、より脆弱な暗号スイートをより強力な暗号に置き換えるいくつかの機能強化が含まれていました。TLS 1.3は、バージョン1.2から10年後の2018年にリリースされました。IETFはRFC 8446で最新リリースを標準化しました。1.2から1.3への主な変更点は次のとおりです。

TLS 1.2TLS 1.3
ハンドシェークTLSハンドシェイクを完了するには、2回の往復通信が必要です。ハンドシェイクを完了するために必要な往復時間（RTT）は1回のみです。以前にアクセスしたサイトに接続する場合は、RTTを0に設定することも可能です。
セキュリティ100種類以上の暗号アルゴリズムの組み合わせをサポートしていますが、そのほとんどは安全ではありません。認証付き暗号化と関連データ（AEAD）のみをサポートします。
バージョン交渉存在。ダウングレード攻撃を防ぐために削除されました
圧縮圧縮方式を変更しました。機能が削除されました。
デジタル署名TLS 1.2は複数の署名アルゴリズム（ECDSA、RSA、DSA）をサポートしており、ECDSAの使用は任意です。TLS 1.3は、ECDSAやRSA-PSSといった最新のオプションをサポートしており、特にECDSAを重視している。
コンプライアンスほとんどのコンプライアンスフレームワークで求められる最低限のプロトコル。2024年1月現在、NISTはアプリケーションがTLS 1.3をサポートすることを義務付けています。 
前方秘匿性オプションオプション

握手プロセス

どちらのプロトコルも、まずハンドシェイクと呼ばれるプロセスから始まります。このプロセスでは、非対称暗号化と対称暗号化を組み合わせて、クライアントとサーバー間に安全な暗号化トンネルを構築します。実際のデータ転送は、ハンドシェイクが完了した後に行われます。 

TLS 1.2のハンドシェイクプロセスは時間がかかり、煩雑でした。TLS 1.3では、このプロセスがより効率的になり、セキュリティも強化されました。 

TLS 1.2

TLS 1.2 ハンドシェイクを完了するには、クライアントとサーバー間で 2 回のラウンドトリップ (2-RTT)、つまりメッセージの交換が必要です。そのプロセスは次のとおりです。

クライアント様、こんにちは

クライアントはTLSハンドシェイクを開始します クライアントこんにちは 以下の内容を含むメッセージ：

  1. クライアントがサポートするTLSバージョン
  2. クライアントがサポートする暗号スイート
  3. 後のステップで暗号化キーを生成するために使用される乱数。
  4. クライアントがサーバーとの以前のセッションを再開したい場合は、空でないセッションIDを指定します。

サーバーこんにちは

Status クライアントこんにちは セッション ID が空でない場合、サーバーは以前にキャッシュされたセッションを検索して再開します。空の場合、サーバーは新しいランダムなセッション ID を生成します。その後、サーバーは、 サーバーこんにちは 以下の内容を含むメッセージ：

  1. クライアントHelloに含まれるリストからTLSバージョンが選択されます。
  2. クライアントの Hello に含まれるリストから選択された暗号スイート。 
  3. 後のステップで使用する暗号化キーのための、サーバーが生成する乱数。
  4. セッションID
  5. サーバーの公開鍵を含む、署名済みのSSL/TLS証明書。

サーバーは次に サーバーこんにちは完了 クライアントへのメッセージ

鍵交換

受け取ってから サーバーこんにちは完了クライアントは、 認証局 サーバー証明書を信頼します。検証後、ランダムに生成されたプリマスターキーをサーバーの公開鍵で暗号化した鍵交換メッセージをサーバーに送信します。 

サーバーは自身の秘密鍵を用いてプリマスターキーを復号します。クライアントとサーバーは、事前に共有された乱数とプリマスターキーを用いてマスターシークレットを生成します。両者は共有されたマスターシークレットを用いてセッションキーを生成します。

握手終了

最後に、クライアントは 暗号仕様の変更 サーバーへのメッセージには、セッションキーを使用した対称暗号化に切り替えていることが示され、続いて 握手終了 メッセージ。

サーバーは、 暗号仕様の変更 メッセージと 握手終了 これは、共有対称鍵を使用する準備も整っていることを示すメッセージです。 

クライアントとサーバーは、セッションキーを使用して完全に暗号化されたデータの交換を開始します。これらのキーは一時的なものであり、クライアントとサーバー間のセッションが継続している間のみ有効です。

TLS 1.2 ハンドシェイクプロセス (ソース)

TLS 1.3

それに対し、TLS 1.3のハンドシェイクプロセスは1回のラウンドトリップ（1-RTT）で完了します。

クライアント様、こんにちは

クライアントはTLSハンドシェイクを開始します クライアントこんにちは 以下の内容を含むメッセージ：

  • 提供されているプロトコルバージョン（1.3）
  • クライアントがサポートする暗号スイート
  • クライアントがサポートする鍵交換方式
  • クライアントが生成した乱数
  • オプションの拡張機能

サーバーこんにちは

サーバーはマスターシークレットを生成し、 クライアントこんにちは 乱数、独自に生成した乱数、クライアントパラメータ、および暗号スイート。その後、 サーバーこんにちは (NAIST) と サーバー終了 以下の内容を含むメッセージ：

  • サーバーが選択したプロトコルバージョン（1.3）
  • サーバーが選択した暗号スイート
  • サーバーが選択した鍵交換方式
  • サーバーが生成した乱数 
  • サーバーSSL/TLS証明書 
  • オプションのパラメータ

握手終了

クライアントはサーバー証明書を検証し、マスターシークレットを生成し、 クライアント終了 メッセージを受信すると、クライアントとサーバーは直ちに共通鍵暗号化を用いてデータの交換を開始します。

TLS 1.3 ハンドシェイクプロセス (ソース)

TLS 1.2と1.3の機能の違い

TLS 1.2の一部の機能は1.3では引き継がれていません。また、いくつかの新機能が追加されています。

アルゴリズム

TLS 1.2 の旧式で脆弱な暗号化アルゴリズムは削除されました。TLS 1.3 では、認証付き暗号化と関連データ (AEAD) アルゴリズムのみがサポートされます。AEAD は、データの機密性、完全性、および認証性を同時に保証する暗号化方式です。暗号化されるデータ (平文) と、機密性は不要だが完全性が必要な追加データ (関連データ) を組み合わせて処理します。この統合的なアプローチにより、暗号化されたデータ (暗号文) が改ざんまたは偽造されても検出されず、変更があった場合は復号時にすぐに確認できます。

バージョン管理

TLS 1.2以前のバージョンでは、バージョンネゴシエーションメカニズムにより、クライアントとサーバーは両者がサポートできるTLSの最新バージョンを通信することができました。しかし、このプロセスは攻撃者による操作を受けやすく、攻撃者はネゴシエーションプロセスを傍受してメッセージを改ざんし、古いプロトコルバージョンの使用を強制することができました。TLS 1.3では、TLS 1.3を使用するにはクライアントとサーバーがTLS 1.3をサポートしている必要があるため、このプロセスが簡素化されています。

圧縮

TLS 1.3より前のバージョンでは圧縮がサポートされており、サポートされている圧縮方法のリストがクライアント Helloで交換されていました。しかし、これらの方法は一部の攻撃で悪用されています。TLS 1.3では、null バイト( 従来の圧縮方法）これにより、プロトコルから圧縮が事実上排除される。 

デジタル署名の検証

サーバーがTLSハンドシェイクの一環として相手側に証明書を提示する際、証明書の正当な所有者であることを証明するためにデジタル署名も提供します。デジタル署名は、鍵交換プロセスの検証にも使用されます。 

TLS 1.2は、署名検証のために様々な暗号スイート（主にRSA）をサポートしており、どの暗号スイートを選択するかは、クライアントとサーバーの両方がサポートし、かつ好むものによって決まります。 

対照的に、TLS 1.3は楕円曲線デジタル署名アルゴリズム（ECDSA）の使用を重視しており、鍵サイズが小さいため、計算速度の向上、帯域幅の使用量削減、接続速度の向上を実現しています。TLS 1.3では、RSAの使用をより安全なパディング方式（具体的にはRSASSA-PSS）に限定し、一般的に楕円曲線暗号の使用を推奨しています。

前方秘匿性

前方秘匿性 これは、安全な通信セッションごとに新しい固有のセッションキーを生成する、一時的な鍵交換メカニズムを指します。 

TLS 1.3では、前方秘匿性の使用が義務付けられています。前述の通り、TLS 1.3のハンドシェイク処理では、クライアントとサーバーはそれぞれ独立して、エフェメラル・ディフィー・ヘルマン鍵交換プロトコルを用いて固有のセッション鍵を生成します。鍵は、クライアントとサーバーの乱数と選択された暗号スイートを用いて数学的に計算されます。これらのセッション鍵はネットワーク上を伝送されず、セッション終了後に破棄されます。 

その目的は、過去のセッションのプライバシーを保護することであり、たとえ攻撃者がサーバーの秘密鍵を入手したとしても、データ交換全体を解読できないようにすることです。 

TLS 1.2と1.3のパフォーマンス比較

TLS 1.3は、バージョン1.2のパフォーマンスを大幅に向上させています。 

ハンドシェイク遅延の低減

TLS 1.2では tハンドシェイク処理を完了するには、2回の往復通信が必要です。TLS 1.3では、初期ハンドシェイクと暗号化パラメータのネゴシエーションが1回の往復通信に統合されています。これにより、ハンドシェイク時間が実質的に半分に短縮されます。 

TLS 1.3では、0-RTTハンドシェイクも提供されており、クライアントとサーバーは以前に確立されたTLSセッションを再開できます。ラウンドトリップゼロでデータ交換を開始するには、クライアントとサーバーの両方がセッションキーを保持する必要があります。サーバーがクライアントの身元を正しく検証する前に、両者はデータを交換します。 

攻撃者が事前にクライアントとサーバー間の通信を傍受していたと仮定します。その場合、攻撃者はクライアントのデータをサーバーに再送信することができ、サーバーはそれが正当なデータかどうかを検証できません。したがって、0-RTTハンドシェイクは推奨されません。

計算オーバーヘッドの削減

TLS 1.3では、旧式の暗号スイートと暗号化機能がネゴシエーションプロセスから削除されています。また、Diffie-Hellman鍵交換方式を採用することで鍵交換プロセスが簡素化され、TLS 1.2で使用されていたRSAのような個別の鍵交換メカニズムが不要になりました。これらの改善により、クライアントとサーバーの両方における計算負荷が軽減されます。

TLS 1.3の採用

まだアップグレードしていない場合は、TLS 1.3にアップグレードすることをお勧めします。

様々な規制機関や標準化団体が、異なるネットワーク間での安全な通信を確保するために、TLS 1.3をコンプライアンス要件に組み込んでいる。

例えば、米国国立標準技術研究所（NIST） 特別刊行物800-52 改訂版2 本ガイドラインは、連邦政府システムにおけるTLS 1.3の実装に関する指針を示しています。NISTは、組織に対し、2024年1月までにTLS 1.3のサポートを計画し、追加することを求めています。この義務付けは、業界標準およびベストプラクティスに準拠するために、TLS 1.3へのアップグレードがいかに重要であるかを強調するものです。

その他の一般的な標準規格としては、ペイメントカード業界標準セキュリティ評議会（PCI SSC）などがあります。PCI-DSS）および医療保険の携行性と説明責任に関する法律（HIPAA）については、NIST SP 800-52 ガイドラインも参照してください。多くの Web サイトは、ほとんどのエンド デバイスとの相互運用性を維持するために 1.2 と 1.3 の両方を使用しています。Qualys SSL Labs は、 継続的な調査 Alexaによると、最も人気のある上位15万サイトのうち、2024年2月の調査では、99.9%のサイトがバージョン1.2をサポートしており、67.8%のサイトがTLS 1.3をサポートしています。

TLS 1.3 採用統計 (ソース)

TLS 1.3の普及における主な課題は、クライアントデバイスのサポートが限られていることです。本稿執筆時点で、TLS 1.3を完全にサポートしているブラウザとアプリケーションは以下のとおりです。

  • Firefoxの63 +
  • クローム70 +
  • エッジ75+
  • オペラ57 +
  • サファリ12.1 +
  • アンドロイド10.0 +
  • ジャワ 11+
  • SSL1.1.1以降を開く

設定オプション

Mozillaは SSL設定ジェネレーター 多くのサーバーソフトウェアでTLS 1.3を有効にするには、以下の手順が必要です。以下は、TLS 1.3のみを有効にしたApache 2.4.41ウェブサーバーの推奨設定です。

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile      /path/to/signed_cert_and_inter_certs
    SSLCertificateKeyFile   /path/to/private_key
    Protocols h2 http/1.1
    Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

最後の考え

TLSは、公開鍵暗号とクライアントとサーバー間のハンドシェイクメカニズムを使用して、あらゆるネットワークインフラストラクチャ上での通信を安全に保護するために不可欠です。TLS 1.2と比較して、TLS 1.3はセキュリティの向上、パフォーマンスの強化、機能の合理化を実現しています。パフォーマンスの問題でお困りの場合は、TLSのアップグレードが最初のステップとなります。ボトルネックを特定し、パフォーマンスを向上させるには、環境全体のエンドツーエンドの可視性も必要です。 MTTR。 右で 監視および可観測性ツールこれにより、ユーザー接続、パブリックネットワークとプライベートネットワーク、データセンター、アプリケーション層全体にわたるパフォーマンスに関する洞察を得ることができ、問題をより迅速に診断して解決できます。

章

    ニュースレター

    最新情報のメール配信を登録

    最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

    シェア

    インフラストラクチャ全体でTLS 1.3の監視を実装し、最適なセキュリティとパフォーマンスを確保してください。

    NIST準拠の期限が既に到来しているため、安全な通信を維持するにはTLS 1.3へのアップグレードが不可欠です。LogicMonitorは、TLSの実装状況を監視し、ネットワークインフラストラクチャ全体におけるパフォーマンスのボトルネックを特定するのに役立ちます。

    よくあるご質問

    TLS 1.3がTLS 1.2に比べて持つ主なパフォーマンス上の利点は何ですか？

    TLS 1.3では、ハンドシェイク処理がTLS 1.2の2回の往復通信に比べて1回の往復通信で完了するため、接続確立時間が実質的に半分になります。この遅延時間の短縮により、特に高遅延接続のユーザーにとって、ページの読み込み時間とアプリケーション全体のパフォーマンスが大幅に向上します。

    TLS 1.3ではなぜバージョンネゴシエーションが削除されたのか、そしてこれはどのようにセキュリティを向上させるのか？

    TLS 1.2におけるバージョンネゴシエーションは、ダウングレード攻撃に対して脆弱であり、攻撃者は接続を強制的に古い、セキュリティの低いプロトコルバージョンを使用させることができました。TLS 1.3では、バージョンネゴシエーションを完全に削除することでこの脆弱性を解消し、TLS 1.3を使用するにはクライアントとサーバーの両方が明示的にTLS 1.3をサポートする必要があります。

    現在、TLS 1.3をサポートしているブラウザとシステムはどれですか？

    TLS 1.3は、Firefox 63以降、Chrome 70以降、Edge 75以降、Opera 57以降、Safari 12.1以降、Android 10.0以降、Java 11以降、およびOpenSSL 1.1.1以降でサポートされています。2024年2月現在、上位15万のウェブサイトのうち約67.8%がTLS 1.3をサポートしていますが、ほとんどのサイトは下位互換性のためにTLS 1.2のサポートも維持しています。

    TLS 1.3の0-RTTハンドシェイク機能は安全に使用できますか？

    0-RTTは繰り返し接続時のハンドシェイク遅延を完全に解消できますが、傍受されたクライアントデータがサーバーに再送信されるリプレイ攻撃に対して脆弱です。サーバーは0-RTT中にデータが正当かどうかを検証できないため、パフォーマンス上の利点があるにもかかわらず、機密性の高いトランザクションにはこの機能は推奨されません。

    デントン千倉著

    テクニカルライター

    デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。

    免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

    © LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。