Die Präsentation von Aaron, Martin und Pepi fokussiert sich auf die Sicherheit im Internet, insbesondere auf angewandte kryptographische Absicherung und den Einsatz von TLS. Es wird darauf hingewiesen, dass ein großer Teil der Webseiten nicht die erforderliche Sicherheit bietet und die Geschichte von SSL und TLS sowie häufige Implementierungsfehler erläutert. Zudem wird ein praktischer Leitfaden zur Verbesserung der Kryptografie für Systemadministratoren vorgestellt, um die Kommunikationssicherheit signifikant zu erhöhen.

1. BetterCrypto.org Cover Slide, vor der Präsentation!
damit das Publikum weiß, daß es im richtigen Saal ist.!
!

2. Los gehts…
!
Durchs Programm führen jetzt:
Aaron,
Martin und
Pepi

3. Aaron Zauner!
Martin Leyrer!
Pepi Zawodsky!
@a_z_e_t!
@leyrer!
@maclemon!
Durchs Programm führen jetzt:
Aaron,
Martin und
Pepi
!
Wir erzählen Euch jetzt etwas über
Applied Crypto Hardening und TLS
Deploying strong, fast and sound cryptography from an operational perspective.

4. Applied Crypto Hardening
Applied Crypto Hardening:
Deploying strong, fast and sound cryptography from an operational perspective.

5. Das Internet ist gefährlich
Das internet ist gefährlich…

6. ＼(=^‥^)
Katzen, überall lauern Katzen!
Und wir wissen alle: Katzen sind Raubtiere!

7. ＼(=^‥^)
Und wir wissen alle: Katzen sind gefährliche Raubtiere!
!
CAT CONTENT

8. Außerdem… die NSA…
NSA collecting phone records of millions of Verizon customers daily.
!
!
Verizon forced to hand over telephone data – full court ruling

9. Verizon forced to hand over telephone data – full court ruling
!
NSA Prism program taps in to user data of Apple, Google and others

10. NSA Prism program taps in to user data of Apple, Google and others
!
Washington Post:
U.S., British intelligence mining data from nine U.S. Internet companies in broad secret program

11. Washington Post:
U.S., British intelligence mining data from nine U.S. Internet companies in broad secret program
!
!

12. [insert evil hacker pic]
Organisierte Wirtschaftskriminalität
(Schlipsträger)
!
Unglaubwürdiger „Häcker“.
!
Nicht nur Kriminalität durch die NSA… sondern auch Regierungen, beliebige andere 3-Buchstaben Institutionen.
!
Copyright von diesem Bild ist NICHT geklärt!

13. [insert evil hacker pic]
und mit handschuhen kamma nicht tippen.
!
Copyright von diesem Bild ist NICHT geklärt!

14. Status Quo bei Webseiten die SSL/TLS verwenden. Von denen sind nur 25% sicher. Das bedeutet, daß ¾ aller
http„s“ Webseiten dem „s“ nicht gerecht werden.
!
Von den milliarden an Webseiten die nur Plaintext sprechen ganz abgesehen.
!
Quelle: SSL Pulse, SSLLabs, 2014-04
https://www.trustworthyinternet.org/ssl-pulse/

15. •
Um es auf den Punkt zu bringen, ihr müsst Euch damit beschäftigen wie ihr das ordentlich macht und verstehen
wie SSL und TLS funktionieren.
!
Und das erklärt Euch nun der Aaron!

16. Eine kurze Geschichte…
Die Geschichte von SSL und TLS ist eine Geschichte voller Missverständnisse und noch mehr schlechten
Implementationen.

17. SSLv1
1970 2014
1994
Nur Netscape intern… (ca. 1994)
wurde also nie veröffentlicht.

18. SSLv2
1970 2014
1995
Kipp Hickman von Netscape stellt 1995 SSLv2 als IETF draft vor:
!
The SSL Protocol is designed to provide privacy
between two communicating applications (a client
and a server). Second, the protocol is designed
to authenticate the server, and optionally the
client. SSL requires a reliable transport
protocol (e.g. TCP) for data transmission and
reception.
– http://tools.ietf.org/html/draft-hickman-netscape-ssl-00
!
SSLv2 Protokoll war schlecht designed und dessen Sicherheit binnen kuerze fundamental gebrochen. Zahlreiche
Angriffe - u.a. keine Sicherheit gegen Man-In-The-Middle: http://osvdb.org/56387
!
Wir erinnern uns kurz… *hach* (Netscape Logo)

19. Animation schaltet nach 4s automatisch weiter auf
SSLv2 again, damit die Timeline wieder erfasst werden kann.
!
Dann weiter mit SSLv3

20. SSLv2
1970 2014
1995
Kipp Hickman von Netscape stellt 1995 SSLv2 als IETF draft vor:
!
The SSL Protocol is designed to provide privacy
between two communicating applications (a client
and a server). Second, the protocol is designed
to authenticate the server, and optionally the
client. SSL requires a reliable transport
protocol (e.g. TCP) for data transmission and
reception.
– http://tools.ietf.org/html/draft-hickman-netscape-ssl-00
!
SSLv2 Protokoll war schlecht designed und dessen Sicherheit binnen kuerze fundamental gebrochen. Zahlreiche
Angriffe - u.a. keine Sicherheit gegen Man-In-The-Middle: http://osvdb.org/56387

21. SSLv3
1970 2014
1996
SSLv3 wurde 1996 von Paul Kocher, Phil Karlton und Alan Freier eingefuehrt: https://tools.ietf.org/html/rfc6101
!

