/
108.txt
205 lines (149 loc) · 10.9 KB
/
108.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
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
[1] [DFN[[[クライアント認証]]]]は、 [[TLSクライアント]]から [[TLSサーバー]]へ[DFN[[[クライアント証明書]]]]を送信することで[[サーバー]]において[[認証]]を行う[[認証方式]]です。
[34] [[HTTPS]] で使われることが多いですが、それ以外でも [[TLS]]
を使う[[アプリケーション]]で利用できます。
* プロトコル
[FIG(short list)[
- [[TLS [CODE[Certificate]]]]
- [[TLS [CODE[CertificateRequest]]]]
- [[TLS [CODE[CertificateVerify]]]]
- [[証明書]]
- [[秘密鍵]]
- [CODE(MIME)@en[[[application/x-x509-user-cert]]]]
- [CODE(HTMLe)@en[[[keygen]]]] [[要素]]
- [CODE(DOMm)@en[[[importUserCertificates]]]]
]FIG]
** 再折衝
[29] [[クライアント認証]]は、 [[TLS handshake]] で[[サーバー]]からの要求に応じて[[クライアント]]が[[サーバー]]へと[[証明書]]を送信するものです。
[30] この [[TLS handshake]] は、 [[TLS]] を開始する最初のものであっても構いませんし、
その後の任意のタイミングで行っても構いません ([[再折衝]])。
[EG[
[31] [[Apache]] の [[mod_ssl]] は [[HTTP]] [[応答]]を返すに当たり、
[[ディレクトリー]]ごとに[[クライアント認証]]の設定を行うことができます。
[[要求]]の処理の時点でその[[ディレクトリー]]に必要な[[クライアント証明書]]を受け取っていないことに気づいたら、
[[サーバー]]は[[クライアント]]に対して[[再折衝]]を求めます。
[[クライアント]]が適切な[[証明書]]を提示できれば、
[[サーバー]]は[[応答]]を送ります。
[32] [[サーバー]]がどのように[[クライアント認証]]を行うかは[[ディレクトリー]]がわかるまで決められませんが、
どの[[ディレクトリー]]へのアクセスなのかは [[HTTP要求]]を受信するまでわかりません。
[[HTTP要求]]を受信するためには最初の [[TLS handshake]]
は終わっている必要があります。つまりこの [[Apache]] の方法を実現するには、
[[再折衝]]を使うしかありません。
]EG]
[33] [[クライアント認証]]のための[[再折衝]]は、上位のプロトコルで適当なタイミング
([[HTTP要求]]を受信して[[HTTP応答]]を送る前など) で行われるのが普通ですが、
[[TLS]] と上位のプロトコルとの間でこのタイミングを調整する方法はないので、
それは保証されません。
;; >>27 のように扱いは実装によります。
* 文脈
[2] 多くの [[Webブラウザー]]や、その他の[[HTTPS]] [[クライアント]]が対応しています。
[3] 公開された [[Webサイト]]では滅多に使われませんが、組織内等の[[イントラネット]]系
[[Webアプリケーション]]ではしばしば用いられています。
* 証明書データベース
[13] 多くの [[Webブラウザー]]は[[証明書データベース]]に[[クライアント証明書]]と[[秘密鍵]]
(および[[ルート証明書]]や必要があれば[[中間証明書]]) を保持しています。
[14] [[PKCS #12]] などのファイルを手動で[[利用者]]が追加することもできますし、
[CODE(HTMLe)@en[[[keygen]]]] および[[証明書ダウンロード]]により半自動で追加することもできます。
;; [[証明書データベース]]参照。
[15] [[TLSクライアント]]は、[[サーバー]]から[[クライアント証明書]]を要求された場合、
その条件に該当する[[証明書]]が見つかればそれを送信します。
;; 要求は [CODE[[[CertificateRequest]]]] [[メッセージ]]により行います。
送信するべき[[証明書]]の条件もそこに記述されています。
[36] 実装上は[[クライアント証明書]]のことを[[個人証明書]]などと呼ぶようです。
* ダイアログ
[20] [[Webブラウザー]]は[[クライアント証明書]]の求めがあると、
[[モーダルダイアログ]]を表示します。これは初回の [[handshake]] だけでなく、
[[再折衝]]であってもです。[[ダイアログ]]では利用可能な[[証明書]]のリストか、
[[証明書]]なしを選ぶことができます。
[23] ただし利用できる[[証明書]] (サーバーが指定した条件に合致する[[個人証明書]]) がまったくなければ、自動的に[[証明書]]なしとなります。
[22] [[Webブラウザー]]は[[証明書]]の選択 (または無選択) を記憶しています。
[[Firefox]] は[[ホスト名]]ごとに覚えているようです。
[[Chrome]] と [[IE]] は[[ホスト名]]と[[ポート番号]]の組ごとに覚えているようです。
[TIME[2015-09-07T13:59:17.00Z]]
[21] [[Firefox]] では、記憶させずにその場限りで選択するオプションが[[ダイアログ]]に表示されます。
[24] 一旦記憶させるとその後ずっと (認証失敗しても) 同じものを選択し続けます。
[25] [[Firefox]] では[[サーバー]]から求められた「組織」と「発行者」がダイアログに表示されます。
[26] 選択後、まだ接続が有効なら、そのまま選択した[[証明書]]を使って処理を継続します。
接続が既に無効になっていれば、改めて接続します。そちらで[[サーバー]]が[[証明書]]を要求して来れば、
記憶している選択された[[証明書]]を使います。
[27] [[Chrome]] は[[HTTPヘッダー]]後の[[空行]]より前で[[再折衝]]があればダイアログを表示し、
それ以降なら[[ネットワークエラー]]として扱うようです。[[本体]]終了後なら無視するようです。
[[Firefox]] と [[IE]] は[[本体]]終了後も含めてどこであってもダイアログを表示するようです。 [TIME[2015-09-07T15:55:14.800Z]]
[28] [[Firefox]] で選択を記憶させないようにすると、同じ[[要求]]の処理中の複数回の[[再折衝]]でもそれぞれダイアログを表示するように見えます。 [TIME[2015-09-07T16:03:35.000Z]]
* 関連
[4] [[OAuth 2.0クライアント認証]]とは無関係です。
* メモ
[16] [[TLSクライアント認証]]は[[利用者]]に[[パスワード]]を入力させる必要がないという意味で安全な[[認証]]方式です。
[17] [[TLSクライアント認証]]は[[証明書]]の管理が必要という点で、
[[利用者]]にとってはハードルが高いかもしれません。 [CODE(HTMLe)@en[[[keygen]]]]
と[[証明書ダウンロード]]を使うと[[利用者]]がほとんど意識することなく
[[Webブラウザー]]に[[証明書]]と[[秘密鍵]]の管理を委ねられますが、
他の [[Webブラウザー]]を使ったり、他の[[装置]]上で動作する [[Webブラウザー]]を使ったりしたい時に、
[[証明書]]と[[秘密鍵]]を安全に共有することは平均的な[[利用者]]には困難かもしれません。
[18] [[HTTP認証]]や[[クッキー認証]]では、[[認証]]失敗時の [[HTTP応答]]で[[アカウント登録]]や[[パスワード]]の再発行などの回復手段を案内することができます。
しかし [[TLSクライアント認証]]は [[TLS]] のセッション開始前に接続を閉じてしまうため、
同様の案内の機会がありません。
そのため [[Webブラウザー]]は一般的な認証エラーの表示しか行えません。
;; [19] 理論上は[[TLSサーバー]]は認証に失敗しても未認証状態で接続を継続し、
[[HTTP応答]]等の方法でエラーを伝えることはできます。しかしそのような利用方法が実際になされているのかどうかは不明です。
[EG[
[35] [[Apache]] には[[クライアント証明書]]を必須とするオプションの他に、
[[証明書]]の提示は求めるが必須とはしないオプションもあります。
[[証明書]]の有無により異なる[[応答]]を返すことにすれば、
認証エラーの表示を行えます。
]EG]
[5] [CITE@en[RFC 4681 - TLS User Mapping Extension]]
([TIME[2015-02-01 19:05:39 +09:00]] 版)
<http://tools.ietf.org/html/rfc4681>
[FIG(quote)[
[FIGCAPTION[
[6] [CITE[Transport Layer Security (TLS) Parameters]]
([TIME[2015-02-27 12:03:35 +09:00]] 版)
<http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-14>
]FIGCAPTION]
>
> CSV
> table-tls-parameters-14-range
> Range Registration Procedures
> 0-63 Standards Action
> 64-223 Specification Required
> 224-255 Reserved for Private Use
]FIG]
[7] [CITE@ja[Chrome 搭載デバイスのクライアント証明書を管理する - Chrome for Business ヘルプ]]
([TIME[2015-04-14 13:47:25 +09:00]] 版)
<https://support.google.com/chrome/a/answer/6080885?hl=ja>
[8] [CITE[chrome.platformKeys - Google Chrome]]
([TIME[2015-04-14 13:48:42 +09:00]] 版)
<https://developer.chrome.com/extensions/platformKeys>
[9] [CITE[chrome.enterprise.platformKeys - Google Chrome]]
([TIME[2015-04-14 13:48:50 +09:00]] 版)
<https://developer.chrome.com/extensions/enterprise_platformKeys>
[10] [CITE[Developer Guide: Certificate Management Extension API on Chrome OS - The Chromium Projects]]
([TIME[2015-04-14 09:20:04 +09:00]] 版)
<http://www.chromium.org/administrators/certificate-management-extension-api-on-chrome-os>
[11] [CITE@ja[クライアント証明書の登録方法 | サイボウズ製品 マニュアルサイト]]
([TIME[2014-08-16 02:59:55 +09:00]] 版)
<https://manual.cybozu.co.jp/tech/webbrowser/certificate.html>
[12] [CITE@en[draft-agl-tls-encryptedclientcerts-00 - Transport Layer Security (TLS) Encrypted Client Certificates]]
([TIME[2015-01-27 14:46:10 +09:00]] 版)
<https://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00>
[FIG(quote)[
[FIGCAPTION[
[37] [CITE@en[RFC 6546 - Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS]]
([TIME[2016-01-08 21:27:35 +09:00]] 版)
<https://tools.ietf.org/html/rfc6546>
]FIGCAPTION]
> RID systems MUST use mutual authentication; that is, both RID systems
> acting as HTTPS clients and RID systems acting as HTTPS servers MUST
> be identified by an X.509 certificate '''['''RFC5280''']'''. Mutual
> authentication requires full path validation on each certificate, as
> defined in '''['''RFC5280''']'''.
]FIG]
[38] [CITE@en[Keygen and Client Certificates]]
([TIME[2015-12-01 07:01:19 +09:00]] 版)
<https://w3ctag.github.io/client-certificates/>
[39] [CITE@en[Fix #222: no credentials, no TLS client certificate · whatwg/fetch@bef06e1]]
([TIME[2016-03-15 11:36:54 +09:00]] 版)
<https://github.com/whatwg/fetch/commit/bef06e11e3b3b7589d23c0c892057c5cd5174c2a>
[40] [CITE@en[21013 – Credentials and HTTP authentication]]
([TIME[2016-03-15 11:41:02 +09:00]] 版)
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=21013>