そもそも『SSL/TLS』とは何かを説明するのに、通信手順解析をするサイトを見つけました。
*******************************************************************
*** Mike's Toolbox Enhanced Multi-Threaded SSL/TLS Test Server ***
*** ***
*** https://www.mikestoolbox.net/ ***
*** https://www.mikestoolbox.org/ ***
*** ***
*** Contact info: ***
*** ***
*** WEB: http://mikestoolbox.com/ ***
*** ***
*** Copyright (c) 2010-2015 Michael D'Errico, ***
*******************************************************************
このサイトは米国のジョージア州アトランタにあります。
※ サイト証明書の有効期限に問題がある可能性があるようですが。。。
そこでウェブ魚拓との間で通信させて、実際のやり取りを見てみる事にとしました。
通常のＨＴＴＰ通信であれば、『このページデータを下さい』と要求すると
サーバー側は『要求されたページデータはこれです』と返してくるだけですけど、
ＨＴＴＰＳ通信の場合は、通信の内容を複雑に暗号化しますので、
ＨＴＴＰ通信のような単純な手順ではないのです。
パソコン側がページデータの要求を始める点では同じですけど、
最初にホスト側と暗号化された通信の手順を確認することから始めます。
最初はきっちりと暗号化されているわけではなく、パソコン側がホスト側へ
『こんにちわ！』と呼び掛けて、ホスト側からの応答を得ます。
応答があれば、パソコン側からランダムに作成された暗号鍵と、
パソコン側のソフトウェアで準備してある暗号化の方式を一覧にしてホスト側へ送ります。
例えば、ウェブ魚拓（パソコン側に見立ててあります）からは、
ランダム作成された暗号鍵（Client Random）と、
暗号化の方式（Client Cipher Suites）のうちパソコン側で利用できるものすべてを
ホスト側へ送ります。
Client Version: TLS 1.2
Client Random: B405A011FCF38A9B6274379EBB9F84A0564BB0960226754417970B07E884682F
Client Session ID:
Client Cipher Suites: C030 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
C02C TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
C028 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
C024 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
（一部省略）
00A2 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
009E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
0067 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
0040 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
009A TLS_DHE_RSA_WITH_SEED_CBC_SHA
0099 TLS_DHE_DSS_WITH_SEED_CBC_SHA
（一部省略）
0005 TLS_RSA_WITH_RC4_128_SHA
0004 TLS_RSA_WITH_RC4_128_MD5
0015 TLS_DHE_RSA_WITH_DES_CBC_SHA
0012 TLS_DHE_DSS_WITH_DES_CBC_SHA
0009 TLS_RSA_WITH_DES_CBC_SHA
ここで暗号化の方式は『_WITH_』の次に示される部分で、
『AES_256』、『AES_128』、『RC4_128』、『DES_CBC』など、多数の方式の中から、
誤りがないかを確認する計算式（ハッシュ）として『SHA384』、『SHA256』、『SHA』など
組み合わせで送り、ホスト側で利用できる組み合わせを選んでもらうのです。
ここまでパソコン側から送り終えるとホスト側からの応答待ちです。
するとホスト側（この事例では米国側）で利用できる暗号化の方式などを送り返してきます。
Server Version: TLS 1.2
Server Random: 77F5D881F9A9C3407601ED8BB9498C8E4C6927172861617D3CCDD031DA312318
Server Session ID:
Server Cipher Suite: 009E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Server Compression: NULL
Server Name Chosen: www.mikestoolbox.net
Session Ticket: 264 Bytes
Renegotiation Info: Empty
ここまで揃ったら、始めてパソコン側は『このページを下さい』と言えるようになり、
ホスト側からページのデータを受け取れることになるのです。
もちろん、パソコン側が『このページを下さい』と要求する通信電文も、
ホスト側から送られてくるページのデータも、最初の通信確立の中で取り決めした
暗号化の方式や暗号鍵を使って高度に暗号化されますので、
途中から盗み見たり、通信の片方だけの内容を拾っても解読できません。
しかし、最初からこの手順を両方ともに盗み見されてしまうと全部があからさまとなり、
どんなに頑張ってもセキュリティは確保できません。
このように複雑な手順を利用しますから、ブラウザ側で準備してある暗号化の方式と
ホスト側で準備してある暗号化の方式が一致しないと、接続そのものができなくなります。
今回も他の変更と同様に実施の公表から実施までの期間があまりにも短いため、
悪質ブログの検出プログラム変更が間に合わない可能性があります。
すでにいくつかの暗号化の方式や誤り計算式（ハッシュ）については
プログラミングしてありますけど、それが利用できる保証もなく、
実際に常時SSL化が始まらないと確認ができないことも多いのです。
実際、米国のサイトでは国外秘とされている暗号化が使われていたこともあります。
可用性を失うだけの技術は、問題が大きい無線系統で処置して欲しいんですけどね。
|
ブログ／記事の閲覧者総数 ： 
こちらに
スパム対策に関するお知らせ 
記事と無関係な連続コメント、複数トラックバックは無条件削除します 
