SSL/TLSプロトコルの設計を求められた場合

ネットワーク通信プロトコルといえば、今日のインターネット通信の要と言えるTCPやHTTPは誰もが知っていると思います。ただし、ネットワークセキュリティの観点からは、これらは大きなセキュリティリスクです。

  1. 盗聴のリスク。サードパーティの攻撃者は、支払いアカウントのパスワードの取得など、通信コンテンツを自由に盗聴することができます。
  2. リスクを取る。サードパーティの攻撃者は、銀行のWebサイトになりすまして銀行口座のパスワードを盗むなど、他人になりすましてあなたと通信する可能性があります。
  3. 改ざんリスク。サードパーティの攻撃者は、応答にフィッシングURLを追加するなど、通信の内容を自由に変更できます。

この目的のために、SSL/TLSプロトコルが誕生しました。SSL / TLSは、トランスポート層とアプリケーション層の下に構築された安全な通信プロトコルです。その主な設計目的は、上記のセキュリティリスクを排除し、ネットワーク通信のセキュリティを確保することです。よく知られているHTTPSはHTTPSSL/ TLSに基づいて構築されており、SSL/TLSは今日のインターネットの安全な通信の基礎であると言えます。続きを読む:SSLセキュリティ証明書のインストールはWebサイトにどのように影響しますか?

では、SSL / TLSプロトコルの設計を求められた場合、どのように設計しますか?

この記事では、SSL / TLSの簡略化されたバージョンを設計者の観点から段階的に設計するプロセスを紹介します。記事の最後に、理解に役立つTLS1.2バージョンの動作メカニズムを簡単に紹介します。 SSL/TLSプロトコルの基本原則。より深い理解があります。

対称暗号化アルゴリズムに基づくデータ暗号化

盗聴のリスクは主に、通信の2つの当事者がネットワーク上でプレーンテキストでデータを送信するため、攻撃者は単純なネットワークパケットキャプチャを介して通信のコンテンツを取得できます。

SSL/TLSプロトコルの設計を求められた場合

盗聴のリスクに対処する最善の方法は、データを暗号化することです。つまり、クライアントはデータを送信する前に暗号化し、サーバーは暗号文を受信した後にデータを復号化して復元します。これにより、ネットワーク上でのクリアテキストの送信が回避され、サードパーティの攻撃者による盗聴が防止されます。

暗号化アルゴリズムに関しては、多くの人が最初に対称暗号化アルゴリズムについて考えます。対称暗号化アルゴリズムは、その単純さと効率で知られています。対称暗号化とは、暗号化と復号化の両方で同じキーを使用することを意味します。一般的なアルゴリズムには、DES、AESなどがあります。

それでは、安全な通信のために対称暗号化アルゴリズムを使用してみましょう。

SSL/TLSプロトコルの設計を求められた場合

対称鍵暗号化を使用する前提は、データを暗号化するために両方の当事者が同じ鍵を使用する必要があるということです。この目的を達成するために、オフラインとオンラインの鍵交換には主に2つのスキームがあります。

  1. オフラインの鍵交換、つまり、両方の当事者が直接(たとえば、USBフラッシュドライブを介して)鍵を交換することに同意します。このスキームは鍵交換のセキュリティを保証できますが、普及させることは困難です。ほとんどのシナリオでは、クライアントとサーバーが会うことは不可能だからです。
  2. オンライン鍵交換、つまりネットワークを介した鍵の送信。しかし、ネットワークでは、平文の送信キーも攻撃者によって傍受されるため、このような暗号化は無意味です。

SSL/TLSプロトコルの設計を求められた場合

したがって、純粋な対称暗号化は通信セキュリティの要件を満たすことができず、最適化を継続する必要があります…

非対称暗号化アルゴリズムに基づくデータ暗号化

非対称暗号化アルゴリズムとは、暗号化と復号化に異なる鍵を使用することを指し、これら2つの異なる鍵は、公開鍵と秘密鍵という鍵のペアを形成します。公開鍵は誰でも入手できる公開鍵であり、秘密鍵は秘密にされています。公開鍵を使用してデータを暗号化すると、対応する秘密鍵のみが復号化を完了できます。一般的な非対称暗号化アルゴリズムには、RSA、ECCなどがあります。