22. TLS 1.0
1970 2014
1999
1999 wird SSL (Secure Sockets Layer) mit einem neuen Standard in TLS (Transport Layer Security) umbenannt und
neu versioniert: TLS 1.0.
https://tools.ietf.org/html/rfc2246

23. TLS 1.1
1970 2014
2006
TLS 1.1 wird 2006 - sieben Jahre spaeter - zum Standard
versucht einige der aufgekommenen Probleme zu beheben
sowie generelle (kryptographische) Sicherheit des Protokolls zu verbessern

24. TLS 1.2
1970 2014
2008
TLS 1.2 wurde 2008 als Standard akzeptiert
https://tools.ietf.org/html/rfc5246
!
bringt vorallem: Moderne Kryptographie.
SHA-256, AES Ciphersuites, GCM und CCM Block-modes so
wie Protokollverbesserungen beim Verbindungsauf- und abbau.

25. 1970 2014
2013
TLS 1.2
TLS 1.2 von Firefox erst im Herbst 2013 unterstuetzt (!).
Anfangs musste der User TLS 1.2 in about://config aktivieren m(
Mozilla Devs. meinten zu mir "Das kann doch eh jeder".
Nein! Nicht jeder ist Poweruser oder Entwickler.
Der Grossteil ist es nicht.
!
Voller Support seit Firefox 27 am 4. Feb. 2014.

26. TLS 1.2
1970 2014
2014
TLS 1.2 von Firefox erst im Herbst 2013 unterstuetzt (!).
Anfangs musste der User TLS 1.2 in about://config aktivieren m(
Mozilla Devs. meinten zu mir "Das kann doch eh jeder".
Nein! Nicht jeder ist Poweruser oder Entwickler.
Der Grossteil ist es nicht.
!
Voller Support seit Firefox 27 am 4. Feb. 2014.

27. Chromium
a_z_e_t:
Persönliche Meinung: Nehmt bitte Chrome(ium). Google hat eines der besten und schnellsten Security Teams in
puncto TLS Sicherheit.

28. TLS Handshake

29. TLS Handshake
Wer weiß wie das genau funktioniert?
Wir wiederholen das mal schnell…

30. Application Data
CertificateVerify
ClientKeyExchange
ChangeCipherSpec
Finished
ClientHello
ACK
SYN
SYN ACK
ServerHello
Certificate
ServerKeyExchange
CertificateRequest
ServerHelloDone
ChangeCipherSpec
Finished
Application Data
Sender (Client)
Receiver (Server)
!
BLUE: TCP (Standard 3-way TCP Handshake)
ORANGE: TLS Handshake
BLACK: Appliaction Data
!
Vereinfacht:
Server und Client haben sich auf eine Ciphersuite (wird spaeter erklaert) geeinigt. Der Client hat das
Zertifikat das die Echtheit des Servers bestaetigt verifiziert und beide haben ihre Public Keys
ausgetauscht.
Anhand der Public Keys wird ein gemeinsamer Schluessel verschluesselt und mit dem Zertifikat
signiert. Der Schluessel (Sessionkey) sichert die Verbindung - dient als Schluessel fuer den Algorithmus
der anhand der Ciphersuite vereinbart wurde.
Daten koennen ausgetauscht werden.

31. Angriffsvektoren

32. Version Rollback (SSLv3+)
Angreifer modifiziert ClientHello message > Rollback auf SSLv2. Erst 2011 gefixed fuer
alle TLS(!) versionen. SSLv3 noch immer anfaellig.

33. Bleichenbacher (1998)
Problem mit PKCS#1 - RSA ist anfaellig fuer ChosenCiphertext Attacks. Angreifer sammel TLS/SSL
PreMasterSecret des ClientKeyExchanges
(RSA Ciphersuites only), macht statistische analyse (z.b. TLS Error Messages) und entschluesselt das
PreMasterSecret womit die Verbindung entschluesselt werden kann. Attacke wurde ueber die Jahre immer wieder
verbessert.

34. Timing attacks
In den folgenden Jahren werden immer wieder sogenannte “timing attacks” publiziert. diese basieren auf
information die ein algorithmus oder das protokoll verraten aufgrund von unterschiedlichen zeitabfolgen bei
operationen. wurde meistens in implementationen gefixed.

35. BEAST (2011)
Doung und Rizzo @ ekoparty sept 2011. Browser <-> Web sicherheitsluecke, User wird z.b. ueber phishingmail
auf eine webseite geleitet die ein script aufruft und information einer anderen seite liesst. der angreifer sammelt
so session-cookie information
!
!
Browser Exploit Against SSL/TLS

36. CRIME (2012)
Kelsey stellt 2002 eine potentiellen side-channel der durch Kompression und verschluesselung im TLS protokoll
entsteht vor. Rizzo und Doung zeigen 2012
das die Attacke in der Realitaet (einfach) ausnuetzbar ist um Inhalt (wie z.b. Cookies ueber viele Verbindungen
hin zu entschluesseln)
!
!
Crompression Ratio Info Leak Made Easy

37. TIME
Kurz darauf veroeffentlicht - im grunde ident zu CRIME, basiert aber auf der moeglichkeit das ein angreifer den
Plaintext der von einem Server zurueckgeschickt wird modifizieren kann
!
Timing Info Leak Made Easy

38. BREACH (2013)
Veroeffentlicht auf BlackHat 2013.
CRIME fuer Kompression in HTTP statt TLS selbst. Alle TLS versionen anfaellig.
-> gzip in euren webservern abdrehen!
!
Browser Reconnaisasance and Exfiltration via Adaptive Compression of Hypertext

