SSL/TLS, OpenSSL und https

SSL/TLS, OpenSSL und https Holger Jakobs bibjah@bg.bib.de, holger@jakobs.com 2006-09-21 Inhaltsverzeichnis 1 Sicherheit beim Surfen 1 1.1 http und https................................. 2 1.2 Erkennen einer sicheren Verbindung...................... 2 2 SSL die Technik hinter https 2 2.1 Verschlüsselung................................. 2 2.2 Zertifikate.................................... 3 2.2.1 Standard-Zertifikate.......................... 4 2.2.2 Webseiten-Zertifikate.......................... 4 3 Einrichtung eines eigenen https-servers 5 3.1 Server-Schlüssel und Certification Request.................. 5 3.2 Server-Zertifikat................................. 6 3.3 Einrichten des Webservers........................... 8 1 Sicherheit beim Surfen Üblicherweise werden Webserver nicht sicher betrieben, d. h. die Kommunikation zwischen Server und Client wird nicht verschlüsselt. Das hat zur Folge, dass Verbindungen abgehört werden können. Das kann zwar nicht jeder x-beliebige Benutzer im Internet machen, aber zumindest alle Administratoren, die Zugriff auf Router im Internet haben, können sämtlichen Verkehr mithören bzw. mitprotokollieren. Neben der Möglichkeit, den Verkehr abzuhören was beim Abruf öffentlich zugänglicher Seiten auf den ersten Blick uninteressant erscheint besteht auch die Gefahr, dass die Inhalte auf dem Weg vom Server zum Client verändert werden. Über den ersten Blick hinaus ist aber auch beim Abruf öffentlich zugänglicher Seiten vielleicht von Bedeutung, wer eine bestimmte Seite wann abruft. Man denke nur an den Abruf von Schmuddelseiten vom Arbeitsplatz aus oder das Betreiben eines schwunghaften Handels in Online-Auktionen während der Arbeitszeit. 1

1.1 http und https 2 SSL DIE TECHNIK HINTER HTTPS 1.1 http und https Insbesondere sensible Daten sollten daher nicht über normale http-verbindungen, sondern ausschließlich über https-verbindungen übermittelt werden. Beim Online-Banking werden beispielsweise auch nur diese Verbindungen angeboten, d. h. die Server verweigern einen Verbindungsaufbau ohne Verschlüsselung bzw. machen sofort eine Umleitung (redirect) auf die sichere Verbindungsart. Auch beim Online-Shopping und bei Auktionshäusern sind sichere Verbindungen Standard. Über https abgewickelte Verbindungen sind sowohl gegen Abhören als auch gegen Veränderung der Inhalte gesichert. Allerdings wird der URL (Uniform Resource Locator) an einen Proxy genauso übermittelt wie bei http, d. h. bei den meisten Firmen werden die URLs auch bei der Verwendung von https mitprotokolliert. Bei einer direkten Verbindung ins Internet erfahren die beteiligten Router nur die IP-Adressen der beiden beteiligten Rechner (Client und Server) und die Portnummer (bei https üblicherweise 443), aber nicht, welche konkrete Seite abgerufen wurde, weil dies schon zum geschützten Inhalt der Verbindung gehört. Um auch bei der Verbindung über einen Proxy vor dem Aufzeichnen der URLs sicher zu sein, muss man einen sogenannten Anonymizer 1 verwenden. Alle Verbindungen laufen dann über diesen, und nur dieser weiß, wohin die tatsächliche Verbindung weiter geht. Anonymizer teilen auch dem Server nicht mit, welcher Client nach der Seite gefragt hat. Dem Betreiber des Anonymizers muss man allerdings vollständig vertrauen. Um dieses Problem einzudämmen, gibt es auch Netzwerke von Anonymizern, beispielsweise TOR 2. 1.2 Erkennen einer sicheren Verbindung Webbrowser zeigen im Falle einer sicheren Verbindung ein entsprechendes Symbol in der Statusleiste an, siehe Tabelle 1 auf der nächsten Seite. Dies ist über die Anzeige von https in der Adressleiste hinaus ein Zeichen der sicheren Verbindung. Bei Verwendung von Framesets kann es allerdings dazu kommen, dass zwar der Hauptframe sicher übertragen wird, andere Frames aber nicht. Wenn die unsicheren Frames dann die Formulare enthalten, über die der Anwender sensible Daten schickt, dann trügt der Schein. Ebenso können sicher übertragene HTML-Seiten durchaus eingebettete Grafiken enthalten, die nicht sicher übertragen werden. Manche Browser erzeugen in einem solchen Fall eine Warnung oder zeigen ein noch anderes Symbol an, andere aber nicht. 2 SSL die Technik hinter https 2.1 Verschlüsselung SSL steht für Secure Sockets Layer, stellt also eine Schicht dar, über die eine sichere Socket-Kommunikation möglich ist. Es arbeitet oberhalb von TCP und kann daher nicht 1) http://de.wikipedia.org/wiki/anonymizer 2) http://tor.eff.org 2

