Autor: kernel-error (Seite 29 von 48)

Unsichere Protokolle und Chiper aus Postfix, Dovecot und Apache2 sind schonmal weg!

Jetzt ist mein xmpp Jabber Server ejabberd dran… Auch hier müssen die Protokolle SSLv2 sowie SSLv3 weichen. Nur alles größer TLSv1 ist erlaubt…. Bei den Chipern fliegt alles raus das „böse“ ist… Zum Beispiel MD5, RC4 usw. usw… Natürlich werden auch die ECDHE Cipher suite aktiviert um Forward secrecy zu unterstützen.

Test lässt sich alles am besten über die folgenden Links. Einmal aus der Sicht eines Client und einemal aus der Serversicht!
Client: https://xmpp.net/result.php?id=19649
Server: https://xmpp.net/result.php?id=19650

Next…

Ich habe den Facebook Like Button und Google Plus One Button nun doch von der Webseite geworfen. Ich kann ja schlecht immer darauf schimpfen und es dann doch selbst in die Webseite schrauben, oder?
Klar sammelt man darüber den einen oder anderen Like oder Plus One ein und natürlich „hilft“ einem dieses. Kosten nutzen passt aber einfach nicht 

Vor allem mein Gewissen macht hier nicht mit. Zudem muss jeder Besucher noch wieder irgendwelchen externen Code nachladen das ggf. nicht verschlüsselt und die Besucher müssen sich so noch einmal zusätzlich traken lassen und das alles für was? Genau…

*flup* weg sind die Buttons!

Huch, was ist denn hier passiert? Der Nachfolger von rfc-ignorant.org, rfc-ignorant.de, ist „weg“. Zugegeben, das Projekt ist nie so richtig online gegangen … Es gab jedoch eine Webseite, eine Mailingliste und eine abfragbare DNS-RBL.