39. Lucky13 (2013)
Gefunden von Al Fardan, Kenny Paterson et al. @ Royal Holloway, Uni London. Timing problem in CBC mode - ein
Man in the middle Angreifer kann alle Verbindungen die auf CBC mode Ciphern basieren entschluesseln. Fixed in
TLS 1.2 mit Blockciphermodes wie Galois Counter Mode (GCM)
!

40. RC4 biases (2013)
Wieder AlFardan und Paterson von der Holloway - Rivest Cipher 4. Ungleichheit im Output des Ciphertextes s.g.
“Bias”. Die Attacke ist nur wirklich effizient wenn sehr grosse datenmengen (TB+) uebertragen werden,
verbesserungen sind nicht auszuschliessen, RC4 ist immer wieder unter beschuss von der Cryptocommunity
gekommen,..

41. Web of Mistrust
Certificate Authorities / X.509
Inhaerent hirachisches protokoll, wenn eine CA kompromitiert wird, ist die ganze Kette hin.
CAs die unzulaengliche singaturalgos (MD5) zum signireren verwenden sind faelschbar.
Diginotar.
CAs die SubCAs fuer Firmen erstellen um DPI zu ermoeglichen,
Grossteil der CAs in Browsern nicht in Verwendung, unzaehlige Probleme mit der Implementation von X.509 in
crypto libs (fuzzing owned praktisch alle)
..so kaputt wuerde eigenen 2 stunden Vortrag benoetigen,..

42. …das war nur ein selektiver Einblick
Es gibt noch eine Reihe von komplexeren Kryptographischeren Angriffen
Es gibt immer wieder Probleme bei Implementationen (z.b. gotofail, heartbleed, gnutls gotofail,..)
Standardisierung von TLS und von Cryptoalgorithmen nicht perfekt (NIST, NSA)
[TLS 1.3 kommt mit guten security improvements (ChaCha20, ETM, sinnvollen handshakes usw usf)]

43. Abgang: Aaron
Auftritt: Pepi
!
Bettercrypto YAY

44. Wer hat schon mal davon gehört?
Wer hat schon versucht was davon umzusetzen?
Wer kennt es noch gar nicht?

45. Warum?
Warum das ganze?
!
Wir wissen schon länger, was so alles ±theoretisch möglich ist im Internet.
Inzwischen wissen wir auch, daß einige 3 Buchstaben Organisationen (TLA)
sehr neugierig sind. ZU neugierig.
!
GCHQ it auch ein TLA, ein sog. ETLA, extended TLA.

46. Keinen Klartext herschenken
Das bedeutet… wir wollen keinen Klartext mehr herschenken. Soviel wie möglich verschlüsseln.
und das SO gut wie es momentan möglich ist.
!
Also dachten sich ein paar Leute aus Wien… zB Aaron Kaplan vom CERT, Adi Krigisch vom VRVis…
Jede Crypto ist besser als Klartext. Wir wollen aber auch gute Crypto und das ist kompliziert.
wäre cool wenns einen GUIDE gäbe der einem die Konfig ganz einfach macht.
Gabs aber nicht… na dann schreiben wir halt einen.
!
Hätten wir gewisst, daß das fast unmöglich ist, hätten wir wohl nicht angefangen. wussten wir nicht, also haben
wir in unserem jugendlichen Übermut etwas gutes tun zu wollen, begonnen.
Das Projekt heisst nun:

47. Was ist das nun?
WTF?
Ein praktischer Guide

48. Praktischer Crypto Guide
der genau diese Dinge einfach erklärt.
Dir das Research abnimmt, erklärt warum, wie Du testen kannst und wie Du Deiner Marketingabteilung erklärst
warum ihr das braucht. Oder Management (Layer 9 oder?)

49. Applied Crypto Hardening
Crypto kamma leider viel falsch machen. Es ist ein komplexes Thema und erfordert viel Fachwissen in zu vielen
Bereichen. Für Einzelpersonen machbar, aber hoher Aufwand… Cryto, Sysadmin, Mathematik, Kosten,
Kompatibilität, Performance…
!
Zielgruppe
Für WEN ist das nun?

50. System Administration
Zielgruppe sind sysadmins… also die Leute die auch die Server die unsere Kommunikationsinfrastruktur
betreiben, warten, einrichten, konfigurieren.
ein paar Server da besser zu machen, verbessert sehr schnell die Kommunikationssicherheit von hunderten oder
gar tausenden Menschen.
Es geht also größtenteils um Transportverschlüsselung, also Data in Transit.
!
Dafür haben wir ein Dokument.

51. Was ist jetzt schon drinnen?
!
Aktuell… 94 Seiten, Ja, PDF ist nicht optimal, haben wir inzwischen auch gemerkt.
mit folgenden Inhalten:

52. Umfang
Testen… erstmal rausfinden was nicht ok ist.
Was brauchst Du als erstes?
Status Quo, wie schlimm stehts um meine Infrastruktur. Also TESTEN.

53. Server Tests
Testen… erstmal rausfinden was nicht ok ist.
Für die wichtigsten Servertypen…
Sowohl command line utilities als auch zunehmend web basierte hübsche tools.
!
Was für Serversachen sind bisher erfasst?

54. Webserver
Apache 2.2/2.4, nginx, lightttpd, MS IIS Internet information server

55. Proxy
Squid, Pound

56. Mailserver
postfix, dovecot, cyrus, exim, grundsätzlich SMTP

57. VPN
IPSec, L2TP, OpenVPN, OpenSwan, tinc, ASA, Checkpoint

58. Datenbanken
mySQL, Postgres, DB2, Oracle

