Mein Datenhaufen zu IT und Elektronik Themen.

Kategorie: Kernel-Error-Blog (Seite 4 von 46)

RSPAMD automatisch SPAM / HAM lernen mit Dovecot und IMAPSieve

Bei jedem Spamfilter rutscht schon mal spam durch oder eine echte Nachricht wird falsch als spam eingestuft. Rspamd bietet über das Webinterface die Möglichkeit trainiert zu werden. Hier kann man einfach den Quellcode jeder E-Mail kopieren und rspamd die Information mitgeben ob es sich dabei um SPAM oder HAM handelt. Dieses Vorgehen ist vollständig unbrauchbar um den Spamfilter ordentlich zu trainieren.

Viel schöner wäre doch Folgendes: Immer wenn ein Benutzer eine E-Mail in den Ordner „Junk“ schiebt soll diese E-Mail automatisch von rspamd als Spammail gelernt werden. Zusätzlich soll jede E-Mail welche vom Benutzer aus dem „Junk“ Ordner herausgeholt wird als Ham gelernt werden.

Genau dieses Beispiel möchte ich hier kurz beschreiben. Hostsystem ist dabei ein FreeBSD, Linuxuser müssen daher bei den Ordnern /usr/local etwas aufpassen! Ebenfalls lauscht mein rspamd-worker nicht auf einen unix-socket sondern auf der IP 127.0.0.3, da er in einer jail steckt.

 Beginnen wir mit der Konfiguration für dovecot.

20-imap.conf:

protocol imap {
  mail_plugins = $mail_plugins imap_sieve
}

90-plugin.conf:

plugin {
  sieve_plugins = sieve_imapsieve sieve_extprograms

  # From elsewhere to Spam folder or flag changed in Spam folder
  imapsieve_mailbox1_name = Junk
  imapsieve_mailbox1_causes = COPY FLAG
  imapsieve_mailbox1_before = file:/usr/local/etc/dovecot/sieve/report-spam.sieve

  # From Spam folder to elsewhere
  imapsieve_mailbox2_name = *
  imapsieve_mailbox2_from = Junk
  imapsieve_mailbox2_causes = COPY
  imapsieve_mailbox2_before = file:/usr/local/etc/dovecot/sieve/report-ham.sieve

  sieve_pipe_bin_dir = /usr/local/libexec/dovecot

  sieve_global_extensions = +vnd.dovecot.pipe
}

/usr/local/etc/dovecot/sieve/report-spam.sieve:

require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "imap4flags"];

if environment :is "imap.cause" "COPY" {
    pipe :copy "sa-learn-spam.sh";
}

# Catch replied or forwarded spam
elsif anyof (allof (hasflag "\\Answered",
                    environment :contains "imap.changedflags" "\\Answered"),
             allof (hasflag "$Forwarded",
                    environment :contains "imap.changedflags" "$Forwarded")) {
    pipe :copy "sa-learn-spam.sh";
}

/usr/local/etc/dovecot/sieve/report-ham.sieve:

require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];

if environment :matches "imap.mailbox" "*" {
  set "mailbox" "${1}";
}

if string "${mailbox}" [ "Trash", "train_ham", "train_prob", "train_spam" ] {
  stop;
}

pipe :copy "sa-learn-ham.sh";

Natürlich nicht vergessen die beiden neuen Sieve scripte für sieve zu compilieren:

# sievec /usr/local/etc/dovecot/sieve/report-spam.sieve
# sievec /usr/local/etc/dovecot/sieve/report-ham.sieve

Fehlen nur noch die beiden shell scripte um die Mails an rspamd weiterleiten zu können.

/usr/local/libexec/dovecot/sa-learn-spam.sh:

#!/bin/sh
exec /usr/local/bin/rspamc -h 127.0.0.3:11334 learn_spam

/usr/local/libexec/dovecot/sa-learn-ham.sh:

#!/bin/sh
exec /usr/local/bin/rspamc -h 127.0.0.3:11334 learn_ham

Beide müssen ausführbar sein:

