Archive for the ‘Sicherheit’ tag
TLS 1.0/1.1 Abschaltung: Eigene Versionsverteilung herausfinden und serverseitig abschalten
Browserhersteller planen, ab 2020 die TLS-Versionen 1.0 und 1.1 nicht mehr zu unterstützen:
https://www.heise.de/security/meldung/Verschluesselung-im-Web-Chrome-Firefox-Co-verabschieden-sich-von-TLS-1-0-1-1-4191864.html
https://www.golem.de/news/https-browser-wollen-alte-tls-versionen-2020-abschalten-1810-137135.html
Mit den richtigen Einstellungen und Ciphers ist TLS 1.0 noch sicher zu betreiben, aber man muss es eben richtig konfigurieren, wenn man alles beachten will: BEAST, POODLE, Sloth, DROWN, CRIME und BREACH, RC4, MD5, ROBOT, Sweet32, Bleichenbacher, Heartbleed, FREAK und Logjam, …
Da es schon ein Dutzend Probleme gab in den letzten Jahren, möchte man sich des Problems lieber früher als später entledigen, gern bevor es zum großen Knall kommt. TLS 1.2 ist nicht gegen all diese Probleme gewappnet, man muss nach wie vor aufpassen wie man die Ciphers konfiguriert. Aber man kann weniger Fehler machen. Und das Ziel ist es, TLS 1.3 zu nutzen, wo all dieses Probleme gelöst sind, da alles unsichere radikal entfernt wurde, und nicht mehr 100 Ciphers zur Auswahl stehen, sondern nur noch eine Handvoll. Weniger Auswahl ist eben manchmal besser.
Ich schrieb 2014 über die Abschaltung von SSLv3, und im Dezember 2017 darüber, dass ab dem 30. Juni 2018 im Kreditkarten-/Payment-Bereich TLS 1.2 als Minimum genutzt werden muss.
SSLv3: Uralt, bröckelig, abschalten!
[EDIT] Tja, da schreibt man gerade drüber und ein paar Minuten später wird die Lücke veröffentlicht: Poodle . Details im Google Blog. Das Problem liegt im SSLv3 Protokoll selbst, es wird keine Patches geben, es muss ausgeschaltet werden. Eigentlich wäre nur uralt-Software wie der IE6 unter WindowsXP betroffen, aber durch Downgrade-Attacken die bei TLS möglich sind, sind alle betroffen und können auf das schwache SSLv3 downgegraded werden wenn es denn auf Server+Client unterstützt wird. Also abschalten!
Seit 2 Tagen gibt es Gerüchte über eine kritische Lücke in SSLv3. Aktuell (Mitternacht) ist noch nichts publik geworden außer ein eventuell interessanter Patch von Microsoft, und eine Falschmeldung eines OpenBSD-Patches, der in Wirklichkeit schon einige Monate alt ist.
Sicher ist dass SSLv3 18 Jahr alt ist, und vor 15 Jahren durch TLSv1.0 abgelöst wurde. Bei mail.de haben wir SSLv3 bereits vor einigen Monaten deaktiviert auf den Webseiten da kaum ein Client dieses alte Protokoll benutzte außer der IE6 auf WindowsXP Systemen. Da wir den IE6 eh schon lange nicht mehr unterstützen war es sehr einfach, SSLv3 abzuschalten.
Für die anderen Protokolle wie IMAP, POP3 und SMTP haben wir SSLv3 allerdings noch aktiviert gelassen da es noch diverse E-Mail-Clients gibt die TLS >1.0 noch nicht beherrschen. Auch einige ältere Smartphones beherrschen noch kein TLS1.0 oder neuer, sodass es Sinn machte es noch aktiviert zu lassen, denn es gab auch (noch) keine bekannten Angriffsvektoren.
HSTS – HTTP Strict Transport Security: Hast’s schon?
HSTS steht für HTTP Strict Transport Security und ist ein HTTP-Header, den Webseiten nutzen sollten die per HTTPS erreichbar sind.
Wenn ein Benutzer in seinen Browser „webseite.de“ eintippt wird der Browser zuerst versuchen die Webseite unverschlüsselt per HTTP zu erreichen. Genau das ist aber ein Schwachpunkt wenn man sich in einem unsicheren Netzwerk aufhält oder befürchtet, dass irgendwo auf dem Weg zum Zielserver jemand den Request abfangen und verändern könnte (Hallo NSA!), dann sollte man vermeiden eine Webseite unverschlüsselt per HTTP aufzurufen die auch per HTTPS erreichbar ist. Dazu gibt es beispielsweise das Firefox-Addon HTTPS Everywhere, in dem eine Liste eingebaut ist mit Domains, die besser verschlüsselt angesurft werden sollten. Wer nicht auf dieser Liste enthalten ist oder auch Besuchern, die dieses Firefox-Addon nicht installiert haben, mehr Sicherheit bieten möchte, nutzt HSTS.
Fast niemand tippt bei einer Seite, die per HTTPS erreichbar ist, immer brav manuell „https://webseite.de“ ein, die meisten schreiben einfach „webseite.de“ und werden dann vom Webserver automatisch auf die HTTPS-Variante weitergeleitet.
SSL-Sicherheit testen
Aus Interesse habe ich mal einige bekanntere Webseiten durch zwei SSL-Checks laufen lassen, um zu gucken wer patzt bzw. wer vieles richtig macht. Dazu habe ich die Online-Services von ssllabs.com und wormly.com genutzt. Einfach Domain eingeben, und schon hat man Ergebnisse. Dabei ist der Test von wormly.com ausführlicher und strenger, deshalb ist die Tabelle auch danach sortiert. Eigentlicher Ansporn war der Vergleich von mail.de mit anderen E-Mail-Anbietern (blau markiert), und dann habe ich noch weitere hinzufügt:
Hilfe, ich habe unsichere Passwörter in meiner Datenbank!
Seit einigen Monaten sollte jedem, der die IT-Nachrichten und sogar die Mainstream-Presse etwas verfolgt, klargeworden sein dass es keine besonders kluge Idee ist, Passwörter von Kunden im Klartext zu speichern. Hashing ist nach wie vor eine gute Idee, wenn man den richtigen Algorithmus verwendet. Hashes sollten nur noch eingesetzt werden wenn man einen Salt mit einbaut, aber auch dan gibt es noch große Unterschiede zwischen alten Verfahren wie MD5/SHA und neueren Algorithmen wie bcrypt. Dank Artikeln zum Thema bcrypt von Oliver sollte auch jedem mindestens eine Lösung bekannt sein die man heutzutage einsetzen sollte. Doch wie macht man das in der Praxis, wie migriert man die bestehenden Daten zum neuen bcrypt Verfahren? Darauf möchte ich hier etwas eingehen.
Ein neues Projekt
Wenn ein neues Projekt gestartet und auf der grünen Wiese begonnen wird ist alles sehr einfach. Neue Kunden- bzw. Benutzerpasswörter werden einfach mittels bcrypt gehasht und dann in einer Datenbank gespeichert. Man kann natürlich auch Textdateien, Arbeitsspeicher oder etwas anderes nehmen, Hauptsache man hat das gehashte Passwort zur Hand wenn sich der Benutzer einloggen möchte und kann das eingegebene Passwort gegen das Gespeicherte prüfen.