2 SSL DIE TECHNIK HINTER HTTPS 2.2 Zertifikate Tabelle 1: Webbrowser-Sicherheits-Icons Icon Beschreibung Sichere Verbindung mit Mozilla Navigator 1.7.12 Unsichere Verbindung mit Mozilla Navigator 1.7.12 Sichere Verbindung mit Internet Explorer 5.5 Hinweis: Der Internet Explorer 5.5 zeigt einfach kein Icon an, wenn keine sichere Verbindung besteht. Ein spezielles Icon für eine unsichere Verbindung gibt es dort nicht. mit UDP verwendet werden. Mittlerweile werden Weiterentwicklungen von SSL verwendet, die TLS heißen, was Transport Layer Security bedeutet. Beide Begriffe werden oft synonym verwendet. Damit die Verbindung verschlüsselt und damit sicher geschehen kann, müssen Server und Client sich über eine Verschlüsselung in einer Form einigen, die von anderen nicht mitgehört werden kann. Dies geschieht ähnlich wie bei SSH (welches intern auch SSL verwendet). In einer Handshake-Phase am Anfang der Verbindung wird ein einmaliger Session Key vereinbart, den nur die beiden beteiligten Rechner kennen. Dieser dient als Schlüssel für die symmetrische Verschlüsselung der Verbindungsinhalte. Im allgemeinen wird eine 128-bit- Verschlüsselung verwendet, die als ausreichend sicher gilt. Durch die notwendige Handshake-Phase wird der Aufbau der Verbindung verlangsamt, durch die Ver- und Entschlüsselung wird auch während der bestehenden Verbindung ein wenig Rechenaufwand benötigt. Abbildung 1 auf der nächsten Seite zeigt einen vereinfachten Ablauf des Handshakes. Mit SSL werden gelegentlich neben https auch andere Protokolle abgewickelt und damit abgesichert, z. B. pop3 und smtp. SSL ist im RFC 2246 standardisiert worden, der mittlerweile vom RFC 4346 abgelöst wurde. Das Verfahren mit den Schlüsseln bei https wird auch erläutert unter http://www.softed.de/fachthema/allgemeines/https.asp, insbesondere die Abbildung http://www.softed.de/fachthema/allgemeines/sslfuerweb.png ist sehr gelungen. 2.2 Zertifikate Wie aber erkennt der Browser, ob das vom Server für den Schlüssel verwendete Zertifikat tatsächlich zu diesem Server gehört, oder ob vielleicht ein anderer Server sich nur als derjenige ausgibt? Bei SSH bekommt man beim Verbinden mit einem bislang unbekannten Server den Fingerprint des verwendeten Schlüssels angezeigt, den man im Zweifel über einen sicheren Weg (z. B. per Telefon oder persönlich beim Administrator) überprüfen sollte. Man kann sich leicht vorstellen, dass es schlecht möglich ist, dass alle Welt beim Betrei- 3

2.2 Zertifikate 2 SSL DIE TECHNIK HINTER HTTPS Abbildung 1: vereinfachter SSL-Handshake (von Apache.org) ber einer Website anruft, um die Echtheit des verwendeten Schlüssels durch Abgleich des Fingerabdrucks zu überprüfen. Ganz abgesehen von evtl. Sprachbarrieren wäre das auch vom Arbeitspensum und den Arbeitszeiten her nicht realisierbar. 2.2.1 Standard-Zertifikate Es muss also eine automatisierte Möglichkeit geben, die Echtheit des Schlüssels bzw. des Zertifikats zu überprüfen. Hierzu gibt es eine Hierarchie von Zertifikaten. Eine Reihe von root-zertifikaten ist im Lieferumfang der Webbrowser vorhanden. Alle Zertifikate, deren Existenz auf ein solches root-zertifikat zurückgeführt werden kann, d. h. direkt oder indirekt damit unterzeichnet worden sind, werden unmittelbar als echt angesehen und akzeptiert. Welche Zertifikate beispielsweise dem Mozilla Browser bekannt sind, können Sie unter Bearbeiten/Einstellungen/Datenschutz & Sicherheit/Zertifikate nachschauen. Abbildung 2 auf Seite 9 zeigt einen Screenshot des Zertifikatsmanagers von Mozilla 1.7.12. 2.2.2 Webseiten-Zertifikate Möchte man seine eigene Website ebenfalls mit einem Zertifikat ausstatten, um eine Kommunikation per https zu ermöglichen, so muss man sich den Schlüssel selbst erstellen und anschließend entweder von einer Zertifizierungsstelle zertifizieren lassen oder aber ihn quasi selbst zertifizieren. 4

