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

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

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.

Applied Crypto Hardening

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

Das Internet ist gefährlich

Das internet ist gefährlich…

＼(=^‥^)

Katzen, überall lauern Katzen! Und wir wissen alle: Katzen sind Raubtiere!

＼(=^‥^)

Und wir wissen alle: Katzen sind gefährliche Raubtiere! !CAT CONTENT

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

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

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

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

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!

und mit handschuhen kamma nicht tippen. !Copyright von diesem Bild ist NICHT geklärt!

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/

•

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!

Eine kurze Geschichte…

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

SSLv1

1970 2014

1994

Nur Netscape intern… (ca. 1994) wurde also nie veröffentlicht.

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)

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

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

SSLv3

1970 2014

1996

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

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

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

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.

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.

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.

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.

TLS Handshake

TLS Handshake

Wer weiß wie das genau funktioniert? Wir wiederholen das mal schnell…

Application Data

CertificateVerify ClientKeyExchange ChangeCipherSpec

Finished

ClientHelloACK

SYNSYN 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.

Angriffsvektoren

Version Rollback (SSLv3+)

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

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.

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.

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

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

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

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

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) !

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,..

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,..

…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)]

Abgang: Aaron Auftritt: Pepi !Bettercrypto YAY

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

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.

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:

Was ist das nun? WTF? Ein praktischer Guide

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?)

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?

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.

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

Umfang

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

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?

Webserver

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

Proxy

Squid, Pound

Mailserver

postfix, dovecot, cyrus, exim, grundsätzlich SMTP

VPN

IPSec, L2TP, OpenVPN, OpenSwan, tinc, ASA, Checkpoint

Datenbanken

mySQL, Postgres, DB2, Oracle

Kerberos

MIT Version, Heimdal ist in Arbeit und Review.

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.

PGP/GnuPG

Nur Inhaltsverschlüsselung. !

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.

Lights out management

IPMI, ILO, etc.

Schlüssel

keylengths, types of keys, Key Exchange, Authentication, MACs

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.

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?

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)

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.

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.

Review

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

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.

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…) !

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. !

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. !

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!

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

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!

Webserverhttps://ssllabs.com/

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…

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!

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.

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

Home Projects Qualys.com Contact

Overall Rating

FIf trust issues are ignored: B

Assessed on: Fri May 09 00:22:52 UTC 2014 | HIDDEN | Clear cache Scan Another »

You are here: Home > Projects > SSL Server Test > linuxwochen.at

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

Revocation status Unchecked (only trusted certificates can be checked)

Trusted No NOT TRUSTED (Why?)

Additional Certificates (if supplied)

Certificates provided 1 (1067 bytes)

Chain issues Incomplete

Certification Paths

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

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

SubjectGeoTrust 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…

Valid until Tue Feb 18 22:39:26 UTC 2020 (expires in 5 years and 9 months)

Key RSA 2048 bits

Issuer GeoTrust Global CA

Signature algorithm SHA1withRSA

Certification Paths

Path #1: Trusted

1 Sent by server

www.nsa.gov

SHA1: ac40f58487a796c69efc7d62f513f523a1cdd9c6

RSA 2048 bits / SHA1withRSA

2 Sent by server

GeoTrust SSL CA

SHA1: 780a06f6e9b4061cad0c6502710606eb535f1c26

RSA 2048 bits / SHA1withRSA

3 In trust store

GeoTrust Global CA

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…

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…

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…

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

191.189.90.58 www-ubuntu-com.avocado.canonical.com No secure protocols supported

www.ubuntu.comFri May 09 00:36:50 UTC 2014

Duration: 52.559 sec-

291.189.94.156 vostok.canonical.com No secure protocols supported

ubuntu.comFri 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?

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

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.

Emailhttps://starttls.info/

Email… verwendet das noch wer? Seit 1982 quasi unverändert… !Naja… Altlasten…

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. !!

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?

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…

https://starttls.info/stats

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.

security@example.orgRFC 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.

Chathttps://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

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…)

ASag’ 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

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

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.

$ 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

$ opensslJa, 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…

$ 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) !

$ 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

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.

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:!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.

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?

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!

$ cipherscanhttps://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.)

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

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

ECDHE-RSA-AES256-GCM-SHA384 !

SSLv3,TLSv1,TLSv1.1,TLSv1.2 !

ECDH,P-256,256bits

NIST: National Institute of Standards and Technology

$ nmap

Auch auf der command line.

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

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.

$ telnet

Der war gut… wer kann STARTTLS von hand machen? !

$ openssl s_client

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

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

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!

depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance CA-3verify error:num=20:unable to get local issuer certificateverify return:0DONEOCSP 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)

root@bettercrypto.org:~ # cat .todo !

Test

Deploy strong crypto

Test again

Eure Hausaufgaben!

Danke

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

Just a black slide for the end.