/
862.txt
159 lines (115 loc) · 7.93 KB
/
862.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
[21] [DFN[OCSP]] は、[[証明書]]の[[失効][revoke (証明書)]]の有無を確認するための[[プロトコル]]です。
* プロトコル
[20]
[FIG(short list)[
- [[OCSPサーバー]]
- [[OCSPクライアント]]
- [[OCSP要求]]
- [[OCSP応答]]
- [[OCSP Stapling]]
]FIG]
* メモ
[1] [CITE@en[RFC 6960 - X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP]]
([TIME[2015-03-09 19:35:19 +09:00]] 版)
<http://tools.ietf.org/html/rfc6960>
[2] [CITE@en[ImperialViolet - Revocation checking and Chrome's CRL]]
([[Adam Langley]] 著, [TIME[2015-03-21 15:52:01 +09:00]] 版)
<https://www.imperialviolet.org/2012/02/05/crlsets.html>
[3] [CITE@ja[Online Certificate Status Protocol - Wikipedia]]
([TIME[2015-03-20 16:10:52 +09:00]] 版)
<http://ja.wikipedia.org/wiki/Online_Certificate_Status_Protocol>
[4] [CITE@en[CA:ImprovingRevocation - MozillaWiki]]
([TIME[2015-03-21 11:05:17 +09:00]] 版)
<https://wiki.mozilla.org/CA:ImprovingRevocation>
[5] [CITE@en-US[Revoking Intermediate Certificates: Introducing OneCRL | Mozilla Security Blog]]
([TIME[2015-03-21 15:31:36 +09:00]] 版)
<https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/>
[FIG(quote)[
[FIGCAPTION[
[6] [CITE@en[Necko/Differences - MozillaWiki]]
([TIME[2015-03-21 17:34:27 +09:00]] 版)
<https://wiki.mozilla.org/Necko/Differences>
]FIGCAPTION]
> Other browsers implement persistent OCSP caches, but we do not (for various reasons).
]FIG]
[7] [CITE@en[157555 – OCSP tracking bug]]
([TIME[2015-03-21 22:53:11 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=157555>
[8] [[OCSP stapling]]
[9] [CITE@en[ImperialViolet - No, don't enable revocation checking]]
( ([[Adam Langley]]著, [TIME[2016-05-09 20:48:57 +09:00]]))
<https://www.imperialviolet.org/2014/04/19/revchecking.html>
[FIG(quote)[
[FIGCAPTION[
[10] [CITE@en-US[Improving Revocation: OCSP Must-Staple and Short-lived Certificates | Mozilla Security Blog]]
( ([TIME[2016-05-09 21:15:03 +09:00]]))
<https://blog.mozilla.org/security/2015/11/23/improving-revocation-ocsp-must-staple-and-short-lived-certificates/>
]FIGCAPTION]
> In an ideal world, the browser would perform an online status check (such as OCSP) whenever it verifies a certificate, and reject the certificate if the check failed. However, these checks can be slow and unreliable. They time out about 15% of the time, and take about 350ms even when they succeed. Browsers generally soft-fail on revocation in an attempt to balance these concerns.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[11] [CITE[Security FAQ - The Chromium Projects]]
( ([TIME[2016-05-07 09:19:23 +09:00]]))
<https://www.chromium.org/Home/chromium-security/security-faq#TOC-What-s-the-story-with-certificate-revocation->
]FIGCAPTION]
>
> Chrome performs online checking for Extended Validation certificates if it does not already have a non-expired CRLSet entry covering the domain. If Chrome does not get a response, it simply downgrades the security indicator to Domain Validated.
]FIG]
[34] [CITE[Chromeは既定だとオンラインで証明書の失効確認していないので設定方法を調べてみた - piyolog]]
([TIME[2015-12-07 19:59:38 +09:00]] 版)
<http://d.hatena.ne.jp/Kango/20140413/1397345642>
[12] [CITE@en[Issue 361820 - chromium - Check For Server Certificate Revocation checkbox is confusing - Monorail]]
( ([TIME[2016-05-09 23:42:16 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=361820>
[13] [CITE@en-US[Certificate revocation and the performance of OCSP | Netcraft]]
( ([TIME[2016-05-05 10:34:42 +09:00]]))
<http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html>
[FIG(quote)[
[FIGCAPTION[
[14] [CITE@ja[Internet Explorer 7 における HTTPS セキュリティの強化点]]
( ([TIME[2016-05-10 21:05:57 +09:00]]))
<https://msdn.microsoft.com/ja-jp/library/bb250503>
]FIGCAPTION]
> 原因 : Windows Vista にパフォーマンス強化および OCSP プロトコルのサポートが追加されたことで、WININET では既定で失効状態のチェックが有効になり、セキュリティが強化されます。
]FIG]
[15] [CITE@en[991815 – (mozilla::pkix) Sites not getting EV treatment with mozilla::pkix is on, but do get EV treatment when mozilla::pkix is off because OCSP response is old]]
( ([TIME[2016-05-10 22:58:11 +09:00]]))
<https://bugzilla.mozilla.org/show_bug.cgi?id=991815>
[16] [CITE@en[OpenSSL]]
( ([[OpenSSL Foundation, Inc.]]著, [TIME[2016-05-28 17:15:40 +09:00]]))
<https://www.openssl.org/docs/manmaster/crypto/OCSP_sendreq_new.html>
[17] [CITE@en[OpenSSL]]
( ([[OpenSSL Foundation, Inc.]]著, [TIME[2016-05-28 17:51:02 +09:00]]))
<https://www.openssl.org/docs/manmaster/crypto/OCSP_response_status.html>
[18] [CITE[OpenSSL: how to setup an OCSP server for checking third-party certificates? - Server Fault]]
( ([TIME[2016-05-28 21:55:41 +09:00]]))
<http://serverfault.com/questions/131983/openssl-how-to-setup-an-ocsp-server-for-checking-third-party-certificates>
[19] [CITE@en[OpenSSL]]
( ([[OpenSSL Foundation, Inc.]]著, [TIME[2016-05-28 21:58:38 +09:00]]))
<https://www.openssl.org/docs/manmaster/apps/ocsp.html>
[FIG(quote)[
[FIGCAPTION[
[22] [CITE[Feature request: OCSP Must Staple (RFC 7633) - Google グループ]]
( ([TIME[2016-05-30 23:58:05 +09:00]]))
<https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/-pB8IFNu5tw>
]FIGCAPTION]
> The state of the world for OCSP code is bad. Real bad. Unless you're running IIS, or running a home-grown OCSP daemon, you're going to staple bad responses. That is, if you turn on stapling in Apache or nginx, you're going to serve junk to a portion of your users. When you serve junk, in a must-staple world, everything goes badly.
> Further, the world assumes clients are well-behaved - they have good clocks, good caching logic, and good OCSP implementations. Unfortunately, those assumptions can all be wrong - and when something's wrong on the client, it could brick sites. We already see this with HSTS and a variety of otherwise fixable errors (such as clock skew) contributing significantly to warning fatigue or user frustration - and it's actually rather surprisingly hard to quantify, on the client, the ways in which the client could have screwed up.
> To that end, our focus has been on quantifying the OCSP ecosystem - both in terms of what the CAs are sending (... frequently, horribly bloated responses that often fail basic DER encoding rules), and what servers are doing. We're also exploring how to allow server operators to participate in that virtuous feedback cycle, by providing something akin to 'expect-staple' - that is, a signifier that the server *should* always be sending valid stapled responses, and a means of getting feedback when this is not the case. This will allow sites to further debug and investigate, both client errors and the fact that, again, most of the OCSP fetching code on servers is bad.
]FIG]
[23] [CITE@en[RFC 4557 - Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)]]
([TIME[2016-07-03 18:00:41 +09:00]])
<https://tools.ietf.org/html/rfc4557>
[24] [CITE@en[Only specific APIs should skip the fetch event when called within a service worker · Issue #303 · whatwg/fetch]]
([TIME[2017-02-15 23:49:23 +09:00]])
<https://github.com/whatwg/fetch/issues/303>
[25] [CITE@en[Document CORS safelist exceptions]]
([[estark37]]著, [TIME[2017-11-21 17:35:02 +09:00]])
<https://github.com/whatwg/fetch/commit/860ab8669fb3775b77b6f81e44e5a2609db0bc93>
[26] [CITE@en[High-reliability OCSP stapling and why it matters]]
([TIME[2018-01-29 23:55:46 +09:00]])
<https://blog.cloudflare.com/high-reliability-ocsp-stapling/>
[27] [CITE@en[OCSP / SCT requirements of the cert-chain · Issue #175 · WICG/webpackage]]
([TIME[2018-04-13 00:46:23 +09:00]])
<https://github.com/WICG/webpackage/issues/175>