一般

SSL（およびその後継の TLS ）は、 TCP上で直接動作します（ただし、UDPなどのデータグラムベースのプロトコルの実装もあります）。このようにして、上位層（HTTPなど）のプロトコルは変更しないでおくことができます。安全な接続を提供するまで。 SSLレイヤーの下では、HTTPはHTTPSと同じです。

SSL / TLSを正しく使用すると、攻撃者はケーブル上で接続しているIPとポート、おおよそ送信しているデータの量だけを確認できます。 、および使用される暗号化と圧縮。彼は接続を終了することもできますが、双方は接続がサードパーティによって中断されたことを認識します。

通常の使用では、攻撃者はあなたが接続しているホスト名を特定することもできます。 （ただし、URLの残りの部分は公開しません）：HTTPS自体はホスト名を公開しませんが、ブラウザーは通常、最初にDNS要求を行って、要求の送信先のIPアドレスを見つける必要があります。

高プロトコルのレベルの説明

TCP接続を構築した後、SSLハンドシェイクがクライアントによって開始されます。クライアント（ブラウザ、およびWindows UpdateやPuTTYなどの他のプログラム）は送信します。いくつかの仕様：

• SSL / TLSのバージョンが実行されています
• what ciphersuites 使用したいもの、および
• what 使用したい圧縮方法。

サーバーは、サーバーとクライアントの両方でサポートされている最高のSSL / TLSバージョンを識別し、クライアントのオプションの1つ（サポートしている場合）から暗号スイートを選択し、オプションで圧縮方法を選択します。

この基本的なセットアップが完了すると、サーバーは証明書を送信します。この証明書は、クライアント自体またはクライアントが信頼する当事者のいずれかによって信頼されている必要があります。たとえば、クライアントがGeoTrustを信頼している場合、GeoTrust 暗号署名された Googleの証明書であるため、クライアントはGoogle.comからの証明書を信頼できます。

証明書を検証し、このサーバーが実際に彼が主張する人物である（中間者ではない）ことを確認すると、キーが交換されます。これは公開キー、” PreMasterSecret “選択した暗号スイートに応じて、または単に何もしません。サーバーとクライアントの両方が対称暗号化 ^{なぜPKEではないのですか？} 。クライアントはサーバーに、今後すべての通信が暗号化されることを通知します。暗号化および認証されたメッセージをサーバーに送信します。

サーバーは、MAC（認証に使用）が正しく、メッセージを正しく復号化できることを確認します。次に、クライアントが確認するメッセージを返します。なので

これでハンドシェイクが終了し、2つのホストが安全に通信できるようになりました。詳細については、 technet.microsoft.com/en-us/library/cc785811 および en.wikipediaを参照してください。 .org / wiki / Secure_Sockets_Layer 。

接続を閉じるには、close_notify「アラート」が使用されます。攻撃者がTCP接続を終了する（FINパケットを挿入する）ことによって接続を終了しようとすると、双方は接続が不適切に終了したことを認識します。ただし、これによって接続が危険にさらされることはなく、単に中断されるだけです。

詳細

GeoTrustを信頼することでGoogle.comを信頼できるのはなぜですか？

Webサイトが安全に通信したいと考えています。 IDを証明し、攻撃者ではないことを確認するには、サーバーの公開鍵が必要です。ただし、すべての鍵を保存することはできません。地球上のすべてのWebサイトから、データベースは巨大になり、更新は1時間ごとに実行する必要があります！

これに対する解決策は、認証局、または略してCAです。オペレーティングシステムまたはブラウザをインストールすると、信頼できるCAのリストが付属している可能性があります。このリストは自由に変更できます。信頼していない人を削除したり、他の人を追加したり、独自のCAを作成したりすることもできます（ただし、このCAを信頼するのはあなただけなので、公開Webサイトにはあまり使用されません）。このCAリストには、CAの公開鍵も保存されます。

Googleのサーバーから証明書が送信されると、GeoTrustによって署名されていることも示されます。 GeoTrustを信頼する場合は、GeoTrustが実際にサーバーの証明書に署名したことを（GeoTrustの公開鍵を使用して）確認できます。自分で証明書に署名するには、GeoTrustだけが知っている秘密鍵が必要です。このようにして、攻撃者は自分で証明書に署名したり、Google.comであると誤って主張したりすることはできません。証明書が1ビットでも変更されている場合、符号は正しくなく、クライアントはそれを拒否します。

したがって、公開鍵を知っている場合、サーバーは次のことができます。身元を証明しますか？

はい。通常、公開鍵は暗号化し、秘密鍵は復号化します。サーバーの公開鍵でメッセージを暗号化して送信します。サーバーが元のメッセージを繰り返すことができる場合は、鍵を公開せずに秘密鍵を取得したことを証明しただけです。

これが理由です。公開鍵を信頼できるようにすることは非常に重要です。誰でも秘密鍵と公開鍵のペアを生成でき、攻撃者も生成できます。攻撃者の公開鍵を使用することになりたくないのです！

信頼できるCAの1つが侵害された場合、攻撃者は盗まれた秘密鍵を使用して、好きなWebサイトの証明書に署名することができます。攻撃者が、信頼できるCAの秘密鍵を使用して自分で署名した偽造証明書をクライアントに送信できる場合、クライアントは、公開鍵が偽造されたものであり、盗まれた秘密鍵で署名されていることを知りません。

しかし、CAを使用すると、必要なサーバーを信頼できます。

はい、それが信頼の源です。ただし、Microsoft、Apple、Mozillaなどの組織がCAを信頼する場合、CAは監査を行う必要があります。別の組織が定期的にチェックして、すべてが正常に実行されていることを確認します。

証明書の発行は、登録者が証明書の発行先のドメインを所有していることを証明できる場合にのみ行われます。

メッセージ認証用のこのMACは何ですか？

すべてのメッセージはいわゆるメッセージ認証コードで署名されています、または略してMAC。キーとハッシュ暗号に同意する場合は、私のメッセージが私からのものであることを確認できます。また、メッセージがあなたからのものであることを確認できます。

