Merge pull request #146 from roock/ciscoasa98
[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 appearing
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 **Crypto-Apocalypse**
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 know) for sysadmins.
39 * Many eyes must check this!
40 * FOSS
41
42 ## Why is this relevant for you?
43
44 * You run networks and services. These are targets. If you believe it or not.
45 * You produce code. Make sure it uses good crypto coding practices
46
47 * However good crypto is hard to achieve
48 * Crypto does not solve all problems, but it helps
49
50 ## Who?
51
52 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, ...
53
54 * Sysadmins
55 * Engineers
56 * Devs.
57 * Cryptographers
58 * Security Engineers
59 * ...
60
61
62 ## Contents.
63 About 100 pages. Rough Overview:
64
65 * Intro
66 * Disclaimer
67 * Methods
68 * Theory
69   * Elliptic Curve Cryptography
70   * Keylengths
71   * Random Number Generators
72   * Cipher suites – general overview & how to choose one
73 * Recommendations on practical settings
74 * Tools
75 * Links
76 * Appendix
77
78 ## Methods and Principles
79
80
81 Methods:
82
83 * Public review
84 * commits get **discussed**
85 * recommendations **need** references (like wikipedia)
86 * Every commit gets logged & we need your review!
87
88 ## How to contribute?
89
90 * https://git.bettercrypto.org (master, read-only)
91 * https://github.com/BetterCrypto/ (please clone this one & send PRs)
92
93 1. discuss the changes first on the mailinglist
94 2. clone
95 3. follow the templates
96 3. send pull requests
97 4. **split the commit into many smaller commits**
98 5. don't be cross if something does not get accepted.
99 6. be ready for discussion
100
101 ## What do we provide?
102 * A common 'CipherString'
103 * Template configurations for *a lot* of different open source projects (also as textfiles)
104 * References, Crypto Background, Testing, Tools, etc,..
105
106
107 ## What we have so far
108
109 * Web server: Apache, nginx, MS IIS, lighttpd
110 * Mail: Dovecot, cyrus, Postfix, Exim
111 * DBs: Mysql, Oracle, Postgresql, DB2
112 * VPN: OpenVPN, IPSec, Checkpoint, …
113 * Proxies: Squid, Pound
114 * GnuPG
115 * SSH
116 * IM servers (jabber, irc)
117 * _DANE_ (this section is still WIP)
118 * _Configuration code snippets_
119
120 ## CipherString and Suite
121
122 In SSL/TLS terminology; a *ciphersuite* combines the previously mentioned cryptographic techniques to work together and forms part of a secure (online) communication protocol
123
124   * Elliptic Curve Diffie-Hellman (Ephemeral - PFS)
125   * RSA
126   * AES128
127   * Galois Counter Mode (GCM)
128   * SHA256
129
130 * IANA standardized TLS parameters ``TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256``
131
132 differs between implementations (openssl, gnutls, cryptoapi etc.) and versions!
133
134 ## (Perfect) Forward Secrecy
135
136 Problem:
137 * Three letter agency (TLA) records all encrypted traffic
138 * Someday TLA gains access to private-key (Brute Force, Physical Force)
139 * TLA can decrypt all recorded traffic
140
141 Solution:
142 * **Ephemeral** session keys via Diffie Hellman (**ECDHE** and **DHE**)
143
144 ## Keylengths
145
146   * http://www.keylength.com/
147   * Recommended Keylengths, Hashing algorithms, etc.
148   * Currently:
149     * RSA: >= 3248 bits (Ecrypt II)
150     * ECC: >= 256
151     * SHA 2+ (SHA 256,…)
152     * AES 128 is good enough
153
154 ## AES 128? Is that enough?
155
156 \centering{,,On the choice between AES256 and AES128: I would never consider using AES256, just
157 like I don’t wear a helmet when I sit inside my car. It’s too much bother for the epsilon
158 improvement in security.''\par
159 — Vincent Rijmen in a personal mail exchange Dec 2013
160 }
161   * Some theoretical attacks on AES-256
162
163
164 ## CipherString and Suite
165
166   * What is a SSLCipherSuite?
167   * vs. SSLProtocol
168
169   * Example:
170
171         SSLProtocol All -SSLv2 -SSLv3
172         SSLCipherSuite
173 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:
174 EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:
175 +CAMELLIA256:+AES256:+CAMELLIA128:+AES128:
176 +SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:
177 !PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA
178 :AES256-SHA:CAMELLIA128-SHA:AES128-SHA'
179
180 ## CipherString and Suite
181
182   * General:
183     * Disable SSL 2.0 (weak protocol and algorithms)
184     * Disable SSL 3.0 (BEAST, POODLE)
185     * [Disable RC4 cipher](https://www.ietf.org/rfc/rfc7465.txt) (RFC7465)
186     * Disable EXPORT suites (FREAK Attack)
187     * Enable TLS 1.0 or better
188     * Disable TLS-Compression (SSL-CRIME Attack)
189     * Implement HSTS (HTTP Strict Transport Security)
190     * Implement OCSP stapling (Security and performance improvement)
191   * Variant A: fewer supported clients
192   * Variant B: more clients, weaker settings
193
194
195 ## Variant **A**
196
197   EECDH+aRSA+AES256:EDH+aRSA+AES256:!SSLv3
198
199 ![Variant A](img/variantA.png)
200
201 Compatibility:
202
203 Only clients which support TLS1.2 are covered by these cipher suites
204 (Chrome 30, Win 7 and Win 8.1, Opera 17, OpenSSL >= 1.0.1e,
205 Safari 6/iOS 5, Safari 7/OS X 10.9)
206 Excellent for controlled environments, like intranet.
207
208 ## Variant **B**
209
210 * weaker ciphers, broad client support
211
212 ![Variant B](img/variantB.png)
213
214 ## Example Apache
215
216   * Selecting cipher suites:
217
218 ![Example Apache](img/exampleApache.png)
219
220   * Additionally mod\_rewrite:
221
222 ![Example Apache rewrite](img/exampleApache-rewrite.png)
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 vulnerabilities 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. engineers 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