# chmod +x /usr/local/libexec/dovecot/sa-learn-spam.sh /usr/local/libexec/dovecot/sa-learn-ham.sh

So wenn ich nun eine E-Mail in den Ordner „Junk“ verschiebe lernt rspamd diese automatisch als Spam:

2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_controller_check_password: allow unauthorized connection from a trusted IP 127.0.0.3
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_message_parse: loaded message; id: <FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net>; queue-id: <undef>; size: 49053; checksum: <f5e2fc59515e1da33d532c6f03f6f6f0>
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_controller_learn_fin_task: <127.0.0.3> learned message as spam: FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net

Verschiebe ich eine E-Mail aus dem Ordner „Junk“ heraus wird sie, wie gewünscht, als Ham gelernt:

2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_controller_check_password: allow unauthorized connection from a trusted IP 127.0.0.3
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_message_parse: loaded message; id: <FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net>; queue-id: <undef>; size: 49053; checksum: <f5e2fc59515e1da33d532c6f03f6f6f0>
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_controller_learn_fin_task: <127.0.0.3> learned message as ham: FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net

Tjo… Fragen? Dann fragen..

Oh was man nicht mehr verwenden sollte ich etwas wie das antispam plugin das ist „tot“.

AliExpress Labornetzteil – RIDEN RD6006 DC POWER SUPPLY

RIDEN RD6006 DC POWER SUPPLY Labornetzteil

Vor knapp 20 Jahren habe ich mir ein Labornetzteil gebaut. Elektronik lernen und verstehen war dabei das Ziel. Das Netzteil liefert mir 30V und 3A ist kurzschlusssicher und hält Strom und Spannung auch unter Last sauber. Es ist komplett analog mit zwei dreistelligen Segmentanzeigen für Strom und Spannung.
Insg. ein sehr schönes Gerät welches mich schon viele Jahre begleitet. Dennoch stößt es immer wieder an seine Grenzen. Ich möchte mehr als 30V oder benötige mehr als 3A. Zum einfachen Messen muss ich weitere Geräte einschleifen, ebenfalls wenn ich Strom/Spannung sehr fein einstellen möchte geht es nicht ohne weiteres Messgerät und etwas Fingerspitzengefühl.
Verlaufskurven digital speichern, vorgespeicherte Werte schnell abrufen und ausgeben oder einfach zwischen verschiedenen Werten schnell wechseln…. Alles Dinge an welche man bei dem Gerät nicht denken muss. Ebenfalls ist es kein modernes Schaltnetzteil, sondern basiert noch „ganz Oldschool“ auf einem großen Trafo. Erst dahinter mache ich Strom und Spannung „sauber“ zu den damit verbundenen Nachteilen kommt die hohe Verlustleistung in Wärme.
Ein neues Labornetzteil was mir diese Möglichkeiten eröffnet muss her. Dabei benötige ich kein Highendgerät. Dafür sind meine Anwendungen zu simpel. Preis/Leistung muss halt passen. Ich bin daher auf das RIDEN RD6006 gestoßen. Ein Gerät von AliExpress aus China… Puhhh… Naja, im Grunde kommt ja inzwischen fast alles aus China. Nur kommt ebenfalls viel Schrott von dort. Die Eckdaten des Netzteils sind so gut, dass ich es probieren wollte.

Nach knapp 3 Wochen waren alle Teile bei mir und ich konnte beginnen es zusammen zu bauen. Das Handbuch gibt es als PDF in Chinesisch und Englisch, in diesem ist das nötigste beschrieben. Ich kann Akkus damit Laden, bekomme bei 60V noch 6A heraus, es lässt sich per USB mit dem PC verbinden, es gibt Software dafür, Firmwareupdates ebenfalls und und und…

Gut, das WLAN Modul funktioniert irgendwie nicht oder öhm nicht so wie ich es erwarten würde. Der Temperatursensor zur Überwachung der Akkutemperatur beim Laden muss „irgendwie“ aus dem Gehäuse gelegt werden und ich habe mich dann die Schutzerde doch zusätzlich noch ans Gehäuse geklemmt.