たとえば、キー正しい馬のバッテリーステープル”とメッセージ”例”、 MAC ” 58393 “を計算できます。このメッセージをMACとともに送信すると（すでにキーを知っています）、同じ計算を実行して、計算されたMACを送信したMACと照合できます。

攻撃者はメッセージを変更できますしかし、鍵を知りません。彼は正しいMACを計算できず、メッセージが本物ではないことがわかります。

MACの計算時にシーケンス番号を含めることで、リプレイを排除できます。攻撃。 SSLがこれを行います。

クライアントがキーを送信し、それをセットアップに使用するとおっしゃいました。対称暗号化。攻撃者がそれを使用するのを妨げるものは何ですか？

サーバーの公開鍵は使用します。公開鍵が実際にサーバーに属し、他の誰にも属していないことを確認したので、公開鍵を使用して鍵を暗号化できます。サーバーがこれを受信すると、秘密鍵を使用して復号化できます。他の誰かが受信すると、復号化できません。

これが、鍵のサイズが重要な理由でもあります。公開鍵と秘密鍵が大きいほど、クライアントがサーバーに送信する鍵を解読するのが難しくなります。

SSLを解読する方法

要約：

• ユーザーが証明書の警告を無視するかどうか試してください;
• アプリケーションは改ざんされる可能性のある暗号化されていないチャネル（HTTPなど）。
• HTTPSに送信する保護されていないログインページは、HTTPに送信するように変更される可能性があります。
• パッチが適用されていないアプリケーションはBEASTやCRIMEなどのエクスプロイトに対して脆弱です。
• 他の方法に頼るhを物理的な攻撃として;
• メッセージの長さや時間などのサイドチャネルを悪用するがメッセージの作成に使用されました。
• 量子攻撃を待ちます。

関連項目： IvanRisticによるSSLに対する攻撃ベクトルが多いスキーム ^（png）

詳細：

単純でわかりやすいものはありません仕方; SSLは、正しく実行されれば安全です。ただし、攻撃者は、ユーザーが証明書の警告を無視した場合に試行できます。これにより、セキュリティが即座に破られます。ユーザーがこれを行う場合、攻撃者は証明書を偽造するためにCAからの秘密鍵を必要とせず、自分の証明書を送信するだけで済みます。

別の方法は、アプリケーション（サーバー側またはクライアント側）。簡単な例はWebサイトです。Webサイトで使用されるリソースの1つ（画像やスクリプトなど）がHTTP経由で読み込まれると、機密性は保証されなくなります。ブラウザーであっても安全なページ（ソース）から安全でないリソースを要求するときは、HTTP参照ヘッダーを送信しないでください。トラフィックを盗聴している誰かがあなたの場所を推測する可能性があります。 「から訪問しています。たとえば、画像X、Y、Zが1つのページで使用されていることを知っている場合、ブラウザがこれら3つの画像を一度に要求するのを見ると、そのページにアクセスしていると推測できます。さらに、Javascriptをロードすると、ページ全体が危険にさらされる可能性があります。攻撃者はページ上の任意のスクリプトを実行して、たとえば銀行取引の宛先を変更できます。

これが発生すると（リソースがHTTP経由で読み込まれる）、ブラウザはコンテンツが混在する警告を表示します。 Chrome 、 Firefox 、 Internet Explorer 9

HTTPのもう1つのトリックは、ログインページが保護されておらず、httpsページに送信される場合です。 “すばらしい、”開発者はおそらく”サーバーの負荷を節約してパスワードは引き続き暗号化されて送信されます！”問題は sslstrip です。これは、安全でないログインページを変更して次のようにするツールです。攻撃者が読み取れるようにどこかに送信します。

TLS再ネゴシエーションの脆弱性 aなど、過去数年間にさまざまな攻撃もありました。 >、 sslsniff 、 BEAST 、そしてごく最近では犯罪。ただし、すべての一般的なブラウザはこれらすべての攻撃から保護されているため、最新のブラウザを実行している場合、これらの脆弱性はリスクになりません。

最後になりましたが、他の方法で入手できます。 SSLが取得を拒否する情報。ユーザーの接続をすでに確認して改ざんできる場合は、ユーザーの.exeダウンロードの1つをキーロガーに置き換えることや、単にそのユーザーを物理的に攻撃することはそれほど難しくないかもしれません。暗号化はかなり安全かもしれませんが、人間です。ヒューマンエラーは依然として弱い要因です。 Verizonによるこの論文によると、データ侵害の10％は物理的な攻撃に関係しているため（3ページを参照）、「確かに覚えておくべきことがあります。

コメント

• “キーが対称キーと交換されます”。パケットスニファを持っている人がアクセスできないのはどうしてですか。
• @Yehosefいい質問です！私は私の答えでそれを説明するのを忘れました。周りを見回すと、実際にはこれに関する質問があります： security.stackexchange.com/q/6290/10863
• @岩猿すべてのCAは初日からこれを行っています。証明書のポイントは、特定のドメインの公開鍵を提供することであり、証明書に署名して、それが本当にドメインの正しいキーであることを証明することです。 ‘ s Encryptは、ドメインを所有していることを確認し、証明できる場合は証明書に（キーを使用して）署名するという、本来の機能を正確に実行します。これで、Let ‘ s Encryptを信頼するすべての人（事実上すべてのブラウザ）がその証明書を信頼するようになります。
• ええと、違います。 TLSは確かにTCPの上に実装されているだけです。
• このグラフィカルSSLハンドシェイクプロセスが非常に明確であることがわかりました。

SSLの一般的な概念はすでに他のいくつかの質問でカバーされているため（例：これとあれ）、今回は詳細を説明します。詳細は重要です。この答えはやや冗長になります。

履歴

