多くのクライアントがSSLを使用して接続するサーバーがあります。最近、サーバーログでSSLハンドシェイクエラー(SSL MACエラーなど)を観察しています。エラー自体は重要ではありませんが、なぜ一部のクライアントが接続できて他のクライアントが失敗するのか、またどのクライアントが失敗しているかを特定する必要があるのかを知りたいです。
この問題をデバッグするために、サーバーで発生するすべてのSSLハンドシェイクをキャプチャします。問題のあるクライアントがいつ接続するかわからないため、それが発生するまですべてのトラフィックをキャプチャしません。すべてのSSLハンドシェイクをキャプチャし、後でWiresharkで分析したいだけです。私はtcpdumpにのみアクセスでき、他のキャプチャ用ツールはないと仮定します。
あなたが何をハンドシェイクと呼んでいるのか正確にはわかりませんが、おそらくあなたが望むものの95%以上をキャプチャするこのコマンドを提案します:
_tcpdump -ni eth0 "tcp port 443 and (tcp[((tcp[12] & 0xf0) >> 2)] = 0x16)"
_
今、それは何をしますか:
_tcp[12]
_は、tcpパケットの13番目のバイトをキャプチャすることを意味します。これは、前半がオフセットで、後半が予約されていることに対応します。オフセットに4を掛けると、TCPヘッダーのバイトカウント、つまり_((tcp[12] & 0xf0) >> 2)
_がTCPヘッダーのサイズを提供します。
TLSパケットの最初のバイトは、コンテンツタイプを定義します。値22(16進数で0x16)は、「ハンドシェイク」コンテンツとして定義されています。
結果として、tcp[((tcp[12] & 0xf0) >> 2)] = 0x16
は、TCPヘッダーが_0x16
_に設定された後の最初のバイトを持つすべてのパケットをキャプチャします。
さらにフィルタリングを実行できますが、これはあなたの質問に厳密に答えます。
受け入れられた答えは、脆弱なソリューションによる時期尚早な最適化だと思います。
SSLハンドシェイクは、接続が確立されるとすぐに発生します。
簡単なアプローチ:クライアントがリモートホストに接続する前にキャプチャを開始し、最初の完全なNパケットをキャプチャします。
たとえば、300パケットの場合:
/ usr/sbin/tcpdump -i eth0 -p -s 65535 -c 300 "tcpおよびホスト1.2.3.4およびポート443"
このように、wiresharkはSSLハンドシェイクの完全なペイロードを持ち、それをデコードしてすべてのビットを表示できます。