3 EINRICHTUNG EINES EIGENEN HTTPS-SERVERS Letzteres hat natürlich nicht zur Folge, dass ein Webbrowser Ihrer Seite unmittelbar vertraut im Gegenteil. Beim Aufruf der Seite wird mitgeteilt, dass die Website von einer unbekannten Zertifizierungsstelle zertifiziert worden ist und daher der Anwender im Einzelfall entscheiden muss, ob er das Zertifikat anerkennt oder nicht, siehe Abbildung 3 auf Seite 10. 3 Einrichtung eines eigenen https-servers Folgende Schritte sind nötig, um alles Erforderliche für den Betrieb eines Webservers über https zu erzeugen: 3.1 Server-Schlüssel und Certification Request 1. Erstellen eines privaten Server-Schlüssels: openssl genrsa -out skey.pem Soll Ihr Schlüssel mehr als 512 Bits haben, können Sie am Ende der Kommandozeile noch 1024 oder 2048 angeben. 2. Erstellen eines Certification Requests: openssl req -new -nodes -out server_request.pem -key skey.pem Hierbei werden einige Daten für den Schlüsselinhaber abgefragt. You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter., the field will be left blank. ----- Country Name (2 letter code) [AU]:DE State or Province Name (full name) [Some-State]:NRW Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]:Fritz Meier Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:beispiel.bib.de Email Address []: Please enter the following extra attributes to be sent with your certificate request A challenge password []: An optional company name []: Bei Organization Name sollten Sie etwas eingeben, das Sie identifiziert, bei Common Name ist der Name Ihres Servers anzugeben. Jetzt sind der Schlüssel und die Bitte um 5

3.2 Server-Zertifikat 3 EINRICHTUNG EINES EIGENEN HTTPS-SERVERS Zertifizierung erstellt. Die Datei server_request.pem könnten Sie einer Zertifizierungsstelle zuschicken. Um sich die Eigenschaften des Certification Requests anzuschauen, kann man folgendes Kommando verwenden: openssl req -text -in server_request.pem 3.2 Server-Zertifikat Möchten Sie den Schlüssel zu Testzwecken selbst zertifizieren, so sind noch folgende Schritte zu tun: 1. Erstellen eines privaten Schlüssels für unsere Zertifizierungsstelle: openssl genrsa -out cakey.pem 2. Erstellen eines Zertifikats für unsere Zertifizierungsstelle: openssl req -x509 -nodes -out ca.pem -key cakey.pem -new Achten Sie darauf, dass die Angaben Country Name, State or Province Name und Organization Name mit den obigen bei der Erzeugung des Certification Request des Servers übereinstimmen. Das hier erstellte Zertifikat ca.pem können Sie im Zertifikatsmanager Ihres Webbrowsers importieren, so dass sämtliche damit unterschriebenen Serverzertifikate unmittelbar akzeptiert werden. In der Abbildung 2 auf Seite 9 sehen Sie das importierte Zertifikat von b.i.b./fhdw. 3. Zertifizieren des Server-Schlüssels. Dieser Schritt setzt einige Verzeichnisse und Dateien voraus, die vorher erzeugt werden müssen: mkdir -p democa/newcerts touch democa/index.txt echo 01 > democa/serial Wenn das alles vorbereitet ist, kann das Kommando eingegeben werden: openssl ca -keyfile cakey.pem -cert ca.pem -in server_request.pem Wenn die Voraussetzungen erfüllt sind, dann erscheint folgender Dialog: Using configuration from /usr/lib/ssl/openssl.cnf Check that the request matches the signature Signature ok Certificate Details: Serial Number: 2 (0x2) Validity Not Before: Jul 11 12:10:25 2006 GMT Not After : Jul 11 12:10:25 2007 GMT Subject: countryname = DE stateorprovincename = NRW organizationname = Fritz Meier 6

3 EINRICHTUNG EINES EIGENEN HTTPS-SERVERS 3.2 Server-Zertifikat commonname = beispiel.bib.de X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 4B:AA:CE:F6:BA:A5:82:DD:57:37:6A:C9:DA:81:38:BC:3B:58:28:89 X509v3 Authority Key Identifier: keyid:83:50:43:9d:dc:06:73:13:1a:79:0b:f2:b1:7a:ad:d8:3d:ca:0b:8c Certificate is to be certified until Jul 11 12:10:25 2007 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha1withrsaencryption Issuer: C=DE, ST=NRW, O=Fritz Meier, CN=beispiel.bib.de Validity Not Before: Jul 11 12:10:25 2006 GMT Not After : Jul 11 12:10:25 2007 GMT Subject: C=DE, ST=NRW, O=Fritz Meier, CN=beispiel.bib.de Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (512 bit) Modulus (512 bit): 00:b7:38:a1:5d:18:71:d6:50:d6:04:1b:9e:01:31: 68:63:fd:d5:95:e8:ec:16:1b:4b:c9:19:f0:83:25: ca:af:ab:90:56:0a:d5:6e:15:e9:ae:46:57:cf:c9: e2:14:c8:0c:48:04:88:c7:b6:1b:d1:bb:ad:52:f2: 8e:ad:46:d6:15 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 4B:AA:CE:6A:A5:82:DD:C9:F6:BA:57:37:DA:81:38:BC:3B:58:28:89 X509v3 Authority Key Identifier: keyid:83:50:43:9d:dc:1a:79:06:73:13:0b:f2:b1:7a:ad:d8:3d:ca:0b:8c 7