SSLは長い歴史といくつかのバージョンを持つプロトコル。最初のプロトタイプは、主力ブラウザである Netscape Navigator の最初のバージョンを開発していたときにNetscapeから提供されました（このブラウザはモザイクは、新しい競合他社とはいえ、依然として激怒しています）。バージョン1は公開されたことがないため、どのように表示されたかはわかりません。 SSLバージョン2は、そこに読むことができるドラフトで説明されています。いくつかの弱点があり、そのうちのいくつかはかなり深刻であるため、非推奨であり、新しいSSL / TLS実装はサポートしていません（古いものはデフォルトで非アクティブ化されています）。たまに参照する場合を除いて、SSLバージョン2についてはこれ以上説明しません。

SSLバージョン3（「SSLv3」と呼びます）は、現在でも機能し、広くサポートされている拡張プロトコルでした。 Netscape Communications（または現在それを所有している人）の所有物ですが、プロトコルは「歴史的なRFC」（ RFC 6101 ）として公開されています。一方、プロトコルは標準化されており、法的な問題を回避するために新しい名前が使用されています。新しい名前は TLS です。

これまでに3つのバージョンのTLSが作成されており、それぞれに専用RFC： TLS 1.0 、 TLS 1.1 、 TLS1.2 。これらは内部的には互いに非常によく似ており、SSLv3と非常に似ています。その点で、実装はSSLv3と3つのTLSバージョンすべてを簡単にサポートでき、コードの少なくとも95％が共通です。それでも、内部的には、すべてのバージョンは major.minor 形式のバージョン番号で指定されています。その場合、SSLv3は3.0ですが、TLSバージョンはそれぞれ3.1、3.2、および3.3です。したがって、TLS1.0がSSL3.1と呼ばれることもあるのも不思議ではありません（そしてそれも正しくありません）。 SSL3.0とTLS1.0は、ほんのわずかな詳細だけが異なります。 TLS 1.1および1.2はまだ広くサポートされていませんが、弱点の可能性があるため、その推進力はあります（以下の「BEAST攻撃」を参照）。 SSLv3とTLS1.0は「どこでも」サポートされます（IE 6.0でも認識されます）。

コンテキスト

SSLは、任意のデータに安全な双方向トンネルを提供することを目的としています。 TCP を検討してください。これは、インターネット経由でデータを送信するためのよく知られたプロトコルです。 TCPはIP「パケット」を介して機能し、バイト用の双方向トンネルを提供します。すべてのバイト値に対して機能し、同時に動作できる2つのストリームに送信します。 TCPは、データをパケットに分割し、確認し、正しい順序に再組み立てすると同時に、重複を削除して失われたパケットを再送信するという大変な作業を処理します。 TCPを使用するアプリケーションの観点からは、ストリームは2つだけであり、パケットは表示されません。特に、ストリームは「メッセージ」に分割されません（メッセージが必要な場合は、アプリケーションが独自のエンコーディングルールを使用する必要があります。これは、まさにです。 HTTP はそうです）。

TCPは、「事故」、つまり、ハードウェアの不安定さ、ネットワークの混雑、特定の基地局の範囲外に出て行くスマートフォンを持っている人による送信エラーが存在する場合でも信頼できます。 、およびその他の悪意のないイベント。ただし、トランスポートメディアへのアクセス権を持つ悪意のある個人（「攻撃者」）は、送信されたすべてのデータを読み取ったり、意図的に変更したりする可能性があり、TCPはそれを防止しません。 SSL。

SSL は、信頼性の高いストリームを提供するTCPのようなプロトコルで動作することを前提としています。SSLは、失われたパケットなどの再送信を実装していません。攻撃者は避けられない方法で通信を完全に中断する力があるはずなので（たとえば、彼はケーブルを切断することができます）、SSLの仕事は次のとおりです。

• 検出変更（攻撃者はデータをサイレント変更できないようにする必要があります）;
• データの機密性を確保します（攻撃者は交換されたデータの知識を得てはなりません。

SSLはこれらの目標を大部分（絶対ではありません）達成します。

レコード

SSLは階層化され、最下層はレコードプロトコル

。 SSLトンネルで送信されるデータはすべて、レコードに分割されます。有線（基盤となるTCPソケットまたはTCPのようなメディア）では、レコードは次のようになります。

HH V1:V2 L1:L2 データ

ここで：

• HHは、レコード内のデータのタイプを示す1バイトです。4つのタイプが定義されています： change_cipher_spec （20）、 alert （21）、 handshake （22）、 application_data （ 23）。
• V1: V2は、2バイトを超えるプロトコルバージョンです。現在定義されているすべてのバージョンで、V1の値は0x03ですが、V2の値はSSLv3の場合は0x00、TLS 1.0の場合は0x01、TLS1.1の場合は0x02です。 TLS1.2の場合は0x03。
• L1: L2はdataの長さ（バイト単位）です（ビッグエンディアンの規則は使用：長さは256 * L1 + L2）です。 dataの全長は18432バイトを超えることはできませんが、実際にはその値に達することさえできません。

したがって、レコードには5つあります-バイトヘッダーと、それに続く最大18kBのデータ。 dataは、対称暗号化と整合性チェックが適用される場所です。レコードが発行されると、送信者と受信者の両方が、現在適用されている暗号化アルゴリズムとキーについて合意することになっています。この合意は、次のセクションで説明するハンドシェイクプロトコルを通じて取得されます。圧縮がある場合は、その時点でも適用されます。

詳細には、レコードの作成は次のように機能します。

