Hinweis: Das ist die FAQ zur Benutzung mit einem Hamster, der eine eingebaute SSL-Unterstützung besitzt und kein STunnel mehr benötigt, also dem Hamster Classic ab Version 2.0.0.0. Für Hamster, die noch STunnel benötigen (z.B. Hamster Classic vor Version 1.3.23.140), sollte die dafür gedachte FAQ benutzt werden. Sie ist zu finden unter: http://www.philippwendler.de/hamster/hamster-ssl-stunnel.txt.
Folgendes wird benötigt:
Diese ersten Schritte sind immer nötig:
Kopiere die beiden OpenSSL-DLLs, die Du kompiliert oder heruntergeladen hast, in das Hamsterhauptverzeichnis oder ein Verzeichnis, das in der Umgebungsvariable %PATH% enthalten ist. Starte dann den Hamster neu.
Zuerst einmal musst Du herausfinden, ob der Server SSL/TLS auf dem Standardport oder über einen separaten Port unterstützt. Das steht oft auf der Website des Providers. Es gibt auch bei Remo Müllers anytool-Projekt (siehe Linkverzeichnis) im dortigen Wiki eine Übersicht über bekannte Freemail-Dienste, die SSL zumindestens auf separatem Port anbieten.
Wenn der Server SSL/TLS auf einem separaten Port unterstützt, und Du dir die Portnummern nicht merken kannst, öffne die Datei services (ohne Endung!). Bei Windows 95 bis Windows ME liegt sie im Windows-Verzeichnis, bei Windows NT und Nachfolgern im Verzeichnis %SYSTEMDIR%\drivers\etc (normalerweise c:\windows\system32\drivers\etc). Füge folgende Zeilen ein und speichere sie unter demselben Namen:
| smtps | 465/tcp |
| nntps | 563/tcp |
| imaps | 993/tcp |
| pop3s | 995/tcp |
Jetzt kannst Du überall statt Port 465 smtps, statt Port 563 nntps und statt Port 995 pop3s, also den Standardportnamen mit angehängtem s, angeben.
Beachte im folgenden, dass es bei zwei oder mehr verschlüsselten Verbindungen gleichzeitig und wenig Hauptspeicher Probleme wegen Speichermangels geben kann. Sollte die Fehlermeldung library has no ciphers - Creating SSL context failed im Hamsterlog auftreten, musst Du die Zahl der gleichzeitigen verschlüsselten Verbindungen (auch mehrere Threads zu einem Newsserver zählen dazu) reduzieren.
Wenn der Server SSL/TLS auf dem Standardport unterstützt, trage den Server ganz normal ein und stelle die erste Auswahlliste in den SSL-Einstellungen auf TLS immer nutzen. Dazu müssen temporär die erweiterten Einstellungen aktiviert werden. Wenn der Server öfter mal Probleme mit dem TLS hat, und Du dann lieber über eine unsichere Verbindung abfragst, als gar nicht, kannst Du es auch auf TLS nutzen, wenn möglich stellen.
Wenn der Server SSL/TLS ausschließlich über einen separaten Port unterstützt, trage den Server in den Hamster ein, setze die Auswahlliste auf SSL bei sicherem Port immer nutzen und ersetze den Standardport (meist angegeben mit dem Protokollnamen) durch den SSL-Port. Das ist normalerweise 995 bei POP3-SSL, 465 bei SMTP-SSL und 563 bei NNTP-SSL.
Wenn Du jetzt über das Online-Menü eine Verbindung zu diesem Server aufbaust, wird eine SSL-Verbindung aufgebaut. Vergiss aber nicht, falls vorhanden, denselben Server ohne SSL aus der Gruppe im Online-Menü herauszunehmen. Das ist sonst ein Sicherheitsrisiko, da zusätzlich noch eine unverschlüsselte Verbindung aufgebaut wird und Dein Passwort wieder unverschlüsselt übertragen wird.
Beachte, dass Du dir ohne Zertifikat nicht sicher sein kannst, dass Du auch wirklich mit dem gewollten Server sprichst. Du solltest dir also das Zertifikat beschaffen (s. Frage 5) und benutzen (s. Frage 8.1.2). Mit der Auswahlbox Wähle Überprüfungsverfahren kannst Du die verwendete Stufe einstellen. Bei Zertifikate immer überprüfen wird nur das Zertifikat der CA und die Signatur des Serverzertifikats überprüft. Bei Peer mittels lokal vorhandener Zertifikate überprüfen wird zusätzlich das Serverzertifikat selber überprüft. Zum Feld Überprüfung über Datei siehe Frage 7.
Folge einfach den Anweisungen in Frage 1 und 1.1.
Beachte, dass in der Serverliste, die übergeben wird, eventuell der Port geändert werden muss.
Ergänze den Befehl HamFetchMail im Skript um die SSL-Parameter. Mindestens der SSLMode muss bei SSL-Benutzung immer angeben werden, da der Hamster die SSL-Einstellungen, die eventuell im Menü für diesen Server gemacht wurden, nicht übernimmt. Die anderen SSL-Parameter können weggelassen werden, dann nimmt der Hamster die Standardwerte (SSLVerify = 0; SSLCaFile = "").
HamFetchMail( <server>, <port>, <user>, <pass>, <destuser>, <filter>, <LeaveOnServer>, <SSLMode>, <SSLVerify>, <SSLCaFile> )
Per OLE musst Du jetzt den Befehl ControlRunFetchMailTLS statt ControlRunFetchMail verwenden.
function ControlRunFetchMailTLS( <server>: WideString; <port>: WideString; <user>: WideString; <pass>: WideString; <destuser>: WideString; <SSLMode>:Integer; <SSLVerify>:Integer; <SSLCaFile>:WideString ) :Integer
Die Wörter in den spitzen Klammern müssen dabei ersetzt werden, siehe die Erläuterungen zu den Befehlen in der Hilfe.
Bemerkungen:
# Abruf vom SSL-Port 995, dazu passend der SSLMode = 1: #!hs2 HamFetchMail( "pop3-server.example.com", "995", "$42", "", "admin", "", 0, 1, 3, "" ) # Abruf vom Standardport 110, dazu passend der SSLMode = 3: #!hs2 HamFetchMail( "pop3-server.example.com", "110", "", "", "admin", "", 0, 3, 3, "" )Beispiele VBScript:
' Abruf vom SSL-Port 995, dazu passend der SSLMode = 1: Set Hamster = Wscript.CreateObject( "Hamster.App" ) ControlRunFetchMailTLS( "pop3-server.example.com", "995", "", "", "admin", "", 1, 3, "" ) Wscript.DisconnectObject Hamster ' Abruf vom Standardport 110, dazu passend der SSLMode = 3: Set Hamster = Wscript.CreateObject( "Hamster.App" ) ControlRunFetchMailTLS( "pop3-server.example.com", "110", "", "", "admin", "", 3, 3, "" ) Wscript.DisconnectObject Hamster
Damit werden Mails aus einem Postfach auf dem Server pop3-server.example.com über SSL abgeholt. Das Serverzertifikat wird überprüft, es liegt im Standardpfad.
Das wär's. Vergiss aber nicht, falls vorhanden, den Befehl zum Mailholen vom selben Server, aber nicht über SSL, zu löschen oder auszukommentieren. Das ist sonst ein Sicherheitsrisiko, da zusätzlich noch eine unverschlüsselte Verbindung aufgebaut wird und Dein Passwort wieder unverschlüsselt übertragen wird.
Ergänze den Befehl HamSendMail bzw. HamSendMailAuth im Skript um die SSL-Parameter. Mindestens SSLMode muss bei SSL-Benutzung immer angeben werden, da der Hamster die SSL-Einstellungen, die eventuell im Menü für diesen Server gemacht wurden, nicht übernimmt. Die anderen SSL-Parameter können weggelassen werden, dann nimmt der Hamster die Standardwerte (SSLVerify = 0; SSLCaFile = "").
HamSendMail( <server>, <port>, <from-select>, <to-select>, <SSLMode>, <SSLVerify>, <SSLCaFile> )
HamSendMailAuth( <server>, <port>, <user>, <pass>, <from-select>, <to-select>, <SSLMode>, <SSLVerify>, <SSLCaFile> )
Per OLE musst du jetzt den Befehl ControlRunSendMailTLS statt ControlRunSendMail bzw. ControlRunSendMailAuthTLS statt ControlRunSendMailAuth verwenden.
function ControlRunSendMailTLS( <server>: WideString; <port>: WideString; <from-select>: WideString; <to-select>: WideString; <SSLMode>: Integer; <SSLVerify>: Integer; <SSLCaFile>: WideString ) : Integer
function ControlRunSendMailAuthTLS( <server>: WideString; <port>: WideString; <user>: WideString; <pass>: WideString; <from-select>: WideString; <to-select>: WideString; <SSLMode>: Integer; <SSLVerify>: Integer; <SSLCaFile>: WideString ): Integer;
Die Wörter in den spitzen Klammern müssen dabei ersetzt werden, siehe die Erläuterungen zu den Befehlen in der Hilfe.
Bemerkungen:
Beispiel Hamster-Skript:
# Abruf vom SSL-Port 465, dazu passend der SSLMode = 1: #!hs2 HamSendMail( "smtp-server.example.com", "465", ".*", ".*", 1, 3, "" ) # oder: # HamSendMailAuth( "smtp-server.example.com", "465", "", "", ".*", ".*", 1, 3, "" ) # Abruf vom Standardport 25, dazu passend der SSLMode = 3: #!hs2 HamSendMail( "smtp-server.example.com", "25", ".*", ".*", 3, 3, "" ) # oder: # HamSendMailAuth( "smtp-server.example.com", "25", "", "", ".*", ".*", 3, 3, "" )Beispiele VBScript:
' Abruf vom SSL-Port 465, dazu passend der SSLMode = 1: Set Hamster = Wscript.CreateObject( "Hamster.App" ) Hamster.ControlRunSendMailTLS( "smtp-server.example.com", "465", ".*", ".*", 1, 3, "" ) ' oder: ' Hamster.ControlRunSendMailAuthTLS( "smtp-server.example.com", "465", "", "", ".*", ".*", 1, 3, "" ) Wscript.DisconnectObject Hamster ' Abruf vom Standardport 25, dazu passend der SSLMode = 3: Set Hamster = Wscript.CreateObject( "Hamster.App" ) Hamster.ControlRunSendMailTLS( "smtp-server.example.com", "25", ".*", ".*", 3, 3, "" ) ' oder: ' Hamster.ControlRunSendMailAuthTLS( "smtp-server.example.com", "25", "", "", ".*", ".*", 3, 3, "" ) Wscript.DisconnectObject Hamster
Damit werden alle Mails über den Server smtp-server.example.com per SSL verschickt. Das Serverzertifikat wird überprüft, es liegt im Standardpfad.
Das wär's. Vergiss aber nicht, falls vorhanden, den Befehl zum Mailsenden zum selben Server, aber nicht über SSL, zu löschen oder auszukommentieren. Das ist sonst ein Sicherheitsrisiko, da zusätzlich noch eine unverschlüsselte Verbindung aufgebaut wird und dein Passwort wieder unverschlüsselt übertragen wird.
Trage alle Daten in das Menü ein, wie unter Frage 1 und 1.1 beschrieben. Wenn Du alles im Menü richtig eingetragen hast (eventuellen Portwechsel von 119 auf 563 beachten) und Du jetzt im Skript oder per OLE den Befehl gibst, News von diesem Server abzuholen, benutzt der Hamster automatisch SSL.
Um SSL mit den lokalen Servern vom Hamster zu verwenden, brauchst Du ein Zertifikat mit geheimem Schlüssel. Solltest Du keines haben, erscheint beim Start des lokalen Servers mit aktiviertem TLS eine Warnung im Log und der Server wird ohne TLS gestartet. Die Verbindung vom Client zum Hamster wird also nicht verschlüsselt! Wie Du ein eigenes Zertifikat erzeugen kannst, wird in Frage 6 beschrieben.
Nun zur Hamster-Konfiguration:
Im Hamster unter Einstellungen → Grundeinstellungen müssen eventuell temporär die erweiterten Einstellungen aktiviert werden und dann auf der Registerkarte SSL im Feld Schlüsselpaar die Datei, die Dein eigenes Zertifikat mit dem dazugehörigen privaten Schlüssel im PEM-Format (wird beim Erstellen, wie in Frage 6 beschrieben, automatisch benutzt) enthält, angegeben werden. Wenn Du den privaten Schlüssel mit einem Passwort geschützt hast, musst Du dieses Passwort ebenfalls eingeben. Wenn Du es nicht speichern lassen willst, kannst Du auch ? angeben, dann fragt der Hamster nach jedem Start einmal nach dem Passwort. Die nächsten zwei Einstellfelder sind nur interessant, wenn Du Clientzertifikate benutzen willst.
Auf der Registerkarte des jeweiligen Servers unter Einstellungen → Lokale Server einstellen, dass TLS verwendet werden soll. Wenn alle Deine Clients TLS (eigentlich korrekt: SSL/TLS auf dem Standardport) unterstützen, solltest Du das Auswahlfeld auf Erzwinge TLS stellen, ansonsten auf Erlaube TLS. Bei letzterem wird aber nur dann SSL (also Verschlüsselung) verwendet, wenn der Client das auch unterstützt und so konfiguriert ist!
Ab dem nächsten Start des jeweiligen Servers, also beim Starten des Hamsters oder beim Benutzen des jeweiligen Eintrags im Menü Lokale Server, wird der Server mit SSL-Unterstützung gestartet.
Beachte bitte, dass es nicht möglich ist, Hamster als SSL-Server auf einem separaten SSL-Port zu benutzen. RFC 2595 (Link s. Frage 11) nennt im Abschnitt 7 gute Gründe, warum eine solche Konfiguration nicht mehr verwendet werden sollte. Möchtest Du SSL trotzdem über einen separaten SSL-Port verwenden, brauchst Du dazu einen externen SSL-Wrapper, z. B. das Programm STunnel. STunnel muss dann an 0.0.0.0:<SSL-Port> (je nach Protokoll) gebunden werden und eingehende verschlüsselte Verbindungen an 127.0.0.1:<Port> (wenn der Hamster auf demselben Computer wie STunnel läuft) weiterleiten. Das Zertifikat muss ebenfalls bei STunnel angegeben werden. Den Hamster bindest du dann an 127.0.0.1 und stellst ihn auf Kein TLS. Zu einer ausführlichen Erklärung lies dir die Hilfe zu STunnel durch (siehe ebenfalls Frage 11).
Beachte bitte, dass, wenn der Hamster als Server Verbindungen vom Internet annehmen soll, auf jeden Fall weitere Schutzmaßnahmen notwendig sind. In dieser Hinsicht hilft kein SSL, außer Du verwendest Client-Zertifikate. Also, für jeden Hamsteraccount starke Passwörter verwenden. Schalte in den Einstellungen der lokalen Server auf der Seite Mail SMTP-AUTH ein, wenn Du einen Mailreader hast, der dies beherrscht. Dabei muss der Mailreader sich mit einer gültigen Username-Passwort-Kombination beim Hamster authentifizieren, bevor er Mails verschicken kann. Wenn Dein Mailreader dies nicht kann, schalte SMTP-after-POP3 ein. Dabei muss der Mailreader, bevor er Mails verschicken kann, Mails abholen. Wenn Du keines von beiden machst, kann jeder, ohne ein Passwort kennen zu müssen, Spam über Deinen Rechner verschicken. Erstelle auch einen Benutzer mit dem Usernamen nntpdefault und dem Passwort * (ein Stern). Dieser Benutzer wird immer dann verwendet, wenn der Client keinen Benutzernamen und kein Passwort beim lokalen Newsserver angibt. In den Einstellungen dieses Benutzers darf dann in keinem Eingabefeld mit weißem Hintergrund außer voller Name irgendetwas stehen und der Benutzer darf keine Mailbox haben, so dass dieser Benutzer (und damit auch ein eventueller Spammer oder Angreifer ohne Benutzernamen und Passwort) gar nichts machen kann. Es wäre zwar nicht unbedingt notwendig, diesen Benutzer einzurichten, da sich der Hamster ohne diesen ebenso verhält, aber es ist trotzdem zu empfehlen, damit nicht später einmal dieser Benutzer mit zu vielen Berechtigungen eingerichtet wird und dabei eine große Sicherheitslücke entsteht.
Zur Einrichtung von Client-Zertifikaten siehe Frage 8.2.1.
Für eine SSL-Verbindung braucht OpenSSL und damit der Hamster, denn der benutzt die OpenSSL-Biliotheken, möglichst zufällige Zufallsdaten. Dazu wird automatisch die Datei randseed.!!! im Hamsterverzeichnis angelegt, in der die Zufallsdaten aus dem internen Pseudozufallszahlengenerator (PRNG) von OpenSSL gespeichert werden. Wenn Du eine Quelle guter Zufallsdaten hast, die du stattdessen verwenden möchtest, kannst Du unter Einstellungen → Grundeinstellungen auf der Registerkarte SSL im Feld Externe Datei mit Zufallsdaten für PRNG eine andere Datei angeben, aus der Zufallsdaten gelesen werden. Bitte beachte dabei, dass Hamster in die Datei randseed.!!! nach jeder Benutzung neue Zufallsdaten schreibt, nicht aber in die zusätzlich angegebene Datei.
Vielleicht solltest Du auch mal über Server- und Client-Zertifikate nachdenken. Siehe dazu Frage 4 und folgende bis inkl. Frage 8.
Zertifikate kann man vielleicht mit einem Pass vergleichen. Du zeigst es/ihn vor, wenn Du willst, dass andere sich darauf verlassen können, dass Du wirklich der bist, der Du zu sein vorgibst. Dafür bürgt jemand, dem Du traust: eine Certificate Authority (CA) oder der Staat. Du kannst zwar nicht wie bei einem Pass mit dem Bild prüfen, ob das Zertifikat wirklich dem gehört, der es benutzen will, aber das macht nichts, da der andere ohne den zum öffentlichen Schlüssel (= Zertifikat) passenden geheimen Schlüssel oder eine sehr, sehr große Rechenpower nichts entschlüsseln kann, was Du an den Inhaber des Zertifikats schickst.
Self-Signed-Zertifikate musst Du dir vorstellen wie den Pass eines Königs: Der Austellende (hier: der Staat = König) bürgt für sich selbst. Du brauchst also Zertifikate, wenn Du sichergehen willst, dass der, mit dem Du sprichst, wirklich der ist, mit dem Du sprechen willst und nicht irgendein x-beliebiger Betrüger. Technisch gesehen ist ein Zertifikat ein öffentlicher RSA-Schlüssel. Weil im Normalfall nur der richtige Server den dazu passenden privaten Schlüssel hat, weißt Du, wenn der Server Deine Texte richtig entschlüsseln kann, ist es der richtige.
Voraussetzung dafür ist natürlich, dass Du das richtige Zertifikat (= öffentlicher Schlüssel) hast. Wenn Du dir dieses über das Internet holst, wie in Frage 5 beschrieben, kannst Du dir dessen erst mal nicht sicher sein! Eine Möglichkeit, eine größere Gewissheit zu bekommen, sind Signaturen. Nehmen wir an, es hat schon mal jemand (z.B. eine Certificate Authority = CA) überprüft, ob dieses Zertifikat echt ist, und dann das Zertifikat signiert. Wenn Du jetzt den (garantiert) richtigen öffentlichen Schlüssel von diesem Jemand besitzt und diesem vertraust, dass er z. B. keine gefälschten Zertifikate signiert, kannst Du dir auch über das Zertifikat sicher sein.
Nochmal eine Zusammenfassung: Ein Zertifikat ist normalerweise dazu da, dass man sich sicher sein kann, mit wem man spricht. Dies ist z. B. beim Serverzertifikat der Fall. Ein Zertifikat einer CA ist dazu da, die Richtigkeit eines anderen Zertifikats zu bestätigen. Ein Self-Signed-Zertifikat ist ein beliebiges Zertifikat, dessen Richtigkeit nur vom Aussteller bestätigt wird, nicht noch zusätzlich von jemand anderem. Wenn man ein solches bekommt, muss man dieses Zertifikat also genau prüfen, während es normalerweise ausreicht, das Zertifikat der CA zu überprüfen, weil diese ja schon das Serverzertifikat überprüft hat.
Wenn Du schon weißt, welche CA das Serverzertifikat signiert hat, kannst Du die nächsten Schritte überspringen. Ansonsten brauchst Du das Serverzertifikat (s. Frage 5.2) und die OpenSSL.exe (s. Frage 10), um das herauszufinden. Rufe OpenSSL.exe mit folgender Befehlszeile auf:
openssl x509 -issuer -noout -in <Serverzertifikat.pem>
Die Ausgabe sollte dann den Namen der CA enthalten. Eine Gesamtübersicht über das Zertifikat erhältst Du mit:
openssl x509 -text -noout -in <Serverzertifikat.pem>
Wenn Du den Namen der CA hast, brauchst Du noch deren Zertifikat. Meistens bekommst Du es auf deren Website. Die am häufigsten verwendeten sind auch bei den meisten Browsern mitgeliefert. Wenn Du dem Browserhersteller vertraust und dir sicher bist, dass Du wirklich die Originalversion des Browsers hast, kannst Du sie auch von dort exportieren:
Beachte jedoch unbedingt, dass Du dir der Echtheit der Zertifikate so nicht sicher sein kannst. Du solltest daher unbedingt den Fingerprint des Zertifikats, den dir OpenSSL mit dem Parameter x509 info anzeigt, überprüfen. Das kann z. B. per Telefon geschehen oder Du besuchst ein Büro der jeweiligen Firma.
Manchmal findest Du das Serverzertifikat auf der Website des Serverbetreibers oder Du holst es dir mit der OpenSSL.exe (s. Frage 10) direkt vom Server.
Wenn der Server SSL auf einem separaten Port unterstützt, starte OpenSSL, während eine Onlineverbindung besteht, mit dieser Kommandozeile:
openssl s_client -connect <Server>:<Port> -showcerts > OpenSSL.log
Für <Server>:<Port> gib die Adresse des SSL-Servers an, dessen Zertifikat du bekommen willst.
Bei einem POP3- oder SMTP-Server, der SSL/TLS auf dem Standardport unterstützt, bekommst du das Zertifikat so:
openssl s_client -connect <Server>:<Port> -starttls <Protokoll> -showcerts > OpenSSL.log
Wenn Du noch eine ältere Version von OpenSSL benutzt (was nicht zu empfehlen ist!), dann unterstützt diese leider den -starttls-Parameter nur für SMTP. Bei einem anderen Protokoll musst du daher dann zuerst eine Klartextverbindung aufbauen und die Verschlüsselung händisch starten. Von Martin Germann gibt es das Programm SSL-Tool, das genau das für die Protokolle SMTP, POP3, NNTP und IMAP automatisch macht (Achtung, Direktlink!):
http://www.ximera.de/hamster/SSL_Tool.zip
Auch bei Verwendung dieses Programms benötigst Du OpenSSL. Starte das Programm, trage die Daten des Servers unter Remote und einen freien lokalen Port unter local ein, und starte den Wrapper mit einem Klick auf Start Wrapper. Jetzt verbinde dich mit OpenSSL auf dem lokalen Port, den du angegeben hast:
openssl s_client -connect localhost:<Port> > OpenSSL.log
Das Programm handelt daraufhin eine TLS-Verbindung mit dem angegebenen Server aus und tunnelt dann die Verbindung zu OpenSSL.
Öffne anschließend die Datei OpenSSL.log im OpenSSL-Verzeichnis mit einem beliebigen Texteditor und kopiere alles von einschließlich der Zeile
-----BEGIN CERTIFICATE----- bis zu einschließlich der Zeile -----END CERTIFICATE-----
in eine neue Datei. Gib dieser Datei einen möglichst aussagekräftigen Namen. Der Übersichtlichkeit halber ist zu empfehlen, für alle Zertifikatsdateien mit diesem Format die Endung .pem zu nehmen (von PEM).
Bei einigen Servern erfolgt die Zertifizierung mehrstufig. Daher werden (bei korrekter Konfiguration) auch mehrere Zertifikate ausgeliefert, die allesamt abgespeichert werden müssen. Das Serverzertifikat ist dabei das zuerst aufgeführte.
OpenSSL.log kannst Du jetzt löschen.
Genau wie beim CA-Zertifikat kannst Du dir jedoch so nicht sicher sein, dass Du das richtige Zertifikat hast. Du kannst jedoch die Signatur mit dem CA-Zertifikat überprüfen, oder du prüfst wieder den Fingerprint über andere Kanäle wie Telefon oder persönliches Erscheinen.
Als erstes ein kurzer Hinweis: Du benötigst meist kein eigenes Zertifikat, wenn Du nur SSL-Verbindungen zu einem fremden Server, wie Web.de oder GMX aufbauen willst, da diese meistens keine Clientzertifikate unterstützen.
Zum Zertifikat-Erstellen benötigst Du die OpenSSL.exe (s. Frage 10) sowie die 2 Dateien MakeCert.bat und cert.cnf von Martin Germann, die du unter folgendem URL bekommst (Achtung, Direktlink!):
http://www.ximera.de/hamster/MakeCert.zip
Kopiere die beiden Dateien aus dem Zip-Archiv in das Verzeichnis von OpenSSL.exe, führe MakeCert.bat aus und folge den Anweisungen. Das Passwort sollte allerdings wegen möglichen Kompatibilitätsproblemen keine Umlaute und Sonderzeichen enthalten. Der öffentliche Schlüssel (= Zertikat) und ein dazugehöriger privater RSA-Schlüssel befindet sich dann in der Datei certificate.pem im OpenSSL-Verzeichnis.
Das Zertifikat alleine kann bedenkenlos weitergegeben werden, aber der RSA-Schlüssel nicht! Wenn ein Angreifer beides hat, kann er so tun, als wäre er Du und die ganzen Zertifikate wären wirkungslos. Also auf keinen Fall die Zeilen
-----BEGIN RSA PRIVATE KEY----- ----END RSA PRIVATE KEY-----
weitergeben. Auf dem lokalen Computer müssen sie natürlich trotzdem vorhanden sein.
Achtung: Der RSA-Schlüssel darf nur auf dem Computer sein, der sich mit diesem Zertifikat authentifizieren soll, also auf dem Server bei Verwendung von Serverzertifikaten und auf dem Client bei Verwendung von Clientzertifikaten. Gib ihn deshalb nicht weiter! Gelangen der Schlüssel und das Zertifikat in fremde Hände, kann der Dritte ohne irgendein Problem so tun, als wäre er Du! Der ganze Sinn von Zertifikaten wäre also hinfällig.
Zum Einbinden des Zertifikates in den Hamster siehe Frage 8.1.1 (als Serverzertifikat) oder Frage 8.2.2 (als Clientzertifikat).
Beide hier beschriebenen Methoden sind technisch gleichwertig, jede hat ihre Vor- und Nachteile. Die Auswahl bleibt daher dem Anwender überlassen.
Grundsätzlich gilt, dass, wenn in den Servereinstellungen oder im Skript keine Angaben gemacht werden, die Standardpfade aus den entsprechenden Feldern auf der Registerkarte SSL in den Grundeinstellungen des Hamsters übernommen werden. In den Grundeinstellungen darf im Feld Datei mit Zertifikaten zwecks Überprüfung nur eine einzelne Datei (s. Frage 7.1) und im Feld Pfad mit Zertifikaten zwecks Überprüfung nur ein Verzeichnis (s. Frage 7.2) stehen. Das nicht benutzte Feld kann leergelassen werden. In dem Feld im Servermenü oder im Parameter <SSLCaFile> im Skript kann entweder eine einzelne Datei oder ein ganzes Verzeichnis angegeben werden.
Bei nur einem oder wenigen Zertifikaten ist es am einfachsten, diese alle in eine Datei zu kopieren. Diese sieht dann z. B. so aus:
-----BEGIN CERTIFICATE----- -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- -----END CERTIFICATE-----Der Dateiname und der Ort der Datei ist egal, der Übersichtlichkeit wegen ist aber ein möglichst aussagekräftiger Name mit der Endung .pem zu empfehlen (von PEM).
Außer den Zertifikaten kann auch noch anderer Text in der Datei stehen, z. B. um zu notieren, zu welchem Server welches Zertifikat gehört, aber nur außerhalb der Zeilen von -----BEGIN CERTIFICATE----- bis -----END CERTIFICATE-----. Um möglichen Problemen aus dem Weg zu gehen, sollte der eigene Text auch nur aus ASCII-Zeichen bestehen, d. h. keine Umlaute usw. enthalten.
Das könnte dann so aussehen:
news.example.com: -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- pop3.example.com: -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- smtp.example.com: -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- CA-Zertifikat von <Zertifizierungsstelle> fuer example.com: -----BEGIN CERTIFICATE----- -----END CERTIFICATE-----
Im Hamster wird dann an der entsprechenden Stelle der Name der Datei inklusive komplettem Pfad angegeben.
In Abwandlung dieses Vorgehens kann man z. B. die Zertifikate für alle Server eines Providers und das dazugehörende CA-Zertifikat (denn gewöhnlich ist es je Provider nur eines) in einer Datei speichern und diese in den Einstellungen für die einzelnen Server angeben.
Vorteil: Vollständige manuelle Pflege der Zertifikate möglich.
Nachteile: Manuelle Pflege mit deutlich größerem Aufwand als in Methode 2 notwendig. Vor allem, wenn alle Zertifikate in einer Datei abgelegt werden, wird diese schnell unübersichtlich. Letzteres wird durch die Aufteilung in mehrere Dateien aber deutlich abgemildert.
Mit vielen Zertifikaten kann eine Datei leicht unübersichtlich werden. Dann empfiehlt sich diese Methode: Alle Zertifikate stehen jeweils einzeln in einer Datei. Damit der Hamster sie findet, müssen sie im gleichen Verzeichnis liegen und ein bestimmtes Dateinamensformat haben, nämlich <Hash-des-Zertifikats>.0. Von Martin Germann gibt es das Skript SSL-Cert-Hash, das mit Hilfe der OpenSSL.exe (s. Frage 10) allen Zertifikaten in einem Verzeichnis, die in .pem-Dateien vorliegen, automatisch den richtigen Dateinamen gibt (Direktlink):
http://www.ximera.de/hamster/SSL-Cert-Hash.hsc
Im Hamster wird dann nur der Pfad zu diesem Verzeichnis angegeben. Natürlich funktioniert diese Methode auch dann, wenn Du nur ein Zertifikat hast.
Vorteil: Sehr wenig Aufwand nötig, einfach aktuelle Zertifikate im entsprechenden Format ins Verzeichnis ablegen.
Nachteil: Das Aufräumen des Verzeichnisses wird durch das kryptische Dateinamensformat massiv erschwert, vor allem, wenn die jeweils dazugehörige Textdatei gelöscht wurde. Es muss in jeder einzelnen Textdatei nachgelesen werden, ob das dazugehörige Zertifikat noch gültig ist. Fehlt die Textdatei, muss die entsprechende Zertifikatsdatei wieder die Endung .pem erhalten und noch einmal mit SSL-Cert Hash umgewandelt werden.
Mit Serverzertifikaten stellt der Client sicher, dass er mit dem richtigen Server spricht. Das wird z. B. dann verwendet, wenn der Hamster einen fremden Server abfragen soll (s. Frage 8.1.2) oder als TLS-Server mit einem Zertifikat versehen werden soll (s. Frage 8.1.1). Clientzertifikate werden verwendet, wenn der Server sicherstellen will, dass er mit dem richtigen Client spricht (also das, wozu normalerweise Benutzername und Passwort verwendet werden). Das wird von externen Servern leider selten unterstützt.
Du kannst natürlich auch ohne Probleme Serverzertifikate und Clientzertifikat gleichzeitig verwenden.
Wie Du ein eigenes Zertifikat erstellen kannst, steht in Frage 6. Eingebunden wird es, indem Du den Dateinamen bei temporär aktivierten erweiterten Einstellungen in den Grundeinstellungen auf der Registerkarte SSL in der ersten Box eingibst. Außerdem musst Du eventuell noch das Passwort angeben. Dann authentifiziert sich der Hamster dem Client gegenüber automatisch.
Dabei gibt es zwei Stufen. Die erste Stufe überprüft nur das Zertifikat der CA und die Signatur dieser CA auf dem Serverzertifikat. Das Serverzertifikat selber wird nicht überprüft. Wenn Du der CA vertraust, reicht das normalerweise aus. Wenn Du allerdings der CA nicht vertraust, solltest Du unbedingt die zweite Stufe nutzen, dabei ist das Vertrauen in die CA nicht mehr so wichtig. Du solltest dann aber das Serverzertifikat besonders genau überprüfen, auf jeden Fall auch durch einen Kanal außerhalb des Internets. Die zweite Stufe baut auf der ersten auf und überprüft zusätzlich noch das Serverzertifikat selber. Wie Du ein Zertifikat von einer CA oder von einem externen Server bekommst, steht in Frage 5.
Wenn Du nun das Zertifikat der CA hast, sagst Du dem Hamster, dass er es beim Aufbau der Verbindung überprüfen soll. Dazu setzt Du im Skript den Parameter <SSLVerify> auf 2 oder im Menü die Auswahlbox Wähle Überprüfungsverfahren auf Zertifikate immer überprüfen. Was Du in das Feld Überprüfung über Datei eingeben musst, ist in Frage 7 erklärt.
Im Skript setzt Du nun den Parameter <SSLVerify> auf 3 oder im Menü die Auswahlbox Wähle Überprüfungsverfahren auf Peer mittels lokal vorhandener Zertifikate überprüfen. Was Du in das Feld Überprüfung über Datei eingeben musst, steht in Frage 7. Beachte aber, dass Du dem Hamster jetzt zwei Zertifikate (das Server- und das CA-Zertifikat) auf einmal bekannt machen musst.
Du benötigst auf dem Server das Zertifikat des Clienten (nicht jedoch dessen privaten Schlüssel!), der sich beim Server authentifizieren soll. Außerdem muss der Hamster, wie in Frage 2 beschrieben, vollständig für den Betrieb als TLS-Server eingerichtet sein.
In den Grundeinstellungen auf der Registerkarte SSL aktivierst Du eventuell temporär die erweiterten Einstellungen und gibst entweder bei Datei mit Zertifikaten zwecks Überprüfung eine Datei an, die alle Zertifikate gesammelt enthält oder bei Pfad mit Zertifikaten zwecks Überprüfung ein Verzeichnis, in dem alle Zertifikate in Einzeldateien liegen. Siehe dazu auch Frage 7.
Jetzt kann der Hamster zwar die Zertifikate vergleichen, aber er fängt mit dem Ergebnis noch nichts an. Damit der Hamster nur Verbindungen mit gültigem Clientzertifikat akzeptiert, musst Du in der hamster.ini im Abschnitt [SSL] (siehe auch Hamster.ini, sonstige Sektionen) den Eintrag VerifyLevel auf 2 oder 3 stellen.
Wie Du ein eigenes Zertifikat erstellen kannst, steht in Frage 6. Eingebunden wird es, indem Du den Dateinamen bei temporär aktivierten erweiterten Einstellungen in den Grundeinstellungen auf der Registerkarte SSL in der ersten Box eingibst. Außerdem musst Du eventuell noch das Passwort angeben.
[ ] Verify error: unable to get local issuer certificate depth=0 [...]
[ ] OpenSSL error: SSL_connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wenn diese Fehlermeldungen auftauchen, ist höchstwahrscheinlich Zertifikate überprüfen eingestellt (oder der Parameter <SSLVerify> auf <>0 gesetzt), aber der Hamster kann das Zertifikat der CA nicht finden. Stelle sicher, dass Du es hast, dass es im richtigen Format vorliegt (s. Frage 7) und dass alle Pfade stimmen. Wenn Du keine Möglichkeit hast, das Zertifikat der CA zu bekommen, musst Du die Zertifikatsüberprüfung leider ausschalten.
[ ] OpenSSL error: SSL_CTX_new: error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers
[ ] Creating SSL context failed
Hier konnte OpenSSL nicht initialisiert werden. Wahrscheinlich ist es ein Speicherproblem. Prüfe, ob Du mehrere SSL-Verbindungen gleichzeitig aufbaust (auch mehrere Threads zu einem Newsserver sind verschiedene Verbindungen!) und stelle auf weniger bis eine gleichzeitige SSL-Verbindung um.
Den OpenSSL-Sourcecode gibt es auf http://www.openssl.org/.
Eine Anleitung zum Kompilieren unter Windows ist darin enthalten. Prinzipiell solltest Du OpenSSL selber kompilieren, denn nur so kannst Du sicher sein, dass derjenige, von dem das Binary kommt, keine Schadfunktion oder einen Trojaner eingefügt hat.
Für diejenigen, die sich OpenSSL nicht selber kompilieren können, gibt es zum Zeitpunkt, als dies geschrieben wird, das Shining Light Productions Win32 OpenSSL unter http://www.slproweb.com/products/Win32OpenSSL.html.
Unter http://de.wikipedia.org/wiki/OpenSSL ist mit hoher Wahrscheinlichkeit immer eine aktuelle Downloadmöglichkeit zu finden.
Als erstes nochmal die Download-URLs:
URLs zum Einlesen:
Achtung! Der in früheren Versionen der SSL-FAQ aufgeführte Netzauftritt des Entwicklers der OpenSSL-Einbindung in den Hamster (http://www.ximera.de/hamster.html) ist leider weitgehend veraltet, insbesondere die Links für die OpenSSL-Binaries und die Anleitung zum Selbstkompilieren.
Newgroups:
Änderungshistorie unter http://www.philippwendler.de/hamster/hamster-ssl-classic-history.txt.)