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