😶 💐 💆🏿 HTTPS接続の最初の数ミリ秒 😹 🎌 🐕

レビューを何時間も読んだ後、ボブは全乳1ガロンの[精算]ボタンをクリックし、...

うわー、何が起きたの？

Firefoxはアドレスバーの色を変更し、右下隅にロックを表示したため、220ミリ秒を超えると、多くの興味深いことが起こりました。私のお気に入りのWiresharkツールとわずかに変更されたFirefoxデバッグビルドを使用して、正確に何が起こったかを把握しようとします。

RFC 2818により、Firefoxは「https」がAmazon.comに接続するためにポート443を使用する必要があることを意味していることを認識しています。

顧客挨拶

TLSは、すべてのトラフィックをさまざまなタイプの「レコード」にラップします。 HEXのパケットの最初のバイトは0x16 = 22であることがわかります。これは、「レコード」が「ハンドシェイク」であることを意味します。

次の2バイトは0x0301で、バージョン3.1を意味します。つまり、TLS 1.0は実際にはSSL 3.1です。

ハンドシェイクレコードはいくつかのメッセージに分割されます。 1つ目は「顧客挨拶」（0x01）です。ここにはいくつかの重要なポイントがあります。

ランダムネス：

これらの4バイトは、現在のUnix時間、1970年1月1日からの秒数です。この場合、0x4a2f07caです。後に必要な28バイトのランダムバイトが続きます。
セッションID：

私たちの場合、このフィールドは空です。数秒前にAmazon.comに接続した場合、セッションを続行できますが、完全なハンドシェイクはできません。
暗号スイート：

ブラウザでサポートされているすべての暗号化アルゴリズムのリスト。デフォルトでは、非常に強力なTLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHAが使用され、その後に33個のオプションが続きます。何も分からなくても心配しないでください。次に、Amazonがデフォルトのオプションを受け入れないことを学びます。
サーバー名の拡張子：

ブラウザにwww.amazon.comのページが必要であることをamazon.comに伝える方法。 TLSハンドシェイクはHTTPトラフィックのかなり前に開始されるため、これは非常に便利です。 HTTPには「Host」ヘッダーがあり、これにより同じIPで数百のサイトをホストできます。 SSLは従来、サイトごとに異なるIPを必要としていましたが、この拡張機能により、サーバーは特定のサイトの証明書で応答できます。

サーバー挨拶

Amazon.comは、サイズが2パケット（2,551バイト）のかなり大きなハンドシェイクで応答します。これは、同じバイトシーケンス0x0301を示しています。つまり、AmazonはTLS 1.0の使用に同意しています。レコードには、興味深いデータを含む3つのサブメッセージがあります。

サーバーのウェルカムメッセージ：
- 4つのUnix時間バイトと28のランダムバイト。
- 次のリクエストを高速化するための32バイトのセッションID。
- 提案した34個のアルゴリズムのうち、Amazonは「TLS_RSA_WITH_RC4_128_MD5」（0x0004）を選択しました。これは、証明書の署名と鍵交換を検証するためにRSAアルゴリズムが使用され、データを暗号化するためにRC4アルゴリズムが、コンテンツを検証するためにMD5ハッシュ関数が使用されることを意味します。これについては後で詳しく説明します。 Amazonには、たとえばCPUの負荷を減らすなど、これらの特定のアルゴリズムを選択する独自の理由があるように思えます。可能性が低いオプションは、上記の3つのアルゴリズムすべての作成者であるRon Rivestのおかげです。
証明書メッセージ：
- クライアントがAmazon証明書を検証するために使用できる2.464バイトの巨大なメッセージとその証明書。これらはすべてブラウザでも表示できます。
「サーバーの挨拶が完了しました」というメッセージ

「あいさつ」が正常に完了し、サーバーがクライアント証明書を要求しないことを示す空のメッセージ。

証明書の検証