それでは、安全な通信のために非対称暗号化アルゴリズムを使用してみましょう。

SSL/TLSプロトコルの設計を求められた場合

非対称暗号化アルゴリズムにより、データを暗号化するだけでなく、鍵交換の問題も解決できるため、盗聴のリスクを排除できます。ただし、非対称暗号化アルゴリズムの最大の欠点は、暗号化と復号化の速度が非常に遅く、対称暗号化アルゴリズムよりも1000倍以上遅いことです。したがって、非対称暗号化アルゴリズムは通常、少量のデータの暗号化にのみ適しています

これまでのところ、対称暗号化アルゴリズムまたは非対称暗号化アルゴリズムを使用するだけでは要件を満たすことができず、引き続き最適化する必要があります…

対称暗号化非対称暗号化アルゴリズムに基づくデータ暗号化

対称暗号化アルゴリズムは暗号化と復号化の速度が速いため、鍵交換の問題があります。非対称暗号化アルゴリズムは鍵交換の問題を解決できますが、暗号化と復号化の速度は遅くなります。次に、2つのアルゴリズムを組み合わせることができます。つまり、対称暗号化アルゴリズムを使用してデータを暗号化します。対称鍵を交換する場合は、非対称暗号化アルゴリズムを使用して対称鍵を暗号化し、ネットワーク送信中に鍵が攻撃されないようにします。盗聴。

ここで、対称暗号化非対称暗号化アルゴリズムを使用して、安全な通信を実現しようとします。

SSL/TLSプロトコルの設計を求められた場合

対称暗号化と非対称暗号化アルゴリズムのスキームを使用して、盗聴のリスクを排除し、暗号化と復号化のパフォーマンスの問題は発生しませんが、それでもなりすましのリスクを排除することはできません。

次のシナリオを検討してください。

  1. 攻撃者はサーバーの公開鍵を傍受して保存します。
  2. 攻撃者はサーバーになりすまして、公開鍵をクライアントに送信します。
  3. 攻撃者は、不正な公開鍵で暗号化された対称鍵を傍受し、復号化して対称鍵の平文を取得し、保存します
  4. 攻撃者はサーバーの公開鍵を使用して、クライアントからサーバーに偽造された対称鍵を再暗号化します。

この操作の後、攻撃者はクライアントとサーバーの知識がなくても対称鍵を取得できます。このシナリオでは、攻撃者は受動的な盗聴攻撃から能動的な攻撃のなりすましに切り替え、クライアントとサーバーの両方が互いに通信していると誤って考えます。

SSL/TLSプロトコルの設計を求められた場合

したがって、クライアントが受信する公開鍵が実サーバーによって送信される必要があること、つまり「サーバー」の実際のIDを認証できることをクライアントが保証できるようにする方法を見つける必要があります…

CA証明書に基づく認証

デジタル証明書の概要

ウィキペディアからの定義の引用:

デジタル証明書とは、インターネット通信における通信相手の身元情報を示すデジタル認証のことであり、インターネット上で相手の身元を特定するために使用することができます。

デジタル証明書は、現実の世界ではIDカードのようなものであり、ネットワークユーザー(個人、会社、サーバーなど)の法的IDを識別するために使用されます。IDカードが公安局によって発行される必要があるのと同様に、信頼できるデジタル証明書も認証局(CA ) である機関によって発行される必要があります。CAによって発行されるデジタル証明書は通常 CA証明書と呼ばます。

CA証明書には、主に申請者の公開鍵、申請者の情報、発行機関のCAの情報、有効期間、証明書のシリアル番号、その他のプレーンテキスト情報が含まれ、署名の存在であるCAのデジタル署名も含まれます。この証明書の有効性。

デジタル署名は非対称暗号化アルゴリズムに基づいています。CAが証明書を発行すると、最初に指定されたアルゴリズム(SHA256アルゴリズムなど)を使用して証明書のプレーンテキスト情報からデジタルダイジェストを計算し、次にCAのプライベートでダイジェストを暗号化します。キー。、署名を形成します。