Davon abgesehen ist das Ding echt gut. Ja es tut was es soll und steigert meine Möglichkeiten.

Hier der Link zum „Nachkaufen“:  https://s.click.aliexpress.com/e/_DBNqtJT

Was habe ich da wieder gekauft?!? OBI LED

Vor knapp zwei Jahren habe ich für meine Werkstatt ein paar neue Deckenleuchten benötigt. Bisher waren zwei Neonröhren meine Lichtquelle. Lichtfarbe und Stärke passten einfach nicht mehr. Im OBI habe ich zu diesem Zeitpunkt zufällig LED Leuchten gesehen, welche in Form und Länge an klassische Neonröhren erinnern. Der Preis lag irgendwo zwischen 10 bis 20 €, also kein Preis bei dem man viel falsch machen kann, oder?

OBI LED SCHROTT Typ LY-5024-2 von Ritter Leuchten GmbH

Naja, vielleicht ja doch!??! Jetzt nach zwei Jahren beginnen ein paar der LED Leuchten zu flackern. Also schnell eine der Leuchten von der Decke geschraubt um sie zu zerlegen. Vielleicht findet sich ja das Problem?!?

Die Schaltung ist sehr überschaubar. Zuerst eine kleine Sicherung, dann ein Brückengleichrichter, ein kleiner Kondensator zur Spannungsglättung (ich habe wohl zwei Versionen der Leuchten, mit und ohne diesen Kondensator), ein kleiner hochohmiger Widerstand (zur schnellen Entladung vom Kondensator beim „Licht aus“) und noch zwei „Einchip“ LED Treiber mit seinen Steuerwiderständen. Oh und natürlich die einzelnen LEDs!

Der Brückengleichrichter ist ein MB6s, welcher laut den Specs „passen“ sollte. Der 400v 10uF Kondensator zur Spannungsglättung passt ebenfalls für mich, auch der 1M Ω Endladewiderstand passt schon. AAAABBBEERRR die beiden LED Treiber SM2082D sehen schon etwas spannend aus, so als wenn die „warm“ werden. Laut specs geben sie bei 10V bis zu 60mA raus. Der Rest wird also in „Wärme“ verwandelt. Was man an den Operating temperature von -40 ~ 125°C bewundern kann.

Bei den Leuchten mit Kondensator pendelt sich die Temperatur bei etwas zwischen 70 und 75°C ein. Bei den Leuchten ohne Kondensator werden es auch mal 90°C. Da hat der kleine LED Treiber wohl ganz schön was zu regeln, wohl der Grund warum in Version 2 ein Kondensator vorgesehen ist 😉

Gut der Hersteller hat versucht mit etwas Wärmeleitpaste auf der Rückseite des LED Streifens die Temperatur ans Alugehäuse abzugeben. Die Menge und Verteilung der Wärmeleitpaste ist aber sehr sehr dürftig. Nach etwas Einsatzzeit nimmt die Leistung der Paste natürlich ab und irgendwann ist es halt zu schlecht oder besser gesagt, die LED Treiber werden zu heiß und verbrennen ihre eigenen Lötkontakte bis zum Haarriss. Dann flackert es… Ich habe daher die Kontakte nachgelötet (kein Flackern mehr) und mit Wärmeleitkleber einen kleinen Kühlkörper auf die Treiber geklebt. Damit hält sich die Temperatur bei knapp 50°C. Das sollte die Lebenszeit deutlich erweitern. Passende Kondensatoren liegen hier ebenfalls noch und sind verbaut. Mal sehen wie lange sie nun nicht flackern!

Zusätzlich habe ich das Alugehäuse noch mit der Schutzerde verbunden. Die simple Lackisolierung vom LED Streifen bei den Temperaturen hat mich nicht ganz überzeugt 😉

Ich würde sagen, dass hat jemand auf Verschleiß gebaut. Die Leuchten sollen wohl kurz nach der Garantie ausfallen. So zumindest mein Eindruck…. Bei dem Preis, naja…

