TLS セッションを開始した後にサーバーが FIN を実行するのはなぜですか?

Question

TLS サーバーが、理解できない動作を実行しています。

1. TCP ハンドシェイクは正常に実行されます。
2. SSL クライアント Hello は正常に実行されます。
3. SSL Server Hello は正常のようです。証明書が提供され、Server Hello 完了と表示されます。
4. 解析により、クライアントの問題「クライアント キー交換、暗号仕様の変更、暗号化されたハンドシェイク メッセージ」が表示されます。
5. 解析により、サーバーが「暗号仕様の変更」と「暗号化されたハンドシェイクメッセージ」を発行していることが示される

クライアントは ACK を送信し、データの送信を開始します。ただし、サーバーは ACK を送信した後、「暗号化されたアラート」を送信し、FIN を送信します。

これは、証明書を交換した直後に発生しました。SSL ハンドシェイクで提示された証明書が新しいキーです。

誰か手がかりはありますか?

Answer 1

これはおそらく、クライアントまたはロードバランサーなどの中間のデバイスの SNI の問題が原因です。ロードバランシングデバイスは、最初の Client Hello の一部としてバックエンドホストにサーバー名を提示できる必要があります。https://en.m.wikipedia.org/wiki/サーバー名表示

Answer 2

最も重要なパケットは「暗号化されたアラート」であり、これには接続が閉じられた理由が含まれています。

検証エラーのようです。これは証明書が信頼されていないか無効であることを意味します。しかし、本当の理由は、TLSアラートプロトコル

Answer 3

pure-ftpd明示的な TLS モード (FTPS サーバー)でも同様の問題が発生しました。

しかし私の場合はいいえ Encrypted Alertサーバーから送信され、鍵交換後すぐにFinされました（Change Cipher Spec, Finishedサーバーからのメッセージ → サーバーからのFIN）。次に、クライアントEncrypted alertレベル 1 コード 0を送信しましたClose Notify(サーバー FIN とは異なり、これは予想どおりです)。

これは特定のクライアント (デバイス ファームウェア) でのみ発生し、他の FTP クライアントでは再現されませんでした。

問題の根源を解明したわけではないが、サーバーのバグ. pure-ftpdApacheのような接続ごとのフォークモデルを使用しています。そして私は観察しました子プロセスがクラッシュするgdb では (コード -1 で終了)、当然ながら OS はソケット FD を閉じて FIN を送信します。

私の場合、これがサーバーのバグであると言えるもう 1 つの理由は、FTP サーバーを別の実装に交換するとすぐに、動作が再現されなくなったことですproftpd。

---

これは OP のケースとは一致しないと思います。サーバーは TLS に適した方法で、暗号化されたアラートを使用して接続を終了しますが、それでも、このページにアクセスするすべてのユーザーが考慮すべき事項です。