59. Kerberos
MIT Version, Heimdal ist in Arbeit und Review.

60. Instant Messaging
Chat
XMPP/Jabber, IRC, OTR
ejabberd, charbybdis, SILC
!
Dabei gilt natürlich noch immer, OTR muß auch auf jeden Fall sein um die Inhalt Ende-zu-Ende zu verschlüsseln.

61. PGP/GnuPG
Nur Inhaltsverschlüsselung.
!

62. SSH
Die Administrationsseite auch absichern
OpenSSH, Cisco ASA, Cisco IOS
!
Bitte kein SSH1 mehr verwenden…
Das ist in The Matrix auch zum Verhängnis geworden.

63. Lights out management
IPMI, ILO, etc.

64. Schlüssel
keylengths, types of keys, Key Exchange, Authentication, MACs

65. Verfahren
Welche sollte ich einsetzen, welche nicht mehr, Cipher Strings
Elliptic curves, RSA, DSA, etc. Cipher Modi, CBC, CTR, GCM, etc.
!
Forward Secrecy wollt ihr unbedingt unterstützen.

66. Zufallszahlen
Hardware, Software, Entropie, können wir CPUs trauen und falls nein, welchen nicht, welchen schon?
Wie wirkt sich das auf meine Key generation aus?
Insbesondere bei VMs, Paravirtualisierung, Embedded Devices.
!
Verwendet jemand einen Hardware Random Number Generator wie diesen hier?

67. Praktische Einstellungen
Sprich, was für settings schreib ich wo hin um was zu erreichen.
!
Dabei gibt es meist zwei Einstellungen, bzw. Cipherstrings.
A: Der Goldstandard. Da wollen wir hin, das beste was Du bekommen kannst. Dabei pfiefen wir auf
bettercompatibility.org und betterperformance.org
!
2014-04-20 20:33 (noch zu haben)

68. Kopieren/Einsetzen
Ja, sollte im wesentlichen Copy paste sein.
es gibt aber zu allem Erklärungen warum genau das empfohlen wird und wie diese Empfehlung zustande
gekommen ist.
!
Caveat Lector: PDFs sind, je nach verwendeter Applikation etwas oder auch etwas mehr problematisch beim
Kopieren. Gelegentlich werden Anführungszeichen substituiert, was lästig ist, oder auch mal ein bösartiges
Leerzeichen eingefügt. Und wir wissen ja was ein Leerzeichen zuviel anrichten kann.

69. Beteiligung
Wer kann da mitmachen?
Alle!
Jeder Vorschlag wird reviewed nichts wird einfach so eingepflegt. Deswegen dauert das auch öfter mal etwas
länger.
!
Immer wieder ein Problem: WER kennt sich mit X aus und das auf einem Level der das auch beurteilen kann.
!
Genau das sollte Euch motivieren mitzumachen.

70. Review
Schaut Euch das Zeug an, wenn ihr Fehler findet, bitte sagt es uns. noch besser, pull-requests!

71. Webseite, dort ist alles verlinkt.
Wer einen zu schlechten Browser mit schlechter Crypto verwendet, kommt da nicht hin.
Updaten! :-)
!
Alles was ihr braucht ist da verlinkt.

72. https://git.bettercrypto.org
Git Repository, Gesamte Entstehung ist komplett offen.
TeX Dokument, ja grauslich. War nicht die optimale Entscheidung im Nachhinein betrachtet. Die 2.0 wird besser.
(Wie immer… Iterationen…)
!

73. github.com/bettercrypto
Github Repo…
Wir nehmen Pull Requests!
Bitte beachten, das dauert ein wenig… auch mal ein bissl länger. Wir müssen alles reviewen, alle arbeiten rein
ehrenamtlich da mit, niemand bekommt einen einzigen Cent bezahlt.
!

74. http://lists.cert.at/cgi-bin/mailman/listinfo/ach
Mailingliste, Diskussion, jede Änderung, jede Ergänzung wird überprüft und reviewed.
Ist eh alles nachher nochmal verlinkt.
Mailingliste wird vom österreichischen CERT gehostet. Projekt Initiator Aaron Kaplan arbeitet dort.
!

75. ach@conference.jabber.metalab.at
Beim Metalab gibts eine MultiuserInnen Jabber Conference.
IRC…ja gibts auch. Den Channel namen dürft ihr selbst erraten. :-)
Wirklich was los ist im IRC aber nicht… ein paar wenige die dort power-idlen, sonst nix. Diskussion findet im
jabber und auf der Mailingliste statt und bei lokalen Treffen in Wien. Wir können aber meist jemanden online
zuschalten!

76. Dort findet ihr das alles…
Gibts natürlich auch auf Twitter und ADN unter @bettercrypto.
!

77. Praxis
Gibt es im Applied Crypto Hardening Workshop
SAMSTAG Sem 4.08 13:00
!
!
Das wichtigste ist mal rauszufinden… was die Eigenen Dinger so können.
!
Also TESTEN…
Kurze Tips zum Testen!

78. Webserver
https://ssllabs.com/

79. und da gebe ich jetzt die Adresse der Webseite ein die ich testen möchte.
Das kann zum beispiel der eigene Webshop sein…
Oder der der Konkurrenz…

80. Nicht IT-AdministrationsMenschen:
Sieht das Sicher aus oder eher weniger?
!
Akuter Handlungsbedarf…
A-F Versteht auch Marketing oder Management…
Würdet ihr dort was kaufen?
!
Gibt natürlich auch mehr Details!