Natürlich hätte ich damit rechnen können. Ich meine Leuchten kaufen, im OBI und dann für etwas bis 20€. Was können die schon in der Herstellung gekostet haben?

Typ LY-5024-2 von Ritter Leuchten GmbH www.ritos.de

TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384 was bedeutet das eigentlich? TLS cipher einfach erklärt..

TLS_AES_256_CGM_SHA384 oder TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384 liest man immer mal wieder, wenn man sich etwas mit Transportverschlüsselung beschäftigt. Was genau dieses bedeutet ist nicht immer ganz klar. Daher möchte ich einmal probieren es etwas aufzuschlüsseln.

Um dieses nachvollziehen zu können, müssen vorher noch die folgenden Begriffe geklärt werden:

  • Key exchange
    Damit ist der Schlüsselaustausch gemeint.
  • Certificate verification
    Hier geht es um das eigentliche Zertifikat vom Server.
  • Bulk encryption
    Die eigentliche Verschlüsselung welche am Ende genutzt wird um die Daten auf ihrem Weg zu verschlüsseln.
  • Hashing
    Die eingesetzten Prüfsummen um sicherstellen zu können, das alles „richtig“ ist.
Verschlüsselung-cipher

Ebenfalls muss man wissen, dass es seit TLSv1.3 einen Unterschied in der Schreibweise der cipher suite gibt. Bei <= TLSv1.2 tauchen in der cipher suite als erstes das Protokoll auf, dann der Algorithmus für den Schlüsselaustausch, nun die digitalen Signaturen des Serverzertifikates gefolgt vom „Rest“. Die Menge möglicher Kombinationen ist jetzt schon sehr hoch. Damit diese „Liste“ nicht in ihrer Länge explodiert hat man bei TLSv1.3 die beiden Punkte Key exchange und Certificate verification aus der Schreibweise entfernt.

Mit diesem Wissen kann man nun anfangen die beiden Zeichenkennten zu „zerlegen“.

TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384

  • TLS
    Nicht schwer, das eingesetzte Protokoll TLS (Transport Layer Security)
  • ECDHE
    Key exchange in diesem Fall ECDHE
  • ECDHE
    Certificate verification bei mir inzwischen ECDHE, sehr oft aber RSA
  • WITH_AES_256_GCM
    Bulk encryption also die eigentliche Verschlüsselung der Daten. In diesem Fall AES (Advanced Encryption Standard) mit der maximalen Länger von 256bit und GCM (Galois/Counter Mode).
  • SHA384
    Das eingesetzte Hashing SHA (Secure Hash Algorithm) in Version 2 mit einer Länge von 384bit.

TLS_AES_256_CGM_SHA384 schafft nun jeder allein, oder?

Sprechen wir noch kurz über den Key exchange. In diesem ist spezifiziert, wie sich Client und Server auf einen eigenen Schlüssel für ihre verschlüsselte Kommunikation einigen. Brauchbar sind dabei Kombinationen aus DHE (wenn sie >= 2048bit sind) und besser noch ECDHE, dabei stehe EC für elliptische Kurven DHE ist Diffie-Hellman. Diffie-Hellmann hat nämlich eine Möglichkeit aufgeführt, wie man für die Verschlüsselung einer Verbindung temporäre Schlüssel einsetzten kann. Denn es lassen sich auch verschlüsselte Verbindungen aufzeichnen. Natürlich kann man so noch immer nicht den Inhalt sehen.. Kommt man an den eingesetzten Schlüssel für die Kommunikation kann man diese damit entschlüsseln. Setzte man also auf einen temporären Schlüssel, gibt es diesen nur für eine gewisse Zeit und dann verschwindet er. Die Zeit, um an diesen Schlüssel zu kommen, ist daher extrem begrenzt und sorgt für eine zusätzliche Sicherheit. „Früher“ hat es gereicht sich einfach irgendwann/irgendwie den Schlüssel vom Server zu besorgen und man konnte mit diesem die Aufgezeichneten Verbindungen entschlüsseln. Bugs wie Heartbleed haben dieses noch vereinfacht. DHE minimiert also etwas das Risiko von Bugs und ergaunerten privat Keys vom Server. Man möchte für seine Verbindungen also nur DHE, besser noch ECDHE! Am besten bietet der Server nichts anders an, da sonst ggf. ein Angreifer versuchen könnte die Verbindung auf etwas „schlechteres“ herunter zu stufen, um so doch am Ende wieder an etwas kommen zu können.