• 最初は、転送するバイトがいくつかあります。 ;これらは、アプリケーションデータまたはその他の種類のバイトです。このペイロードは最大16384バイトで構成されますが、それより少ない可能性もあります（長さ0のペイロードは有効ですが、Internet Explorer6.0はそれをまったく好まないことがわかります ）。 。
• ペイロードは、現在合意されている圧縮アルゴリズムで圧縮されます。圧縮はステートフルであるため、以前のレコードの内容に依存する場合があります。実際には、圧縮は「null」（圧縮なし）または「Deflate」（ RFC 3749 ）のいずれかであり、後者は現在、丁寧に、しかししっかりと出口を示しています。最近の CRIME攻撃によるWebコンテキストのドア。圧縮はデータの短縮を目的としていますが、一部の好ましくない状況では必然的にデータをわずかに拡張する必要があります（鳩の巣原理による）。 SSLでは、最大1024バイトの拡張が可能です。もちろん、null圧縮は拡張されません（ただし、短縮されることはありません）。実装に問題がなければ、Deflateは最大10バイト拡張されます。
• 圧縮されたペイロードは変更から保護され、暗号化されます。現在の暗号化と整合性のアルゴリズムが「null」の場合、このステップは操作なしです。それ以外の場合は、 MAC が追加され、次にパディング（暗号化アルゴリズムに応じて）が追加され、結果が暗号化されます。これらの手順により、SSL標準で1024の追加バイトに制限される拡張が再び発生します（圧縮手順からの最大拡張と組み合わせると、18432バイトになり、それに5バイトのヘッダーを追加する必要があります）。

MACは通常、 HMAC であり、通常のハッシュ関数の1つ（主にMD5、SHA-1、またはSHA-256）を備えています。 （SSLv3では、これは「真の」HMACではありませんが、非常によく似たものであり、私たちの知る限りでは、HMACと同じくらい安全です）。暗号化では、 CBCモードのブロック暗号、または RC4 ストリーム暗号のいずれかを使用します。理論的には、他の種類のモードまたはアルゴリズムを使用できることに注意してください。たとえば、暗号化と整合性チェックを組み合わせたこれらの気の利いたモードの1つです。 そのためのRFCもあります。ただし、実際には、デプロイされた実装はこれらをまだ認識していないため、HMACとCBCを認識しています。重要なのは、MACが最初に計算されてデータに追加され、結果が暗号化されることです。これはMAC-then-encryptであり、実際にはあまり良い考えではありません。 MACは、（圧縮された）ペイロードとシーケンス番号の連結に基づいて計算されるため、勤勉な攻撃者はレコードを交換できません。

ハンドシェイク

ハンドシェイクは、レコードプロトコル内で再生されるプロトコルです。その目標は、レコードに使用されるアルゴリズムとキーを確立することです。 メッセージで構成されています。各ハンドシェイクメッセージは、4バイトのヘッダーで始まり、メッセージタイプを説明する1バイト、メッセージの長さを表す3バイトです（ビッグエンディアンの規則）。連続するハンドシェイクメッセージは、「ハンドシェイク」タイプでタグ付けされたレコードとともに送信されます（各レコードのヘッダーの最初のバイトの値は22です）。

レイヤーに注意してください：ハンドシェイクメッセージ、4つで完了-バイトヘッダーはレコードとして送信され、各レコードにも独自のヘッダーがあります。 さらに、複数のハンドシェイクメッセージを同じレコード内で送信でき、特定のハンドシェイクメッセージを複数のレコードに分割できます。ハンドシェイクメッセージを作成するモジュールの観点からは、「レコード」はバイトを送信できる単なるストリームです。そのストリームが実際にレコードに分割されることはありません。

フルハンドシェイク

最初は、クライアントとサーバーは、MACとnull圧縮を使用しないnull暗号化に「同意」します。これは、最初に送信するレコードがクリアテキストとして保護されずに送信されることを意味します。

ハンドシェイクの最初のメッセージはClientHelloです。これは、クライアントがSSLを実行する意図を示すメッセージです。 「クライアント」は象徴的な役割であることに注意してください。それは「最初に話す党」を意味します。 HTTP-within-SSL-within-TCPであるHTTPSコンテキストでは、3つのレイヤーすべてに「クライアント」と「サーバー」の概念があり、それらはすべて同意します（TCPクライアントはSSLクライアントでもあり、 HTTPクライアント）ですが、それは一種の偶然です。

ClientHelloメッセージには次のものが含まれます。

• 最大プロトコルクライアントがサポートしたいバージョン;
• 「クライアントランダム」（32バイト、そのうち28バイトは暗号的に強力な数値ジェネレーターで生成されることになっています）;
• “セッションID」（クライアントが簡略化されたハンドシェイクでセッションを再開したい場合は、以下を参照）。
• クライアントが知っている「暗号スイート」のリスト（クライアントの好み順に並べられている）。
• クライアントが知っている圧縮アルゴリズムのリスト。クライアントの好み順に並べられています。
• いくつかのオプションの拡張機能。

暗号スイートは、一連の暗号の16ビットシンボリック識別子です。 cアルゴリズム。たとえば、TLS_RSA_WITH_AES_128_CBC_SHA暗号スイートの値は0x002Fであり、「レコードは128ビットキーでHMAC / SHA-1およびAES暗号化を使用し、キー交換は暗号化によって行われます。サーバーのRSA公開鍵を使用したランダムキー。

サーバーはClientHelloにServerHello含まれるもの：

• クライアントとサーバーが使用するプロトコルバージョン;
• 「サーバーランダム」（32バイト、28ランダムバイト）;
• この接続のセッションID;
• 使用される暗号スイート;
• 使用される圧縮アルゴリズム;
• オプションで、一部の拡張機能。

完全なハンドシェイクは次のようになります：

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

（このスキーマRFCから恥知らずにコピーされました。）

ClientHelloとServerHelloが表示されます。次に、サーバーは送信します。暗号スイートと他のいくつかのパラメータに依存する他のいくつかのメッセージrs：

• 証明書：サーバーの証明書。公開鍵が含まれています。詳細については、以下をご覧ください。このメッセージは、暗号スイートが証明書なしでハンドシェイクを要求する場合を除いて、ほとんどの場合送信されます。
• ServerKeyExchange：証明書の内容が十分でない場合は、鍵交換用のいくつかの追加値。特に、「DHE」暗号スイートは、エフェメラルDiffie-Hellman 鍵交換を使用します。これには、そのメッセージが必要です。
• CertificateRequest：クライアントが自身の証明書で自分自身を識別することを 要求するメッセージ。このメッセージには、サーバーがクライアント証明書の検証に使用するトラストアンカー（別名「ルート証明書」）の名前のリストが含まれています。
• ServerHelloDone：サーバーが終了し、クライアントが通信する必要があることを示すマーカーメッセージ（長さゼロ）。

