|
@@ -0,0 +1,301 @@
|
|
1
|
+<h1>Checks</h1>
|
|
2
|
+<h2>Protection</h2>
|
|
3
|
+<h3>Hard protection</h3>
|
|
4
|
+
|
|
5
|
+<p>
|
|
6
|
+ Such protection are hard or risky to deploy but give strong protection
|
|
7
|
+ against attack.<br/>
|
|
8
|
+ Deploying such protection can just break your service for a long time if you
|
|
9
|
+ don't understand what you are doing.<br/>
|
|
10
|
+ Service using such protection really tries to protect you and really know
|
|
11
|
+ what security is.
|
|
12
|
+</p>
|
|
13
|
+<hr/>
|
|
14
|
+
|
|
15
|
+<h4 id="hpkp">
|
|
16
|
+ <%= rank_label :A %>
|
|
17
|
+ HTTP Public Key Pinning (HPKP)
|
|
18
|
+ <span class="small">HTTPS only, incoming feature</span>
|
|
19
|
+</h4>
|
|
20
|
+
|
|
21
|
+<p>
|
|
22
|
+ HPKP protection, specified in <%= rfc_link_to 7469 %>, consists of putting
|
|
23
|
+ headers on HTTP response to specify which keys or certificats are allowe
|
|
24
|
+ for the encryption.
|
|
25
|
+ If pinning mismatches, for example because of a
|
|
26
|
+ <%= wikipedia_link_to 'man-in-the-middle attack', 'Man-in-the-middle_attack' %>
|
|
27
|
+ connection is rejected and no data at all is transfered.
|
|
28
|
+</p>
|
|
29
|
+
|
|
30
|
+<pre>
|
|
31
|
+ <code>
|
|
32
|
+$ curl -sI https://cryptcheck.fr/ | grep public-key-pins
|
|
33
|
+public-key-pins: report-uri="https://aeris.report-uri.io/r/default/hpkp/enforce"; max-age=5184000;
|
|
34
|
+ pin-sha256="wdkD38iQQzxE7g0RpmN8VoaIqX7YmPWwoueD9Iqawfg="; pin-sha256="EswdUzfH2N8sx6Nb4Vr9gamtNF5VWQxLWUG0gDIPVLw=";
|
|
35
|
+ </code>
|
|
36
|
+</pre>
|
|
37
|
+
|
|
38
|
+<p>
|
|
39
|
+ HPKP is difficult to deploy because has a redemption period of some days
|
|
40
|
+ (maximum allowed: 60). During this time, in case of misconfiguration,
|
|
41
|
+ returning visitors will faced a TLS error page, even if the configuration
|
|
42
|
+ was fixed.
|
|
43
|
+</p>
|
|
44
|
+
|
|
45
|
+<hr/>
|
|
46
|
+
|
|
47
|
+<h3>Medium protection</h3>
|
|
48
|
+
|
|
49
|
+<p>
|
|
50
|
+ Such protection is not so easy to deploy and can have hazardous side effects,
|
|
51
|
+ but provides quiet good protection against some attacks.<br/>
|
|
52
|
+ Broken service is unexpected or could be fixed in a small time range.<br/>
|
|
53
|
+ Using such protection is a clear sign the service try to protect you.
|
|
54
|
+</p>
|
|
55
|
+
|
|
56
|
+<hr/>
|
|
57
|
+
|
|
58
|
+<h4 id="hsts">
|
|
59
|
+ <%= rank_label :A %> <%= rank_label :B %>
|
|
60
|
+ HTTP Strict Transport Security (HSTS)
|
|
61
|
+ <span class="small">HTTPS only</span>
|
|
62
|
+</h4>
|
|
63
|
+
|
|
64
|
+<p>
|
|
65
|
+ HSTS protection, specified in <%= rfc_link_to 6797 %>, consists of putting
|
|
66
|
+ headers on HTTP response to specify the service supports HTTPS.<br/>
|
|
67
|
+ After the first connection (HSTS is
|
|
68
|
+ "<%= wikipedia_link_to 'Trust On First Use', 'Trust_on_first_use' %>" (TOFU)),
|
|
69
|
+ the browser automatically rewrite <code>http://</code> address to
|
|
70
|
+ <code>https://</code>, avoiding a plain request (with potential data leak)
|
|
71
|
+ to be asked by the service to redirect to the <code>https://</code> address.
|
|
72
|
+</p>
|
|
73
|
+
|
|
74
|
+<pre>
|
|
75
|
+ <code>
|
|
76
|
+curl -sI https://cryptcheck.fr/ | grep strict-transport-security
|
|
77
|
+strict-transport-security: max-age=31536000; includeSubDomains; preload;
|
|
78
|
+ </code>
|
|
79
|
+</pre>
|
|
80
|
+
|
|
81
|
+<p>
|
|
82
|
+ To have full score on HSTS, you need to have a long <code>max-age</code>
|
|
83
|
+ period, at least 1 year (<code>31536000</code> seconds).<br/>
|
|
84
|
+ If you correctly configure your service with HSTS, you can also ask for
|
|
85
|
+ <a href="https://hstspreload.org/" target="_blank">browser preloading</a>,
|
|
86
|
+ avoiding the trouble of the first connection.
|
|
87
|
+</p>
|
|
88
|
+
|
|
89
|
+<hr/>
|
|
90
|
+
|
|
91
|
+<h3>Easy protection</h3>
|
|
92
|
+
|
|
93
|
+<p>
|
|
94
|
+ Such protection is easy to deploy and without .<br/>
|
|
95
|
+ Broken service is unexpected or could be fixed in a small time range.<br/>
|
|
96
|
+ Using such protection is a clear sign the service try to protect you.
|
|
97
|
+</p>
|
|
98
|
+
|
|
99
|
+<hr/>
|
|
100
|
+
|
|
101
|
+<h4 id="aead">
|
|
102
|
+ <%= rank_label :C %>
|
|
103
|
+ Authentificated Encryption with Authenticated Data (AEAD)
|
|
104
|
+</h4>
|
|
105
|
+
|
|
106
|
+<p>
|
|
107
|
+ Since 2014, TLS (and SSL) suffers of
|
|
108
|
+ <a href="https://www.imperialviolet.org/2014/12/08/poodleagain.html" target="_blank">PODDLE</a>
|
|
109
|
+ vulnerability on the way padding is done during TLS handshake.
|
|
110
|
+ An attacker can play with this encrypted padding to guess underlying plain
|
|
111
|
+ data.<br/>
|
|
112
|
+
|
|
113
|
+ Any <%= wikipedia_link_to 'cipher mode operation', 'Block_cipher_mode_of_operation' %>
|
|
114
|
+ other than <%= wikipedia_link_to 'AEAD', 'Authenticated_encryption' %> is
|
|
115
|
+ vulnerable to this attack.
|
|
116
|
+</p>
|
|
117
|
+
|
|
118
|
+<p>
|
|
119
|
+ In practice, POODLE is a serious flaw for SSLv2/v3, which must be avoided
|
|
120
|
+ in all cases, but also for TLSv1.0/1.1.<br/>
|
|
121
|
+ Service operators must support AEAD cipher suite as soon as possible, to
|
|
122
|
+ avoid trouble when practical attack will be found on POODLE on TLS.<br/>
|
|
123
|
+ Such cipher suite is only available on TLSv1.2, so operators must disable
|
|
124
|
+ TLSv1.0 now, and TLSv1.1 as soon as possible.
|
|
125
|
+</p>
|
|
126
|
+
|
|
127
|
+<hr/>
|
|
128
|
+
|
|
129
|
+<h4 id="scsv">
|
|
130
|
+ <%= rank_label :C %>
|
|
131
|
+ TLS Fallback Signaling Cipher Suite Value (SCSV)
|
|
132
|
+</h4>
|
|
133
|
+
|
|
134
|
+<p>
|
|
135
|
+ SCSV, specify in <%= rfc_link_to 7507 %> is a TLS extension to allow a
|
|
136
|
+ client to signal to the server a previous hanshake attempt with higher TLS
|
|
137
|
+ version was done, but unsuccessfully.<br/>
|
|
138
|
+ This way, the server can detect a downgrade attack on the line, because
|
|
139
|
+ supporting better than the current TLS version.<br/>
|
|
140
|
+ Without this signaling value, the server has no way to distinguish between
|
|
141
|
+ a client supporting TLSv1.2 but downgraded to TLSv1.1 and a client TLSv1.1
|
|
142
|
+ only.<br/>
|
|
143
|
+ For example, this feature allows blocking of downgrade attack from TLSv1.2
|
|
144
|
+ (AEAD & PFS) to TLSv1.0 (nor AEAD nor PFS) to exploit POODLE vulnerability
|
|
145
|
+ more easily.
|
|
146
|
+</p>
|
|
147
|
+
|
|
148
|
+<p>
|
|
149
|
+ To activate SCSV, you just need a decent OpenSSL version (1.0.1j+).
|
|
150
|
+ LibreSSL currently doesn't have support for this.
|
|
151
|
+</p>
|
|
152
|
+
|
|
153
|
+<hr/>
|
|
154
|
+
|
|
155
|
+<h2>Weaknesses</h2>
|
|
156
|
+<h3>Future weakness</h3>
|
|
157
|
+
|
|
158
|
+<p>
|
|
159
|
+ This kind of weakness is theorical vulnerability but without practical
|
|
160
|
+ attack or with too much side effects to be able to patch it.
|
|
161
|
+</p>
|
|
162
|
+
|
|
163
|
+<hr/>
|
|
164
|
+
|
|
165
|
+<h3>Current weakness</h3>
|
|
166
|
+
|
|
167
|
+<p>
|
|
168
|
+ Such weakness knows practical attacks to break encryption.
|
|
169
|
+ Using such features is hightly discourage, and operators must take quick
|
|
170
|
+ actions to remove them.
|
|
171
|
+</p>
|
|
172
|
+
|
|
173
|
+<hr/>
|
|
174
|
+
|
|
175
|
+<h4 id="tlsv1.0">
|
|
176
|
+ <%= rank_label :F %>
|
|
177
|
+ TLSv1.0
|
|
178
|
+</h4>
|
|
179
|
+
|
|
180
|
+<p>
|
|
181
|
+ TLSv1.0 is vulnerable to
|
|
182
|
+</p>
|
|
183
|
+
|
|
184
|
+<hr/>
|
|
185
|
+
|
|
186
|
+<!--
|
|
187
|
+<h4 id="pfs">
|
|
188
|
+ <%= rank_label :F %>
|
|
189
|
+ Perfect Forward Secrecy (PFS)
|
|
190
|
+</h4>
|
|
191
|
+
|
|
192
|
+<p>
|
|
193
|
+ <%= wikipedia_link_to 'PFS', 'Forward_secrecy' %> is
|
|
194
|
+</p>
|
|
195
|
+
|
|
196
|
+<hr/>
|
|
197
|
+-->
|
|
198
|
+
|
|
199
|
+<h3>Deprecated feature</h3>
|
|
200
|
+
|
|
201
|
+<hr/>
|
|
202
|
+
|
|
203
|
+<h4 id="ssl">
|
|
204
|
+ <%= rank_label :G %>
|
|
205
|
+ SSLv2, SSLv3
|
|
206
|
+</h4>
|
|
207
|
+
|
|
208
|
+<p>
|
|
209
|
+ SSLv2 and SSLv3 are deprecated SSL protocol version.<br/>
|
|
210
|
+ Pratical attacks exist to decrypt SSL encrypted traffic to plain text in
|
|
211
|
+ some minutes with standard computer.
|
|
212
|
+ For SSLv3, it's
|
|
213
|
+ <a href="https://security.googleblog.com/2014/10/this-poodle-bites-exploiting-ssl-30.html" target="_blank">POODLE</a>
|
|
214
|
+ again.
|
|
215
|
+ For SSLv2, it's was supposed to never be in production because too bad and
|
|
216
|
+ broken cryptography under the hood.
|
|
217
|
+ <a href="https://drownattack.com/" target="_blank">DROWN</a> vulnerability
|
|
218
|
+ allows an attacker to decrypt encrypted traffic (even TLSv1.2!) as soon as
|
|
219
|
+ one of the servers used for the service supports SSLv2 with the same key.
|
|
220
|
+</p>
|
|
221
|
+
|
|
222
|
+<hr/>
|
|
223
|
+
|
|
224
|
+<!--
|
|
225
|
+<h4 id="rc4">
|
|
226
|
+ <%= rank_label :G %>
|
|
227
|
+ RC4
|
|
228
|
+</h4>
|
|
229
|
+
|
|
230
|
+<p>
|
|
231
|
+ <%= wikipedia_link_to 'RC4', 'RC4' %> is a stream cipher, recently known to
|
|
232
|
+ have
|
|
233
|
+</p>
|
|
234
|
+
|
|
235
|
+<hr/>
|
|
236
|
+-->
|
|
237
|
+
|
|
238
|
+<h4 id="sha1">
|
|
239
|
+ <%= rank_label :E %> <%= rank_label :G %>
|
|
240
|
+ SHA-1
|
|
241
|
+ <span class="small">incoming feature for HMAC</span>
|
|
242
|
+</h4>
|
|
243
|
+
|
|
244
|
+<p>
|
|
245
|
+ <%= wikipedia_link_to 'SHA-1', 'SHA-1' %> is a cryptographic hash function
|
|
246
|
+ used in TLS cipher suite.
|
|
247
|
+ <a href="https://shattered.io/" target="_blank">It was broken</a> in 2016.
|
|
248
|
+</p>
|
|
249
|
+
|
|
250
|
+<p>
|
|
251
|
+ SHA-1 is used in two parts of the handshake.<br/>
|
|
252
|
+ For <%= wikipedia_link_to 'HMAC', 'Hash-based_message_authentication_code' %>,
|
|
253
|
+ which protect each messages exchanged during handshake. Because lifetime of
|
|
254
|
+ such HMAC is very short (TCP/IP round trip), SHA-1 collision is not a real
|
|
255
|
+ trouble on this part.<br/>
|
|
256
|
+ For key exchange and authentication. Each certificate is signed by the issuer
|
|
257
|
+ certificate using a digest.
|
|
258
|
+ In this case, if SHA-1 digest is used and because certificate lifetime is
|
|
259
|
+ long (years to decades), collision on digest could allow an attacker to
|
|
260
|
+ forge a rogue certificate which match the real certificate digest, and so
|
|
261
|
+ to impersonate the TLS service behind.
|
|
262
|
+</p>
|
|
263
|
+
|
|
264
|
+<p>
|
|
265
|
+ SHA-1 signed certificates must be banned.<br/>
|
|
266
|
+ SHA-1 HMAC is currently quite safe, but operators must take action to ensure
|
|
267
|
+ SHA-2 compatibility with clients in case if SHA-1 must be revoked even for
|
|
268
|
+ HMAC.
|
|
269
|
+</p>
|
|
270
|
+
|
|
271
|
+<hr/>
|
|
272
|
+
|
|
273
|
+<h4 id="digest">
|
|
274
|
+ <%= rank_label :G %>
|
|
275
|
+ MD-5, MD-4, MD-2, MDC-2
|
|
276
|
+</h4>
|
|
277
|
+
|
|
278
|
+<p>
|
|
279
|
+ MD-5, MD-4, MD-2 and MDC-2 are completely broken hash function.
|
|
280
|
+ Just don't use it.
|
|
281
|
+</p>
|
|
282
|
+
|
|
283
|
+<h4 id="compression">
|
|
284
|
+ <%= rank_label :G %>
|
|
285
|
+ Compression
|
|
286
|
+ <span class="small">incoming feature</span>
|
|
287
|
+</h4>
|
|
288
|
+
|
|
289
|
+<p>
|
|
290
|
+ With TLS compression activated, some oracle attacks allow to decrypt the
|
|
291
|
+ content.
|
|
292
|
+ For example the
|
|
293
|
+ <a href="https://arstechnica.com/information-technology/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/" target="_blank">BREACH</a>
|
|
294
|
+ or
|
|
295
|
+ <a href="https://threatpost.com/crime-attack-uses-compression-ratio-tls-requests-side-channel-hijack-secure-sessions-091312/77006/" target="_blank">CRIME</a>
|
|
296
|
+ attacks.
|
|
297
|
+</p>
|
|
298
|
+
|
|
299
|
+<p>
|
|
300
|
+ TLS compression must be disabled on the service.
|
|
301
|
+</p>
|