Wenn wir dabei sind… Certificate verification. Nur eine verschlüsselte Verbindung alleine hilft ja nicht, wenn man sich mit dem falschen Server unterhält. Ich meine damit, dass ein Angreifer einfach dafür sorgt, dass wir nicht mit dem gewünschten Server sprechen, sondern mit seinem und dieser vielleicht einfach nur alle Daten durchreicht. Um dieses möglichst zu erschweren gibt es eine ganze Reihe verschiedener Möglichkeiten. Eine davon ist die Certificate verification. Der Server hat also ein Zertifikat, welches vielleicht noch von einer CA signiert wurde, dessen Prüfsumme im DNSsec geschützten DNS liegt, zu dem es HPKP (http Public Key Pinning) gibt oder oder… Dieses Zertifikat sollte daher ebenfalls so gebaut sein, dass man es nicht einfach „nachmachen“ kann. Daher sollte es >=2048bit RSA (asymmetrisches kryptographisches Verfahen) sein, besser noch 4096bit RSA. Hier sieht man schon ein „Problem“. Die Systeme „rechnen“ schneller und damit wird die Bitzahl erhört und die zu übertragenden Daten und das errechnen der Clients usw.. Insg. keine sehr schöne Lösung. ECDHE Zertifikate sind deutlich kleiner, damit schneller zu übertragen und zudem noch für den Client schneller zu prüfen.

Als Beispiel:
Ein Zertifikat mit elliptischen Kurven und einer Länge von 256bit ist grob vergleichbar mit einem RSA Zertifikat mit 3072bit. Wenn jemand daher auf elliptische Kurven setzt, sollten diese nicht kleiner als <=secp256r1 sein. secp224r1 liegt schon zu nahe an 1024bit RSA und fliegt bald weg. secp384r1 ist ganz vorne mit dabei, hat aktuell keinen besonderen Vorteil.

Bulk encryption, tjo die eingesetzte Verschlüsselung. Hier gibt es verschiedene Kombinationen, welche als „sicher“ gelten. Alle zu erklären sprengt sicher den Rahmen. April 2020 kann man sicher merken:

Kombinationen aus AES >=128bit mit GCM oder ChaCha20 mit Poly1305 sind ganz gut. OK ist im Moment noch AES >=128bit mit CBC. 3DES sollte man in keiner Kombination mehr nutzen, das fliegt bald aus der „Sicher“ Liste raus, so wie <= TLSv1.2. Von allen anderen Kombinationen sollte man tunlichst die Finger lassen!

Das Hashing bei der Bulk encryption (das Hashing für Key exchange und Certificate verification hängt am Serverzertifikat, unterliegt den gleichen Merkpunkten) sollte etwas um >= 256bit SHA 2 sein. Ein ganz guter Mittelweg ist hier SHA-384. SHA1 „geht“ wohl dabei ebenfalls noch. Ich würde davon und von allem anderen dennoch die Finger lassen. Wenn ihr irgendwo MD5 RC4 oder ähnliches seht, rennt weg!

Habe ich etwas vergesse, ist etwas falsch oder es gibt Fragen? Dann einfach E-Mail bitte!

SSH bruteforce mit „alter“ Implementierung?!?

Wenn man mit einem System im Internet steht fummelt immer irgendein script kiddie oder bot an den Diensten herum. Oft ist hier eine IP Adresse aus China dabei. Dann probieren sie ein paar default logins und wandern weiter zur nächsten IP Adresse. Die Bots geben dem Ganzen in der Regel schon nicht mehr als drei Versuche, weil sie dann eh von irgendeinem Sicherheitssystem geblockt werden. Da es noch viele andere bots hinter anderen IP Adressen gibt, übermittelt der bot nur seinen Stand der Versuche an das Hirn des Botnetzes und der nächste, nicht geblockte bot, kommt und probiert es weiter…

