IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.
Ihr erinnert euch daran das man bei GlobalSign keine Sonderzeichen im Kennwort für die Zertifikatsverwaltung nutzen kann? Nun ratet doch mal was man beim Kennwort für p12 auch nicht nutzen kann! ….Richtig… Sonderzeichen im Kennwort.
Siehe auch: GlobalSign S/MIME, S/MIME-Zertifikat per DNS veröffentlichen – SMIMEA
Fragen? Einfach melden.
Neues S/MIME Zertifikat, neuer SMIMEA-Record. Weil E-Mail-Verschlüsselung nicht nur für Paranoide ist. Oder doch? Egal, ich mache es trotzdem.
Wie angekündigt habe ich ein neues S/MIME Zertifikat. Wer mir verschlüsselt schreiben will, braucht den neuen öffentlichen Schlüssel. Den gibt es wie immer über die üblichen Wege oder halt per erster unverschlüsselter Mail an mich.
Das Spannende daran: ich habe direkt einen SMIMEA-Record dazu im DNS hinterlegt. SMIMEA ist quasi DANE für S/MIME. Statt nur TLS-Zertifikate von Servern im DNS zu veröffentlichen, kann man damit auch S/MIME-Zertifikate von E-Mail-Adressen per DNS verifizierbar machen. Der RFC dazu war 2017 noch im Draft-Status (RFC 8162), inzwischen ist er finalisiert.
Die Idee ist simpel: Du hast DNSSEC für deine Domain (habe ich), du hast ein S/MIME-Zertifikat (habe ich jetzt neu) und du packst den Fingerprint oder das ganze Zertifikat als SMIMEA-Record in deine DNS-Zone. Jeder der mir eine verschlüsselte Mail schicken will, kann mein Zertifikat dann per DNS-Abfrage verifizieren. Kein Rumsuchen auf Keyservern, keine manuelle Prüfung ob das Zertifikat echt ist.
In der Praxis nutzt das aktuell fast niemand. Mailclient-Support ist mager, die meisten Leute wissen nicht mal was S/MIME ist, geschweige denn SMIMEA. Aber genau deshalb mache ich es. Jemand muss ja anfangen.
Wer sich für DANE, SMIMEA oder E-Mail-Sicherheit interessiert, kann mich gerne fragen.
Nach dem „tot“ von StartSSL brauche ich ja auch mal ein neues S/MIME Zertifikat. Class 2 bei GlobalSign sollte für mich privat reichen (auch wenn ich schon auf Class 3 geschielt habe, mal sehen ob ich das noch nachziehe). Als erstes habe ich da trocken angerufen und gefragt ob ich auf sie bauen kann oder mich am Ende so ärgere wie über StartSSL / Symantec usw… Klar es ist eine große CA die zu viel Geld für Mist bekommen und der Anruf war total nutzlos. Er hat dennoch für Spaß bei mir und da bin ich mir sicher, ebenfalls bei GlobalSign geführt.
Nun klicke ich mich also gerade durch die Anmeldung und muss alle möglichen Daten eingeben sowie Vereinbarungen zustimmen usw. an einer Stelle soll ich dann schon mal mein Kennwort für die Zertifikatsverwaltung festlegen. Ich überzeuge also wie immer pwgen mir eines zu würfeln werfe es rein. Die Info unter dem Kennwortformular lese ich natürlich nicht und bekomme direkt die Quittung. Ich habe unerlaubte Sonderzeichen in meinem Passwort für die Zertifikatsverwaltung angegeben. Unerlaubte Sonderzeichen?!?!? Stimmt… Die Kennwörter dürfen nur aus Zahlen und Buchstaben (groß/klein) bestehen..
Das Kennwort für die Zertifikatsverwaltung darf also keine Sonderzeichen enthalten. Den Satz habe ich jetzt schon ein paar mal gesagt aber öhm ich begreife ihn irgendwie noch nicht. *kopfschüttel* Kann mir das bitte mal jemand verständlich machen? Am besten ich ruf da noch mal an, oder?
Siehe auch: S/MIME per DNS mit SMIMEA, Kleiner Nachtrag zum GlobalSign S/MIME Zertifikat…, Neues StartSSL S/MIME Zertifikat
Fragen? Einfach melden.
Ihr erinnert euch doch sicher noch an meinen Bla zum BSI und nextcloud, oder? ==> Die Jungs vom BSI und nextcloud
Inzwischen ist der Scanner wohl für jeden einfach nutzbar… So wie man es von Qualys oder ähnlichem kennt. Einfach mal hier klicken: https://scan.nextcloud.com/ und fröhlich scannen.
Solche Scanner haben ja auch schon irgendwie etwas für sich, oder? Ein A+ sollte wohl für den Moment jeder ohne weitere Probleme erreichen können!
So long…
Siehe auch: MTA-STS einrichten
Fragen? Einfach melden.
Nextcloud hat sie die Mühe gemacht und mal nach owncloud und nextcloud Installationen gesucht. Dabei haben sie direkt mal geprüft wie sicher oder unsicher die wohl sind. Das hat seinen Weg zum BSI gefunden und die haben dann die abuse Adressen aller Netzbetreiber „gefüttert“.
Erstmal keine schlechte Idee. Natürlich will nextcloud was damit erreichen, das BSI macht auch brav mit super… Solange wir alle IPv4 machen läuft diese Version auch!
Oh ja, die abuse Mail:
Sehr geehrte Damen und Herren, ownCloud und Nextcloud sind Software-Lsungen zum Betrieb selbst gehosteter Cloud-Instanzen zur Synchronisation und zum Austausch von Daten. Das Unternehmen Nextcloud GmbH hat offen aus dem Internet erreichbare Installationen von ownCloud und Nextcloud geprft. Dabei wurden zahlreiche Cloud-Instanzen identifiziert, die mit veralteten Software-Versionen laufen, welche verschiedene Sicherheitslcken aufweisen. Angreifer knnen diese Schwachstellen ausnutzen, um unter anderem unberechtigt auf die in der Cloud gespeicherten Daten zuzugreifen. Dabei knnen die Angreifer ggf. sensible Informationen wie z.B. persnliche Dokumente, Fotos oder Kundendaten von Unternehmen aussphen und diese anschlieend im Internet verffentlichen oder fr kriminelle Zwecke wie Erpressungen nutzen. Andere Schwachstellen ermglichen Angreifern die Ausfhrung beliebigen Programmcodes auf dem Cloud-Server. Dies kann ggf. zu einer vollstndigen Kompromittierung des Systems und dessen Missbrauch fr weitere kriminelle Aktivitten fhren. Die Nextcloud GmbH hat CERT-Bund ihre Ergebnisse der Prfungen zur Untersttzung bei der Benachrichtigung betroffener Server- Betreiber bereitgestellt. Nachfolgend senden wir Ihnen eine Liste betroffener Systeme in Ihrem Netzbereich. Der Zeitstempel (Zeitzone UTC) gibt an, wann die verwundbare Cloud-Installation identifiziert wurde. Weiterhin sind fr jedes System eine Risikoeinstufung sowie eine eindeutige ID (UUID) angegeben. Die Nextcloud GmbH stellt unter folgender URL detaillierte Informationen zu den bei der jeweiligen Cloud-Instanz erkannten Schwachstellen und deren Behebung zur Verfgung: https://scan.nextcloud.com/results/[UUID] Der Parameter [UUID] muss dabei durch die zu der jeweiligen Instanz angegebene UUID ersetzt werden. Beispiel: https://scan.nextcloud.com/results/12345678-1234-1234-1234-12345678 Wir mchten Sie bitten, den Sachverhalt zu prfen und Manahmen zur Aktualisierung der Cloud-Installationen auf den betroffenen Systemen zu ergreifen bzw. Ihre Kunden entsprechend zu informieren. Fr alle auf den betroffenen Systemen identifizierten Schwachstellen stehen entsprechende Sicherheitsupdates der Hersteller zur Verfgung. Bei Rckfragen zu den durchgefhrten Prfungen der Cloud-Instanzen wenden Sie sich bitte direkt an die Nextcloud GmbH unter <cloud-security-scan@nextcloud.com>. Diese E-Mail ist mittels PGP digital signiert. Informationen zu dem verwendeten Schlssel finden Sie unter <https://reports.cert-bund.de>. Bitte beachten Sie: Dies ist eine automatisch generierte Nachricht. An die Absenderadresse kann nicht geantwortet werden. Bei Rckfragen zu dieser Benachrichtigung wenden Sie sich bitte unter Beibehaltung der Ticketnummer in der Betreffzeile an <certbund@bsi.bund.de>. ====================================================================== Betroffene Systeme in Ihrem Netzbereich: Format: ASN | IP | Timestamp (UTC) | UUID | Severity | Port | Hostname 12345 | 1.2.3.4 | 2017-02-06 19:53:17 | 1ae3f7da-3367-4012-9382-7912dd4bd163 | high | 80 | cloud.domain.de 12345 | 1.2.3.5 | 2017-02-06 19:53:17 | 2e0a45fa-1568-458f-898e-2a888b44c9c6 | medium | 80 | cloud.wurst.com 12345 | 1.2.3.6 | 2017-02-06 19:53:17 | 32288a95-d396-4c9b-8998-d1968dc30ad7 | low | 80 | cloud.alalaa.de 12345 | 1.2.3.7 | 2017-02-06 19:53:17 | ecfd4e62-b1b5-4c7d-b888-3f19ca3ca7ff | high | 443 | cloud.butani.cn 12345 | 1.2.3.8 | 2017-02-06 19:53:17 | 52ff7f71-c004-4a36-9975-2b5a99f280d6 | high | 80 | cloud.bima.org 12345 | 1.2.3.9 | 2017-02-06 19:53:17 | e388d8c5-4124-4af3-b052-57f77469783a | high | 80 | cloud.2083a.net 12345 | 1.2.3.10 | 2017-02-06 19:53:17 | 5cad0785-a6eb-47ca-aeec-6c4252928d13 | low | 443 | cloud.lutzola.nl 12345 | 1.2.3.11 | 2017-02-06 19:53:17 | 7da5d2dc-8556-4699-9ea4-7814c6afb8c0 | high | 80 | cloud.weglaa.wu 12345 | 1.2.3.12 | 2017-02-06 19:53:17 | adac575f-6a42-487d-a8c3-1b789ebafe39 | medium | 80 | cloud.breck.aa [.....] Mit freundlichen Gren / Kind regards Team CERT-Bund Bundesamt fr Sicherheit in der Informationstechnik (BSI) Federal Office for Information Security Referat CK22 - CERT-Bund Godesberger Allee 185-189, D-53175 Bonn, Germany
Fragen? Einfach melden.
Tach zusammen,
StartSSL ist ja aktuell einfach tot 🙁 Eine für mich sinnvolle Alternative konnte ich aber nicht finden. Eine Wildcard Zertifikat für meine Domains und dann einfach überall das gleiche *grusel* aber 10000 € ausgeben um sonst meine Wünsche zu erfüllen macht auch keinen Sinn. Tja bleibt Let’s Encrypt…. Gott, ich will nicht alle drei Monate neue Zertifikate bauen. Das ist Käse, vor allem mit TLSA/DANE, HPKP usw. *brech*
Für jetzt bin ich dennoch dazu gezwungen auf Let’s Encrypt zu wechseln. Es wird also ein solches Zertifikat hier geben. Ich hoffe nun einfach darauf, dass StartSSL wieder in die Browser kommt. 01.06.2017 soll es da wohl weiter gehen, hm?
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832
https://startssl.com/NewsDetails?date=20160919
Klar ist jetzt dieser China CA zu vertrauen? Nö… Nur bis zu einem gewissen Punkt und ab dann halt HPKP, TLSA/DANE, DNS CAA. Was mir so gut gefällt ist die Möglichkeit für einen vertretbaren Preis so viele unterschiedliche Zertifikate raus zu hauen, wie ich es für richtig halte.
Also kommt nun Let’s Encrypt als „hoffentlich Übergang“ und dann wieder StartSSL oder jemand von euch hat eine gute Idee für mich?
So long…
Siehe auch: Von RSA zu ECDSA
Fragen? Einfach melden.
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.
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