Am Samstag, dem 22.02.2014, war dann plötzlich alles verschwunden – für mich völlig unerwartet. Die Domain-Webseite (http://www.rfc-ignorant.de/) leitet jetzt auf einen typischen Domainparker um, und ich könnte sie sogar kaufen. Alle Dienste sind tot. Ich habe davon rein gar nichts mitbekommen. Dabei hatte ich noch leise die Hoffnung, dass das Team irgendwann mit einem funktionierenden Service zurückkommt. Zugegeben, an mir gehen manchmal Informationen vorbei, aber ich hätte zumindest erwartet, dass auf der Mailingliste etwas dazu zu lesen ist.

Oder hat hier ein Domain-Snapper zugeschlagen? Ich sollte wohl mal die Ente fragen – vielleicht hat sie ja Antworten.

Mir rennt hier gerade eine Kiste aus ?Schweden? ganz schön die Bude ein und versucht seinen SPAM bei mir abzuladen..

Alles von post.lidingo.se[194.22.4.7]… Ein wc -l sagt mir nach einem grep mit | der letzten Stunde: 7606

Die Kiste steht bereits ganz fett in allen möglichen RBL Listen, was ist denn da los? Na ja, für Spaß habe ich noch mal etwas in deren Abuse Mailbox gekippt, vielleicht reagiert ja jemand 😛

Sind die Schweden jetzt die neuen „Chinesen“? Solche Aktionen bin ich sonst eher von dort gewohnt. Da kann man sich die abuse mail aber auch meist sparen!

So long…

 

 

ownCloud Tasks Aufgaben synchronisieren

Nachdem ich nun am Postfix hinsichtlich der SSL / TLS Sicherheit einige Einstellungen vorgenommen habe und sogar die nutzbare Cipher Suite eingeschränkt habe, da interessiert mich natürlich welche von den Clients genutzt werden. Daher fische ich für meinen Testzeitraum einfach mal per Regex (Regular expression) und egrep ein paar Infos aus dem Logfile und lege es hier zur Begutachtung hin 🙂

So lässt sich nun gut verfolgen, welche Cipher, wie oft genutzt wird.

 

 

Ich habe vor kurzem etwas über sichere SSL / TLS Einstellungen beim Mozilla Firefox geschrieben. Dabei habe ich etwas die Serveradmins in die Pflicht genommen, dafür zu sorgen dass ihre Seite so konfiguriert wird, dass erst überhaupt keine unsicheren Verfahren angeboten werden. Inzwischen sind ein paar Fragen bei mir angekommen wie ich es umgesetzt habe.

Begonnen habe ich mit dem Strict-Transport-Security Header. Sind diese gesetzt, und ein Client verbindet sich verschlüsselt (SSL / TLS) mit dem Webserver sagt ihm der Server: „Schön das du da bist. Ach ja, verbinde dich bitte die nächsten X Tage nur noch verschlüsselt mit mir, ok?“.

Normalerweise richten sich Webbrowser an diese „Bitte“ des Servers. Damit wird verhindert das ein Angreifer den Client überredet sich unverschlüsselt mit einem anderen Server zu unterhalten oder von der verschlüsselten Übertragung zur unverschlüsselten zu wechseln. Denn würde ein solcher Wechsel klappen, könnte der Angreifer ja ab dem Moment mitlesen!

Damit ich nun also die Strict-Transport-Security nutzen kann muss zuerst das Apache Modul headers aktiviert werden. Dieses erledige ich mit:

$ a2enmod headers

 Fehlt nur noch eine weitere Zeile in der vhost Konfiguration:

Header always set Strict-Transport-Security "max-age=15552000"

max-age gibt einen Zeitwert in Sekunden vor. Dieser darf/sollte nicht kleiner als 180 Tage sein. 15552000 entspricht dabei genau 180 Tagen.

Damit wird also schon mal jeder Client für die kommenden 180 Tag versuchen verschlüsselt mit mir zu sprechen. Natürlich ist an dieser Stelle zu bedenken, wenn ich mich plötzlich dazu entscheiden sollte SSL/TLS nicht mehr anzubieten, werden es die Clients denn noch weiter so probieren. Also aufpassen….

Auf zu ssl crime attack… Dieser Angriff ist möglich wenn die SSLCompression aktiviert ist. Ich erweitere also meine Konfiguration des vhosts im Apache um folgende Zeile:

SSLCompression off

Um direkt die unsicheren und veralteten Protokolle zu deaktivieren folgt auf dem Fuße:

SSLProtocol +ALL -SSLv3 -SSLv2

Damit sich gleich alle an die Reihenfolge meiner zugelassenen Cipher Suite halten, gebe ich dieses noch einmal expliziet vor:

SSLHonorCipherOrder On

Fehlen nur noch die zu verwendenden Cipher Suites…. Dabei beginne ich mit den gewünschten Favoriten und gehe Stück für Stück weiter runter. Am Ende verbiete ich noch diese, welche ich auf keinen Fall nutzen will (alles vor dem ein Ausrufezeichen „!“ steht).

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4

 Nur noch den Apache neu starten und den aktuellen Zustand testen: https://www.ssllabs.com/ssltest/analyze.html?d=kernel-error.de

Noch Fragen? Na dann fragen!

Um mit meinem privaten Mailsystem nicht nach zu stehen, habe ich mir heute (warum erst heute?!?) die „Mühe“ gemacht auf diesem PFS (Perfect Forward Secrecy) bei Postfix und Dovecot zu aktivieren.

Test gefällig? OK, openssl hilft natürlich wie immer:

Für Postfix:

$ openssl s_client -starttls smtp -connect smtp.kernel-error.de:25
$ openssl s_client -connect smtp.kernel-error.de:465

Für Dovecot:

$ openssl s_client -starttls imap -connect imap.kernel-error.de:143
$ openssl s_client -connect imap.kernel-error.de:993

Findet sich in der Ausgabe etwas wie:

Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384

Oder auch etwas wie:

Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-GCM-SHA384

Dann ist alles wunderbar. Wie es zu aktivieren ist muss ich nicht weiter beschreiben, denn hier hat Heinleine wie so oft sehr gute Arbeit geleistet: http://www.heinlein-support.de/blog/security/perfect-forward-secrecy-pfs-fur-postfix-und-dovecot/

Wenn ich das Thema nun in den Logfiles etwas beobachte sehe ich das der Android 4.3 / 4.4 standard Mailclient wohl gerne auf RC4 setzt: TLSv1 with cipher RC4-MD5 (128/128 bits)

Mein K9-Mail hingegen macht ganz brav: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

K-Mail auch…: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

 

Nun bleibt noch zu überlegen ob ich die möglichen Cipher etwas genauer „vorschreibe“, ähnlich wie schon beim Apache…. Ich überlege mal 🙂 Fertig überlegt, wie im Update zu sehen ist!

 

---

U-P-D-A-T-E

Da fällst du ja vom Glauben ab… Schreibe ich vor das für IMAP tatsächlich nur DHE-RSA-AES256-GCM-SHA384 eingesetzt werden soll, dann macht dieses jeder krümelige Client welchem ich es zum Test zum Fressen gegeben habe. Nur einer nicht… Kommt ihr nie drauf! Das aktuell neuste und beste was Microsoft hinsichtlich E-Mail Client zu bieten hat. Genau Microsoft Office Outlook 2013. Der kann es einfach nicht O_o Ist das wirklich noch Zufall? Also das Outlook 2013 dieses nicht bringt und somit die große Möglichkeit besteht den verschlüsselten Datenstrom später mal zu entschlüsseln? Wie auch immer, ich habe nun meine Konfiguration für Dovecot um diese Zeile erweitert:

ssl_cipher_list = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4

Damit ist es fürs Erste vertretbar… Oh ja, wenn ich schon dabei bin Microsoft hier etwas in Frage zu stellen. Dann muss ich natürlich bei Google gleich weiter machen! Denn der standard Mailclient, selbst beim neusten Android, sucht sich doch extrem häufig einen der schwächsten Chiper aus die angeboten werden. Sicher um CPU und oder Akku zu sparen, oder doch wieder nur Zufall?

Oh ja, Postfix sollte ja nicht nachstehen, daher wurde auch dort von mir etwas mehr vorgeschrieben. Folgende Zeilen erweitern nun die main.cf:

smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_mandatory_ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4

Mal schauen welche Probleme sich mit dieser Konfiguration nun auftun 🙂

 

 

 

Nach der NSA „Geschichte“ sollte klar sein dass man mehr denn je darauf achten sollte eine möglichst sichere Verschlüsselung zu nutzen. Als Benutzer kann man leider nicht immer Einfluss auf die Gegenseite, den Server nehmen. Um denn noch etwas mehr steuern zu können, dass eine „sichere“ Verschlüsselung benutzt wird kann jeder etwas an seinem Client schrauben.

 

Warum? Nun ja….. Nehmen wir als Beispiel den Firefox Web Browser. Dieser unterstützt viele verschiedene Protokolle, diese noch in vielen verschiedenen Version und noch mehr Chiffrensammlungen. Die Gegenseite sollte ebenso mehrere Verfahren unterstützten. Der Hintergedanke dabei ist dass sich beide Seiten so auf ein Verfahren einigen können welches beide unterstützen. Wenn man also nun seinen Client nur Verfahren anbieten lässt, welche man als sicher erachtet… Tja, dann können sich beide nur auf ein sicheres Verfahren einigen. OK, wenn der Server nun nichts „sicheres“ anbietet, werden sie sich nicht einig werden. An dem Punkt muss man sich dann fragen ob man wirklich „unsicher“ mit der Gegenseite sprechen möchte oder nicht!

Es ist doch hin und wieder erschreckend, welche Seite nur ~schlechte~ Chipher anbieten. Hier ist wohl, wie so oft per IPv6, ein Weg zur Lösung… Nachfragen 🙂 Also den Betreibern einer solchen Seite die Frage stellen, warum geht das nicht?!?! Manche Antworten sind echt lustig 😛

 

Ich denke es gibt drei große Punkte an denen man ansetzten kann:

1. Als kleinstes Protokoll TLS1
2. RC4-Stromchiffren komplett deaktivieren
3. Perfect Forwad Secrecy (PFS) vorschreiben

 

1. Sorgt dafür das der Browser nur noch als sicher bekannte Protokolle nutzt.
2. Wirft die als unsicher geltende RC4 Cipher Suite raus.
3. Sorgt dafür das selbst aufgezeichnete SSL/TLS Verbindungen in der Zukunft nicht so schnell gebrochen werden können, selbst wenn die Rechenleistung deutlich zunimmt.

 

Im Firefox lässt sich alles schnell und sehr einfach über die Seite: about:config einrichten.

B.t.w.: TLS (Transport Layer Security) ist der Nachfolger, die Weiterentwicklung von SSL (Secure Sockets Layer). Wir sprechen also besser nur von TLS, oder? Zurück zum Text…

 

1. TLS Version 1.0 als kleinstes unterstütztes Protokoll.
Unter der about:config Seite in der Suche nach security.tls.version suchen. Hier den Wert security.tls.version.max auf 3 und den Wert security.tls.version.min auf 1 setzten.

 

2. RC4 Cipher Suite deaktivieren.
Wieder über die Suche der about:config Seite nach rc4 suchen. Nun bei allen angezeigten Zeilen den Wert auf false setzten.

 

3. Perfect Forwad Secrecy (PFS) vorschreiben
Erraten, about:config und die Suche benutzen. Gesucht wird security.ssl3…. Bei den Suchergebnissen nun alle Werte auf false setzten bei denen nicht ECDHE, DHE oder RC4 (wobei die RC4 „Jungs“ sollten ja bereits aus sein) in der Bezeichnung steht.

 

Seine Einstellungen kann man nun am besten prüfen auf: https://www.ssllabs.com/ssltest/viewMyClient.html

 

 

Ach ja…. Die Seite https://www.ausweisapp.bund.de/ kann spannenderweise nicht mehr aufgerufen werden, wenn man diese sicheren Einstellungen in seinem Browser vorschreibt. Lustig, hm?

 

---

U-P-D-A-T-E

Wem das alles etwas zu hart ist, der kann bei security.ssl3 den Wert: security.ssl3.rsa_aes_256_sha auf true lassen/setzten. Dieses würde sich zwar vielleicht mit steigender Rechenleistung entschlüsseln lassen. Ist aber aktuell noch recht sicher und wird von mehr Webseiten angeboten als nur auf Diffie Hellman zu setzten.

Oh ja, was man Serverseitig tun könnte findet sich hier…

 

 

 

 

Da brat mir einer einen Storch…. Auf meinem Samsung Galaxy S2 arbeitet schon lange ein CyanogenMod 10.2. Ganz brav aktualisiere ich es immer mit den Nightly Builds. Heute morgen sehe ich doch tatsächlich ein Upgrade auf CM 11 (Android 4.4.2 KitKat). Habe ich direkt und ganz mutig installiert!

Was soll ich sagen? Läuft prima! Ich habe noch kein Problem gefunden. OK, ich musste noch mal die passenden Google-Apps nachinstallieren. Das ist aber normal so 🙂 Genau so gefällt es mir! Es hat mir so viel Spaß gemacht, dass ich direkt mal bei CM auf Donate klicke!