/
843.txt
100 lines (70 loc) · 5.54 KB
/
843.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
[2] [DFN[[[closure alert]]]] は、 [[TLS]] の[[接続]]を閉じることを表す[[メッセージ]]です。
[CODE[[[AlertDescription]]]] の値 [DFN[[CODE[[[close_notify]]]]]] ([CODE[[[0]]]]) は、
[[closure alert]] を表します。
* 仕様書
[REFS[
- [1] [CITE@en[RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2]] ([TIME[2015-02-19 08:58:15 +09:00]] 版) <http://tools.ietf.org/html/rfc5246#section-7.2.1>
]REFS]
* プロトコル
[3] [[クライアント]]と[[鯖]]は、[[truncation attack]] の防止のため、
[[接続]]を終える旨を共有しなければなりません [SRC[>>1]]。
[[closure alert]] ([CODE[[[AlertDescription]]]] = [CODE[[[close_notify]]]] ([CODE[[[0]]]])
の[[メッセージ]]) をこれに用います。他の [[fatal alert]]
を転送した場合を除き、[[クライアント]]や[[鯖]]は、[[接続]]の書き込み側を閉じる前に
[CODE[[[close_notify]]]] [[alert]] を送信する必要があります [SRC[>>1]]。
[6] [CODE[[[close_notify]]]] [[alert]] は、送信者が当該[[接続]]においてそれ以上は[[メッセージ]]を送らないことを意味します
[SRC[>>1]]。[[クライアント]]と[[鯖]]のどちらから送信しても構いません
[SRC[>>1]]。
[5] [[closure alert]] より後に受信したデータは、無視します [SRC[>>1]]。
[7] [[closure alert]] を受信したら、 [CODE[[[close_notity]]]] [[alert]]
を返送すると共に、直ちに[[接続]]を閉じ、書き残したものがあれば捨てなければ[['''なりません''']] [SRC[>>1]]。
[8] [CODE[[[close_notify]]]] を先に送った側は、返送の到着を待たずに[[接続]]の読み込み側を閉じて構いません [SRC[>>1]]。
[[TLS]] を使う[[応用プロトコル]]が [[TLS]] が閉じられた後に下位の[[輸送路]]を使ってデータを転送する場合には、
[[TLS]] の[[接続]]が閉じられたと[[応用プロトコル]]側に通知するのは
[CODE[[[close_notify]]]] [[alert]] が返送された後としなければなりません [SRC[>>1]]。
[[応用プロトコル]]がそれ以上データを転送せずに下位の[[輸送路]]を閉じるだけの場合には、
[CODE[[[close_notify]]]] [[alert]] の返送を待たずとも構いません [SRC[>>1]]。
[4] [[接続]]を正しく閉じることに失敗しても、[[TLSセッション]]を[[再開]]することを妨げるものではありません [SRC[>>1]]。
;; [12] これは [[TLS/1.0]] から [[TLS/1.1]] での仕様変更 [SRC[>>1]] ですが、
それ以前から既にそのような実装がなされていた [SRC[>>1]] ようです。
;; [13] [[error alert]] の場合は、[[TLSセッション]]の[[再開]]は禁止されています。
[11] [[alert level]] は [[closure alert]] では無視されるようです。
* 応用
[9] [[アプリケーション層プロトコル]]は、 [[TLS]] を使う場合に [[closure alert]]
との関係 (どのタイミングで [[closure alert]] を送信するのか、 [[closure alert]]
を受信した場合に[[アプリケーション層プロトコル]]側でどうエラー処理するのか、
[[TLS]] より下の層の[[プロトコル]]の[[接続]]を閉じるタイミングなど)
を規定する必要があります。
;; [10] 例えば [[RFC 2818]] は [[HTTPS]] における取り扱いを規定しています。
[FIG(quote)[
[FIGCAPTION[
[14] [CITE[Issue 244260 - chromium - Security: TLS Truncation attack on HTTP headers, including cookie flags - An open-source project to help move the web forward. - Google Project Hosting]]
([TIME[2015-07-04 16:53:26 +09:00]] 版)
<https://code.google.com/p/chromium/issues/detail?id=244260>
]FIGCAPTION]
> Requiring close_notify isn't possible because so many sites don't send it
]FIG]
[FIG(quote)[
[FIGCAPTION[
[15] [CITE[Issue 244260 - chromium - Security: TLS Truncation attack on HTTP headers, including cookie flags - An open-source project to help move the web forward. - Google Project Hosting]]
([TIME[2015-07-04 16:55:54 +09:00]] 版)
<https://code.google.com/p/chromium/issues/detail?id=244260>
]FIGCAPTION]
> However, like all other browsers, it doesn't implement the mandatory TLS closure alert enforcement from TLS 1.1 to prevent truncation attacks at the transport layer.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[16] [CITE[SSL / TLS: Is a server always required to respond to a close notify? - Information Security Stack Exchange]]
([TIME[2015-09-07 11:27:14 +09:00]] 版)
<http://security.stackexchange.com/questions/82028/ssl-tls-is-a-server-always-required-to-respond-to-a-close-notify>
]FIGCAPTION]
> For example, https://www.oracle.com sends the close notify as I expect it, but https://www.google.com does not - it just closes the connection after my app sends the close notify.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[17] [CITE[SSL / TLS: Is a server always required to respond to a close notify? - Information Security Stack Exchange]]
([TIME[2015-09-07 11:27:14 +09:00]] 版)
<http://security.stackexchange.com/questions/82028/ssl-tls-is-a-server-always-required-to-respond-to-a-close-notify>
]FIGCAPTION]
> OpenSSL, and thus implementations based on OpenSSL (clients and server), tend to no longer send close_notify messages; they just drop the connection. The main reason is that in existing Web servers and clients, connections are managed in a pool that closes them after some inactivity delay; that pool manages low-level sockets and has no notion of what SSL could be; thus, the SSL layer has no way to send (or wait for) an explicit close_notify.
]FIG]