証明書の検証には、主に次の2つの部分が含まれます。

  1. 証明書の有効期限が切れているかどうか、ドメイン名に一貫性があるかどうかなど、証明書のプレーンテキスト情報が有効かどうかを確認してください。
  2. CAによって公開された公開鍵を使用して証明書の署名を復号化し、取得します数字摘要1。次に、同じアルゴリズムを使用して、証明書のプレーンテキスト情報を計算します数字摘要2。コントラスト数字摘要1数字摘要2等しい。

証明書を発行する機関は1つだけではありません。たとえば、機関AはCAによって発行されたルート証明書を使用して機関Bに二次証明書を発行でき、機関Bは二次証明書を使用して機関Cに三次証明書を発行できます。は、いわゆる証明書チェーンです。

CA証明書を使用して、通信する当事者のIDを認証します

次に、CA証明書を追加して、通信する当事者のIDを認証します。

SSL/TLSプロトコルの設計を求められた場合

CA証明書の導入後、サーバーの公開鍵は、提供された証明書に配置されます。クライアントがサーバー証明書が渡されたことを確認すると、その公開鍵が実際にサーバーからの正当な公開鍵であることを意味します。このようにして、その後の通信プロセスを正常に実行することができます。

ただし、対称鍵が変更されていない場合でも、攻撃者が対称鍵をブルートフォース攻撃する可能性があります。したがって、接続ごとに異なることができる対称鍵も必要です…

乱数を使用して対称鍵を生成する

接続ごとに対称鍵を異なるものにするために、乱数を導入して対称鍵を生成し、そのランダム性を確保することができます。ただし、現在のコンピューターで生成される乱数はすべて疑似乱数であることを考慮すると、ランダム性をさらに向上させるために、複数の乱数を生成することでこの目標を達成できます。

次のように設計できます。

  1. クライアントとサーバーは最初に乱数(随机数1sum )を生成し、  sum  メッセージ随机数2で交換を完了し ます。ClientHelloServerHello
  2. クライアントはサーバーのIDを確認した後、随机数3サーバーの公開鍵暗号化を介してサーバーを生成してサーバーに送信します。(この時点で、両方の通信当事者は3つの同一の乱数を持っています)
  3. 次に、クライアントとサーバーは、3つの乱数に基づいて最終的な対称鍵を生成します。

このようにして、3つの乱数によって生成されたキーは、キーのランダム性をより確実にし、攻撃者によってクラックされる可能性を減らすことができます。

随机数1合計随机数2はプレーンテキストで送信されますが随机数3、暗号化された送信により、攻撃者がキーを解読することは困難です。

SSL/TLSプロトコルの設計を求められた場合

これまでのところ、攻撃者がさまざまな方法でクライアントとサーバー間の通信コンテンツを盗聴するのを防ぐことに成功しています。ただし、攻撃者が通信の内容を盗聴するつもりはなく、単に妨害したい場合。たとえば、攻撃者が ClientHello メッセージを傍受してに変更すると随机数1随机数4クライアントとサーバーによって生成されたキーに一貫性がなくなります。このシナリオでは、接続は確立されていますが、クライアントとサーバーは引き続き正常に通信できません。

SSL/TLSプロトコルの設計を求められた場合

このためには、接続確立フェーズ(ハンドシェイクフェーズ)ですべてのメッセージの正当性を検証し、誤った接続の確立を防ぐメカニズムが必要です…

ハンドシェイクメッセージの正しさを確認してください

デジタルダイジェストを使用して、すべてのハンドシェイクメッセージの正当性を検証できます。つまり、ハンドシェイクフェーズの最後に、両方の当事者がハッシュアルゴリズム(SHA256など)を数字摘要使用して、送受信するすべてのメッセージを計算してから、前のネゴシエートされた対称鍵は数字摘要それを暗号化し、相手に送信します。

数字摘要相手から送信された暗号文を受信したら、まず対称鍵で復号化します。復号化に成功した場合は、鍵の生成に問題がない数字摘要ことを意味します。次に、両者が整合しているかどうかを比較します。整合している場合は、これは、ハンドシェイクフェーズのメッセージが改ざんされていないことを意味します。その後、正しい接続を確立できます。

SSL/TLSプロトコルの設計を求められた場合

これまでに、盗聴(データ暗号化による)、なりすましリスク(証明書認証による)、および改ざんリスク(デジタルダイジェストによる)のリスクを本質的に排除しました。ただし、安全な通信チャネルを確立するには、メッセージの相互作用、暗号化と復号化、ID認証などの複数のステップを実行する必要があり、パフォーマンスがある程度低下します。

