- Details
-
Erstellt: Samstag, 13. April 2019 10:43
Einer der Vorteile eines eigenen Mailservers ist, dass man hier so restriktiv in seiner Konfiguration sein kann wie man es selbst für sich und seine Zwecke für richtig erachtet. So habe ich für mich entschieden, dass ich nur E-Mails annehmen möchte, welche über eine Transportverschlüsselung (TLS) bei mir eingeliefert werden. Wer also die folgende Meldung in seiner Errormail hat, dessen Mailserver hat sicher probiert die E-Mail bei mir ohne Transportverschlüsselung (also im Klartext) abzuliefern.
[...]
530-5.7.0 Must issue a STARTTLS command first
530 5.7.0 For assistance, visit https://riot.im/app/#/user/@kernel-error:kernel-error.com?action=chat
[...]
Transportverschlüsselung ist dabei bitte nicht zu verwechseln mit einer signierten oder gar verschlüsselten E-Mail. Ich nehme auch E-Mails an, welche weder signiert oder verschlüsselt sind. Die Transportverschlüsselung ist hier etwas wie das s bei httpS://. Das Mitlesen der E-Mail auf dem Weg zwischen eurem und meinem Mailserver soll damit nach Möglichkeit verhindert werden.
Möglichst verhindert werden? Ja, einen 100%tigen Schutz gibt es selbstverständlich nicht. Man kann nur versuchen sich diesem zu nähern. Dieses Nähern betrifft nun den zweiten Punkt welcher verhindern könnte, dass ihr mir eine E-Mail senden könnt. Die eingesetzte Transportverschlüsselung muss nämlich als "sicher" gelten. Ich nehme also keine SSLv3 RC4 MD5 bla Verbindungen an. Wer also etwas wie das Folgende oder halt "Verbindung nicht möglich" bekommt, dessen Mailserver ist nicht in der Lage eine "sichere" TLS Verbindung aufzubauen.
warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared ciphe
warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol
warning: TLS library problem: error:142090FC:SSL routines:tls_early_post_process_client_hello:unknown protocol
Warum macht dieses nun nicht jeder so? Nun... Möchte man als Unternehmen Geld damit verdienen, dass man in irgendeiner Form Benutzer dazu bringt bei einem einen E-Mail Service zu nutzen, dann möchte man natürlich seinen Kunden einen möglichst reibungsfreien Austausch ermöglichen. Denn der normale Benutzer wird es kaum verstehen und sicher einfach einen Anbieter wählen bei dem es "funktioniert". Dieses könnte man daher als Grund anführen warum nicht jeder so restriktiv in seinen Empfangseinstellungen ist. Davon abgesehen hindert es kein Unternehmen daran, seinem Mailserver für ausgehende E-Mails die Möglichkeit zu schaffen gutes TLS zu sprechen. Ok, es sei denn dieser Server steht in China oder Nordkorea. Mein Mailserver ist also weit davon entfernt etwas Unmögliches zu verlangen!!!
Sprecht also mal mit der zuständigen Person eures Mailservers und fragt aus welchem Grund euer Mailserver nicht in der Lage ist sicheres TLS zu sprechen und ob man dieses nicht vielleicht doch ändern könnte!
Um mich in der Zwischenzeit dennoch irgendwie zu erreichen gibt es verschiedene Möglichkeiten welche man >>hier<< findet. Am einfachsten sicher über Matrix/Riot: @kernel-error:kernel-error.com.
Bis dahin :-)
- Details
-
Erstellt: Freitag, 19. April 2019 17:43
FreeBSD portierte bisher seinen ZFS Zweig von Illumos. Dieses wechselt nun zu ZFS on Linux. Was es für mich so spannend macht ist der Verschlüsselungssupport. ZFS on Linux bietet diesen bereits und somit wird er wohl auch bald für FreeBSD zur Verfügung stehen :-)
Gerade eben lese ich eine E-Mail von Kris Moore auf der FreeBSD-Current Mailingliste. In der E-Mail werden zwei ISO Images genannt welche es ermöglichen FreeBSD mit ZFS on Linux zu testen. \o/ Natürlich ist es nicht die Version welche am Ende "drin" sein wird und es ist nichts was man auch nur im Ansatz produktiv einsetzten kann/sollte. ABER testen soll man es ja und ich möchte unbedingt mal die Verschlüsselung sehen!
Daher habe mich mir die gepatchte FreeBSD13 Version einmal herunter geladen: https://pkg.trueos.org/iso/freebsd13-zol/FreeBSD13-ZoL-20190418-x64.iso
Zuletzt habe ich den Einsatz unter Solaris beschrieben. Nun also einmal ganz kurz und knapp in FreeBSD :-)
Erstellen eines neuen Datasets:
root@freebsd13-zol:~ # zfs create -o encryption=aes-256-gcm -o keyformat=passphrase usbpool/test01
Enter passphrase:
Re-enter passphrase:
Als Art der Verschlüsselung habe ich hier aes-256-gcm gewählt und der Schlüssel soll als passphrase von mir eingegeben werden. Nachdem ich mein passphrase eingegeben habe wird das neue Dataset erstellt und direkt für mich ein gehangen, wie man es gewohnt ist:
root@freebsd13-zol:~ # zfs list usbpool/test01
NAME USED AVAIL REFER MOUNTPOINT
usbpool/test01 99K 899G 99K /usbpool/test01
root@freebsd13-zol:~ # zfs get encryption usbpool/test01
NAME PROPERTY VALUE SOURCE
usbpool/test01 encryption aes-256-gcm -
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME PROPERTY VALUE SOURCE
usbpool/test01 mounted yes -
Da ein passphrase von mir jeweils eingegeben werden muss, kann dieses Dataset bei einem reboot oder impot/export nicht automatisch eingehangen werden.
root@freebsd13-zol:~ # zpool export usbpool
root@freebsd13-zol:~ # zpool import usbpool
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME PROPERTY VALUE SOURCE
usbpool/test01 mounted no -
Daher muss ich dieses von Hand anstoßen.
root@freebsd13-zol:~ # zfs mount -l usbpool/test01
Enter passphrase for 'usbpool/test01':
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME PROPERTY VALUE SOURCE
usbpool/test01 mounted yes -
Genau so habe ich es mir gewünscht. Schnell, einfach und unkompliziert. Ob es ebenfalls über Snapshots send/recv und mit Keyfiles usw. so arbeitet wie ich es mir wünsche, werde ich nun probieren können!
Ein verschlüsseltes Dataset anlegen zu können, erfreut mich aber jetzt schon sehr!
Fragen? Dann fragen :)
Update
Um Fragen zu beantworten. Ja, die Userland Tools und das Kernelmodul sind bereits in den Ports. Will man es auf einem FreeBSD 12.x RELEASE bauen funktioniert dieses nicht:
root@test:/usr/ports/sysutils/zol-kmod # make install clean
===> zol-kmod-2019041800 needs FreeBSD 12/13 with AES-CCM support.
*** Error code 1
Stop.
make: stopped in /usr/ports/sysutils/zol-kmod
Es funktioniert sauber mit FreeBSD 13 CURRENT und dem FreeBSD 12 STABLE. CURRENT ist bei FreeBSD immer die nächste Version. Die RELEASE Versionen sind die stabilen Versionen welche auch nur noch Security und Bugfixes bekommen. Die STABLE Verstion bekommt zudem noch "Veränderungen" mit. Ganz grob kann man es also mit Stable, Testing, Unstable bei Debian vergleichen :-)
Der AES-CCM Support ist also nur in FreeBSD 13 CURRENT und in FreeBSD 12 STABLE im Kernel aktiviert. Man kann also nun zum Testen auf die 13 wechseln, auf die 12 Stable gehen, auf das nächste RELEASE warten, seinen Kernel neu bauen oder eines der ISOs oben probieren. Jetzt ist auch klar, warum ich die ISOs so empfehlenswert fand/finde :-D Vor allem da das FreeBSD 12 ISO das FreeBSD 12.0-RELEASE-p3 ist und man so schon seine Produktivumgebung testen kann!