81. Da muß ich jetzt auch nicht ausgebildete IT-Fachkraft sein um zu erkennen, daß das wohl nicht so gut ist.
Ja, da gibts auch noch viele technische Details…
Wer das alles versteht, SUPER! Helfen sie diesen Leute das zu reparieren.
!
Also lieber BenutzerInnen…
Einfach mal die eigene Webseite da eingeben…
Reicht das Ergebnis an die IT Abteilung weiter… Oder an die Webagentur, die Personen die die Webseite machen.
!
Ops sollte das verstehen und erkennen, daß da was eher streng riecht.

82. Ist ein F immer gleich schlimm?
!
Nein! Ein F gibts auch bei nichtüberprüfbaren Zertifikaten! zB CA-Cert.
Ein Zertifikat, welches nicht überprüft werden kann, ist nicht auch zwangsläufig ungültig.
Die Linuxwochen bekämen sonst ein B.
Ja, bekämen, denn in dem Fall IST das Zertifikat tatsächlich ungültig… und nur 1024bit RSA… und überhaupt…
!
If trust issues are ignored…
B

83. Overall Rating
FIf trust issues are ignored: B
Assessed on: Fri May 09 00:22:52 UTC 2014 | HIDDEN | Clear cache Scan Another »
SSL Report: linuxwochen.at (195.230.168.88)
Summary
Documentation: SSL/TLS Deployment Best Practices, SSL Server Rating Guide, and OpenSSL Cookbook.
This server is not vulnerable to the Heartbleed attack. (Experimental)
This server's certificate is not trusted. Grade set to F.
The server private key is not strong enough. Grade capped to B.
The server does not support Forward Secrecy with the reference browsers. MORE INFO »
Authentication
Server Key and Certificate #1
Common names *.icb.at MISMATCH
Alternative names -
Valid from Mon Oct 01 13:07:38 UTC 2012
Valid until Wed Oct 01 13:07:38 UTC 2014 (expires in 4 months and 25 days)
Key RSA 1024 bits WEAK
Weak key (Debian) No
Issuer CAcert Class 3 Root
Signature algorithm SHA1withRSA
Extended Validation No
Revocation information CRL, OCSP
0 20 40 60 80 100
Certificate 0
Protocol Support 90
Key Exchange 80
Cipher Strength 90
Ist ein F immer gleich schlimm?
!
Nein! Ein F gibts auch bei nichtüberprüfbaren Zertifikaten! zB CA-Cert.
Ein Zertifikat, welches nicht überprüft werden kann, ist nicht auch zwangsläufig ungültig.
Die Linuxwochen bekämen sonst ein B.
Ja, bekämen, denn in dem Fall IST das Zertifikat tatsächlich ungültig… und nur 1024bit RSA… und überhaupt…
!
If trust issues are ignored…
B

84. Home Projects Qualys.com Contact
Overall Rating
C
Assessed on: Thu May 08 21:52:57 UTC 2014 | Clear cache Scan Another »
You are here: Home > Projects > SSL Server Test > nsa.gov
SSL Report: nsa.gov (23.63.180.226)
Summary
Documentation: SSL/TLS Deployment Best Practices, SSL Server Rating Guide, and OpenSSL Cookbook.
This server is not vulnerable to the Heartbleed attack. (Experimental)
The server does not support Forward Secrecy with the reference browsers. MORE INFO »
Authentication
Server Key and Certificate #1
Common names www.nsa.gov
Alternative names www2.nsa.gov www.nsa.gov nsa.gov
Prefix handling Both (with and without WWW)
Valid from Fri Apr 18 16:46:53 UTC 2014
Valid until Tue Oct 21 04:48:03 UTC 2014 (expires in 5 months and 15 days)
Key RSA 2048 bits
Weak key (Debian) No
Issuer GeoTrust SSL CA
Signature algorithm SHA1withRSA
Extended Validation No
Revocation information CRL, OCSP
Revocation status Good (not revoked)
Trusted Yes
Additional Certificates (if supplied)
Certificates provided 2 (2317 bytes)
Chain issues None
#2
Subject
GeoTrust SSL CA
SHA1: 780a06f6e9b4061cad0c6502710606eb535f1c26
Valid until Tue Feb 18 22:39:26 UTC 2020 (expires in 5 years and 9 months)
0 20 40 60 80 100
Certificate 100
Protocol Support 90
Key Exchange 40
Cipher Strength 60
Von anderen wiederrum würde man das auch nicht besser erwarten…

85. 3 In trust store SHA1: de28f4a4ffe5b92fa3c503d1a349a7f9962a8212
RSA 2048 bits / SHA1withRSA
Configuration
Protocols
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 Yes
SSL 2 No
Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x3) WEAK 40
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6) WEAK 40
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8) WEAK 40
TLS_RSA_WITH_DES_CBC_SHA (0x9) WEAK 56
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_IDEA_CBC_SHA (0x7) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
Handshake Simulation
Android 2.3.7 No SNI 2 TLS 1.0 TLS_RSA_WITH_RC4_128_MD5 (0x4) No FS RC4 128
Android 4.0.4 TLS 1.0 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256
Android 4.1.1 TLS 1.0 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256
Android 4.2.2 TLS 1.0 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256
Android 4.3 TLS 1.0 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256
Android 4.4.2 TLS 1.2 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256
BingBot Dec 2013 No SNI 2 TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) No FS 128
BingPreview Dec 2013 TLS 1.0 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256
Chrome 33 / Win 7 R TLS 1.2 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256
Firefox 24.2.0 ESR / Win 7 TLS 1.0 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256
Von anderen wiederrum würde man das auch nicht besser erwarten…
Das passiert auch den besten der besten der besten…