握手後、鍵が交渉され、双方がそれを保存したからです。次の接続が確立されると、最後のハンドシェイクでネゴシエートされたキーを使用できるため、キーの再ネゴシエーションが回避され、パフォーマンスが向上します。プロトコルのパフォーマンスを向上させるためにセッションを再利用するメカニズムが必要です…

セッションを再利用してパフォーマンスを向上させる

最後にネゴシエートされたキーを使用するために、各接続にセッションIDを割り当てます。

  1. 接続が最初に作成されると、サーバーによって生成され、 ServerHello を介してクライアントに返されます。
  2. 次の接続の作成時に、クライアント ClientHello はセッションIDをサーバーに送信することにより、セッションを再利用したいという希望を表明します。
  3. セッションIDを受信した後、サーバーは Finished セッションの再利用に同意することを示すメッセージを送信できます。つまり、サーバーは最後のセッションでネゴシエートされたキーを使用して安全な通信を行うことができます。

SSL/TLSプロトコルの設計を求められた場合

これまでに、SSL / TLSプロトコルの簡略化されたバージョンの設計が完了しました。もちろん、実際のSSL / TLSプロトコルはそれほど単純ではありませんが、基本的な考え方と基本原則は似ています。SSL / TLSは、複数の暗号化アルゴリズムのサポートや、通常のデジタルダイジェストの代わりにMACを使用して整合性検証を完了するなど、セキュリティ、スケーラビリティ、および使いやすさを向上させるためのメカニズムを追加するだけです。

以下では、実際のSSL/TLSプロトコルの動作メカニズムを簡単に紹介します。

SSL/TLSプロトコルメカニズムの概要

SSLプロトコル(Secure Sockets Layer)は、TLS(Transport Layer Security)プロトコルの前身であり、バージョンの進化は次のとおりであり、最新バージョンはTLS1.3です。このセクションでは、最も広く使用されているバージョンのTLS 1.2を分析オブジェクトとして取り上げ、SSL/TLSの基本的な動作メカニズムを紹介します。

SSLバージョン1.0->SSLバージョン2.0->SSLバージョン3.0->TLSバージョン1.0->TLSバージョン1.1->TLSバージョン1.2->TLSバージョン1.3

SSL/ TLSプロトコルの概要

SSL / TLSプロトコルは、ネットワークプロトコルスタックのトランスポート層とアプリケーション層の間にあります。内部で2つの層に分割でき、合計5つのサブプロトコルがあります。

SSL/TLSプロトコルの設計を求められた場合

合意を記録する

最下位レベルの レコードプロトコルは、上位層のサブプロトコルのカプセル化を担当し、安全に通信する機能を提供します。

  1. プライベート接続。対称暗号化アルゴリズム(AES、RC4など)を使用してデータを暗号化します。各接続で、セキュリティを強化するために、両者がネゴシエートする暗号化キーは異なります。さらに、Recordプロトコルは、ハンドシェイクフェーズのHelloパケットなど、暗号化されていないカプセル化を提供することもできます。
  2. 信頼できる接続。MAC(メッセージ認証コード、 メッセージ認証コード、TLSで現在使用されている HMACも一種のMACに属します)を使用して、データの整合性チェックを提供します。同様に、この機能はハンドシェイクフェーズでは使用できません。

ハンドシェイクプロトコル

上位層の ハンドシェイクプロトコルは、ハンドシェイクフェーズで使用され、ID認証、暗号化アルゴリズム、およびキーネゴシエーション機能を両方の当事者に提供します。

  1. 認証。ピアのID認証は、非対称暗号化テクノロジー(RSA、DESなど)を使用するCA証明書に基づいて完了します。この機能はオプションですが、少なくとも一方向の認証を行うのが一般的な方法です。
  2. セキュリティパラメータのネゴシエーション。セキュリティパラメータ(暗号化アルゴリズム、ハッシュアルゴリズム、キーなど)のネゴシエーションを完了し、攻撃者がネゴシエーションプロセス中にキーを取得できないようにすることができます。
  3. 信頼できる交渉。セキュリティパラメータのネゴシエーションプロセス中に、攻撃者がパケットを改ざんできないようにします。

