HTTPS通信がSSLハンドシェイク終了後に切断される

Question

前提・実現したいこと

TLS1.2の通信をwiresharkでキャプチャしたのですが、切断の原因が分かりません。

2019/1/9 追記
SSLハンドシェイクは正常に終了しているように見えます。
サーバー側から"finished"を送信し、一度"Application Data"のやりとりをした後、SSLが切断されます。
どのような原因が考えられますでしょうか？
お手数ですが御教授ください。

発生している問題・エラーメッセージ

TLSv1.2のパケットを順に見ていくと、

Client Hello
Server Hello, Certificate, Server Hello Done
Client Key Exchange, Change Cipher Spec, Finished
New Session Ticket, Change Cipher Spec, Finished
Application Data
Alert
Alert
Alert
Alert

となり、また先頭のClient Helloからを繰り返す状況です。

Alertの中身は以下の画像の通りになっていました。
close_notifyが送信された原因は何でしょうか？
SSLハンドシェイクが終了しているので、正常に通信が継続されるはずではないでしょうか？

![]

お手数ですが御教授よろしくお願いします。

Answer 1

えーと。
どの部分の何が問題と思われているのでしょうか？

---

画像を見ると

Alert Message
Level: Warning
Description: close_notify

とあります。

この内容について、TLS Protocol の仕様書である The Transport Layer Security (TLS) Protocol Version 1.2 (RFC5246) の日本語訳である
7. TLS ハンドシェイク関連プロトコル より引用すると

7.2.1. Closure アラート English
クライアントおよびそのサーバは、「そのコネクションは、truncation 攻撃を避けるために終了する」という知識を共有しなければならない。いずれの主体も、closing メッセージの交換を開始する可能性がある。

close_notify
このメッセージは、「その送信者は、これ以上、このコネクション上のメッセージを送らないこと」 を、その受信者宛に通知する。 「TLS 1.1 においては、 コネクションを正しく閉じることの失敗は、もはや、セッションが中断（resume）されないことを要求しないこと」に注意。これは、広範な実装実践を確保するための TLS 1.0 からの変更点である。

両者は、close_notify アラートを送ることによって閉鎖を開始する可能性がある。closure アラートの後、受け取られた、いかなるデータ も、無視される。

と規定されています。

「warning レベルの close_notify メッセージ」なので、コネクションの終了を通知する正常なやりとりと思いますが...

通信の内容に疑問点があれば、プロトコルの仕様書を読みましょう。

Comments

[ma-yu]

ご回答ありがとうございます。
なぜclose_notifyが送信されたのかが知りたいです。
SSLハンドシェイクが終了しているので、暗号化通信が開始されるはずではないでしょうか？
close_notifyは「これ以上、このコネクション上のメッセージを送らないこと」とありますが、何が原因で送信されているかは追いかけることができないのでしょうか？

[CHERRY]

HTTPS の話ですよね？

HTTPS 通信は、基本的に「TCP接続 → SSL/TLSハンドシェイク → クライアントからのリクエスト → サーバのレスポンス → 切断」が、1つの単位です。ただし毎回接続／切断していると接続の負荷が高いので、通常は、Keep-Alive の設定をして設定した時間コネクションが継続する(サーバー側から切断しない)ように設定します。

ログの詳細が不明ですが、提示された内容だけで判断すると「ハンドシェイク」して「Application Data」の送信(or受信)が終わったので、どちらかがコネクションは不要として、「close_notify」を送信しているのだと思います。

何が原因で、「close_notify」を送信してコネクションを切断しているかは、WebブラウザやWebサーバーの内部処理になると思いますので、パケットモニタ上で追いかけることは難しいでしょう。

たとえば、Webサーバー側から `close_notify` を送信しているのであれば、
まず、Webサーバーの設定を確認する。
そして、Webサーバーで詳細なデバッグログを出力させて送受信した内容を確認する。
それでもわからなければ、最終的には、Webサーバーのソースコードを順に追いかけて調べることになると思います。

[ma-yu]

パケットからは分からない理由で停止要求が出ているのですね。パケットで全て分かるものだと勘違いしておりました。
close_notifyの原因をパケットから探っていくと、クライアント側が暗号データを送信するはずのタイミングでTCPのSYNパケットを送信していることがわかりました。そこからサーバがACK,RSTを返して、close_notifyと繋がっているようです。
クライアントの設定を見直してみます。
ありがとうございました。