ブラウザがAmazon.comと明確に通信することを確認できるように、証明書が必要です。証明書の開始日と終了日を調べ、公開鍵が秘密鍵の交換を許可されているかどうかも確認します。

なぜ証明書を信頼する必要があるのですか？

「署名」が添付されています。ビッグエンディアン形式の長い数字です。

誰でもこれらのバイトを送信できます。なぜこの署名を信頼する必要があるのですか？答えるために、数学の世界への短い旅行をします。

RSAの簡単な紹介

一部の人々は、数学がプログラミングと何らかの関係があるのではないかと考えています。証明書は、数学を使用する非常に明白なケースです。 Amazon証明書は、RSAを使用して署名を検証する必要があることを示しています。 RSAは1970年にMIT Ron Rivest教授、Adu Shamir教授、Len Adleman教授によって作成され、2000年の数学のアイデアを組み合わせて簡単なアルゴリズムを作成する美しい方法を見つけました。

2つの素数、pとqを選択します。それらを掛けてnを取得します。次に、暗号化指数となる単純な公開指数eと、解読者となる特別に選択された逆e、dを選択します。次に、nとeを公開し、dを秘密にします。 pとqを忘れるか、dで保存できます。

これで、メッセージがある場合は、そのバイトを数値Mで表すだけで済みます。メッセージを暗号化する必要がある場合は、次のように計算します。

C≡M ^e （mod n）

つまり、Mを自分でe回掛ける必要があります。 mod nは、nによる除算の残りのみを取ることを意味します。たとえば、午前11時+ 3時間=午後2時（mod 12時間）。受信者はdを認識し、逆の操作を実行して復号化できます。

C d≡（M ^e ）d≡M ^{e *} d≡M 1≡M（mod n）

また、メッセージMをdで累乗することにより、dを持つ人がドキュメントに署名できることも興味深いです。

M d≡S（mod n）

これは、署名者がS、M、e、およびnを公開するために可能です。誰でも簡単な計算でSの署名を検証できます。

S e≡（M ^d ）e≡M ^{d *} e≡M ^{e *} d≡M 1≡M（mod n）

公開キー暗号化は、暗号化キー（この場合はe）が復号化キー（d）と等しくないため、非対称と呼ばれます。 RSAマジックは、C≡M ^e （mod n）を非常に迅速に計算できるため機能しますが、dがわからないとC d≡M（mod n）はほとんど不可能です。前に見たように、dはnをpとqに分解することで得られますが、これはかなり複雑です。

署名検証

実際にRSAを使用する場合、すべての数値は__非常に大きくなければならないことに注意することが重要です。いくら AmazonがVeriSign Class 3 Secure Server CAによって認定これは、nが2048ビット長である必要があることを意味します。これは10進数です。

2091550579 0341204005 1169453804 7325464426 0479594122 4167270607 6731441028 3698615569 9947933786 3789783838 5829991518 1037601365 0218058341 7944190228 0926880299 3425241541 4300090021 1055372661 2125414429 9349272172 5333752665 6605550620 5558450610 3253786958 8361121949 2417723618 5199653627 5260212221 0847786057 9342235500 9443918198 9038906234 1550747726 8041766919 1500918876 1961879460 3091993360 1890572922 9464742433 9498401781 6528521078 8629616064 3051642608 4317020197 7241822595 6075980039 8371048211 4887504542 4200635317 0422636532 6376719337 6644159792 1249204891 7079005527 7689341573 9395596650 5484628101 0469658502 1566385762 0175231997 6268718746 7514321

（pとqを選択すると幸運です。可能であれば、偽のVeriSign証明書を生成できます。）

署名Sをpublic e VeriSignで累乗し、モジュールnによる除算の残りを取得すると、復号化された署名が16進数で取得されます。

0001FFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFF00302130 0906052B0E03021A 05000414C19F8786 871775C60EFE0542 E4C2167C830539DB