ハンドシェイクプロトコルにはClientHello、次のメッセージタイプが含まれます:、、、、、、、、、、、、。SeverHelloCertificateServerKeyExchangeCertificateRequestServerHelloDoneClientKeyExchangeCertificateVerifyChangeCipherSpecFinished

暗号仕様プロトコルの変更

Change Cipher Specプロトコルは、ハンドシェイクフェーズでも使用されます。通信側がChange Cipher Specメッセージを送信すると、キーがネゴシエートされたことを意味します。次のメッセージから、キーは暗号化された送信に使用されます。

アラートプロトコル

アラートプロトコルは、接続が異常な場合にのみ使用されます。現在のプロトコルで定義されているアラートメッセージの種類は次のとおりです。

close_notify: 表示发送方不会再发送任何消息,用于正常关闭连接,类似于TCP中的FIN报文
unexpected_message: 收到不在预期之内的消息
bad_record_mac: 收到的消息中MAC不正确,表示消息已经被篡改过
decryption_failed_RESERVED: 解密失败,用于TLS的早期版本
record_overflow: 消息长度溢出,密文长度不超过2^14 2048字节;压缩后的明文不超过2^14 1024字节
decompression_failure: 使用压缩功能时,解压失败
handshake_failure: 握手阶段无法协商出正确的安全参数
no_certificate_RESERVED: 为了兼容SSL 3.0版本,TLS不再使用
bad_certificate: 证书签名认证失败
unsupported_certificate: 收到不支持的证书类型
certificate_revoked: 收到被废弃的证书
certificate_expired: 收到过期的证书
certificate_unknown: 除上述4种情况外,其他证书异常场景
illegal_parameter: 握手阶段报文的参数非法,比如范围溢出等
unknown_ca: 不可信任的CA颁发的证书
access_denied: 证书校验通过,但发送方却拒绝继续握手
decode_error: 消息解码失败
decrypt_error: 握手阶段安全相关的步骤失败,比如签名校验失败、Finished消息校验失败等
export_restriction_RESERVED: 早期的TLS版本使用
protocol_version: 协议版本不支持
insufficient_security: 服务端要求的安全算法,客户端无法满足
internal_error: 协议内部错误
user_canceled: 用户非正常主动关闭连接
no_renegotiation: 拒绝重新握手
unsupported_extension: 不支持的扩展

アプリケーションデータプロトコル

アプリケーションデータプロトコルは、通信フェーズでアプリケーション層のデータをカプセル化するために使用されます。レコードプロトコルによってカプセル化された後、TCPプロトコルを介して転送されます。

SSL/TLSプロトコルのハンドシェイクプロセス

SSL/TLSプロトコルの設計を求められた場合

最初の握手

  1. クライアント ClientHello はサーバーにメッセージを送信して接続の確立を開始します。接続の確立には次の内容が含まれます。
    • バージョン:クライアントでサポートされているTLSプロトコルのバージョン
    • ランダム:クライアントによって生成された乱数。マスターシークレットの生成に使用されます。
    • SessionID:セッションID、空でない場合は、クライアントがセッションを再利用したいことを意味します
    • CipherSuites:クライアントがサポートする暗号スイートのリスト。SessionIDが空の場合に実行する必要があります。
    • CompressionMethods:クライアントがサポートする圧縮アルゴリズムのリスト
    • 拡張機能:拡張機能のコンテンツ

