IT-Blog von Sebastian van de Meer
Notizen & Praxis zur IT-Sicherheit – von Responsible Disclosure bis Härtung.
Inzwischen bin ich etwas weiter. Ich nutze nun einen sauberen Filter um SPAM von meinem Jabberserver fern zu halten. \o/ Somit habe ich die Block der besonders auffälligen xmpp-server zurückgezogen. So gefällt mir die Lösung schon viel besser.
Siehe auch: Eigenen Jabber-Server betreiben
Fragen? Einfach melden.
Aktuell beobachte ich sehr für SPAM mit teils russsichem Inhalt zu Exploits und ähnlichem, der von vielen verschiedenen Domains bei meinem Server ankommt.
Die Admins dieser Server kommen zum Teil aktuell nicht mit dem Aussortieren der Spamaccounts nach. Ich selbst habe ebenfalls schon viele Anmeldeversuche dieser Spamaccounts bewundert. Diese werden automatisch erstellt, dann etwas später wird darüber ein einem riesigen Schwung versucht Spam zu verteilen und nach knapp 1Stunde verstaubt der Account wieder. Dagegen hilft fast nur die einfache Benutzeranmeldung über xmpp zu deaktivieren.
Derzeit bei mir also nur möglich über (Gott ist das hässlich): https://jabber.kernel-error.de:9091/plugins/registration/sign-up.jsp
Oh ja, die Spamserver habe ich aktuell geblockt. Im Moment sind es die folgenden:
ajabber.me
anonymitaet-im-inter.net
codingteam.net
exploit.im
igniterealtime.org
jabber.co.za
jabber.no
jabber.zerties.org
jabbim.cz
jclub.pw
jumbo.li
justnet.pl
km-net.pl
lih.im
pandion.im
qip.ru
svnet.fr
sync-hv.de
talkers.im
tigase.im
xmpp.svnet.fr
Siehe auch: Eigenen Jabber-Server betreiben
Fragen? Einfach melden.
Da kommt folgende Mail rein:
Hi, mein Firefox Plugin und hash-slinger sagen beide, dass dein TLSA Record für munin.kernel-error.com kaputt ist. Gruß Andreas
Recht hat der Mann. Ich hatte das Zertifikat getauscht (auf Elliptic Curve umgestellt) und vergessen, den TLSA-Record im DNS zu aktualisieren. Klassiker. Der TLSA-Record enthält einen Hash des Zertifikats. Tauscht man das Zertifikat, stimmt der Hash nicht mehr, und jeder Client der DANE prüft sieht einen Fehler.
Passiert schneller als man denkt, besonders wenn man mehrere Dienste auf verschiedenen Subdomains hat. Jeder braucht seinen eigenen TLSA-Record. Zertifikat erneuern, TLSA vergessen, niemand merkt es (weil kaum jemand DANE validiert). Bis jemand wie Andreas mit dem Firefox-Plugin vorbeikommt.
Die Lektion: Nach jedem Zertifikatstausch die TLSA-Records prüfen. Am besten automatisiert, zum Beispiel per Skript das nach dem ACME-Renewal den Hash berechnet und den DNS aktualisiert. Wer TLSA-Records von Hand prüfen will, findet die Anleitung unter TLSA/DANE manuell prüfen. Die Grundlagen zu DANE stehen im Beitrag DNSSEC und DANE. Fragen? Einfach melden.
Heute möchte ich einmal ein Zertifikat für meinen munin erstellen. Als Test möchte ich einmal ein Zertifikat mit Elliptischen Kurven im Schlüssel probieren. Dieses soll natürlich ebenfalls von StartSSL signiert werden.
Die openssl Befehle sind wie immer nicht weiter besonders….
Schlüssel erstellen:
$ openssl ecparam -out http.key -name secp521r1 -genkey
CSR erstellen:
$ openssl req -new -sha256 -key http.key -nodes -out http.csr
Den Inhalt des CSRs ausgeben und der CA (StartSSL) zum signieren geben, sowie das signierte Zertifikat in die Datei http.crt gießen:
$ cat http.csr $ vi http.crt
Alles im PEM-File zusammenführen:
$ cat http.key http.crt > http.pem
Als guten Abschluss noch ein paar Diffie Hellman einwerfen (wenn auch etwas unnötig):
$ openssl gendh 4096 >> http.pem
Fertig ist das Zertifikat! Alles noch wie bekannt in den Apachen werfen und zur Sicherheit einmal Qualys auf die Seite loslassen:
https://www.ssllabs.com/ssltest/analyze.html?d=munin.kernel-error.com
Damit habe ich also nun ein EC 521 bits / SHA256withRSA Zertifikat. Tja, in meinem Firefox sieht alles aus wie immer. Gut, der Microsoft Rempel schlägt wie so oft hart auf aber ich nutze die Seite eh nie mit dem IE ;-P
Was meint ihr?
Siehe auch: Von RSA zu ECDSA
Fragen? Einfach melden.
Ich habe ja beruflich ebenfalls mit der Betreuung von Systemen in China zu tun. Die Probleme mit der „great wall of china“ sind mir also bekannt. Onlineüberwachung ist hier also sehr deutlich vertreten, sobald man etwas Crypto einsetzte, wird die Verbindung gleich so schlecht, langsam und instabil, dass es keinen Spaß mehr macht sie zu nutzen. Wenn es überhaupt zu einer Verbindung kommt!
Was mir aber jetzt geschickt wurde ist schon hart 🙂 „sicheres onlinebanking in China“ oder so ähnlich! Erlaubt ist, was geknackt werden kann. *kopfschüttel*.
OK OK, China ist weit weg und wer hat schon ein Konto in China? Ich möchte aber noch einmal anmerken, dass auch bei uns und in den USA bereits Ideen aus der Regierung gekommen sind, nur noch Verschlüsselungen zu erlauben, welche auch „geknackt“ werden können… Oder erinnert euch an die Idee, jede Verschlüsselung ebenfalls noch einmal mit einem speziellen Schlüssel der Regierung mit verschlüsseln zu müssen? So das die Regierung in jedem Fall die Möglichkeit hat alles zu entschlüsseln! Natürlich alles zur Terrorabwehr… versteht sich von selbst!
So anstrengend unsere Aluhüte manchmal sind… Sie retten auch unsere Freiheit!
Danke Jost!
Fragen? Einfach melden.
Kleinere Schlüssel als 2048bit sollte man mit Elliptic Curve Diffie-Hellman (ECDH) ja nicht mehr nutzen. Seit Java Version 1.8 ist dieses auch unterstützt. Wer also seinem Openfire xmpp/jabber Server diese Möglichkeit unterschieben möchte, sollte auf ein Oracle Java 1.8 setzen!
Wie also nun Java 8 dazu überreden? Auf einem Debian 8 (jessi) oder ähnlichem klappt es, wie folgt:
Möglichkeit Nummer 1. Zentral für alle Java Prozesse:
$ vim /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security
jdk.tls.ephemeralDHKeySize=2048
Möglichkeit Nummer 2. Nur für den Openfire, einfach beim Start mit übergeben:
$ vim /etc/default/openfire
# Additional options that are passed to the Daemon. DAEMON_OPTS="-Djdk.tls.ephemeralDHKeySize=2048"
Um zu prüfen ob alles auch sauber umgesetzt ist hilft wie immer xmpp.net:
https://xmpp.net/result.php?id=7146
https://xmpp.net/result.php?id=7134
Oh ja, über Openfire AES 256 und JCE Unlimited Strength Jurisdiction Policy Files müssen wir jetzt nicht mehr sprechen, oder? Ebenfalls nicht darüber, wie bei Openfire unsichere Cipher und Protokolle deaktivieren, oder?
Puhh… das was angenehm einfach oder? Bei Fragen, fragen.
Fragen? Einfach melden.
TLS allein reicht nicht. Auch mit einem A+ bei Qualys SSL Labs fehlt ein wichtiger Teil: die HTTP-Security-Header. Sie schützen vor Cross-Site-Scripting, Clickjacking und MIME-Sniffing. Trotzdem setzen die wenigsten Webserver sie. Einen schnellen Überblick gibt securityheaders.com.
Apache braucht das Headers-Modul. Unter Debian/Ubuntu:
a2enmod headers service apache2 restart
Für spätere Konfigurationsänderungen reicht ein Reload (service apache2 reload).
Die Header können global in /etc/apache2/conf-enabled/security.conf oder pro vHost in der jeweiligen Konfigurationsdatei gesetzt werden:
ServerTokens Prod ServerSignature Off TraceEnable Off Header set X-Content-Type-Options: "nosniff" Header set X-Frame-Options: "sameorigin" Header set X-Permitted-Cross-Domain-Policies: "master-only" Header set X-XSS-Protection: "1; mode=block" Header unset X-Powered-By
ServerSignature Off entfernt die Serverversion aus Fehlerseiten. ServerTokens Prod reduziert den Server-Header auf das Wort „Apache“, ohne Versionsnummer. Komplett entfernen lässt sich der Header im Standard-Apache nicht. Es gibt dazu einen Bug-Report mit WONTFIX. Manche Distributionen patchen das, sonst muss man selbst kompilieren oder damit leben.
TraceEnable Off deaktiviert die HTTP-TRACE-Methode serverweit.
X-Frame-Options: sameorigin verhindert, dass die Seite in fremde iframes eingebettet wird. Wer Einbettungen braucht, sollte diesen Header weglassen oder auf Content-Security-Policy: frame-ancestors umsteigen.
X-Content-Type-Options: nosniff verhindert MIME-Type-Sniffing im Browser. X-XSS-Protection aktiviert den XSS-Filter in älteren Browsern. Moderne Browser setzen stattdessen auf Content Security Policy (CSP).
Header unset X-Powered-By entfernt den PHP-Versionsheader, sofern vorhanden.
Nach dem Reload die eigene Domain auf securityheaders.com scannen. Die Bewertung sollte sich deutlich verbessert haben.
Fragen? Einfach melden.
Veraltet: StartSSL wurde 2017 von allen Browsern als nicht mehr vertrauenswürdig eingestuft und hat den Betrieb eingestellt. OCSP Stapling ist weiterhin relevant, aber die hier beschriebene Fehlerursache (StartSSL OCSP-Responder) existiert nicht mehr.
Natürlich ist bei mir OCSP Stapling am Apache 2.4 aktiviert…. Doch plötzlich zeigt mir meine Webseite beim Besuch mit dem Mozilla Firefox folgende Fehlermeldung:
Secure Connection Failed
An error occurred during a connection to www.kernel-error.de. The OCSP server suggests trying again later. (Error code: sec_error_ocsp_try_server_later)
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
Im Error Log des Webservers finden sich zur gleichen Zeit Logmeldungen wie:
[Mon Aug 10 07:06:28.572899 2015] [ssl:error] [pid 23648] (70007)The timeout specified has expired: [client 1.2.3.4:23726] AH01977: failed reading line from OCSP server [Mon Aug 10 07:06:28.572924 2015] [ssl:error] [pid 23648] [client 1.2.3.4:23726] AH01980: bad response from OCSP server: (none) [Mon Aug 10 07:06:28.572950 2015] [ssl:error] [pid 23648] AH01941: stapling_renew_response: responder error
Ahja… bad response from OCSP Server…. Habe ich nun irgendwo Mist konfiguriert oder hat wirklich der OCSP Server meiner CA StartSSL / StartCOM ein Problem? Mein Verdacht ist natürlich, dass es an der CA liegen muss. ;-P
Am schnellsten Teste ich es einmal von Hand auf meinem Client. Ist hier das gleiche Problem, liegt es sicher an der CA. Wie also manuell per openssl testen ob der OCSP Server tut was er will? Ganz einfach, so:
Als erstes einmal den öffentlichen Teil meines Zertifikates herunterladen und in einer Datei speichern:
# openssl s_client -connect www.kernel-error.de:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > www.kernel-error.de.pem
Jetzt das Intermediate besorgen. Dieses sollte ja ebenfalls mein Server senden, also hole ich es von dort. Dabei ist hier nun etwas copy & paste Arbeit nötig. Folgendes wirft mir einiges um die Ohren:
# openssl s_client -connect www.kernel-error.de:443 -showcerts 2>&1 < /dev/null
Hier ist kopiere ich mir nun das Intermediate Zertifikat heraus in das File interm.pem. Spannend ist dabei das Zertifikat zu:
1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority -----BEGIN CERTIFICATE----- MIIGNDCCBBygAwIBAgIBGzANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEW
Dabei alles ab —–BEGIN CERTIFICATE—– bis einschließlich —–END CERTIFICATE—–
In meinem Zertifikat sollte der OCSP Server meiner CA hinterlegt sein. Diesen lasse ich mir nun mit folgendem Befehl ausgeben:
# openssl x509 -noout -ocsp_uri -in www.kernel-error.de.pem http://ocsp.startssl.com/sub/class2/server/ca
Perfekt… Nun habe ich alle Informationen zusammen um einen manuellen Test gegen den OCSP Server meiner CA zu fahren:
# openssl ocsp -issuer interm.pem -cert www.kernel-error.de.pem -text -url http://ocsp.startssl.com/sub/class2/server/ca
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: B9B2D56DB021B36E42F627245806C4A9A6979AEB
Issuer Key Hash: 11DB2345FD54CC6A716F848A03D7BEF7012F2686
Serial Number: 06D8F968657B18
Request Extensions:
OCSP Nonce:
04109228F685EAF4211B1A6D6CCF67AD9CC9
Error querying OCSP responder
34379249832:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/ocsp/ocsp_ht.c:255:Code=400,Reason=Bad Request
Hm… Sehr eindeutig, oder? Es scheint also wirklich ein Problem am Server der CA zu geben. Eine kurze E-Mail an die CA später habe ich, auf die Frage ob es ein Problem mit dem OCSP Server gibt, die folgende Antwort in meinem Postfach:
Yes. It would be fixed asap. -- Regards Signer: Kirill Ivanov, VO StartCom Ltd.
Na wunderbar… Damit schalte ich also OCSP Stapling mal wieder aus, bis meine CA wieder korrekt arbeitet!
SSLUseStapling Off
Bis spööööter 😀
Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft. Certificate Transparency ist heute bei allen CAs Pflicht und erfordert keine gesonderte Konfiguration mehr.
Google hatte 2014 eine weitere Idee um Zertifikate „vertrauenswürdiger“ zu gestalten. Alles unter dem Namen: „Google’s Certificate Transparency project“ http://www.certificate-transparency.org/ Hat man eine CA „geknackt“ oder entsprechenden Einfluss (z.B.: als Staat), kann man sich für beliebige Domains gültige Zertifikate ausstellen. Der jeweilige User rutscht also auf einer Webseite herum, die Verbindung ist verschlüsselt und das Zertifikat ist sauber. Ihm fällt also erst einmal nichts auf und somit fühlt sich der User sicher…. Genau diesen Punkt möchte Googles Idee verbessern! Die jeweilige CA „veröffentlicht“ das erstellte Zertifikat. So können die Clients/Browser diese „Logs“ absuchen und somit herausfinden, welches Zertifikat für welche Domain wohl das gültige ist. So lassen sich untergeschobene Zertifikate finden. OK, es gibt da schon Wege: – DNSsec – TLSA/DANE – Public Key Pinning (HPKP) Warum also etwas neues? Tja…. Dieses sind alles Techniken, welche der Admin selbst nutzen muss. Der Admin muss aktiv etwas tun. Bei Googles CT übernimmt diese Arbeit im Grunde die CA selbst. Maximal muss man noch einen kleinen Hacken setzten, fertig.
Über Sinn und Unsinn kann man sich nun streiten. Ändert aber nichts, da Google dieses einfach in ihren Browser fest eingebaut hat. Möchte man nun also kein gelbes Ausrufezeichen in der Adresszeile vom Chrome haben, muss die eigene CA CT unterstützen und das Zertifikat veröffentlichen.
StartSSL/StartCOM tut dieses bisher noch nicht. Ich habe aber folgende Info bekommen:
There will be support shortly for submitting to the CT logs and installing the response for CT aware web servers (TLS extension). Support for the latter is lacking for a large part, but it should get better over time, most likely Apache first.
Wenn ich mehr habe, gibt es mehr.
Kaum geht mein Artikel zur erweiterten Sicherheit meiner Webseite online >>TLS Sicherheit weiter verschärft….<< schon kommen Fragen. Eine habe ich nun schon vier mal bekomme, daher hier direkt die Antwort. Ach ja, die Frage:
Wie habe ich meinen Apache dazu überredet DHE-Keys mit 4096bit zu benutzen?
Also… Der Apache beherrscht seit Version 2.4 Diffie Hellman mit mehr als 1024bit. Um dieses nutzen zu können, muss der Apache die passenden dh-params haben. Der Apache nutzt dabei automatisch die ihm gegebene Key stärke.
Ich generiere den DH Teil gerne direkt mit dem jeweiligen Zertifikat und verbinde dieses. Beschrieben habe ich es hier: >>Sicheres SSL / TLS Zertifikat<<
Wer gerne nachträglich generieren möchte macht es mir:
$ openssl gendh 4096 > dh_4096.pem
Dieses lässt sich nun einfach wie ein normales Zertifikat mit in die Konfiguration des Apachen einbinden. Im Grunde nichts besonders und nachdem man es gelesen und absolut einleuchtend, man sucht aber dann doch zuerst etwas.
Viele andere Dienste (Postfix usw…) bringen ja meist einen eigenen Konfigurationspunkt dafür mit. Im Apache liegt es ohne große Konfiguration in Zertifikatsnähe.
So long….
Fragen? Einfach melden.
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