PKCS＃1 v1.5規格によれば、最初のバイト00は、暗号化ブロックを整数に変換してモジュールより小さくするためのものです（モジュールが何であるかはまだわかりませんでした-およそTransl。）。 2番目のバイト01は、これが秘密キー操作であることを示します。次に、空のスペースを獲得するためにFFバイトの束。バイト00で終了し、次にシーケンス「30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14」は、SHA-1関数の使用を意味します。最後の20バイトは、signedCertificateのバイトからのSHA-1の結果です。

復号化された値は正しくフォーマットされており、最後のバイトは自分で計算できるものに対応しているため、VeriSign Class 3 Secure Server CA秘密鍵を知っている誰かがこれに署名したと想定できます。

このプロセスを繰り返して、VeriSign Class 3 Secure Server CA証明書がVeriSignのClass 3 Public Primary Certification Authorityによって署名されていることを確認できます。

しかし、なぜ彼を信頼する必要があるのでしょうか？この信頼チェーンには、これ以上のリンクはありません。

ルートVeriSignクラス3パブリックプライマリ認証局は、それ自体で署名されました。この証明書は、無条件に信頼できる証明書としてMozilla製品に組み込まれています。

プリマスターキー

Amazon.comを確認し、公開暗号化指数eとモジュールnを知っています。私たちの話を聞いている人なら誰でも同じことができます。次に、攻撃者が認識しないランダムキーを生成する必要があります。 Netscape Navigator 1.1の擬似乱数ジェネレーターの脆弱性により、当時のマシンでは25秒でSSLがクラックされる可能性があるため、見かけほど簡単ではありません。偶然の一致が難しいと思わない場合は、OpenSSLメンテナーにDebianを依頼できます。

たとえば、Windowsでは、擬似乱数生成関数は125のソースからデータを取得します。 Firefoxはその結果を使用して、数ビットの独自の擬似ランダムデータを追加します

多くのことが推測されるため、48バイトの「プリマスターキー」を秘密にすることが非常に重要です。 Firefoxが見つけにくいのも不思議ではありません。デバッグバージョンをビルドし、SSLDEBUGFILEおよびSSLTRACEフラグを設定して表示する必要がありました。

4456：SSL [131491792]：Pre-Master Secret [レン：48]