86. Nicht übersehen, daß es mehrer Webserver geben könnte…
schon besser… aber noch alle server gut gemacht.
Einfach mal ALLE Server durchtesten. Damit da nicht einer übersehen.
!
Warning, inconsisten server configuration…
!
Es sollten schon alle Server gleich konfiguriert sein…
Das kann das zum Beispiel so aussehen…

87. Cloud Services…
Cloud ist ja so ein toller Marketing Begriff der bedeutet: … ich habe mehr als einen server und ich weiß nicht genau wo sie
sind.
!
Ja, das kann auch mehrere Server betreffen…
immerhin ist die Konfiguration konsistent!
!
Einfach mal die eigenen Cloud Anbieter ein wenig unter die Lupe nehmen…

88. Home Projects Qualys.com Contact
Assessed on: Fri May 09 00:38:35 UTC 2014 | HIDDEN | Clear cache Scan Another >>
You are here: Home > Projects > SSL Server Test > ubuntu.com
SSL Report: ubuntu.com
Server Domain(s) Test time Grade
1
91.189.90.58
www-ubuntu-com.avocado.canonical.com
No secure protocols supported
www.ubuntu.com
Fri May 09 00:36:50 UTC 2014
Duration: 52.559 sec
-
2
91.189.94.156
vostok.canonical.com
No secure protocols supported
ubuntu.com
Fri May 09 00:37:43 UTC 2014
Duration: 52.582 sec
-
SSL Report v1.9.22
Copyright © 2009-2014 Qualys, Inc. All Rights Reserved. Terms and Conditions
Das ist zwar auch eine konsistente Konfiguration…
!
No secure protocols supported.
Das ist ja fast noch schlimmer als lauter F… Klartext… wirklich?

89. Besser… noch nicht optimal. aber schon mal besser…
in den Detail sind auch da noch ein paar Hunde begraben… aber zumindest steht die Hütte nicht mehr in Flammen
!
Und ja, Fedora und Redhat sind auch nicht schlechter. :-D

90. Wenn ich sowas bekomme… dann ist das schon deutlich besser.
Das ist doch gleich viel freundlicher. So sollte das aussehen…
Nicht vergessen… Die Unternehmensleitung kann das testen.
Jede Benutzerin kann das testen.
Die IT Abteilung kann das testen.
!
Und nicht vergessen… Ihre Kunden können das auch! Jederzeit.
Und wer sich jetzt denkt, na dann blockiere ich solche Tests dann sieht man das nicht. Das schafft zurecht noch mehr
Mistrauen.
!
Zusätzlich: Webapplikation testen mit den OWASP Richtlinien.
Open Web Application Security Project (OWASP)
!
Protocol Support: Warum nur 95%?
97% gibts wemma TLS 1.0 abschaltet, 100% wenn NUR noch TLS 1.2 aktiv ist.

91. Email
https://starttls.info/
Email… verwendet das noch wer?
Seit 1982 quasi unverändert…
!
Naja… Altlasten…

92. Auch hier… muß ich nicht besonders technisch versiert sein um zu erkennen, daß das nicht wirklich gut ist… wenn emails
überhaupt nicht verschlüsselt werden! Also wenn das schon mal die Mailserver ignorieren…
!
auch hier wieder…
Testseite aufrufen… Servername eingeben, und wenn sie den nicht wissen… das ist der Teil nach dem @…
oder einfach die eigenen email adressen mal checken… SO einfach.
!
!

93. Ein anderer Test…
Beim einen kamma nichtmal testen… der andere… ein C…
!
maximal 56bit, also Verschlüsselung am Stand von 1976…
Ihr Smartphone hat genug Rechenleistung um das zu knacken…
!
Handlungsbedarf.
Wollen sie mit solchen Mailserver ihre Firmendaten durch die Gegend schicken?
Verträge? Dokumente ihrer Clienten? Medizinisches? Geheime Produktentwicklungen?

94. Das geht auch besser. Da sind zumindest die MAilserver mal ordentlich konfiguriert.
!
Nein, das ist kein Service Provider
Keine IT-Sicherheitsfirma…
!
Netz-KünstlerInnen
die schaffen das auch… schafft ihr Unternehmen das auch?
!
Ja, die Tests sind noch ein bissl ausbaufähig, nicht alles ist perfekt. Steht außer Zweifel.
Aber wenn ich da ein F bekomme…

96. 27%
39%34%
starttls.info/stats
39% OK
über 60% verschlüsseln schlecht, wenn überhaupt…
!
248.482 unique mail servers rated.
163.872 servers support STARTTLS.
84.610 servers do not support STARTTLS.

97. security@example.org
RFC 2142
Einrichten…
!
RFC 2142 empfielt das auch! (1997),
Winamp (1997) Elton John:
Something About The Way You Look Tonight / Candle In The Wind 1997
!
Wenn ihr die noch nicht habt! Einrichten!
Idealerweise mit GPG key.

98. Chat
https://xmpp.net/
Jabber oder XMPP… also Firmenweite Collaboration Tools.
!
!
XMPP: RFC… weils im vorherigen Talk gefragt wurde:
RFC3920 - 3923 erste Spezifikationen (2004)
O-Zone
Dragostea din teï
Miahiii, miaahoo… maiajahahaaaa

99. Ihr kennt das inzwischen…
die technischen Details stehen auch hier unten… aber die grobe Bewertung… is einfach verständlich.
weiter Beispiele erspare ich euch mal…
Client to Server UND auch für Federation als Server to Server.
Dauert merklich länger als Webserver Tests, weil auch komplexer.
Ist oft auch schwieriger zu fixen. Bitte UPDATED eure Jabber Daemons!
ältere Daemons haben die Crypto oft Hardgecoded! (WTF Moments…)