クライアントは応答する必要があります。使用：

• 証明書：クライアント証明書、 if サーバーが要求しました。バージョン間で微妙な違いがあります（SSLv3では、クライアントは証明書がない場合はこのメッセージを省略する必要があります。TLS1.0以降では、同じ状況でCertificateを送信する必要があります。証明書のリストが空のメッセージ）。
• ClientKeyExchange：実際の鍵交換のクライアント部分（たとえば、サーバーのRSAキーで暗号化されたランダムな値）。
• CertificateVerify： a 以前のすべてのハンドシェイクメッセージに対してクライアントによって計算されたデジタル署名。このメッセージは、サーバーがクライアント証明書を要求し、クライアントが準拠したときに送信されます。これは、クライアントが送信した証明書にエンコードされている公開鍵を実際に「所有」していることをクライアントがサーバーに証明する方法です。

次に、クライアントは ChangeCipherSpec メッセージ。これはハンドシェイクメッセージではありません。独自のレコードタイプがあるため、独自のレコードで送信されます。その内容は純粋にシンボリックです（値1の1バイト）。このメッセージは、クライアントが新しくネゴシエートされた暗号スイートとキーに切り替えるポイントを示します。その後、クライアントからの後続のレコードは暗号化されます。

終了メッセージは、計算された暗号チェックサムです。以前のすべてのハンドシェイクメッセージ（クライアントとサーバーの両方から）。 ChangeCipherSpecの後に発行されるため、整合性チェックと暗号化の対象にもなります。サーバーがそのメッセージを受信してその内容を確認すると、サーバーは実際に同じクライアントとずっと通信していたという証拠を取得します。このメッセージは、ハンドシェイクを変更から保護します（攻撃者は、ハンドシェイクメッセージを変更しても、Finishedメッセージを正しく取得できません）。

サーバーは最終的に独自のChangeCipherSpec次にFinished。その時点で、ハンドシェイクは終了し、クライアントとサーバーはアプリケーションデータを交換できます（そのようにタグ付けされた暗号化されたレコード内）。

覚えておくべきこと：クライアントは提案しますが、サーバーは選択します。暗号スイートはサーバーの手にあります。礼儀正しいサーバーは（可能であれば）クライアントの設定に従うことになっていますが、そうでない場合もあり、実際に実行するものもあります（たとえば、BEASTに対する保護の一部として）。

省略されたハンドシェイク

完全なハンドシェイクでは、サーバーは「セッションID」（つまり、最大32バイトの束）をクライアントに送信します。後で、クライアントは戻ってきて、ClientHelloの一部として同じセッションIDを送信できます。これは、クライアントが以前のハンドシェイクの暗号スイートとキーを引き続き記憶しており、これらのパラメーターを再利用したいことを意味します。サーバーがまた暗号スイートとキーを記憶している場合、サーバーはその特定のセッションIDをServerHelloにコピーしてから、短縮ハンドシェイク：

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

短縮ハンドシェイクは短く、メッセージが少なく、非対称暗号化ビジネス、そして最も重要なこととして、遅延の削減。 Webブラウザとサーバーはそれをたくさん行います。通常のWebブラウザーは、完全なハンドシェイクでSSL接続を開き、同じサーバーへの他のすべての接続（並行して開く他の接続、および同じサーバーへの後続の接続）に対して省略されたハンドシェイクを実行します。実際、通常のWebサーバーは、非アクティブ状態が15秒間続くと接続を閉じますが、セッション（暗号スイートとキー）をはるかに長い時間（場合によっては数時間または数日）記憶します。

鍵交換

SSLで使用できる鍵交換アルゴリズムはいくつかあります。これは暗号スイートによって指定されます。各鍵交換アルゴリズムは、ある種のサーバー公開鍵で機能します。最も一般的な鍵交換アルゴリズムは次のとおりです。

• RSA：サーバーの鍵のタイプはRSAです。クライアントはランダムな値（「 48バイトの「プリマスターシークレット」（うち46はランダム）を使用して、サーバーの公開鍵で暗号化します。 ServerKeyExchangeはありません。
• DHE_RSA：サーバーのキーはRSAタイプですが、次の目的でのみ使用されます。署名。実際の鍵交換はDiffie-Hellmanを使用します。サーバーは、DHパラメーター（モジュラス、ジェネレーター）と新しく生成されたDH公開鍵を含むServerKeyExchangeメッセージを送信します。さらに、サーバーはこのメッセージに署名します。クライアントは、新しく生成されたDH公開鍵も含むClientKeyExchangeメッセージで応答します。DHは「プリマスターシークレット」を生成します。 “。
• DHE_DSS：DHE_RSAと同様ですが、サーバーにはDSSキーがあります（” DSS “も知られています） as “DSA” ）。DSSは署名のみのアルゴリズムです。

あまり一般的に使用されない鍵交換アルゴリズムには次のものがあります。

• DH：サーバーのキーはDiffie-Hellmanタイプです（証明書には、 DHキー）。これは、RSA特許がまだ有効であったとき（これは前世紀のことでした）、管理上の方法で「人気がありました」（米国連邦政府はその使用を義務付けました）。官僚的な推進にもかかわらず、RSAほど広く展開されることはありませんでした。
• DH_anon：DHEスイートのように、ただし、サーバーからの署名はありません。これは証明書のない暗号スイートです。構造上、中間者攻撃に対して脆弱であるため、ほとんど有効になりません。
• PSK：事前共有キー暗号スイート。事前に確立された共有秘密に基づいて構築された、対称のみの鍵交換。
• SRP： SRPプロトコルのアプリケーション。 2672cb5fc2 “>