Alles „kalter Kaffee“… In den letzten Wochen fallen mir zwei kleine Veränderungen auf.

old SSH Bot

Einmal kommen diese IP Adressen noch immer stark aus China… ABER sehr oft ebenfalls von DigitalOcean (USA). Zudem fallen mir die anderen Cloudprovider auf (Google, Microsoft, AWS…). Das verschiebt sich aktuell wohl etwas. Normalerweise kommt ganz viel aus China, dann ganz viel von verschiedenen dynamischen Endkundenanschlüssen auf der Erde. Jetzt kommt ganz viel aus China, dann unglaublich nahe daran Digitalocean, direkt gefolgt von der google-cloud und microsoft-cloud. Erst jetzt kommen die Endkundenanschlüsse und mischen sich mit Adressen aus der AWS-Cloud. Scheinbar haben die Amazonjungs irgendetwas „besser“ gemacht, um ihre Kunden davor zu schützen sich etwas „einzufangen“?!?

Zweitens scheint da ein Botnetz mit recht alter ssh Implementierung unterwegs zu sein. Oder es sucht halt speziell alte SSH-Server? Auf IoT Geräte mit alter Firmware tippe ich weniger, denn von diesen kommt ebenfalls etwas von Cloudanbietern. Bei denen unterstelle ich einfach mal, keine alten IoT Geräte im Einsatz zu haben, die infiziert sind. Naja… Oder es wird halt nach genau solchen Geräten gesucht. Warum alt? Weil ich so etwas in den Logs finde:

Apr  8 10:35:58 YOURMOM sshd[43201]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:35:58 YOURMOM sshd[43201]: Did not receive identification string from 1.2.3.4 port 34244
Apr  8 10:36:22 YOURMOM sshd[43202]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:36:22 YOURMOM sshd[43202]: Unable to negotiate with 1.2.3.4 port 36160: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]
Apr  8 10:36:42 YOURMOM sshd[43204]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:36:42 YOURMOM sshd[43204]: Unable to negotiate with 1.2.3.4 port 39556: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]

Wie ist das bei euch?

Keine RSA Zertifikate mehr o/ ….

….. naja, fast :-/

Wir sind alle in 2020 angekommen und so laaaannngggsssaaammmm könnte man von 4096 bit RSA Zertifikaten mal auf >= 256 bit EC Zertifikate wechseln, oder? Bringt mehr Sicherheit, die Schlüssel sind kleiner und so schneller gerechnet und alle gängigen Browser machen es ebenfalls schon ein paar Jahre.

Vor knapp 6 Monaten habe ich daher einen Satz neuer Schlüssel erstellt und diese schon mal in mein HPKP Header eingebunden, damit der Key-Rollover gut funktioniert. Heute habe ich zu den Schlüsseln Zertifikate gebaut, diese von einer CA signieren lassen und alles eingebunden.

Bei meinem nginx vollkommen schmerzfrei. Einfach die neuen Schlüssel hinterlegt und die Cipherliste von allem RSA-Zeug befreit:

ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256;

Restart vom nginx und zack, schon läuft alles!

Bei den Webseiten also überhaupt kein Problem. Etwas anders ist es bei E-Mail! Postfix macht es natürlich schon, ach LANGE.. Aber ein Microsoft Exchange 2016 in der (weiter weiter fertigstellen) Installation natürlich nicht. Wenn ich also von so einem System weiterhin E-Mails erhalten möchte (ja will ich und per RSA kann so ein System es auch in ~sicher~), muss ich weiterhin etwas auf RSA Basis anbieten.

Jetzt haben sich die Entwickler(innen) bei Postfix schon so etwas gedacht und bieten dieses in der Konfiguration an. Also RSA Keys/Zertifikate? Richtig… OK, das ist nichts besonders aber das es in Kombination mit ECD Keys/Zertifikaten möglich ist. Ach schaut einfach mal die Konfiguration:

smtpd_tls_eckey_file = /usr/local/etc/postfix/ec-postfix.key
smtpd_tls_eccert_file = /usr/local/etc/postfix/ec-postfix.pem
smtpd_tls_key_file = /usr/local/etc/postfix/postfix.key
smtpd_tls_cert_file = /usr/local/etc/postfix/postfix.pem

Ha, ist das nicht schön? smtpd_tls_eckey_ und smtpd_tls_key_?!? Der Server wirft jedem Client nun also zwei Serverzertifikate entgegen. Einmal EC und einmal RSA (ok man braucht also nun ebenfalls zwei Zertifikate).

Schaut mal:

➜  ~ testssl.sh -t smtp smtp.kernel-error.de:25
[....]
  Server Certificate #1
   Signature Algorithm          SHA256 with RSA
   Server key size              RSA 4096 bits
   Server key usage             Digital Signature, Key Encipherment
   Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
   Serial / Fingerprints        4F7A9159AEED9414B7D542ED / SHA1 908FD237EF13A6048077082023C4CDE092F55F33
                                SHA256 74E3984BD5F9FAC26375DAEA6F0326229A0F42AC2EE53088A73DFD5F65107FA9
   Common Name (CN)             *.kernel-error.de 
   subjectAltName (SAN)         *.kernel-error.de kernel-error.de 
   Issuer                       AlphaSSL CA - SHA256 - G2 (GlobalSign nv-sa from BE)
   Trust (hostname)             Ok via SAN wildcard (same w/o SNI)
   Chain of trust               Ok   
   EV cert (experimental)       no 
   ETS/"eTLS", visibility info  not present
   Certificate Validity (UTC)   403 >= 60 days (2020-02-26 14:19 --> 2021-04-05 13:58)
   # of certificates provided   2
   Certificate Revocation List  http://crl2.alphassl.com/gs/gsalphasha2g2.crl
   OCSP URI                     http://ocsp2.globalsign.com/gsalphasha2g2
   OCSP stapling                not offered
   OCSP must staple extension   --
   DNS CAA RR (experimental)    available - please check for match with "Issuer" above
                                iodef=mailto:kernel-erro@kernel-error.de, issue=comodoca.com, issue=geotrust.com, issue=globalsign.com, issue=letsencrypt.org, issue=thawte.com
   Certificate Transparency     yes (certificate extension)

  Server Certificate #2
   Signature Algorithm          SHA256 with RSA
   Server key size              EC 256 bits
   Server key usage             Digital Signature, Key Agreement
   Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
   Serial / Fingerprints        24E25E2F3D57B41671392F25 / SHA1 763EE6D52D3CF0237D9858F27EDF42EF4696B1E2
                                SHA256 9C4C0FCE32BA7E8AEAF17210B509D871D6B2EF237E0E887D7190F28F28011143
   Common Name (CN)             *.kernel-error.de 
   subjectAltName (SAN)         *.kernel-error.de kernel-error.de 
   Issuer                       AlphaSSL CA - SHA256 - G2 (GlobalSign nv-sa from BE)
   Trust (hostname)             Ok via SAN wildcard (same w/o SNI)
   Chain of trust               Ok   
   EV cert (experimental)       no 
   ETS/"eTLS", visibility info  not present
   Certificate Validity (UTC)   365 >= 60 days (2020-02-26 13:37 --> 2021-02-26 13:37)
   # of certificates provided   2
   Certificate Revocation List  http://crl2.alphassl.com/gs/gsalphasha2g2.crl
   OCSP URI                     http://ocsp2.globalsign.com/gsalphasha2g2
   OCSP stapling                not offered
   OCSP must staple extension   --
   DNS CAA RR (experimental)    available - please check for match with "Issuer" above
                                iodef=mailto:kernel-erro@kernel-error.de, issue=comodoca.com, issue=geotrust.com, issue=globalsign.com, issue=letsencrypt.org, issue=thawte.com
   Certificate Transparency     yes (certificate extension)
