fatal alert message

Edit New

fatal alert message

[12] error alert は、 TLS における誤り (エラー) を通知するメッセージです。

仕様書

プロトコル

[2] TLS Handshake protocol では、誤りを検出したら、相手に対してメッセージを送信します >>1。誤りには致死的 (fatal) なものと、そうでないものがあります。 fatal alert と定義されている条件に遭遇したら、接続を閉じる前に適切な alert を送信しなければなりません >>1。 alert level が明示的に規定されていない誤りについては、 誤りの送信者が fatal か否かを決定できます >>1。 alert を送信する場合で、 その直後に接続を閉じるつもりの場合は、 fatal alert level で alert を送信しなければなりません >>1。

[3] fatal alert message を送信または受信したら、直ちに接続を閉じます。 鯖およびクライアントは、失敗した接続に関するセッション識別子、鍵、秘密をすべて忘れなければなりません。 よって fatal alert によって終了した接続を再開してはなりません。 >>1

[11] closure alert とは違って alert を返送する必要は無いようです。

[4] alert level が警告の alert を送信または受信したら、通常は接続は通常通り継続できます。 受信者が接続を継続しないことにした場合は、接続を終える fatal alert を送信するべきです。 >>1

[5] 警告の後受信者がどうするか送信者は事前に予測できませんから、送信者が接続を継続したい時に警告を送信するのは好ましくないこともあり、 そのため省略される場合もあります。例えば証明書が満期していても接続を継続したい場合、 certificate_expired alert は送信しません。 >>1

[19] Firefox は証明書エラーで fatal alert を送った後、 RST するようです。 Chrome は普通に FIN で閉じるようです。

alert の種類

[6] error alert の種類には次のものがあります。

[23] error alert 種別

[7] IANA登録簿も用意されています。

[8] close_notify (0) は closure alert に分類されていて、 error alert とは別の処理が規定されています。

応用

[13] TLS を使うアプリケーション層プロトコルは、 TLS の接続が誤りにより閉じられた際の処理 (何らかの方法で復帰する、更に上位の層に誤りを通知するなど) を規定する必要があります。

[14] 例えば RFC 2818 は HTTPS に関する処理を規定しています。

[16] HSTS は TLS 接続時に誤りや警告があれば、 HSTS の指定を無視すると規定しています。

メモ

[17] Web Security Context: User Interface Guidelines ( 版) <http://www.w3.org/TR/wsc-ui/#sec-tlserrors>

[18] OpenSSL (OpenSSL Foundation, Inc. 著, 版) <https://www.openssl.org/docs/manmaster/ssl/SSL_alert_type_string.html>

Updated: