Autor: kernel-error (Seite 19 von 47)

Na klasse…. Bisher hoffte ich ja noch auf eine Änderung aber vor kurzem ist folgende Info bei mir eingegangen:

….wie bereits im Dezember 2014 angekündigt, müssen wir aufgrund einer Anordnung der Bundesnetzagentur zum 30. Juni 2015 alle 01801-Rufnummern abschalten. Ab diesem Termin sind Sie nicht mehr unter der von Ihnen genutzten Sonderrufnummer erreichbar….

*hmpf* Das wird nervig!

Ich habe diese Rufnummer vor ?13? Jahren bekommen, da es zu diesem Zeitpunkt noch keine Rufnummern aus meinem Ortsnetz gab. OK, die Nummer ist irre lang ABER ich konnte sie über viele Jahre und ein paar Umzüge behalten. Sie war also eine verlässliche Konstante. Immer wenn es darum ging, eine Rufnummer anzugeben über welche man dann doch irgendwie erreichbar sein müsste.

Jetzt ist also meine gute alte Rufnummer tot und ich habe eine neue: (+49) 2225 – 9989127 wo zum Geier muss ich die jetzt wohl überall ändern? Kann mir jemand von der NSA mal eben ein grep auf meinen Datensatz anwerfen?

So long…

Ich erstelle gerade ein Backup eines Notebooks. Plan ist das dieses Backup auf eine USB Platte geht. Dateisystem ist dabei ZFS…

Ein Backup per zfs send und zfs recv ist kein weiteres Problem und sofort zu erledigen. Ein Detail gibt es aber noch, ich will alles verschlüsselt! Das Notebook selbst besitzt eine full disk encryption. Da Notebook, sowie Datensicherung am Ende an einem nicht 100%tig sicherem Ort liegen werden, muss die Datensicherung ebenfalls vollverschlüsselt sein. Da die freie Version von ZFS leider keine Verschlüsselung bietet, setzte ich hier ebenfalls auf eine geli full disk encryption. So muss ich nur den Schlüssel an einem sicheren Ort aufbewahren und darf das Kennwort nicht vergessen 😉 Beides ist machbar, so kann ich mein Backup also liegen lassen. Greift sich jemand die Platte, wird er die Daten kaum entschlüsseln können \o/

Ich habe folgendes gemacht…

dmesg verrät mir, dass die USB-Platte erkannt wurde:

ugen0.2: <Intenso> at usbus0
umass0: <Intenso External USB 3.0, class 0/0, rev 3.00/5.07, addr 2> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x0100
umass0:5:0:-1: Attached to scbus5
da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
da0: <Intenso External USB 3.0 5438> Fixed Direct Access SCSI-6 device
da0: Serial Number 20141231055346
da0: 400.000MB/s transfers
da0: 953869MB (1953525164 512 byte sectors: 255H 63S/T 121601C)
da0: quirks=0x2<NO_6_BYTE>

Als ersten Schritt entferne ich nun per gdisk die voreingerichtete Partitionierung der Platte und erstelle eine neue GPT Partitionstabelle inkl. einer neuen Partition.

geli benötigt einen Schlüssel und dieser besteht am besten aus Zufallsdaten, diese liefert mir /dev/random:

$ dd if=/dev/random of=./backup-key bs=256 count=1

Mit diesem Schlüssel kann ich nun die verschlüsselte geli Partition auf der USB Platte einrichten:

$ geli init -s 4096 -K ./backup-key -l 256 /dev/da0s1
Enter new passphrase:
Reenter new passphrase:

Metadata backup can be found in /var/backups/da0s1.eli and
can be restored with the following command:

    # geli restore /var/backups/da0s1.eli /dev/da0s1

So, los geht es… Die neue verschlüsselte Partition kann eingehangen werden:

$ geli attach -k ./backup-key /dev/da0s1
Enter passphrase:

Fast geschafft, denn nun lässt sich bereits der ZFS-Pool anlegen:

$ zpool create usb-backup /dev/da0s1.eli

Tja, schon kann ich mit dem Pool arbeiten:

$ zpool list
NAME         SIZE  ALLOC   FREE   FRAG  EXPANDSZ    CAP  DEDUP  HEALTH  ALTROOT
smeerbsd     460G   184G   276G    24%         -    40%  1.00x  ONLINE  -
usb-backup   928G   296K   928G     0%         -     0%  1.00x  ONLINE  -

Ich starte also mal ein initiales Backup:

zfs send -R smeerbsd@auto-2015-05-23-21-00-00 | zfs recv -u usb-backup/notebook

Beim zfs send sorgt die Option -R dafür, dass alles rekursiv gesendet wird. Ich schiebe also mein komplettes Notebook auf den USB-Pool unter das neue Volume usb-backup/notebook. Beim zfs revc sorgt die Option -u dafür, dass die Laufwerke dort nicht gemountet werden. Dieses lässt sich optimieren. So kann man dafür sorgen, dass die Volumes auf der USB-Platte unmountbar sind. Dann hängt zfs diese bei einem neuen Import nicht ein, dieses ist aber eher ein neues Thema 😀

Bei weiteren Backups, muss dann natürlich nur noch die Differenz zwischen den Snapshots übertragen werden. Ebenfalls ein anderes Thema.

Beim Aushängen muss man nun natürlich ein paar Dinge beachten:

– sync erzwingen um alle Daten sicher geschrieben zu wissen.
– zpool exportieren
– geli Partition detachen

$ sync
$ zpool export usb-backup
$ geli detach /dev/da0s1

So, nun natürlich noch den Key an einen sicheren Ort legen. Es sollte ein dritter Ort sein, da er ja zur Entschlüsselung benötigt wird. Auf dem Notebook und auf der Sicherungsplatte liegt er also schlecht 😛

Bei Fragen, einfach melden 😀

Die Jungs hinter dem Webmailer roundcube sammeln Geld.

https://www.indiegogo.com/projects/roundcube-next–2

Der Webmailer selbst und vor allem die angepriesenen Ziele klingen sehr unterstützenswert. Vielleicht will der eine oder andere das Projekt ja mit ein paar Euro unterstützten?

So long…

Zwei Jahre sind schon wieder um. Das bedeutet es gibt ein neues S/MIME Zertifikat, da mein altes bald ungültig wird. Hier nun die Daten für interessierte zum Abgleich!

So long

ALT
Zertifikat-Fingerabdruck
SHA1:	7F 8B 92 19 FF 07 BF EB 8E E0 18 D4 98 B8 48 DF E3 0E 4A 85
Läuft ab: 16.05.2015
Signatur-Algorithmus:	SHA1 mit RSA 2048 Bit

 

NEU
Zertifikat-Fingerabdruck
SHA1:	F6 00 F9 B0 DB BF B9 C5 C1 58 03 B2 78 11 84 A7 F1 E8 96 6D
Läuft ab: 08.05.2017
Signatur-Algorithmus:	SHA256 mit RSA 4096 Bit

 

Es gibt bereits seit einigen Jahren die Möglichkeit, seinen GPG Key in die DNS Zone zu packen. Oder besser gesagt, man kann in der Zone einen Ort angeben, an welchem man seinen GPG-Key finden kann.

>>Hinzufügen der GPG Keys zum DNS<<

Dieses ermöglichte bisher einen einfachen Weg um anderen seinen Schlüssel zukommen zu lassen! Unabhängig von den Schlüsselservern und den dort „möglicherweise“ im Umlauf befindlichen ~fake~ Keys.

Inzwischen gibt es einen neuen Ansatz, welcher sich gerade auf dem Weg in ein RFC befindet. Dieser beschreibt, einen neuen Resource Record. Der RR beinhaltet dann direkt den kompletten Schlüssel. So lässt sich dieser noch einfacher und (DNSsec sei Dank) sicherer verteilen.

Nun habe ich meinen aktiven GPG Schlüssel als OPENGPGKEY Record in meine Bind Zone gepackt….

Testen lässt sich dieses hier:
https://openpgpkey.info/?email=kernel-error%40kernel-error.com

Zugegeben, dieser Record „sprengt“ etwas die Zonenlesbarkeit O_o

Den genauen Aufbau und die manuelle Erstellung des Records werde ich sicher bald als kleine „Update“ beschreiben.

Fragen? Dann fragen!

Die aktuelle Gültigkeitsprüfung anhand von CAs hat so ihre Lücken. So erscheint jedes Zertifikat als gültig und vertrauenswürdig, sofern es nur von einer CA unterzeichnet wurde, welcher der Client selbst vertraut.

Erschleiche ich mir also ein gültiges Zertifikat für eine Domain oder schiebe es dem Client als vertrauenswürdig unter, wird sich der Benutzer zwar sicher und geschützt fühlen, dennoch ist er es nicht.

Mögliche Beispiele finden sich hier:
– Google deckt erneut Missbrauch im SSL-Zertifizierungssystem auf
– Comodo stellt fälschlicherweise Microsoft-Zertifikat aus

Nun gibt es mehrere Ansätze um diese Situation zu verbessern. TLSA / DANE zusammen mit DNSsec, HSTS (Strict Transport Security) usw… Inzwischen bin ich auf fast alle eingegangen. Es fehlt aber noch ein, wie ich finde, wichtiger Vertreter. HPKP (Public Key Pinning). Daher soll es nun um HPKP gehen 🙂

Public Key Pinning verfolgt einen ähnlichen Ansatz, wie Strict Transport Security, erweitert diesen nur etwas. Strict Transport Security wird als HTTP-Header gesetzt und sorgt dafür, dass ein Client für den Ablauf einer, durch diesen Header, gesetzten Frist nur noch SSL/TLS gesicherte Verbindungen zu dieser Domain benutzen wird. Public Key Pinning sorgt nun zusätzlich dafür, dass der Client nur gewisse Zertifikate über einen bestimmten Zeitraum annimmt.

Sind beide Header gesetzt, baut der Client also nur noch gesicherte Verbindungen auf und akzeptiert nur noch bestimmte Zertifikate, für einen gewissen Zeitraum. Dieses bietet ebenfalls gewisse Lücken, dennoch hebt es die Sicherheit ein ganzes Stück an, denn es wird für einen Angreifer deutlich aufwendiger seine gefälschten Zertifikate ins Rennen zu bringen.

Wie funktioniert es nun genau?
Im HPKP Header übermittelt der Webserver zwei base64 encodete SHA256-Hash Werte von den Public Keys zweier Zertifikate, sowie eine Ablaufzeit (und ggf. noch ein paar Optionen). Zwei Hash Werte aus einem einfachen Grund… Es kann ja passieren, dass man sein Zertifikat tauschen möchte/muss. Wäre hier nur der Hash eines Zertifikates „fest gepinnt“, würden alle Clients den Verbindungsaufbau mit dem neuen Zertifikat verweigern und dieses im schlimmsten Fall bis zum Ablauf der gesetzten Frist (in meinem Beispiel gleich 60 Tage). Aus diesem Grund nimmt man zwei! Das aktive Zertifikat, welches man ggf. direkt von der CA unterschreiben lässt und einsetzte, sowie ein Backup-Zertifikat, welches man vielleicht nur bis zum CSR vorbereitet und an einer anderen Stelle aufbewahrt. Nun könnte man direkt noch ein anderes Verfahren einsetzten oder ein anderes System um dieses Zertifikat zu erzeugen usw. usw… Wir halten also fest, Hash Werte von zwei Zertifikaten, wobei eines selbstverständlich das aktive ist.

Diese Hashwerte lassen sich nun mittels openssl über die keys, csr oder das fertige Zertifikat bauen. Ich nehme dafür gerne direkt die keys, da sich aus diesen alles weitere ergibt. Als Test, auf korrekte Hash Werte, kann man natürlich alle drei Wege nutzen. Dabei sollten sich natürlich immer die gleichen Werte ergeben!

Ich gehe also davon aus, dass bereits zwei Keys erstellt wurden. Damit lassen sich nun wie folgt die Hash Werte erstellen:

$ openssl pkey -in http-active.key -pubout | grep -v PUBLIC|base64 -d|openssl dgst -sha256 -binary|base64
31XofAyJSqWKGO4xhVZFNe5+grAZQ4cvl2tahddU/ME=
$ openssl pkey -in http-backup.key -pubout | grep -v PUBLIC|base64 -d|openssl dgst -sha256 -binary|base64
KJV9jpFftvj+TjzaVtnI44aYm8DdjdO00vFZ+YtBjdA=

Um die Header setzten zu können muss beim Apache noch das Modul headers geladen werden:

$ a2enmod headers

In der eigentlichen Konfigurationsdatei des jeweiligen hosts/vhosts fehlt nun nur noch folgende Zeile:

Header always set Public-Key-Pins: 'max-age=5184000; pin-sha256="31XofAyJSqWKGO4xhVZFNe5+grAZQ4cvl2tahddU/ME="; pin-sha256="KJV9jpFftvj+TjzaVtnI44aYm8DdjdO00vFZ+YtBjdA="'

Hash Werte natürlich einpassen 😛 und in dem Zuge über HSTS nachdenken!

Zusätzlich können noch ein paar Optionen in diesem Header folgen. So zum Beispiel report-uri=”http://www.example.org/hpkpReportUrl” Hier wird über einen HTTP-Post einige Informationen vom Client im JSON Format übertragen. Also ob es Probleme gab oder nicht… Die dort folgende URL sollte demnach vielleicht nicht SSL/TLS gesichert sein, oder nicht unter der gleichen Domain liegen. Wäre im Fehlerfall ja sonst ebenfalls nicht erreichbar! Ebenfalls lässt sich mittels includeSubdomains; zusätzlich angeben, dass dieses ebenso für alle Subdomains gilt.

Prüfen?
Prüfen kann man alles natürlich wieder per https://www.ssllabs.com/

Viel Spaß und wie immer, bei Fragen; fragen!

DNSSEC und DNS-based Authentication of Named Entities (DANE)

Apache und sichere SSL / TLS Verschlüsselung