[....]

Jetzt kann noch ein 2016 Microsoft Exchangeserver einliefern und auch die „coolen Kinder“. Was mache ich wohl 2021? Exchange 2016 ignorieren?!?!


Kleines Update, da es Fragen gab..

Natürlich sollte man seine ciphers in einer sinnigen Reihenfolge für seinen Postifx konfigurieren. Kommen sie in der Reihe erst nach den RSA ciphern wird es natürlich fast nie benutzt *kopfschüttel*. Leute bitte kein copy & paste, mitdenken!

Ein Beispiel für die cipherliste wäre:

tls_high_cipherlist = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256

TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 sind dabei für TLS1.3

ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256 sind für den gewünschten ECD-Key

ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256 sind dann für TLS 1.2 RSA Verbindungen.

Kommt nun ein Client/einliefernder Mailserver, dann wird dieser dank:

tls_preempt_cipherlist = yes

Die vom Server übermittelte cipherliste durchgehen und die erste für beide funktionierende Kombination benutzen.

RSA Verbindungen sehen dann so aus:

Mar  3 08:24:13 smtp postfix/smtpd[49650]: Anonymous TLS connection established from RSA-mailserver[1.2.3.4]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)

ECD Verbindungen so:

Mar  3 08:23:53 smtp postfix/smtpd[49650]: Anonymous TLS connection established from EDC-mailserver[5.6.7.8]: TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)

Einfach, oder?

Cliqz der „Datenschutzbrowser“

Ich bin auf Cliqz aufmerksam gemacht worden und teste den Browser seit einigen Tagen.  Der Browser ist aus einer Suchmaschinenerweiterung für den Firefox entstanden. Auf Firefoxbasis ist es dann selbst zu einen Browser geworden. Die Entwickelnde Firma sitzt in Deutschland und hält selbst Anteile an Ghostery. Ghostery ist also im Browser integriert, wie auch die Suchmaschinenerweiterung, ein Videodownloader….

Firefox ist seit vielen Jahren der Browser meiner Wahl. Gestartet habe ich mit Netscape und ich habe ihn schon eingesetzt als er noch den Namen Phoenix hatte. Damit möchte ich sagen, dass ich schon sehr „eingesessen“ bin und mir ein Wechsel schwer fallen würde. Da Cliqz aber die Firefox Basis hat, bekannt funktioniert und sogar die Firefox Plugins funktionieren (ja ja)… Ersetzt er mehr und mehr meinen Firefox!

Wer ihn sich also noch nicht angeschaut hat und selbst Firefox Benutzer ist, könnte einen Blick riskieren. Ohne große Schmerzen erwarten zu müssen!

https://cliqz.com/

Oh ja… Bei FreeBSD ist er bereits in den Ports 🙂

Fragen? Dann fragen.

Email test der Niederländer hat angezogen!

Der niederländische Staat bietet ein Tool an um Webseiten sowie Mailserver auf ihre Transportsicherheit zu überprüfen. Heute sind die neuen guidelines gestartet. Dieses zieht die geforderte „Sicherheit“ schon ein deutliches Stück an.

So gibt es nun eine Warnung für TLS 1.0 sowie TLS 1.1. Wie wir alle wissen wollte man es ab Q1 2020 nicht mehr nutzen, hier wird es ebenfalls bald von Qualys SSL eine Abwertung geben. Zusätzlich wird besonderer Wert auf einen guten Diffie-Hellman key exchange gelegt und ebenfalls sind weitere Cipher herausgeflogen. Alles um TLS 1.3 möglichst gut den Weg zu ebnen!

https://en.internet.nl/mail/kernel-error.com/

Ebenfalls gibt es in der Hall of Fame nun noch die Sektion der Champions, also die Domains welche es sowohl beim Webserver als auch beim Mailserver die 100% zu erreichen.

Fragen? Dann fragen 🙂

« Ältere Beiträge Neuere Beiträge »

© 2024 -=Kernel-Error=-

Theme von Anders NorénHoch ↑