aafc7f91c2cd9d296522bb5562fee5a5a050ca05
[ach-master.git] / presentations / troopers16 / agenda.md
1 % BetterCrypto - three years in..
2 % TROOPERS16, Heidelberg, DE | 2016-03-17
3 % Aaron Zauner | @a_z_e_t | azet@azet.org
4 ---------------------------
5
6 ## Timeline
7 We start at the beginning. The year is 2013.
8
9 * June: Snowden revelations
10 * Summer: More leaks start apprearing
11 * ... People start talking about a Crypto-Apocalypse (OMG!)
12 * August: Aaron Kaplan and Adi Kriegisch start discussing this
13   topic/guide
14 * September/October: Project goes public, a lot of contributions and ML discussion
15
16 ## Motivation
17
18 * Lack of available guides for sysadmins/mgmt for 'crypto hardening'
19 * No up-to-date blog posts we could make use of
20 * Crypto-guides (ENISA, eCrypto II, NIST etc.) for experts, not end-users/admins
21
22 ## BetterCrypto
23 BetterCrypto(.org) - Applied Crypto Hardening is born
24
25 * Clear audience: sysadmins without expert knowledge (e.g. crypto),
26   management, decision makers,..
27 * Clear target: explain all decisions, have open-mailing list
28   discussion, everything FOSS, public and auditable
29
30 ## BetterCrypto (cont.)
31 * Do at least something against the **Cryptocalypse**
32 * Check SSL, SSH, PGP crypto settings in the most common services and
33   certificates:
34   –  Apache, Nginx, lighthttpd
35       –  IMAP/POP servers (dovecot, cyrus, ...) –  openssl.conf
36       –  Etc.
37 * Write down our experiences as guide
38 * Create easy, copy & paste-able settings which are "OK" (as far as we
39   know) for sysadmins.
40 * Many eyes must check this!
41 * FOSS
42
43 ## Why is this relevant for you?
44
45 * You run networks and services. These are targets. If you believe it or not.
46 * You produce code. Make sure it uses good crypto coding practices
47
48 * However good crypto is hard to achieve
49 * Crypto does not solve all problems, but it helps
50
51 ## Who?
52
53 Wolfgang Breyha (uni VIE), David Durvaux, Tobias Dussa (KIT-CERT), L. Aaron Kaplan (CERT.at), Christian Mock (coretec), Daniel Kovacic (A-Trust), Manuel Koschuch (FH Campus Wien), Adi Kriegisch (VRVis), Ramin Sabet (A-Trust), Aaron Zauner (azet.org), Pepi Zawodsky (maclemon.at), IAIK, A-Sit, ... 
54
55 * Sysadmins
56 * Engineers
57 * Devs.
58 * Cryptographers
59 * Security Engineers
60 * ...
61
62
63 ## Contents.
64 About 100 pages. Rough Overview:
65
66 * Intro
67 * Disclaimer 
68 * Methods 
69 * Theory
70   * Elliptic Curve Cryptography 
71   * Keylengths 
72   * Random Number Generators 
73   * Cipher suites – general overview & how to choose one
74 * Recommendations on practical settings 
75 * Tools 
76 * Links 
77 * Appendix
78
79 ## Methods and Principles
80
81
82 Methods:
83
84 * Public review
85 * commits get **discussed**
86 * recommendations **need** references (like wikipedia)
87 * Every commit gets logged & we need your review!
88
89 ## How to contribute?
90
91 * https://git.bettercrypto.org (master, read-only)
92 * https://github.com/BetterCrypto/ (please clone this one & send PRs)
93
94 1. discuss the changes first on the mailinglist
95 2. clone 
96 3. follow the templates 
97 3. send pull requests
98 4. **split the commit into many smaller commits**
99 5. don't be cross if something does not get accepted. 
100 6. be ready for discussion
101
102 ## What do we provide?
103 * A common 'CipherString'
104 * Template configurations for *a lot* of different open source projects (also as textfiles)
105 * References, Crypto Background, Testing, Tools, etc,..
106
107
108 ## What we have so far
109
110 * Web server: Apache, nginx, MS IIS, lighttpd
111 * Mail: Dovecot, cyrus, Postfix, Exim
112 * DBs: Mysql, Oracle, Postgresql, DB2
113 * VPN: OpenVPN, IPSec, Checkpoint, …
114 * Proxies: Squid, Pound
115 * GnuPG
116 * SSH
117 * IM servers (jabber, irc)
118 * _DANE_ (this section is still WIP)
119 * _Configuration code snippets_
120
121 ## CipherString and Suite
122
123 In SSL/TLS terminology; a *ciphersuite* combines the previously mentioned cryptographic techniques to work together and forms part of a secure (online) communication protocol
124
125   * Elliptic Curve Diffie-Hellman (Ephemeral - PFS)
126   * RSA
127   * AES128
128   * Galois Counter Mode (GCM)
129   * SHA256
130
131 * IANA standardized TLS parameters ``TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256``
132
133 differs between implementations (openssl, gnutls, cryptoapi etc.) and versions!
134
135 ## (Perfect) Forward Secrecy
136
137 Problem:
138 * Three letter agency (TLA) records all encrypted traffic
139 * Someday TLA gains access to private-key (Brute Force, Physical Force)
140 * TLA can decrypt all recorded traffic
141
142 Solution:
143 * **Ephemeral** session keys via Diffie Hellman (**ECDHE** and **DHE**)
144
145 ## Keylengths
146
147   * http://www.keylength.com/ 
148   * Recommended Keylengths, Hashing algorithms, etc.
149   * Currently:
150     * RSA: >= 3248 bits (Ecrypt II)     
151     * ECC: >= 256       
152     * SHA 2+ (SHA 256,…)
153     * AES 128 is good enough
154
155 ## AES 128? Is that enough?
156
157 \centering{,,On the choice between AES256 and AES128: I would never consider using AES256, just l
158 ike I don’t wear a helmet when I sit inside my car. It’s too much bother for the epsilon improvem
159 ent in security.''\par
160 — Vincent Rijmen in a personal mail exchange Dec 2013
161 }
162   * Some theoretical attacks on AES-256
163
164
165 ## CipherString and Suite
166
167   * What is a SSLCipherSuite?
168   * vs. SSLProtocol
169
170   * Example:
171
172         SSLProtocol All -SSLv2 -SSLv3
173         SSLCipherSuite
174 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA2
175 56:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK
176 :!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'  
177
178 ## CipherString and Suite
179
180   * General:
181     * Disable SSL 2.0 (weak protocol and algorithms)
182     * Disable SSL 3.0 (BEAST, POODLE)
183     * [Disable RC4 cipher](https://www.ietf.org/rfc/rfc7465.txt)
184       (RFC7465)
185     * Disable EXPORT suites (FREAK Attack)
186     * Enable TLS 1.0 or better
187     * Disable TLS-Compression (SSL-CRIME Attack)
188     * Implement HSTS (HTTP Strict Transport Security)
189     * Implement OCSP stapling (Security and performance improvement)
190   * Variant A: fewer supported clients
191   * Variant B: more clients, weaker settings
192
193
194 ## Variant **A**
195
196   EECDH+aRSA+AES256:EDH+aRSA+AES256:!SSLv3
197
198 ![Variant A](img/variantA.png)
199
200 Compatibility: 
201
202 Only clients which support TLS1.2 are covered by these cipher suites
203 (Chrome 30, Win 7 and Win 8.1, Opera 17, OpenSSL >= 1.0.1e, Safari 6/iOS
204 5, Safari 7/OS X 10.9)
205 Excellent for controlled environments, like intranet.
206
207 ## Variant **B**
208
209 * weaker ciphers, broad client support
210
211 ![Variant B](img/variantB.png)
212
213 ## Example Apache
214
215   * Selecting cipher suites:
216
217 ![Example Apache](img/exampleApache.png)
218
219   * Additionally mod\_rewrite:
220
221 ![Example Apache rewrite](img/exampleApache-rewrite.png)
222
223
224 ## Testing
225
226 ![Testing](img/testing.jpg)
227
228 ## Tools: openssl s_client
229
230    openssl s_client -showcerts –connect git.bettercrypto.org:443
231
232 ![openssl s_client](img/openssl-s_client.png)
233
234 ## Tools: sslscan
235
236 ![sslscan](img/sslscan.png)
237
238
239 ## Tools: ssllabs.com
240
241 ![ssllabs.com](img/SSLLabs_bettercrypto_org.png)
242
243
244 ## Tools: ssllabs.com (2)
245
246 ![ssllabs.com](img/ssllabs2.png)
247
248
249 ## Tools: ssllabs.com (3)
250
251 ![ssllabs.com](img/ssllabs3.png)
252
253 ## Tools: SSLyze
254
255 [SSLyze](https://github.com/nabla-c0d3/sslyze/releases) is a "Fast and full-featured SSL scanner"
256
257 A tool to test internally which cipher strings are supported.
258 The tool offers these features (amongst others):
259   * get a list of targets (ip:port) from a file
260   * XML output
261   * heartbleed test
262   * OCSP stapling test
263   * SSLv2-TLS1.2 testing
264   * finding preferred and supported cipher strings
265   * STARTTLS testing (IMAP, pop, ...)
266   * XMPP testing
267   * SNI support
268   * HSTS testing
269
270 ## Tools: SSLyze (1)
271
272 ![sslyze-screenshot1](img/sslyze-scan-sample1.png)
273
274
275 ## Tools: SSLyze (2)
276
277 ![sslyze-screenshot2](img/sslyze-scan-sample2.png)
278
279 ## Mitigated Attacks
280 We've mitigated some high-profile TLS/SSL vulernabilities in the past years if you've deployed our guide. So far users have been pleased.
281
282 ## Mitigated Attacks: CRIME
283 * Requires TLS compression to perform attack.
284 * From the very beginning we've always turned off TLS or application level compression (BREACH e.g. is a very similar attack on HTTP compression).
285
286
287 ## Mitigated Attacks: POODLE
288 * Required SSLv3 ("TLS-POODLE" is specific to a certain unfamous vendor).
289 * We explicitly forbid SSLv3 - this kills the POODLE ;)
290
291 ## Mitigated Attacks: Logjam
292 * MITM Attack which requires 512, 768bit Diffie-Hellman to decrypt
293 * We've always recommended and, if possible, tried to supply a guide how to use DH params with >= 1024 bits
294 * This was a discussion we had **very** early on in the project and a lot of contributors did their research well
295 * Some opened tickets, commited etc. - upstream
296
297 ## Mitigated Attacks: FREAK
298 * Requires EXPORT (low-security, early-90ties US ammunition export law) ciphers.
299 * We explicitly exclude EXPORT ciphers, problem solved.
300
301 ## Mitigated Attacks: DROWN
302 * Cross-"protocol" (version) attack that requires SSLv2.
303 * We've **always** recommended against enabling (completely insecure) SSLv2 in all configurations!
304 * Mail server daemon distributors used to recommend v2 - that's now gone as well.
305
306 ## Implementation specific attacks
307 * We can't do a lot against implementation specific attacks
308   * there have been quite a lot in the past years (OpenSSL, Apple, Microsoft, $APPLIANCEVENDOR,..)
309   * we try to provide a config guide, we're not auditors (up to sec. ngineers like you! ;))
310
311 ## Project statistics
312 * 45 Contributors (git only) - ML as well (commited by others)
313 * 1501 commits
314 * Mostly LateX (a lot of overhead) - no line count stats.
315 * More than 1200 msgs to the mailing list
316
317 ## Project statistics (cont.)
318
319 ![img](img/github.png)
320
321 ## Project statistics (cont.)
322
323 * Always new posts to ML if new attacks appear
324 * Improvements to the document regularly on GitHub (e.g. Mail, Jabber section)
325
326 ## Discussion - PostQuantum
327
328 * some experts believe that a **real** quantum computer (not D-Wave) is only 10-50 years away 
329 * new 'post-quantum crypto schemes' - no standard yet, we can't use them, almost no implementations
330 * we currently have no plans to add anything in this direction, but might in the future
331
332 ## Discussion - ECC
333
334 * djb et al: SafeCurves - are NIST/NSA curves trustable? parameters chosen by NSA, might contain backdoor?
335 * a lot of discussion in the project, we prefered DHE over ECDHE because of uncertainty in 2013
336 * Nowadays opinion by experts: common implementations are "hardened" and work well (see also: https://eprint.iacr.org/2015/1018.pdf)
337 * IETF will standardize new non-NIST curves in the near future, implementations will follow as will we.
338
339 ## Future
340 * We need continued input by (domain) experts.
341 * If you know a service, appliance or math well - talk to us, review,..
342 * This project is still active and needs a bit of upkeep by the community, if you like it, please help out
343
344 ## Future - testing?
345 What about automatically testing our configuration recommendations against different distributions, server daemon versions, TLS stacks et cetera? What about automatically deploying them as well?
346
347 * Jenkins
348 * Packer
349 * Vagrant
350 * Puppet/Chef/Ansible/CfEngine/..
351 * ...
352
353 ## Future - testing?
354
355 We'd like to provide a nice JavaScript-y webinterface for choosing your daemon version and getting a proper, up to date, secure configuration for it on the website. There has been interest in the past, but no one working on it currently.
356
357 ## Status Quo
358 * Distro and Package security w.r.t. Crypto settings has improved sigificantly over the past years
359 * Distribution security teams now work on similar issues, as do other secuity teams (e.g. browser vendors)
360 * There's a lot to do and **tons** of legacy systems with really bad configurations (see ongoing scanning research by various parties)
361 * IETF works on a lot of protocol and crypto security related improvements - time to market? ;)
362
363 ## Status Quo (cont.)
364 * Most sysadmins are still largely unfamiliar with the topic and follow stackexchange, (some-times wrong, unreviewed) blogposts etc.
365 * We do have quite a few sections and recommendations that need regular checking, love, testing and contribution
366 * The more people audit, discuss and review, the better the project becomes (if not spammed by crypto-tinfoils)
367
368 ## Questions?
369
370   * Website: https://www.bettercrypto.org
371   * Master (read-only) Git repo: https://git.bettercrypto.org
372   * Public github repo for PRs:
373     https://github.com/BetterCrypto/Applied-Crypto-Hardening
374   * Mailing list: http://lists.cert.at/cgi-bin/mailman/listinfo/ach 
375   * IRC: #bettercrypto on freenode
376   * Twitter: @bettercrypto
377