後前の回答でのSSLの長いプレゼンテーション、つまり、楽しいものを使ってみましょう：

SSLへの攻撃

SSLに対する攻撃は数多くあり、実装エラーに基づくものもあれば、真のプロトコルの弱点に基づくものもあります。

SSLは最も攻撃されているプロトコルの1つですが（非常に注目度が高いため、SSLへのアプリケーションの成功は、研究記事の要約では非常に優れている）、 SSLは、最も修復されたプロトコルの1つでもあります。トランスポートプロトコルを攻撃するすべての既知の方法がSSLで試行され、SSLが適切な場所にパッチされているため、堅牢であると見なされます。

バージョンロールバック

SSLv3の初期には、SSLv2がまだ広く使用されていたため、クライアントは一般的にSSLv2互換のメッセージ。SSLv3もサポートされていることを示しているだけです。次に、サーバーはヒントを受け取り、SSLv3 +方言で応答します（詳細については、 RFC 2246 の付録Eを参照してください）。 SSLv2には弱点があったため、SSLv3を知っているクライアントとサーバーが、SSLv2を使用して相互に通信できるように手配することが、攻撃者の最大の利益になりました。これは、バージョンロールバック攻撃と呼ばれます。この概念は、正式には後のバージョンにも拡張されます。

ロールバックの試行を検出するためのクラッジが追加されました。 SSLv2に戻るロールバックの場合、SSLv3 +を知っているクライアントは、RSA暗号化ステップに特別なパディングを使用する必要があります（SSLv2はRSAベースのキー交換のみをサポートしていました）：in PKCS＃ 1 、暗号化されるデータは、ランダムなバイト数で埋められることになっています。 SSLv3対応のクライアントは、最後の8つのパディングバイトのそれぞれを固定値0x03に設定することになっています。次に、サーバーはこれらのバイトをチェックします。 8つの0x03が見つかった場合、ロールバックが試行される可能性が高く、サーバーはその試行を拒否します（SSLv2のみのクライアントは、そのようなパディングバイトを使用する確率が255 ^-8 であるため、運が良かったので、誤検知はごくわずかな割合で発生します。

SSL / TLSの古いバージョンへのロールバックで、SSLv3より前ではないため、別の問題が追加されました。プレマスターシークレットクライアントがサーバーのRSAキーで暗号化する48バイトのうち、最初の2バイトはランダムではありませんが、クライアントが最初にメッセージ。残念ながら、一部のクライアントはそれを間違えました。このクラッジはRSAベースのキー交換でのみ機能するため、ロールバックに対する保護は非常に制限されています。幸い、SSLv3 +には別のはるかに強力な保護があります。ロールバック。これは、Finishedメッセージが作成されるときにハンドシェイクメッセージが一緒にハッシュされることです。このプロ「古いバージョン」が完全に弱く、攻撃者がハンドシェイク自体が終了する前に暗号化全体を完全に破ることができない場合を除いて、ロールバックを防ぎます。これはまだ発生していません（SSLv3はまだかなり堅牢です）。

弱い暗号スイート

一部の標準暗号スイートは、何らかの方法で意図的に脆弱になっています。

• 暗号化がまったくなく、整合性チェックのみが行われる暗号スイートがいくつかあります。 TLS_RSA_WITH_NULL_SHA;
• TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5などの40ビット暗号化を備えた一部の暗号スイート（準拠することを目的とした暗号スイート前世紀からの厳格な米国の輸出規則-これらの規則は、ビルクリントン時代の終わりにほとんど解除されました）;
• 。 56ビットDESは、既存のテクノロジーで解読可能ですが、それでもアマチュア（数百台の大学のマシンにアクセスできる退屈な学生でさえ）にとっては少し難しいです。 ）、したがって、私は56ビットDESを「中程度の強度」と見なす傾向があります。

これにより、攻撃者がクライアントとサーバーに同意を強制するバージョンロールバック攻撃の変形への道が開かれます。弱い暗号スイートでは、攻撃者がクライアントによってアナウンスされた暗号スイートのリストを変更するという考えです。これは、選択した暗号スイートが非常に弱いため、明らかに正しいFinishedメッセージ。実際、SSLv3 +で使用されるMACは（MD5に基づく場合でも）それを防ぐのに十分堅牢です。したがって、ここでは実際の心配はありません。また、ここでの本当の弱点は、私の意見です。これは、クライアントまたはサーバーが弱い暗号スイートの使用を受け入れる場合です。

デフォルトでは、最新のWebブラウザーはそのような弱い暗号スイートの使用を許可していません。

秘密鍵の盗難

SSL接続でRSA鍵交換を使用する場合、攻撃者はレコードのコピーを保持し、後で（おそらく数か月後、廃棄されたハードディスクまたはテープ上のすべてのバックアップを検査することにより）秘密鍵のコピーを取得し、それを解明することができます。ハンドシェイクしてデータを復号化します。

Perfect Forward Secrecy は、この「後で」対処することです。 DHE暗号スイートを使用して取得します。 DHE暗号スイートでは、ハンドシェイクを解明するために使用できる実際の秘密鍵は、サーバーのRSA（またはDSS）秘密鍵ではなく、一時的なDiffie-Hellman鍵です。一時的なものであるため、RAMにのみ存在し、ハードディスクに書き込まれることはありませんでした。そのため、盗難に対する耐性がはるかに高いはずです。

したがって、教訓は次のとおりです。原則として、可能であればDHE暗号スイートを使用してみてください。バックアップを気にし、秘密鍵を漏らさないようにする必要がありますが、少なくとも、DHEスイートでは、特に鍵の有効期間が終了した後に発生した場合（つまり、対応する証明書がない場合）、このような漏えいの問題は少し少なくなります。有効期間が長くなります）。

証明書の問題

証明書ビジネス全体はSSLの問題点。

