Archiv für ‘kryptographie’

OpenSSH Snapshot mit ED25519 SSHFP

21. Januar 2014 17:19 | Autor: Marc | 1 Kommentar | Kategorie(n): Allgemeines

Um OpenSSH mit ED25519 zu nutzen, muss nur eine aktuelle Snapshot-Version besorgt, kompiliert und installiert werden.
Das geht wie gewohnt mit configure/make/make install. Für die meisten Linux-User macht es Sinn, configure mit den Parametern –prefix=/usr –sysconfdir=/etc/ssh zu starten, sofern OpenSSH bereits in irgendeiner Vorgängerversion installiert war. Die bestehende Konfiguration wird dabei nicht geändert.

Soll OpenSSH auch mit passenden SSHFP-Resource Records umgehen können, muss spätestens vor dem make dieser Patch angewendet werden. Dafür wird einfach im Verzeichnis openssh, das tar beim Auspacken des Snapshot angelegt hat, folgendes ausgeführt:

$ patch </PFAD/PATCHFILE

Zu den ED25519 SSHFP-RR ist allerdings zu sagen, dass ein RFC hierzu noch aussteht, womit es diesen Typ offiziell noch nicht gibt.

 

Während der Installation wurde ein ED25519-HostKey angelegt. Dieser findet sich, wenn configure entsprechend angewiesen wurde, im Verzeichnis /etc/ssh und sollte der ebenfalls dort residierenden sshd_conf bekannt gemacht werden.

  # HostKeys for protocol version 2
  HostKey /etc/ssh/ssh_host_rsa_key
  HostKey /etc/ssh/ssh_host_ecdsa_key
  HostKey /etc/ssh/ssh_host_ed25519_key

 

Damit identifiziert sich der Rechner mit einem ED25519-HostKey.
Damit ein Verbindungsaufbau mit dem Key Exchange Algorithmus ED25519 und dem Cipher chacha20, der so wie ED25519 ebenfalls von Daniel J. Bernstein stammt, stattfinden kann, müssen noch die Prioritäten dieser entsprechend in den Konfigurationsdateien angegeben werden.
Ein Beispiel kann wie folgt aussehen.

sshd_config (Server)

  Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com (...)
  KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384 (...)

ssh_config (Client)

  HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01@openssh.com (...)
  Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-gcm@openssh.com,aes128-ctr (...)
  VerifyHostKeyDNS yes
  StrictHostKeyChecking ask

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com in Verbindung mit VerifyHostKeyDNS yes weist den Client an, den ED25519-HostKey mit dem im DNS hinterlegten zu vergleichen.
Sofern der Patch mit einkompiliert wurde, kann ssh-keygen verwendet werden, um diesen DNS-Eintrag zu verwenden.

$ ssh-keygen -r `hostname` -f /etc/ssh/ssh_host_ed25519_key

Ohne den Patch könnte der SSHFP-RR zwar auch anders erzeugt werden, der SSH-Client würde allerdings nicht im DNS danach suchen.

 

WPA-Verschlüsselung angreifbar

28. August 2009 00:04 | Autor: Marc | Keine Kommentare | Kategorie(n): Netzwerke, Sicherheit

Forschern der Universtität von Kobe in Japan soll es gelungen sein, die in WLAN häufig eingesetzte WPA-Verschlüsselung zu brechen. Der Angriff auf ein WLAN, welches mittels WPA mit TKIP-Algorithmus gesichert ist, soll nur rund eine Minute dauern. An der Universität von Hiroshima sollen im Rahmen einer Konferenz am 25. September weitere Details bekannt gegeben werden.

Bereits vor einigen Monaten war es gelungen, WPA mit TKIP innerhalb von 12-15 Minuten erfolgreich anzugreifen. Allerdings funktionierte diese Vorgehensweise nur mit einer begrenzten Reihe von Geräten.

Nicht betroffen von den erfolgreichen Angriffen sind RSN(WPA2)- und WPA-verschlüsselte Netzwerke mit AES-Algorithmus. Die meisten Router erlauben einen Mischbetrieb beider Algorithmen im WPA-Modus. RSN unterstützt generell nur AES.

Update:
Golem.de hat inzwischen auch etwas dazu.

 

DKIM mit Postfix und Spamassassin

20. August 2009 19:24 | Autor: Marc | 3 Kommentare | Kategorie(n): Sicherheit

DKIM als Authentifizierungsmechanismus für E-Mails ist ein Zusammenspiel von DNS, MTA und Spam-Filter. Der versendende Mailserver versieht den Header ausgehender Mails mit einer Signatur (Private Key), welche der empfangende MTA anhand eines speziellen DNS TXT-RR (Public Key) verifizieren kann.

Mag kompliziert klingen, ist aber eigentlich ganz einfach umzusetzen, wie das folgende Beispiel auf einem Debian Lenny-Server mit Postfix, BIND und Spamassassin belegen soll. Vorausgesetzt wird hierbei, dass die drei genannten Dienste bereits im Normalbetrieb funktionieren.

Als Erstes muss das Schlüsselpaar erstellt werden. Dies geschieht mit den folgenden Kommandos:
openssl genrsa -out <Schlüsselbez.>.private 1024
openssl rsa -in <Schlüsselbez.>.private -out \
<Schlüsselbez.>.public -pubout -outform PEM

Die Schlüsselstärke von 1024 Bit ist die Minimalanforderung von DKIM, ein längerer Private Key hätte aber naturgemäß auch einen längeren Public Key zu Folge, und hier spielt BIND dann aufgrund einer begrenzten Größe des TXT-RR nicht mehr mit.

Nun kann der Public Key per DNS bekannt gemacht werden. Da dies ohne Zeilenumbrüche geschehen muss, werden eben diese kurzerhand ignoriert:
cat <Schlüsselbez.>.public | tr -d "\n"

Der reine Schlüssel (ohne Header) kann jetzt in die Zonendatei der Domain kopiert werden, die mit DKIM ausgestattet werden soll. Hierfür wird die spezielle Subdomain <Schlüsselbez.>._domainkey verwendet. Ein kompletter TXT-RR für DKIM kann wie folgt aussehen:

mail2009._domainkey   IN TXT "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADC (gekürzt)"

Es macht Sinn, den Schlüssel regelmäßig auszutauschen und dies auch im DNS zu dokumentieren. Statt den alten Schlüssel einfach zu löschen, wird er widerrufen. Einer entsprechender Eintrag im TXT-RR sieht dann so aus: "v=DKIM1\; k=rsa\; p="

Auf dem System kann nun das Paket dkim-filter installiert werden. Dies ist in den Repositories von Debian vorhanden und kann somit per apt installiert werden. Die Konfigurationsdateien sollten in etwa folgendermaßen modifiziert werden (meine Konfiguration ist auch auf dem Gopher zu finden):

/etc/default/dkim-filter:
SOCKET="inet:8891@127.0.0.1"

/etc/dkim-keys.conf:
*domain.tld:domain.tld:/etc/mail/dkim/mail2009

(eine Zeile für jede Domain)

/etc/dkim-filter.conf:
Syslog   yes
UMask   002
Background   yes
SubDomains   yes
KeyList   /etc/dkim-keys.conf
RequiredHeaders   yes
OmitHeaders   Return-Path,Received,Comments,Keywords,Bcc,Resent-Bcc

Außerdem muss die Postfix-Konfiguration noch modifiziert werden:

/etc/postfix/main.cf
(...)
smtpd_milters = inet:localhost:8891

Nach dem Restart der Dienste dkim-filter und postfix kann das System bereits für ausgehende Mails genutzt werden. Ob alles funktioniert, kann mit einer Testmail an check-auth@verifier.port25.com überprüft werden. Nach kurzer Zeit erhält man eine Mail mit einem detaillierten Bericht.

Für die DKIM-Integration in Spamassassin wird nun noch das Paket libmail-dkim-perl benötigt und anschließend die Konfiguration angepasst.

/etc/spamassassin/v320.pre:
loadplugin   Mail::SpamAssassin::Plugin::DKIM

/etc/spamassassin/local.cf:
whitelist_from_dkim *@googlemail.com googlemail.com
score USER_IN_DKIM_WHITELIST -10.0
score DKIM_VERIFIED -5.0
score DKIM_POLICY_TESTING 0

Die Score-Werte in der local.cf können natürlich angepasst werden. Evtl. ist hier ein wenig Testen erforderlich.

 

Mails verschlüsseln mit GnuPG

10. Dezember 2008 23:58 | Autor: Marc | 1 Kommentar | Kategorie(n): Linux, Sicherheit

Zwar gehe ich nicht unbedingt davon aus, dass das BKA oder sonstirgendwer bewusst meine Mails mitliest, aber man weiß ja nicht, ob der Empfänger einer Mail nicht möglicherweise von solchen Maßnahmen betroffen ist. Und aus diesem Grund habe ich mich nun ein wenig mit dem Ver- und Entschlüsseln von Mails per GnuPG beschäftigt.

Zu aller erst benötigt man ein eigenes Schlüsselpaar. Dieses besteht aus einem privaten und einem öffentlichen Schlüssel. Eine kurze, aber verständige Anleitung zur Erstellung findet sich im Wiki des CCC Mainz.

Um eine verschlüsselte und signierte Mail versenden zu können, benötigt man außerdem den öffentlichen Schlüssel des Empfängern. Und genauso benötigt der Empfänger den öffentlichen Schlüssel des Absenders, um die Mail entschlüsseln zu können.

Zahlreiche Mailprogramme bieten native Unerstützung für GnuPG/PGP. Für die meisten anderen gibt es entsprechende Plugins.

Um die Schlüssel nicht immer manuell austauschen zu müssen, gibt es öffentliche Keyserver, auf denen man in aller Regel fündig wird (vorausgesetzt natürlich, der Mensch auf der Gegenseite hat seinen Schlüssel veröffentlicht).

Um besser einschätzen zu können, ob man veröffentlichten Schlüsseln vertrauen kann, gibt es das GnuPG-Web of Trust. Die Idee basiert auf der Signierung des eigenen Schlüssels durch Personen, die einem (möglichst persönlich) bekannt sind. Wie dies technisch umgesetzt ist, kann im Ubuntu-Users Wiki nachgelesen werden.