WiresharkにSSLハンドシェイクが表示されない
私の組織では、ループバックアドレスで機能するクラウドプロキシを使用しています。このプロキシのベンダーは、ループバックアドレスをリッスンするマシンにアプリをデプロイしています。
Wiresharkでアプリのトラフィックをキャプチャしました。以下で確認できます。
また、ラップトップの実際のインターフェイスであるwifiインターフェイスまたはアダプターのトラフィックもキャプチャしました。以下のキャプチャを見ることができます：
Wifiインターフェースで、送信されている「HTTP接続」パケットがプロキシデバイスとして完全に正常であることを確認できますが、問題はクライアントhelloとサーバーhelloを表示できないことです。または他のSSLハンドシェイクパケット。したがって、これらのパケットは暗号化されたトラフィックですが、どこに送信されているのかを知りたいのです。
また、追加情報：このアプリは、サーバーまたはクラウド（プロキシ）への暗号化されていないHTTPマイクロトンネルを作成し、これらのマイクロトンネルでトラフィックが送信されますが、私のFacebook（アプリケーションがSSLパケットなしで送信される暗号化されたトラフィックです） SSLハンドシェイクパケットを作成しており、これらのマイクロトンネルはすべてのセッションで作成されています）
「誤動作している」pcapには、ポート443のHTTPプロキシトラフィック、つまり、HTTP CONNECTリクエストとレスポンスが前に付いたHTTPSトラフィックのキャプチャがあります。ただし、ポート443は直接HTTPS用に予約されており、プロキシされたHTTPS用ではありません。
Wiresharkは、なんらかの理由で、このポートでの直接HTTPS（ポートの一般的な使用方法）であるか、SSLとはまったく関係がないと主張しているようです。したがって、HTTPプロキシ要求と応答を検出しますが、設定で明示的に指定されていても、残りをSSLとしてデコードすることを拒否します。この動作を変更する方法は見つかりませんでした。
tcprewrite を使用してpcapのポート443を他の何か（4433など）に書き換えると、問題は魔法のように消え、SSLプロトコルの詳細が表示されます。したがって、それはすべてWiresharkの奇妙な動作が原因であり、データ自体の問題ではありません。
Wiresharkの最新バージョンでも同じ問題が発生しました（古いバージョンでも動作します）。私が見つけた一時的な回避策は、TCPソースポート、あなたのケースでは55655のHTTPを「デコード」することです。その後、TLS情報は期待どおりに表示されるはずです。