2番目の握手

  1. サーバーはクライアント にServerHello メッセージ を送信します。このメッセージには次の内容が含まれています。
    • バージョン:選択したTLSバージョン、両方の当事者がサポートする最高のバージョンを選択
    • ランダム:サーバーによって生成された乱数。マスターシークレットの生成に使用されます。
    • SessionID:セッションID。空の場合は、サーバーが新しいセッションを開き、再利用を望まないことを意味します。クライアントによって提供されたSessionIDと同じ場合は、セッションが再利用されることを意味します。それ以外の場合は、新しいセッションが開かれ、将来的に再利用される可能性があります
    • CipherSuite:選択された暗号スイート
    • CompressionMethod:選択された圧縮アルゴリズム
    • 拡張機能:拡張機能のコンテンツ
  2. サーバーは、サーバーの証明書を保持するクライアントにメッセージを送信し Certificate ます。証明書は、サーバーの公開鍵、サーバーのドメイン名、発行者の情報を含むx.509標準形式である必要があります。および有効期間。

    オプション、クライアントが証明書を介してサーバーのIDを認証する必要がある場合に送信されます

  3. サーバー Server Key Exchange はクライアントにメッセージを送信します。このメッセージは、クライアントがプリマスターシークレットを生成するために使用するセキュリティパラメーターを伝達します。

    オプション、 Certificate パケットで運ばれる情報がクライアントがプリマスターシークレットを生成するのをサポートできない場合に送信されます

  4. サーバー CertificateRequest はクライアントにメッセージを送信して、期待される証明書の種類、署名アルゴリズム、およびCAリストを含むクライアント証明書を要求します。

    オプション、双方向認証が有効になっている場合に送信されます

  5. ServerHelloDone サーバーは、現在のサーバーがキー交換に関連するすべてのコンテンツを送信したことを示すメッセージをクライアント に送信します。

3番目の握手

  1. Certificate クライアントは、クライアント証明書を運ぶサーバーにメッセージを送信し ます。

    オプション、サーバー からのCertificateRequest メッセージを受信したときに送信されます

  2. クライアント ClientKeyExchange はサーバーにメッセージを送信します。このメッセージには、サーバーの公開鍵で暗号化されたプリマスターシークレット(乱数)が含まれ、マスターシークレットの生成に使用されます。
  3. クライアント CertificateVerify はサーバーにメッセージを送信します。このメッセージには、これまでの2者間のすべてのハンドシェイクメッセージのデジタル署名が含まれます。これは、クライアントが所有する秘密鍵が以前に送信された証明書の公開鍵に対応することを証明するために使用されます。

    オプション、サーバー Certificate にメッセージを送信するときに送信されます

  4. クライアント ChangeCipherSpec はサーバーにメッセージを送信し、暗号化された送信が次のメッセージから開始されることを示します。
  5. クライアント Finished はサーバーにメッセージを送信し、送信を暗号化します。このメッセージには、改ざん防止のためのすべてのハンドシェイクメッセージのデジタルダイジェストが含まれています。

4番目の握手

  1. サーバーはクライアント にChangeCipherSpec メッセージを送信し、暗号化された送信が次のメッセージから開始されることを示します。
  2. サーバーはクライアントにメッセージを送信し、 Finished 送信を暗号化します。この送信には、改ざん防止のためのすべてのハンドシェイクメッセージのデジタルダイジェストが含まれています。

最後に

SSL / TLSプロトコルは完全に安全というわけではなく、ハッカーによって絶えず発掘される多くの抜け穴もあります。もちろん、SSL/TLSプロトコルも絶えず改善されています。2018年にリリースされたTLS1.3バージョンは、TLS1.2バージョンに基づいて多くの機能拡張を行いました。たとえば、パフォーマンスの観点から、ハンドシェイクフェーズは2-RTTから1-RTTに削減され、0-RTTモードがサポートされます。セキュリティの観点から、ServerHello 暗号化された送信はメッセージの後に開始され、一部の安全でない暗号スイートはサポートされなくなります。サポートされています(静的RSA、Diffie-Hellmanなど)。

TLS 1.3の仕組みは大きく変わりましたが、基本的な原則は同じです。したがって、SSL / TLSプロトコルの原理を完全に理解した後、バージョンが将来どのように進化しても、プロトコルメカニズムの学習を迅速に完了することができます。

参照する

トランスポート層セキュリティ(TLS)プロトコルバージョン1.2、RFC 5246

トランスポート層セキュリティ(TLS)プロトコルバージョン1.3、RFC 8446

SSL/TLSプロトコルの操作メカニズムの概要RuanYifeng

SSL / TLS暗号化の概要、MicroSoftドキュメント

HTTPS接続の最初の数ミリ秒、Jeff Moser

HTTPSが7つのハンドシェイクと9倍の遅延を必要とするのはなぜですか、信仰指向プログラミング

HTTPS権威ガイド、Yang Yang、LiZhenyuなど。

デジタル証明書、Baidu百科事典

その他の記事については、WeChatパブリックアカウントに注意してください:YuanRunziの招待

ように

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注