100. A
Sag’ ja zu A… ein alter Slogan der österreichischen wirtschaft…
Ein A sollte es sein.
Wer das bei den Tests bekommt… ist schon mal besser als die meisten anderen. JA, leider.
Wenns schlechter als ein A ist… Handlungsbedarf. JE F, desto mehr bedarf

101. Handlungsbedar F
Ein A sollte es sein.
Wer das bei den Tests bekommt… ist schon mal besser als die meisten anderen. JA, leider.
Wenns schlechter als ein A ist… Handlungsbedarf. JE F, desto mehr bedarf
F wie Feuer löschen… auch keine Schlechte Assoziation.
verdammt schnell auch noch.
!
Das so zu testen ist NICHT perfekt, aber es ist leicht verständlich, geht schnell und irh könnte jeden Servie der public am
Internet hängt damit testen.
!
Abgang: Pepi
Auftritt: Martin

102. Verschlüsselung
als Standard
Verschlüsselung muß zum Standard werden, Klartext die Ausnahme.
Auch wenn Verschlüsselung kein allheilmittel ist wollen wir das so gut wie irgendwie möglich machen.

103. $ testen
Auch auf der command line.
Warum auf der Command line?
nicht alle Services sind public facing. dort kann ich die Webtools nicht verwenden.
Automatisierungen (auch regelmäßige) sind einfacher

104. $ openssl
Ja, wirklich
Ja, OpenSSL hat Bugs… wir werden da heuer noch viele mehr sehen und noch oft unsere Passwörter und Keys und OAuth
Tokens ändern müssen…

105. $ openssl version
OpenSSL 1.0.1g 7 Apr 2014
Aufpassen Debian! Backports!
!
1.0.1e 11Feb 2013 vulnerable!
1.0.1e 7 Apr 2014 nicht! (obwohl nicht 1.0.1g)
!

106. $ openssl version
OpenSSL 0.9.8y 5 Feb 2013
Kann auch passieren… warum ist das relevant?
Weil unterschiedliche Versionen unterschiedliche Bugs haben und unterschiedliche Ciphers unterstützen.
!
wird bei Cipherstrings relevant

107. openssl ciphers
'ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH'
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-
SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-
SHA:DES-CBC3-SHA:DHE-RSA-SEED-SHA:DHE-DSS-
SEED-SHA:SEED-SHA:DHE-RSA-AES128-SHA:DHE-DSS-
AES128-SHA:AES128-SHA:RC4-SHA
Kann auch passieren… warum ist das relevant?
Weil unterschiedliche Versionen unterschiedliche Bugs haben und unterschiedliche Ciphers unterstützen.
!
wird bei Cipherstrings relevant
!
Großzügiger Cipher String, der nach @STRENGTH von OpenSSL sortiert wird. Nicht unbedingt das Gelbe vom Ei.
Hier mit OpenSSL 1.0.1 gezeigt.

108. EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH
+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:
+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SS
Lv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!
DSS:!RC4:!SEED:!IDEA:!ECDSA:CAMELLIA256-
SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
Bettercrypto cipherstring B
Beispiel…
Ich will den cipherstring B von bettercrypto verwenden… und wundere mich warum ich beim SSLLabs Trotzdem
nicht das Ergebnis bekomme, das ich erwarte.
!
Einfach mal schauen was OpenSSL WIRKLICH davon verwendet. Was es nicht kennt, fritst es nicht.
!
Der BetterCrypto.org CipherString B sieht ca so aus.

109. AES256-SHA:AES128-SHA
openssl 0.9.8
bei 0.9.8 bleibt da nicht viel übrig…
!
Das sind zwar gute Ciphers, aber im CBC mode und der ist anfällig auf die BEAST attacke.
!
Eigentlich SOLLTE da mehr sein, es fehlen die DHE (Diffie Hellman Ephemeral) Ciphers mit Forward Secrecy (was
man haben will)
Aaaron hat da einen Bug im Cipher String Parser von OpenSSL 0.9.8 entdeckt der die vergisst. Aaron wegen
details fragen?

110. DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-
SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-
AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-
AES128-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-
RSA-AES128-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-
RSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-
CAMELLIA128-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-
AES128-SHA:CAMELLIA256-SHA:AES256-
SHA:CAMELLIA128-SHA:AES128-SHA
openssl 1.0.1g
bei 1.0.1g sieht das anders aus. Deutlich besser.
Das kann auch bei der gleichen Version je nach Distro sehr unterschiedlich sein.
zB ECC… ciphers sind erst seit kurzem in CentOS/RedHat drinnen.
!
Auch die REIHENFOLGE ist relevant und @STRENGTH sortiert da nicht unbedingt so wie Du das wirklich haben
möchtest.
!
was da jetzt hier am Slide steht welche ciphers das sind ist egal…
wichtig ist zu verstehen, daß Du das SO testen kannst was WIRKLICH genommen wird!

111. $ cipherscan
https://github.com/jvehent/cipherscan
Laufende Server testen!
!
Auch wenn sie nicht im Internet verfügbar sind.
(Geht mit den Webtools ja nicht wenns nur im Intranet sind.)

112. cipherscan
-o ~/openssl/apps/openssl
-starttls xmpp
jabber.at:5222
Damit kamma zum Beispiel schauen was der Jabber.at Server so an Verschlüsselung bekommt. (Das Ergebnis ist ein A-)
!
XMPP: RFC… weils im vorherigen Talk gefragt wurde:
RFC3920 - 3923 erste Spezifikationen (2004)
O-Zone
Dragostea din teï
Miahiii, miaahoo… maiajahahaaaa