Einige haben es ja schon gesehen, ich habe nun doch vorzeitig mein Zertifikat von SHA1 auf SHA2 (SHA256) gehoben. Nein, ich habe nicht für das Widerrufen bezahlt 😛 Wer ins Zertifikat schaut, wird schon sehen wie ich es gemacht habe. Damit bin ich dann wohl erst einmal wieder A+…. Fragt sich für wie lange 😛 OCSP stört mich noch etwas, nicht unbedingt nötig, denn noch finde ich es ~unschön~! Jetzt nicht so unschön, dass ich es unbedingt sofort angehen muss; dennoch ist es irgendwie unschön!

 

So long 🙂

Da bekomme ich doch gerade eine E-Mail zurück mit der Begründung:

Reporting-MTA: dns; smtp.kernel-error.de
X-Postfix-Queue-ID: 30E4E7461347
X-Postfix-Sender: rfc822; kernel-error@kernel-error.com
Arrival-Date: Wed, 28 Jan 2015 11:50:00 +0100 (CET)

Final-Recipient: rfc822; mailer@domain.tld
Original-Recipient: rfc822;mailer@domain.tld
Action: failed
Status: 4.7.5
Diagnostic-Code: X-Postfix; Server certificate not verified

Dazu passend findet sich im Postfix Logfile folgendes:

Feb  2 12:15:21 postfix/smtp[1520]: Trusted TLS connection established to domain.tld[2001:1111:1:1111::1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb  2 12:15:21 postfix/smtp[1520]: 30E4E7461347: Server certificate not verified
Feb  2 12:15:22 postfix/smtp[1520]: Trusted TLS connection established to domain.tld[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb  2 12:15:22 postfix/smtp[1520]: 30E4E7461347: to=<mailer@domain.tld>, relay=domain.tld[1.2.3.4]:25, delay=433522, delays=433521/0.09/0.63/0, dsn=4.7.5, status=deferred (Server certificate not verified)

Na? Schon eine Idee? Erst soll die TLS Verbindung trusted sein und dann doch wieder nicht? Ganz einfach 🙂 Es ist DANE…. Postfix würde ja selbst eine E-Mail zustellen, wenn er das Zertifikat nicht prüfen könnte. Hat der Empfänger aber einen TLSA-Record für sein Mailserver Zertifikat veröffentlicht und Postfix prüft dieses mit negativem Ergebnis, dann kann man wohl davon ausgehen, dass da etwas nicht stimmt. Entweder der Empfänger hat ein Problem mit seiner Konfiguration oder es versucht sich gerade jemand „dazwischen“ zu drängen.

Weiter prüfen konnte ich es mit posttls-finger:

$ posttls-finger -t30 -T180 -c -L verbose,summary domain.tld
posttls-finger: initializing the client-side TLS engine
posttls-finger: using DANE RR: _25._tcp.domain.tld IN TLSA 3 0 1 B3:E7:94:4A:CE:14:0D:CE:53:08:C6:D8:A5:D3:8C:EE:DD:94:FC:8A:B4:DD:8E:DD:DD:DD:DD:DD:DD:DD:DD:DD
posttls-finger: setting up TLS connection to domain.tld[2001:1111:1:1111::1]:25
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=0 verify=1 subject=/C=DE/CN=www.domain.tld/emailAddress=hostmaster@domain.tld
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: subject_CN=www.domain.tld, issuer_CN=StartCom Class 1 Primary Intermediate Server CA, fingerprint=65:76:45:E3:50:1A:54:5D:BE:30:8F:DD:DD:DD:DD:DD:DD:DD:DD:DD, pkey_fingerprint=63:53:F8:60:76:8D:01:E8:57:93:EA:3C:DD:DD:DD:DD:DD:DD:DD:DD
posttls-finger: Untrusted TLS connection established to domain.tld[2001:1111:1:1111::1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Passt also wirklich nicht… Gleicher Test auf verschiedenen Systemen, gleiches Ergebnis. Ebenfalls die einschlägigen Webseiten bringen diese Meldung (https://de.ssl-tools.net/mailservers/).

Ich muss zugeben, ist eine Premiere für mich. Also ein wirklich echt fehlgeschlagener DANE Test von Postfix, welcher die Mailzustellung verhindert hat. Natürlich hat postfix nicht nach dem ersten Versuch aufgegben, diese Prüfung führt zu einem temporären Fehler der 4xx Reihe. Postfix versucht es also ein paar Tage. In meinem Fall hat also alles genau so funktioniert, wie ich es mir gewünscht habe. Postfix testet die TLSA-Records, bemerkt einen Fehler, logt diese und probiert es noch einmal. Der Fehler bestand dauerhaft und Postfix gab mir die Mail zurück, mit der Info das etwas mit dem Zertifikat des Empfängers nicht stimmt. Das hat Postfix wirklich gut gemacht *tätschel*

So long…