技術的には、SSLはX.509から完全に独立しています。証明書チェーンは不透明なブロブとして交換されます。ある時点で、クライアントはサーバーの公開鍵を使用する必要がありますが、クライアントは適切と思われる方法でその鍵を自由に「知る」ことができます。SSLを使用できる特定のシナリオでは、クライアントはすでにサーバーを知っています。の公開鍵（コードにハードコードされている）であり、サーバーから送信された証明書を無視します。それでも、HTTPSの一般的なケースでは、クライアントは X.509 で説明されているように、サーバーの証明書チェーンの検証を実行します（正気を犠牲にして読んでください。警告されています。

これにより、たとえば次のような多数の攻撃ベクトルが生成されます。

• 検証では、次のことを確認する必要があります。証明書は現在の日付でも有効です。クライアントマシンはどのようにして現在の日付を認識しますか？内部クロックを使用し、場合によっては NTPサーバーと通信します（まったく保護されていない方法です！）クライアントは数分、数時間、数日、さらには数年も離れている可能性があり（私はそれを見ました）、ある程度、強力な攻撃者がNTPメッセージをいじって強制する可能性があります。攻撃者は、数年前に取り消された廃止された証明書を使用します。面白い事実に注意してください。SSLの「クライアントランダム」と「サーバーランダム」には、28のランダムバイトとローカルの日付と時刻（4以上）が含まれている必要があります。バイト）。この包含時間のは、時間ベースの攻撃に対する回避策の一部であることが意図されていました。実際にチェックする実装を認識していません。

• 2003年頃まで、Internet Explorer / Windowsでの証明書検証の実装は「基本的な制約」拡張機能を処理しませんでした。正しく。正味の効果は、100ユーロの証明書を持っている誰でもがCAとして機能し、任意に選択した名前とキーで「証明書」を発行できることでした。

• X .509には、失効と呼ばれる損傷封じ込め機能が含まれています。これは、暗号的には見栄えがよいが信頼されるべきではない（たとえば、秘密鍵が盗まれた、または含まれている）、追放された証明書のリストを公開することです。誤った名前）。失効は、関係者（ブラウザなど）が巨大な失効リスト（数メガバイトの長さになる可能性があります！）のダウンロード、または OCSPサーバーへの連絡を受け入れる場合にのみ機能します。最近のブラウザは現在それを行っていますが、少ししぶしぶ、そして多くの人は、失効ステータス情報をタイムリーに取得できなかった場合（人間のユーザーが辛抱強くないため）、とにかく接続を受け入れます。全体的な状況は何年にもわたって改善されますが、非常にゆっくりです。

• 一部のルートCAは、過去にいくつかの失敗を犯しました（ComodoやDigiNotarなど）。これにより、偽の証明書が発行されました（名前はwww.microsoft.comですが、秘密鍵はMicrosoftの手に渡っていません…）。これらの失敗が発見され、証明書が取り消されましたが、それでもいくつかの不快な質問が発生します（たとえば、そのような問題を抱えていたが明らかにしなかった、またはさらに悪いことに、それらに気づかなかった他のCAはありますか？）

X.509は、アルゴリズム、テクノロジー、仕様、および委員会の非常に複雑なアセンブリであり、正しく理解するのは非常に困難です。 Cのような保護されていないプログラミング言語でX.509証明書を「手動で」デコードしようとすると、バッファオーバーフローを簡単に取得できます。

ブライヘンバッハー攻撃

Daniel Bleichenbacher は、1998年にRSAに対する優れた攻撃を発見しました。データをRSAで暗号化する場合（SSLのClientKeyExchangeメッセージで発生するように）、暗号化するデータを順番にパディングする必要があります。 RSAモジュラスと同じ長さのバイトシーケンスを作成します。パディングは主にランダムなバイトで構成されますが、構造が少しあります（特に、パディング後の最初の2バイトは0x00 0x02である必要があります）。

復号化時に（サーバー上で）、パディングは必要です。見つけて削除します。その時点で、サーバーが復号化したが無効なパディングを取得した場合（0x00 0x02バイトが存在しなかった場合）、サーバーはアラートメッセージで報告しましたが（SSL仕様に従って）、有効なパディングは次のようになりました。一見復号化された値を使用し、ハンドシェイクを続行するサーバー。

この種のものは、パディングオラクルとして知られています。これにより、攻撃者は、暗号化されたプリマスターシークレットであるかのように任意のバイトシーケンスを送信し、そのシーケンスの復号化によって有効なパディングが生成されるかどうかを知ることができます。これは「単なる1ビットの情報ですが、数百万のリクエストで秘密鍵を回復するのに十分です（巧妙に作成された「暗号化された」文字列を使用）。

回避策：復号化の結果が無効になった場合パディングすると、サーバーはランダムなプリマスターシークレットを使用し続けます。ハンドシェイクは後で失敗し、Finishedメッセージが表示されます。SSLの現在の実装はすべてそれを行います。

パディングオラクルの逆襲

パディングオラクルが見つかったもう1つの領域はCBC暗号化とHMACを検討してください。暗号化するデータは最初にMAC化され、次に結果が暗号化されます。CBC暗号化では、暗号化されるデータの長さはブロックサイズの倍数である必要があります（3DESの場合は8バイト、 AESの場合は16バイト）。したがって、いくつかのパディングが適用され、いくつかの構造があります。

その時点（攻撃は2002年にVaudenayによって発見されました）、SSL実装が受信を処理していたときdレコードでは、次の2つの条件に対して個別のアラートメッセージが返されました。

• 復号化時に、有効なパディング構造が見つかりませんでした。
• 復号化時に、有効なパディングが見つかりましたが、MACが検証され、一致しませんでした。

これはパディングオラクルであり、暗号化されたデータの回復に使用できます。アクティブな攻撃者が必要ですが、それほど難しくはありません。 Vaudenayはそれを実装し、変更されたSSL実装が両方のケースで同じアラートメッセージを返す場合に拡張されましたが、MACの再計算に時間がかかるため、2番目のケースでは戻るのに時間がかかりました（ タイミング攻撃）。