113. prio ciphersuite protocols pfs_keysize
1 ECDHE-RSA-AES256-GCM-SHA384 SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
2 ECDHE-RSA-AES256-SHA384 SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
3 ECDHE-RSA-AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
4 DHE-RSA-AES256-GCM-SHA384 SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
5 DHE-RSA-AES256-SHA256 SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
6 DHE-RSA-AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
7 DHE-RSA-CAMELLIA256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
8 AES256-GCM-SHA384 SSLv3,TLSv1,TLSv1.1,TLSv1.2
9 AES256-SHA256 SSLv3,TLSv1,TLSv1.1,TLSv1.2
10 AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
11 CAMELLIA256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
12 ECDHE-RSA-DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
13 DHE-RSA-DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
14 DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
15 ECDHE-RSA-AES128-GCM-SHA256 SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
16 ECDHE-RSA-AES128-SHA256 SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
17 ECDHE-RSA-AES128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
18 DHE-RSA-AES128-GCM-SHA256 SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
19 DHE-RSA-AES128-SHA256 SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
20 DHE-RSA-AES128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
21 DHE-RSA-SEED-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
22 DHE-RSA-CAMELLIA128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
23 AES128-GCM-SHA256 SSLv3,TLSv1,TLSv1.1,TLSv1.2
24 AES128-SHA256 SSLv3,TLSv1,TLSv1.1,TLSv1.2
25 AES128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
26 SEED-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
27 CAMELLIA128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
28 ECDHE-RSA-RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
29 RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
30 RC4-MD5 SSLv3,TLSv1,TLSv1.1,TLSv1.2
cipherscan mit openssl 1.0.1g
So kanns dann aussehen wemma die genaue Reihenfolge sehen will die Server dann tatsächlich nehmen.
!
cipherscan wrapped um OpenSSL rum.
!
Zum Testen, idealerweise selbst compiltes OpenSSL verwenden.
!
Zeigt Cipher Order, Suite, Protokolle, Elliptic Curves, DH Difie Hellman Parameter Size in Bits

114. ECDHE-RSA-AES256-GCM-SHA384
!
SSLv3,TLSv1,TLSv1.1,TLSv1.2
!
ECDH,P-256,256bits
NIST: National Institute of Standards and Technology

115. $ nmap
Auch auf der command line.

116. nmap --script
ssl-cert,ssl-enum-ciphers
-p 25,143,465,587,993 example.com
Braucht ein einigermaßen aktuelles nmap
Bei mir ist das 6.4…
!
25 SMTP
143 IMAP
465 SMTS/S
587 Submission
993 IMAP/S

117. Nmap scan report for server.example.org
Host is up (1.3s latency).
PORT STATE SERVICE
25/tcp open smtp
993/tcp open imaps
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_SEED_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_SEED_CBC_SHA - strong
| compressors:
nmap
Strong… naja, diskussionswürdig sagen wir mal. nmap macht daas rein an der Cipbit länge fet und ignoriert die
cipher bei der bewertung.
Seed sollte da eigentlich nicht unterstützt sein.
3DES auch nicht unbedingt.
!
Wobei bei mailservern… incoming sollte man alles unterstüzsden, beser schlechte crypto als plaintext.
!
Das „strong“ ist eher eine fragwürdige Klassifizierung. nmap wertet alles ≥128bit als strong, lässt aber den
Algorithmus dabei komplett außer Acht.

118. $ telnet
Der war gut… wer kann STARTTLS von hand machen?
!

119. $ openssl s_client
damit geht das einfacher…
Nicht unbedingt besonders bequem… cipherscan macht das bequem, aber halt nur für einen sehr speziellen
Anwendungszweck.

120. openssl s_client -connect
webmail.example.com:443
-servername webmail.example.com
openssl…
als telnet ersatz
geht auch für HTTP/1.1 Seiten, also auch SNI gehostetes. (Gibts ab TLS 1.0)
!
SNI: Server Name Indication

121. openssl s_client -connect
example.com:443 -tls1
-tlsextdebug -status
< /dev/null | grep OCSP
OCSP stapling
OCSP Stapling…
OCSP: Online Certificate Status Protocoll
RFC 6960 (2013, obsoletes 2560 (1999))
!
wir wissen…
CRL skaliert nicht…
CRL: Certificate Revocation List
OCSP funktioniert nicht überall, hat privacy issues, ist nicht aufgedreht…
!
OCSP unterstützen wenige Browser… und andere Services könnens kaum wenn überhaupt.
!
Ist aber auch nicht viel Arbeit das zu konfiguriereren und zu testen…
!
1999: Lou Bega
Mambo No. 5 (A Little Bit Of...)
2013: Avicii
Wake Me Up!

122. depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN =
DigiCert High Assurance CA-3
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
OCSP response:
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
OCSP stapling
OCSP Stapling…
wir wissen… OCSP funktioniert nicht, hat privacy issues.
CRL skaliert nicht…
OCSP unterstützen wenige Browser… und andere Services könnens kaum wenn überhaupt.
!
OCSP Response Status: successful (0x0)

123. root@bettercrypto.org:~ # cat .todo
!
Test
Deploy strong crypto
Test again
Eure Hausaufgaben!

124. Danke
Just a blinking cursor for 7 times, then fading out.
!
I see a white slide and I want to fade it black…

125. Just a black slide for the end.