fix image
[ach-master.git] / presentations / org-training / agenda.md
1 % Bettercrypto - Applied Crypto Hardening for Sysadmins
2 % L. Aaron Kaplan <kaplan@cert.at> ; Maclemon (Zawodsky Pepi) <pepi@maclemon.at>
3 % 2015-03-30
4 ---------------------------
5
6
7
8 # Part 1:  Intro to the project
9
10
11 ![logo](img/logo)
12
13
14 ---
15 # Overview 
16
17   1. **Part 1:** Intro to bettercrypto & Motivation
18   2. How we got started, how we work, what's there, what's missing, how to use the guide
19   2. Brainstorming round: what's needed for the organisation?
20   3. **Part 2:** Background
21   3. History of Crypto in a nutshell
22   4. Theory
23   4. 12:30 __lunch break__
24   5. Theory (cont.)
25   5. Practical settings
26   6. **Part 3:** Testing, tools, finding a process for improvement
27   6. Brainstorming round: finding an internal testing strategy
28   7. wrap up & next steps
29     
30
31 # Prerequisites
32
33   * Participants should have a basic knowledge of System administration and be familiar with configuring Apache, nginx, etc.
34   * know git/github
35   * a basic knowledge of crypto will help.
36
37 # Motivation
38
39 ![NSA](img/nsa.png)
40
41 # Motivation (2)
42
43 Please note:
44
45   * the leaks also revealed to all countries worldwide precise recipies on how to do country wide or even Internet-wide surveillance, traffic inspection and -modification, etc.
46   * If politicians in other countries did not know how to do this, now they know!
47   * If criminals did not know how to do this, now they know!
48
49 # Motivation (3)
50
51 \includegraphics[width=2cm]{img/Klaus_Landefeld.jpg}
52
53 Ende-zu-Ende-Verschlüsselung das Einzige, das funktioniert. Leitungen verschlüsseln auch schwierig, gibt keine Standards. Und Problem mit ausländischen Anbietern bleibt. Bereits beim Endkunden verschlüsseln, alles andere wird nicht helfen.  
54 — Klaus Landefeld, 2015-03-26
55 NSA Untersuchungssausschuß im deutschen Bundestag
56
57 # The reaction
58
59 \centering { \textbf{Don't give them anything for free}\par
60   It's your home, you fight! }
61
62
63 # The reaction (2)
64
65   * We as humans are used to certain **modes** in communications:
66 spoken words tend to:
67     * be forgotten over time ("data expires")
68     * get modified/changed whenever "copied" (repeated)
69     * get changed/modified over time  ("forgetfullness")
70     * we tend to be not so harsh about them ("forgive")
71     * have a limited geographic range ("town talk")
72     * be very decentralized ("accoustic range")
73   * digital traces/data tends to be:
74     * stored for ever. Never modified by default
75     * used against you in the future
76     * very centralized
77     * copied very easily
78     * always searchable in O(log(n)) 
79     
80   
81 # The reaction (3)
82
83 \centering { \textbf{Crypto is the only thing that might still help}
84 \par
85 a.k.a.:\par
86         ``\textit{The Bottom Line Is That Encryption Does Work}'', Edward Snowden
87 }
88
89 # But where?
90
91   * Ca. August 2013: Adi Kriegisch asks Aaron Kaplan where he could find good recommendations on SSL settings.
92   * Does that exist? At that time:
93     - no ssllabs cookbook
94     - only theoretical recommendations (ENISA, eCrypt II, NIST)
95     - ioerror's duraconf settings are outdated
96     - no practical copy & paste-able settings exist?
97
98
99 # Project plan
100
101 ![Project plan](img/metalab-world-domination.jpg)
102
103
104 # Project plan  (srsly)
105
106   * Do at least something against the **Cryptocalypse**
107   * Check SSL, SSH, PGP crypto SeIngs in the most common services and certificates:
108     –  Apache, Nginx, lighthNp
109         –  IMAP/POP servers (dovecot, cyrus, ...) –  openssl.conf
110         –  Etc.
111   * Write down our experinces as guide
112   * Create easy, copy & paste-able settings which are "OK" (as far as we know) for sysadmins.
113   * Keep the guide short. There are many good recommendations out there written by cryptographers for cryptographers
114   * Many eyes must check this!
115   * Make it open source
116
117   
118
119
120 # Why is this relevant for you?
121
122   * You run networks and services. These are targets. If you believe it or not.
123   * You produce code. Make sure it uses good crypto coding practices
124
125   * However good crypto is hard to achieve
126   * Crypto does not solve all problems, but it helps
127
128
129 # Who?
130
131 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, ...  
132
133
134 # Contents so far
135
136   * Intro
137   * Disclaimer 
138   * Methods 
139   * Theory
140     * Elliptic Curve Cryptography 
141     * Keylengths 
142     * Random Number Generators 
143     * Cipher suites – general overview & how to choose one
144   * Recommendations on practical settings 
145   * Tools 
146   * Links 
147   * Appendix
148
149
150 # Methods and Principles
151
152 C.O.S.H.E.R principle:
153   * **C**ompletely
154   * **O**pen 
155   * **S**ource
156   * **H**eaders
157   * **E**ngineering and
158   * **R**esearch
159
160 Methods:
161   * Public review
162   * commits get **discussed**
163   * recommendations **need** references (like wikipedia)
164   * Every commit gets logged & we need your review!
165
166 # How to commit
167
168   * https://git.bettercrypto.org (master, read-only)
169   * https://github.com/BetterCrypto/ (please clone this one & send PRs)
170
171 How?
172   1. discuss the changes first on the mailinglist
173   2. clone 
174   3. follow the templates 
175   3. send pull requests
176   3. **split the commit into many smaller commits **
177   4. don't be cross if something does not get accepted. 
178   5. be ready for discussion
179  
180
181 # Feedback from professional cryptographers
182
183   * multiple times mentioned in talks by Dan J. Bernstein & Tanja Lange
184 (ONE Conference, CCC, ...)
185   * good initial feedback from Vincent Rijmen (inventor of AES)
186   * got invited to the IETF STRINT workshop 2014
187
188 # Part 2 
189
190 \centering { \textbf{A large organisation has its own needs} }
191
192 (Taking notes on infrastructure, legacy systems, inventory, etc.)
193
194 # Brainstorming: what's needed in your organisation? 
195 (interactive session)
196
197 Some points to get us thinking:
198   * What are the issues you have encounted with running more crypto?
199   * Which legacy systems exist? Can they be updated ? 
200   * How can you test all of your systems if they use strong crypto?
201   * Is there an inventory of all services and servers?
202   * Which services can be tested from outside? 
203   * Which only from inside? 
204   * Which interfaces exist to outside organisations using crypto? 
205   * ..... interfaces to ... , which should use crypto?
206
207
208 # What's needed in your organisation? (2)
209 (continued) 
210   * Are there any protection rings / classifications on different sets of information?
211   * Are there any automatic processes using SSL/crypto which can get disturbed by 
212 updates?
213   * How to test these processes if they work?
214   * ***Key-roll-overs***: are there procedures for this? What happens when upgrading to 4k?
215   * Do not underestimate the amount of work for key-management
216
217
218 # Proposed meta-strategy
219   * practice key-roll-overs
220   * practice identifying all services which run crypto
221   * practice testing them against known good standards automatically (nagios, ...)
222  
223 Turns out, key management as well as crypto management can be seen similarly to regular
224 patch management: it needs periodic attention.
225
226 # Part 3
227
228 \centering { \textbf{History, Theory}}
229
230 # History part
231
232 Pre-history
233   * Scytale (7h century BC)
234   * Caesar 
235   * Vigenère (in a cifra del. Sig. Giovan Battista Bellaso, 1533)
236
237 ![Scytale](img/scytale.png)
238
239 # How you can loose your head
240   * Mary Queen of Scots (1542 - 1587)
241     * Queen of Scotland until 1567
242     * Try to regain the throne 
243     * Was found guilty of plotting to assassinate Queen Elizabeth I of England
244     * Prooven after his code get broken...
245
246 ![Mary](img/mary.jpg)
247
248 # How it can change a war
249   * II World War
250     * Enigma in use by German Army
251     * Broken by the first comuter (Alan Turing)
252     * Sign the end of U-Boat supremacy on the sea
253
254 ![Enigmae](img/enigma.jpg)
255
256 # A sort of Steganography 
257   * Navajos Code Talkers (Pacific War - US Navy)
258
259 ![Navajo](img/navajo.jpg)
260
261 # Nowadays
262   * Asymetric cryptography
263     * RSA (River - Shamir - Adleman) - 1977
264     * GPG (Phil Zimmerman) - 1991
265   * AES (Rijdael) - 1998
266
267 # Famous names
268   * Cryptography was an hot topic for a lot of people
269     * Thomas Jefferson (1790) - ciphering cylinder (used for 150 years)
270     * Charles Babbage - break the Vigenère Cipher (1854, unknown until 20th Century)
271     * Gilbert S. Vernam (AT&T, 1917) - polyalphatic cipher with random key without repetition
272       * Only ciphersuite impossible to break both in theory and in practice!
273
274 # Theory 
275
276 \[
277  \hbar \frac{\partial}{\partial t}\Psi = \hat H \Psi
278 \]
279
280
281 # Some thoughts on ECC
282
283   * Currently this is under heavy debate
284   * Trust the Math
285     * eg. NIST P-256 (http://safecurves.cr.yp.to/rigid.html)
286     * Coefficients generated by hashing the unexplained seed c49d3608 86e70493 6a6678e1 139d26b7 819f7e90.
287   * Might have to change settings tomorrow
288   * Most Applications only work with NIST-Curves
289   * Bottom line: we leave the choice of ECC yes or no to the reader. You might have to adapt again.
290   * However, many server operators tend towards ECC  (speed)
291
292 # Keylengths
293
294   * http://www.keylength.com/ 
295   * Recommended Keylengths, Hashing algorithms, etc.
296   * Currently:
297     * RSA: >= 3248 bits (Ecrypt II)     
298     * ECC: >= 256       
299     * SHA 2+ (SHA 256,…)
300     * AES 128 is good enough
301
302 # AES 128? Is that enough?
303
304 \centering{,,On the choice between AES256 and AES128: I would never consider using AES256, just like I don’t wear a helmet when I sit inside my car. It’s too much bother for the epsilon improvement in security.''\par
305 — Vincent Rijmen in a personal mail exchange Dec 2013
306 }
307   * Some theoretical attacks on AES-256
308
309
310 # (Perfect) Forward Secrecy
311
312 Motivation:
313
314 * Three letter agency (TLA) stores all ssl traffic
315 * Someday TLA gains access to ssl-private key (Brute Force, Physical Force)
316 * TLA can decrypt all stored traffic
317
318 Solution:
319 * **Ephemeral** session keys via Diffie Hellman (**DHE**)
320
321 # Review of Diffie Hellman
322
323 Let g be a primitive root mod p. p is a Prime.
324
325 Alice to Bob: \[ X = g^x \mod p  \]
326 Bob to Alice:  \[ Y = g^y \mod p  \]
327 Alice calculates: \[  k_1 = Y^x \mod p \]
328 Bob calculates:   \[ k_2 = X^y \mod p .  \text{. Therefore, } k_1 = k_2 \]
329 Proof: \[ k_1 = Y^x = (g^y)^x = g^{(x \times y)} = (g^x)^y = X^y = k_2  \mod p \qed \]
330
331
332 # Reality 
333
334 \centerline{\includegraphics[width=10cm]{img/xkcd-TLA.png}}
335
336 # Well...
337
338 We still recommend perfect forward secrecy.
339
340  * Ephemeral: new key for each execution of a key exchange process
341  * SSL private-Key only for authentication
342  * Alternative new ssl private key every x days months
343  * Pro:
344     - Highest Security against future attacks
345  * Contra: 
346     - Elliptic Curve
347     - Processing costs
348
349 # (P)RNGs
350
351   * (P)RNGs **are** important!
352   * Nadia Heninger et al / Lenstra et al
353 ,,… to identify apparently vulnerable devices from 27 manufacturers.''
354 ![mining P's and Q's](img/mining-ps-and-qs.png)
355   * Entropy after startup: embedded devices quite bad
356
357
358 # (P)RNGs - recommendations
359   * Look out for known weak RNG
360     * Dual EC_DRBG is weak (slow, used in RSA-toolkit)
361     * Intel RNG ? Recommendation: add System-Entropy (Network). Entropy only goes up.
362   * Use tools (e.g. haveged/HaveGE http://dl.acm.org/citation.cfm?id=945516)
363   * RTFM 
364     * when is the router key generated
365     * Default Keys ?
366   * Re-generate keys from time to time
367   * Do not generate keys on fresh VMs.
368   * Always generate new keys when refreshing certificates
369
370
371 # Cipher suites
372
373   * What is a SSLCipherSuite?
374   * vs. SSLProtocol
375
376   * Example:
377
378         SSLProtocol All -SSLv2 -SSLv3
379         SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'
380         
381         Names are not consistent between official IANA strings and most libraries. They are easily mixed up, always double check.
382
383 # Some general thoughts on settings
384
385   * General:
386     * Disable SSL 2.0 (weak algorithms)
387     * Disable SSL 3.0 (BEAST vs IE/XP)
388     * [Disable RC4 cipher](https://www.ietf.org/rfc/rfc7465.txt) (RFC7465)
389     * Disable EXPORT suites (FREAK Attack)
390     * Enable TLS 1.0 or better
391     * Disable TLS-Compression (SSL-CRIME Attack)
392     * Implement HSTS (HTTP Strict Transport Security)
393     * Implement OCSP stapling (Security and performance improvement)
394   * Variant A: fewer supported clients
395   * Variant B: more clients, weaker settings
396
397   Attacks only get better.
398
399
400 # Variant **A**
401
402     EECDH+aRSA+AES256:EDH+aRSA+AES256:!SSLv3
403
404 ![Variant A](img/variantA.png)
405
406 Compatibility: 
407
408 Only clients which support TLS1.2 are covered by these cipher suites (Chrome 30, Win 7 and Win 8.1, Opera 17, OpenSSL >= 1.0.1e, Safari 6 / iOS 6.0.1, Safari 7 / OS X 10.9) 
409
410 # Variant **B**
411
412   * weaker ciphers, many clients 
413
414 ![Variant B](img/variantB.png)
415
416 # Variant B compatibility
417
418 ![Compatibility](img/variantBcompatibility.png)
419
420 # Choosing your own CipherSuite string
421
422   * Rolling your own cipher suite string involves a trade-off between:
423     * Compatibility (server <-> client), vs.
424     * Known weak ciphers/hashes/MACs
425     * The choice ECC or not, vs.
426     * Support by different ssl libs (gnutls, openssl,...) vs.
427     * Different versions of ssl libs
428   * In case of ssl lib version issues: do you want to re-compile the whole server for a newer version?
429   * Be aware of these issues before choosing your own cipher suite. Have test suites!
430
431
432 # Choosing your own CipherSuite string (2)
433
434   * Complexity 
435   * It is a multi-dimensional optimisation problem
436   * Consider strong alternativesto de-facto standards (pros/cons - CAMELLIA vs. AES)
437   * _WISHLIST_: generator for settings? click-dropdown boxes on the webserver -> gernate config
438   * _WISHLIST_: right now we only support OpenSSL CipherSuite names/configs. What about gnutls, etc.?
439
440 # Practical settings
441
442 ![Tools](img/rusty_tools.jpg)
443
444 # What we have so far
445
446 * Web server: Apache, nginx, MS IIS, lighttpd
447 * Mail: Dovecot, cyrus, Postfix, Exim
448 * DBs: Mysql, Oracle, Postgresql, DB2
449 * VPN: OpenVPN, IPSec, Checkpoint, ...
450 * Proxies: Squid, Pound
451 * GnuPG
452 * SSH
453 * IM servers (jabber, irc)
454 * _DANE_ (this section is still WIP)
455 * _Configuration code snippets_
456
457
458 # What are we missing
459
460 _WISHLIST_:
461
462   * Section on generating CSRs (\texttt{-sha256} etc)
463   * Mail: Exchange, Sendmail
464   * SIP
465   * RDP
466
467   * Everything as HTML (easier to copy & paste)
468   * gnutls setttings
469   * Config generator on the website
470   * Automatic testing suite
471
472
473
474
475 # Example Apache
476
477   * Selecting cipher suites:
478
479 ![Example Apache](img/exampleApache.png)
480
481   * Additionally mod\_rewrite:
482
483 ![Example Apache rewrite](img/exampleApache-rewrite.png)
484
485
486 # Testing
487
488 ![Testing](img/testing.jpg)
489
490
491 # How to test - Tools
492
493   * openssl s_client  (or gnutls-cli)
494   * **ssllabs.com**: checks for servers as well as clients
495   * xmpp.net
496   * sslscan: for internal scans
497   * SSLyze: for internal scans
498   * masscan: for internal scans
499   * zmap: for internal scans
500
501
502 # Tools: openssl s_client
503
504    openssl s_client -showcerts –connect git.bettercrypto.org:443
505
506 ![openssl s_client](img/openssl-s_client.png)
507
508 # Tools: sslscan
509
510 ![sslscan](img/sslscan.png)
511
512
513 # Tools: ssllabs.com
514
515 ![ssllabs.com](img/SSLLabs_bettercrypto_org.png)
516
517
518 # Tools: sslllabs.com (2)
519
520 ![ssllabs.com](img/ssllabs2.png)
521
522
523 # Tools: sslllabs.com (3)
524
525 ![ssllabs.com](img/ssllabs3.png)
526
527
528 # Tools: masscan
529
530 [masscan](https://github.com/robertdavidgraham/masscan)
531
532 "TCP port scanner, spews SYN packets asynchronously, scanning entire Internet in under 5 minutes."
533
534 * Idea: if you have a very large network range, use masscan (***be sure to rate-limit!***) to discover all 
535 open ports 443, 993, 143, 25
536 * Now you have an inventory of SSL-speaking ports
537 * Use SSLyze to test these internally
538
539 # Tools: SSLyze
540
541 [SSLyze](https://github.com/nabla-c0d3/sslyze/releases) is a "Fast and full-featured SSL scanner"
542
543 A tool to test internally which cipherstrings are supported.
544 The tool offers these features (amonst others):
545   * get a list of targets (ip:port) from a file
546   * XML output
547   * heartbleed test
548   * OCSP stapling test
549   * SSLv2-TLS1.2 testing
550   * finding preferred and supported cipherstrings
551   * STARTTLS testing (IMAP, pop, ...)
552   * XMPP testing
553   * SNI support
554   * HSTS testing
555 etc.
556
557 # Tools: SSLyze (1)
558
559 ![sslyze-screenshot1](img/sslyze-scan-sample1.png)
560
561
562 # Tools: SSLyze (2)
563
564 ![sslyze-screenshot2](img/sslyze-scan-sample2.png)
565
566 # Brainstorming: finding an internal testing strategy
567
568 Some questions to think about:
569   * Which tests are non-intrusive? Which should be avoided?
570   * Do we need a full inventory? Can we generate the inventory?
571 Does the inventory match the scanned results (hosts & ports)?
572   * Should any  mismatch raise alarms?
573   * Once we identified all ips:ports - do we need to know hostnames? (SNI)?
574   * Defining a common base-line level which MUST be supported
575   * automatic testing against that base-line level? How?
576   * Integration into existing monitoring solutions?
577
578
579 # Wrap-up
580
581
582 ![Wrap-up](img/wrap-up.jpg)
583
584
585 # Current state as of 2015-03-29
586
587   * OK: Solid basis with Variant (A) and (B)
588   * Public draft was presented at the CCC Dec 2013. 
589 Well received. Good feedback (Dan Bernstein, ...)
590   * more work needs to be done:
591    * certificate pinning
592    * Dane
593    * SPDY
594    * etc.
595   * This is a process which should be done regularly
596
597
598 # Links
599
600   * Website: www.bettercrypto.org
601   * Master (read-only) Git repo: https://git.bettercrypto.org
602   * Public github repo for PRs: https://github.com/BetterCrypto/Applied-Crypto-Hardening
603   * Mailing list: http://lists.cert.at/cgi-bin/mailman/listinfo/ach 
604   * IRC: #bettercrypto on freenode
605
606
607
608
609 # Thanks
610
611 \centerline{Thanks}
612