人々は決して学ぶことがないため、ASP.NETで使用されるSSLのMicrosoft実装はパッチが適用されていない 2010年（8年後！）、RizzoとDuongがVaudenay攻撃を再実装し、HTTPCookieを回復するデモを作成しました。

このページ。 SSLが encode-then-MAC を使用していた場合、そのような問題は回避されていたことに注意する必要があります（以前は、障害のあるレコードはMACレベルで拒否されていました）。復号化を考慮しても）。

BEAST

BEAST攻撃は再びDuongとRizzo、そして繰り返しますが、これは古い攻撃のリメイクです（2002年のPhilip Rogawayによる）。アイデアを得るには、 CBC を検討してください。この動作モードでは、データの各ブロックは、最初に前のブロックの暗号化の結果とXORされます。これは、暗号化されたXORの結果です。これは、ブロックを「ランダム化」し、ECBモードで検出されるリークを回避するために行われます。最初のブロックには「前の」ブロックには、初期化ベクトル（IV）が必要です。これは、最初のブロックの前のブロックの役割を果たします。

攻撃者が暗号化されるデータの一部を制御でき、使用されるIVを予測できる場合、攻撃者は暗号化マシンをさらに別の復号化に変えることができます。 oracleを使用して、他の暗号化されたデータ（攻撃者が選択しない）を回復します。ただし、SSLv3およびTLS 1.0では、攻撃者はレコードのIVを 予測できます。これはの最後のブロックです。前のレコード！したがって、攻撃者は、実装が前のレコードを構築して送信した時点（通常は16 kB相当の場合）で、ターゲットデータを「プッシュ」するために、ストリーム内のデータを送信できる必要があります。

TLS 1.1（およびそれ以降のバージョン）では、レコードごとのランダムIVが使用されるため、TLS 1.1+はそれに対して保護されています。 SSLv3およびTLS1.0の場合、回避策は、長さがゼロのレコードを送信することです。つまり、ペイロードがゼロのレコードを送信しますが、MACとパディングおよび暗号化を使用し、MACは秘密鍵からシーケンスを介して計算されます。数なので、これは乱数ジェネレータの役割を果たします。残念ながら、IE6.0は長さがゼロのレコードでチョークします。他の戦略には、1 / n-1分割が含まれます（ n バイトのレコードは2つのレコードとして送信され、1つは1バイトのペイロードで、もう1つは残りの n-1 ）。

別の回避策は、可能な場合は非CBC暗号スイートの使用を強制することです。サーバーは、によって送信される暗号スイートのリストにRC4ベースの暗号スイートがある場合はそれを選択します。クライアントがCBCベースの暗号スイートを好む場合でも。 このツールは、特定のサーバーが明らかにそのように動作するかどうかを示します。（注：BEASTはクライアントへの攻撃ですが、RC4暗号スイートを選択することで、サーバーは不注意なクライアントを保護できます。）

このページ。 TLS 1.1は2006年のものですが、BEAST攻撃により、ブラウザベンダーは最終的にアップグレードを余儀なくされる可能性があります。

CRIME

ハリウッドのフランチャイズについては、DuongとRizzoが2012年に続編の続編を公開しました。 CRIMEは、数年前に理論化されたリークを悪用しますが、最近公開されたデモンストレーションでのみ鮮明に示されました。 CRIMEは、BEAST攻撃と同じ設定で圧縮を悪用します（攻撃者はSSL接続で独自のデータを送信でき、Cookieなどの興味深いターゲットデータも送信されます）。大まかに言えば、攻撃者はそのデータにターゲット文字列の潜在的な値を入力し、一致する場合、圧縮によって結果のレコードが短くなります。 （認知前の）分析については、この質問を参照してください。

TLSレベルの圧縮をまったく使用しないことで、犯罪を回避できます。ブラウザが今何をしているのか。 Internet ExplorerとIISは、そもそもTLSレベルの圧縮を実装したことはありません（かつては、だらしのないことが1日を節約しました）。 FirefoxとChromeはそれを実装し、今年の夏に非アクティブ化しました（彼らは、彼らの活動にかなりの責任を負っているDuongとRizzoによって事前に警告されました）。

CRIMEは、私の SSLの説明：

SSLは、これらの目標を大部分（絶対ではありません）達成します。

実際、暗号化により、暗号化されたデータの長さがリークされます。それに対する既知の良い解決策はありません。そして、長さだけでも多くのことが明らかになります。たとえば、ネットワークモニターでSSL接続を監視する場合、ストリーム内の「余分なハンドシェイク」を見つけることができます（各レコードの最初のバイトはレコード内のデータのタイプを識別し、暗号化されていないため）。レコードの長さを使用すると、クライアントが証明書を提供したかどうかを簡単に確認できます。

Poodle

（編集：このセクションが追加されましたon 2014-10-15）

「Poodle」攻撃は、CBCベースの暗号スイートを使用したSSL3.0に固有の欠陥を悪用します。これは、SSL3.0の見過ごされがちな機能に依存しています。ほとんどのパディングバイトは無視されます。 TLS 1.0では、パディング（完全なブロックのみを処理するCBC暗号化と互換性のある長さにするためにレコードに追加されるバイト）が完全に指定されています。すべてのバイトには特定の値が必要であり、受信者はそれをチェックします。 SSL 3.0では、パディングバイトの内容は無視されるため、攻撃者はほとんど気付かれない変更を実行できます。変更は適用されないデータにのみ影響しますが、BEASTと漠然と同様の方法で復号化オラクルとして使用できます。

詳細はで読むことができます。答え。

未来

人間は決して学びません。 SSLに気の利いた拡張機能を追加することには多くのプレッシャーがあります。多くの理由から、最初は常に見栄えがしますが、追加の問題が発生する可能性があります。

たとえば、 SSL FalseStart 。主に、これは、クライアントがFinishedメッセージを（完全なハンドシェイクで）送信した直後に、ividを待たずにアプリケーションデータを送信することに関するものです。サーバーからの= “82a2dff0c6”>