3.3 Einrichten des Webservers 3 EINRICHTUNG EINES EIGENEN HTTPS-SERVERS Signature Algorithm: sha1withrsaencryption 19:a6:9e:07:97:49:88:c0:25:7f:e8:09:ce:fc:80:f1:e6:e9: 9b:c8:31:88:70:25:28:7b:7e:b7:e4:47:f2:82:35:c5:69:fe: d6:75:a2:10:9a:16:07:b3:bf:1d:c8:4a:ed:51:18:48:3a:3d: cf:c8:99:a8:96:90:7f:ad:98:db -----BEGIN CERTIFICATE----- MIICCjCCAbSgAwIBAgIBAjANBgkqhkiG9w0BAQUFADBPMQswCQYDVQQGEwJERTEM MAoGA1UECBMDTlJXMRYwFAYDVQQKEw1Ib2xnZXIgSmFrb2JzMRowGAYDVQQDExFo b2x5lmr5bmfsawfzlm5lddaefw0wnja3mtexmjewmjvafw0wnza3mtexmjewmjva ME8xCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNOUlcxFjAUBgNVBAoTDUhvbGdlciBK YWtvYnMxGjAMTEWhvbHkuZHluYWYBgNVBAxpYXMubmV0MFwwDQYJKoZIhvcNAQEB BQADSwAwSAJBALc4oV0YcdZQ1gQbngExaGP91ZXo7BYbS8kZ8IMlyq+rCtVukFYV 6a5GV8/J4hTIG1hDEgEiMe2G9G7rVLyjq1UCAwEAAaN7MHkwCQYDVR0TBAIwADAs BglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD VR0OBBYEFEuqzmrJ9rqlgt1XN9qBOLw7WCiJMB8GA1UdIwQYMBaAFINQQ53cGnkG cxml8rf6rdg9ygumma0gcsqgsib3dqebbquaa0eagaaeb5djimalf+gjzvya8ebp myh7frfimyhwjerh8oi1xwn+1nwiejowb7o/hchk7veysdo9z8izqjaqf62y2w== -----END CERTIFICATE----- Data Base Updated Das angezeigte Zertifikat, das nicht nur angezeigt, sondern auch im Verzeichnis democa/newcerts abgelegt worden ist, muss nun in die Datei server.pem geschrieben werden. Gemeinsam mit skey.pem erlaubt sie das Betreiben eines Webservers über https. 3.3 Einrichten des Webservers Alle Dateien und Verzeichnisse außer skey.pem und server.pem werden für den Betrieb des https-fähigen Webservers nicht benötigt und können daher woanders gelagert oder auch gelöscht werden. Ein relevantes Echtheitszeugnis wird durch den hier beschriebenen Vorgang ohnehin nicht erzeugt. Beim Server tclhttpd 3 werden die Dateien skey.pem und server.pem ins Verzeichnis certs gelegt. Beim Apache-Server 4 ist das Modul mod_ssl zu installieren, welches ein Interface zu openssl darstellt. Der Pfad zu den beiden Dateien ist in der Konfigurationsdatei anzugeben: SSLCertificateFile SSLCertificateKeyFile /pfad/nach/server.pem /pfad/nach/skey.pem $Id: openssl.tex,v 1.3 2006/08/17 05:50:08 hj Exp $ 3) http://tcl.tk/software/tclhttpd 4) http://httpd.apache.org 8

3 EINRICHTUNG EINES EIGENEN HTTPS-SERVERS 3.3 Einrichten des Webservers Abbildung 2: Mozilla 1.7.12 Zertifikatmanager Vorinstallierte Wurzelzertifikate sind als builtin object token gekennzeichnet, manuell importierte als software security device bzw. auf Deutsch Software-Kryptographie-Modul. 9

3.3 Einrichten des Webservers 3 EINRICHTUNG EINES EIGENEN HTTPS-SERVERS Abbildung 3: Frage, ob Zertifikat anerkannt werden soll 10