03 01 bb 7b 08 98 a7 49 de e8 e9 b8 91 52 ec 81 ... {... I ..... R ...

4c c2 39 7b f6 ba 1c 0a b1 95 50 29 be 02 ad e6 L.9 {...... P）...

ad 6e 11 3f 20 c4 66 f0 64 22 57 7e e1 06 7a 3b .n。？ .fd "W〜..z;

完全にランダムではありません。TLS標準の最初の2バイトは03 01である必要があります。

キー交換

次に、この秘密の番号をAmazon.comに転送する必要があります。 Amazonは「TLS_RSA_WITH_RC4_128_MD5」の使用を望んでいたため、RSAで暗号化します。プリマスターキーの48バイトのみをメッセージとして使用できますが、PKCS＃1 v1.5標準に従って、空のスペースにランダムデータを入力し、パケットサイズを128バイトにする必要があります。そのため、攻撃者へのパケットを解読することはより困難になります。

最後に、Firefoxは最後の暗号化されていないメッセージ「暗号仕様の変更」エントリを送信します。

これは、以前に渡された秘密鍵を次のメッセージに使用することをAmazonに伝えるFirefoxの方法です。

コンピューティングマスターシークレット

すべてを正しければ、双方は48バイトのプリマスターキーを認識します。プリマスターにはクライアントデータのみが含まれ、サーバーデータは含まれないため、Amazon側にはわずかな不信感があります。マスターキーを計算してこれを修正します。

master_secret = PRF（pre_master_secret、「マスターシークレット」、ClientHello.random + ServerHello.random）

PRFは、仕様で定義されている疑似ランダム関数であり、非常に注意が必要です。 HMACバージョンMD5およびSHA-1を使用します。入力の半分は各機能に送信され、結果は攻撃に対して非常に抵抗力があります。

その結果、48バイトのマスターシークレットを取得します。

4C AF 20 30 8F 4C AA C5 66 4A 02 90 F2 AC 10 00 39 DB 1D E0 1F CB E0 E0 9D D7 E6 BE 62 A4 6C 18 06 AD 79 21 DB 82 1D 53 84 DB 35 A7 1F C1 01 19

他のキーを生成する

両側にマスターシークレットがあるので、仕様に従って、PRFを使用してセッションに必要なすべてのキーを計算して、「キーブロック」を作成し、そこから必要なデータを取得します。

key_block = PRF（SecurityParameters.master_secret、「キー拡張」、SecurityParameters.server_random + SecurityParameters.client_random）;

「キーブロック」のバイトは次の場合に必要です。

client_write_MAC_secret [SecurityParameters.hash_size]

server_write_MAC_secret [SecurityParameters.hash_size]

client_write_key [SecurityParameters.key_material_length]

server_write_key [SecurityParameters.key_material_length]

client_write_IV [SecurityParameters.IV_size]

server_write_IV [SecurityParameters.IV_size]

ブロック暗号化ではなくストリーミングを使用するため、初期化ベクトルは必要ありません。ただし、MD5の結果も16バイト長なので、各側に2つのメッセージ認証コード（MAC）キーがそれぞれ16バイト必要です。さらに、RC4は16バイトのキーを使用しますが、これも両方の当事者が必要とします。一般に、キーブロックから2 * 16 + 2 * 16 = 64バイトが必要です。

PRFを実行すると、以下が得られます。

client_write_MAC_secret = 80 B8 F6 09 51 74 EA DB 29 28 EF 6F 9A B8 81 B0

server_write_MAC_secret = 67 7C 96 7B 70 C5 BC 62 9D 1D 1F 4A A6 79 81 61

client_write_key = 32 13 2C DD 1B 39 36 40 84 4A DE E5 6C 52 46 72

server_write_key = 58 36 C4 0D 8C 7C 74 DA 6D B7 34 0A 91 B6 8F A7

暗号化する準備をしてください！

クライアントが送信した最後のハンドシェイクメッセージは「最終メッセージ」です。これは、誰もハンドシェイクを偽造していないことを証明し、キーを知っていることを証明するトリッキーなメッセージです。クライアントは、ハンドシェイクメッセージからすべてのバイトを取得し、バッファに追加します。次に、擬似乱数ジェネレータ、マスターキー、「クライアント終了」行、およびバッファからのMD5とSHA-1を使用して、12バイトの確認が計算されます。

verify_data = PRF（master_secret、「client finished」、MD5（handshake_messages）+ SHA-1（handshake_messages））

結果を取得し、完了を示すバイト0x14、およびヘッダーに長さ00 00 0のバイトを追加して、12バイトを送信していることを示します。その後、今後のように、すべての暗号化されたメッセージについて、誰も解読されたコンテンツを偽造していないことを確認する必要があります。 MD5、またはむしろそのHMACバージョンを使用します。

HMAC_MD5（キー、m）= MD5（（キー⊕opad）++ MD5（（キー⊕ipad）++ m）

（⊕はXOR、++は連結、「opad」はバイト「5c 5c ... 5c」、「ipad」はバイト「36 36 ... 36」を意味します）。

一般的に、次の計算を行います。

HMAC_MD5（client_write_MAC_secret、seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment））;

お気づきかもしれませんが、リクエスト番号を混ぜて、パケットの繰り返しで特定の攻撃から保護します。

暗号化するだけです。

RC4暗号化

選択した暗号化アルゴリズムのセットは、RC4を使用するように指示します。とても簡単なので、数分で習得できます。

RC4は、256バイトの配列Sを作成し、0から255の値を入力することから始めます。その後、キーのバイトを「干渉」することによって配列を調べる必要があります。これは、ランダムバイトの生成に使用されるステートマシンを作成するために行われます。次に、配列Sを混合します。

グラフィカルには、次のように表すことができます。

バイトを暗号化するために、暗号化されるバイトと疑似ランダムバイトをXORします。

そのため、すべてが非常にシンプルで、すぐに動作します。このため、Amazonはこのアルゴリズムを選択したようです。

「client_write_key」と「server_write_key」があることを思い出してください。これは、RC4の2つのインスタンスが必要であることを意味します。1つは応答の復号化用、もう1つは要求の暗号化用です。

「client_write」からの最初のいくつかのランダムバイトは「7E 20 7A 4D FE FB 78 A7 33 ...」です。暗号化されていないヘッダーでこれらのバイトを選択し、メッセージ「14 00 00 0C 98 F0 AE CB C4 ...」のバイトを確認すると、下のWiresharkのスクリーンショットで確認できるものが得られます。

サーバーはほぼ同じことを行います。「暗号仕様の変更」を送信してから、すべてのハンドシェイクメッセージと暗号化されていない「最終」メッセージを含む「最終」メッセージを送信します。これは、サーバーがメッセージを解読できたことをクライアントに証明します。

アプリケーションレベルへようこそ！

さて、220ミリ秒後（3時間後-約Transl。）、最終的にアプリケーションレベルを使用する準備ができました。これで、通常のHTTPトラフィックを交換できます。これは、RC4を使用してTLSで暗号化され、スプーフィングの場合にチェックされます。

これでハンドシェイクが完了しました。 TLSレコードのコンテンツは現在0x17です。暗号化されたトラフィックは17 03 01から始まり、これはレコードのタイプとTLSのバージョンを示します。

パケット暗号化：

GET /gp/cart/view.html/ref=pd_luc_mri HTTP / 1.1

ホスト： www.amazon.com

ユーザーエージェント：Mozilla / 5.0（Windows; U; Windows NT 6.0; en-US; rv：1.9.0.10）Gecko / 2009060911 Minefield / 3.0.10（.NET CLR 3.5.30729）

許可：text / html、application / xhtml + xml、application / xml; q = 0.9、* / *; q = 0.8

Accept-Language：en-us、en; q = 0.5

Accept-Encoding：gzip、deflate

Accept-Charset：ISO-8859-1、utf-8; q = 0.7、*; q = 0.7

キープアライブ：300

接続：キープアライブ

...

およそ次の結果が得られます。

サーバーは同じことを行います。復号化により、以下が提供されます。

HTTP / 1.1 200 OK

日付：2009年6月10日水曜日01:09:30 GMT

サーバー：サーバー

...

接続：閉じる

転送エンコード：チャンク

接続は、どちらかの側が完了の警告メッセージを送信するまで開いたままになり、その後接続を閉じます。前の接続を閉じた後すぐに再接続する場合、古いキーを使用して、ハンドシェイクを再度実行しないようにすることができます。

アプリケーションレベルでは、絶対に何でもできることを理解することが重要です。 TLSの上で実行できる他の多くのTCP / IPベースのプロトコルがあります。たとえば、FTPS。自転車を発明するよりもTLSを使用する方が常に良いです。

それだけです！

TLS RFCは、これまで議論していない多くの詳細をカバーしています。 FirefoxとAmazon間の220ミリ秒のダンスのみを調べました。誰かがAmazonの数nをpとqに分解すると、証明書を変更するまですべてのAmazonトラフィックを解読できることを学びました。

わずか220ミリ秒で、インターネット上の2つのポイントが接続され、相互に信頼のための十分なデータが提供され、暗号化アルゴリズムが設定され、暗号化されたトラフィックの交換が開始されました。

そして、ボブが牛乳を買うことができるように。

HTTPS接続の最初の数ミリ秒