SSL (Secure Sockets Layer) ist ein System, mit dem Informationen, die über das Internet gesendet werden, automatisch verschlüsselt und beim Empfänger vor ihrer Verwendung wieder entschlüsselt werden. Auf diese Weise werden sensible Informationen wie Kreditkartennummern während der Übertragung über das Internet geschützt.
Caching Proxy verwendet SSL für den Schutz von Ersatzservern und für eine sichere Fernverwaltung. Nähere Informationen hierzu finden Sie in den folgenden Abschnitten. Mit SSL können auch Verbindungen zu Back-End-Servern (z. B. Inhalts- oder Anwendungsservern) und Datenübertragungen zwischen dem Proxy-Server und seinen Clients geschützt werden.
Für Forward-Proxy-Server unterstützt Caching Proxy die SSL-Tunnelung, bei der SSL umgangen wird und die bereits verschlüsselten Daten unverändert gesendet werden.
Der SSL-Zugriffsschutz wird aktiviert, wenn eine Anforderung für eine sichere Verbindung von einer Maschine an eine andere gesendet wird, z. B. wenn ein Browser eine Anforderung an einen Ersatz-Proxy-Server sendet. Die Anforderungssyntax https:// anstelle von http:// teilt dem Browser mit, dass die Anforderung an Port 443 gesendet werden soll. Dies ist der Port, an dem der Server geschützte Verbindungsanforderungen empfängt (im Unterschied zu Port 80, an dem Routineanforderungen empfangen werden). Zum Aufbau einer sicheren Sitzung zwischen Browser und Server führen die beiden Maschinen einen Informationsaustausch aus, den so genannten SSL-Handshake. Mit diesem Austausch legen die beiden Parteien eine Verschlüsselungsspezifikation fest und wählen den Schlüssel aus, mit dem die Informationen ver- und entschlüsselt werden sollen. Die Schlüssel werden automatisch generiert und verfallen mit Beendigung der Sitzung. Im Folgenden wird ein typisches Szenario (mit SSL Version 3) beschrieben:
Der Client leitet eine SSL-Sitzung mit Caching Proxy ein, indem er eine Hello-Nachricht sendet, die die Verschlüsselungsfunktionen des Clients beschreibt.
Der Server sendet sein Zertifikat an den Client und wählt die Cipher Suite aus, die zur Datenverschlüsselung verwendet werden soll.
Der Client sendet die Informationen zum Chiffrierschlüssel, mit dem die symmetrischen Chiffrierschlüssel für die verschlüsselten Daten erstellt werden. Diese Schlüsselinformationen werden als Premaster Secret bezeichnet und sind mit dem öffentlichen Schlüssel des Servers (aus dem Serverzertifikat, siehe Schlüssel- und Zertifikatverwaltung) verschlüsselt. Server und Client können die symmetrischen Chiffrierschlüssel zum Lesen und Schreiben aus dem Premaster Secret abrufen.
Der Server sendet die Abschlussbestätigung und einen Nachrichtenauthentifizierungscode (Message Authentication Code, MAC) für das gesamte Handshake-Protokoll.
Der Client sendet eine Nachricht, um die Abschlussnachricht des Servers zu überprüfen.
Nachdem der Client die Abschlussnachricht des Servers überprüft hat, kann der verschlüsselte Datenfluss beginnen.
Mit einem Caching-Proxy-Server als Endpunkt für sichere Verbindungen können Sie die Arbeitslast auf Ihren Content-Servern und Anwendungsservern verringern. Wenn ein Caching-Proxy-Server eine sichere Verbindung verwaltet, ist er für die Verschlüsselung, Entschlüsselung und die Generierung der Schlüssel zuständig. Bei allen Vorgängen handelt es sich um CPU-intensive Operationen. Außerdem können Sie in Caching Proxy SSL-Sitzungszeitlimits konfigurieren, um eine möglichst lange Verwendung jedes Schlüssels zu gewährleisten.
Einschränkungen von SSL
In WebSphere Application Server Caching Proxy gelten folgende SSL-Einschränkungen:
Bei hohem HTTPS-Datenverkehrsaufkommen kann der Caching-Proxy-Server eine hohe CPU-Belastung verursachen. Optimierungsänderungen an einer Umgebungsvariablen (GSK_V3_SIDCACHE_SIZE) und einer Proxy-Anweisung (SSLV3Timeout) können dem Proxy-Server helfen, die Last zu bewältigen und die CPU-Belastung zu reduzieren.
Die SSL-Sitzungs-ID identifiziert wiederverwendbare SSL-Sitzungen, einschließlich Ver- und Entschlüsselungsschlüsseln, die von Browsern und Servern verwendet werden, und wird verwendet, um unnötige SSL-Handshakes in neuen Verbindungen zu vermeiden, die viel CPU-Zeit des Servers verbrauchen. Die GSKit-Bibliothek für den Caching-Proxy-Server unterstützt SSL-Sitzungs-IDs und enthält einen Cache für SSL-Sitzungs-IDs. Standardmäßig enthält der Cache für SSL-Sitzungs-IDs 512 Einträge. Wenn das Eintragslimit erreicht ist, wird der älteste Sitzungseintrag entfernt und der neue Eintrag dem Cache hinzugefügt.
Verwenden Sie die Umgebungsvariable GSK_V3_SIDCACHE_SIZE, um die Standardgröße des Cache für SSL-Sitzungs-IDs zu ändern. Die gültigen Werte für diese Variable liegen zwischen 1 und 4096. Wenn Sie die Größe heraufsetzen, erhöht sich damit auch die Zeit, die zum Suchen einer zwischengespeicherten SSL-Sitzung erforderlich ist. Die erhöhte Suchzeit ist jedoch im Vergleich mit dem Aufwand für das Einrichten einer SSL-Verbindung unerheblich. Mit einem größeren Cache ist der Proxy-Server bei hohem HTTPS-Datenverkehrsaufkommen in der Lage, mehr SSL-Sitzungen gleichzeitig zu verarbeiten und die CPU-Belastung zu senken.
Caching Proxy besitzt außerdem eine optimierbare Anweisung "SSLV3Timeout". (Siehe SSLV3Timeout - Die Wartezeit vor dem Ablaufen einer SSLV3-Sitzung angeben.) Der Standardwert der Anweisung sind 1000 Sekunden. Diese Anweisung definiert die Lebensdauer einer SSL-Sitzung im Sitzungs-Cache. Wenn keine eingehende SSL-Verbindung eine vorhandene SSL-Sitzung verwendet und die Sitzungslebensdauer diesen Wert überschreitet, wird diese Sitzung aus dem Sitzungs-Cache entfernt. Es wird empfohlen, für den Wert von SSLV3Timeout die Dauer einer typischen sicheren Clientsitzung zu verwenden. Wenn ein zu kurzes Zeitlimit gewählt wird, kann dies die Leistung des Proxy-Servers beeinträchtigen, weil mehrere SSL-Handshake-Sitzungen erforderlich sind, um eine einzelne sichere Sitzung einzurichten. Wird jedoch ein zu hoher Wert gewählt, kann sich dies auch negativ auf die Sicherheit einer sicheren Sitzung auswirken.
Dies gilt nur für Forward-Proxy-Konfigurationen.
Ist Caching Proxy als Forward Proxy konfiguriert, verwendet er die SSL-Tunnelung, um sichere Verbindungen zwischen Clients und Content-Servern zu unterstützen. Bei der SSL-Tunnelung werden verschlüsselte Daten unverändert über den Proxy-Server übergeben. Da der Proxy-Server die Daten nicht entschlüsselt, werden Funktionen, bei denen der Proxy-Server Anforderungen oder Dokument-Header lesen muss, von der SSL-Tunnelung nicht unterstützt. Außerdem werden im Tunnelungsverfahren übertragene Anforderungen nicht im Cache gespeichert.
Abb. 2 zeigt einen Verbindungsaufbau unter Verwendung der SSL-Tunnelung.
Die SSL-Tunnelung wird wie folgt ausgeführt:
In der Konfiguration als Forward Proxy ist nur die SSL-Tunnelung verfügbar. Um die SSL-Tunnelung zu aktivieren, wählen Sie in den Konfigurations- und Verwaltungsformularen Konfiguration des Proxy –> Einstellungen für Proxy aus. Wählen Sie das Markierungsfeld SSL-Tunnelung aus.
Für Verbindungen, die das SSL-Tunnelungsverfahren verwenden, muss die Methode CONNECT (die standardmäßig inaktiviert ist) ebenfalls aktiviert sein. Wählen Sie dazu in den Konfigurationsformularen Serverkonfiguration –> Anforderungsverarbeitung aus und rufen Sie das Formular HTTP-Methoden auf.
Für die Anweisung Enable CONNECT werden für die erweiterte Sicherheit bei der SSL-Tunnelung drei Optionen bereitgestellt: OutgoingPorts, OutgoingIPs und IncomingIPs. Sie müssen zumindest für OutgoingPorts einen Wert angeben, andernfalls wird die Methode CONNECT nicht aktiviert.
Enable CONNECT OutgoingPorts [all | [port1|port1-port2|port1-*],...]Setzen Sie die folgenden Anweisungen, wenn Clients für die SSL-Tunnelung nur Verbindungen zum fernen Serverport 443 herstellen dürfen: (Normalerweise ist Port 443 für HTTPS-Anforderungen auf dem fernen Server reserviert.)
Enable CONNECT OutgoingPorts 443 SSLTunneling onSetzen Sie die folgenden Anweisungen, wenn Clients für die SSL-Tunnelung Verbindungen zu jedem fernen Serverport 443 herstellen dürfen:
Enable CONNECT OutgoingPorts all SSLTunneling onSetzen Sie die folgenden Anweisungen, wenn Clients für die SSL-Tunnelung Verbindungen zu den fernen Serverport 80, 8080-8088 und 9000 (und höheren Ports) herstellen dürfen:
Enable CONNECT OutgoingPorts 80,8080-8088,9000-* SSLTunneling on
Ports und Portbereiche werden in der Liste durch Kommas (ohne Leerzeichen) getrennt.
Wichtiger Hinweis: Geben Sie für Forward-Proxy-Konfigurationen mindestens 443 oder all für die Option OutgoingPorts an, um eine normale SSL-Tunnelung zuzulassen.
Enable CONNECT OutgoingIPs [[!]IP-Muster,...]Setzen Sie die folgenden Anweisungen, um Clients die Verbindungsherstellung zu jedem Port auf den fernen Servern zu erlauben, die der IP-Adresse bzw. dem Hostnamen *.ibm.com und nicht der Angabe 192.168.*.* entsprechen:
Enable CONNECT OutgoingPorts all OutgoingIPs *.ibm.com,!192.168.*.* SSLTunneling on
Enable CONNECT IncomingIPs [[!]IP-Muster,...]Setzen Sie die folgenden Anweisungen, wenn Sie beispielsweise Clients mit der IP-Adresse 192.168.*.* für die SSL-Tunnelung die Verbindungsherstellung zu jedem Port auf den fernen Servern erlauben möchten:
Enable CONNECT OutgoingPorts all IncomingIPs 192.168.*.* SSLTunneling on
Weitere Informationen zum Aktivieren der SSL-Tunnelung und der CONNECT-Anweisungen durch Editieren der Konfigurationsdatei des Proxy-Servers finden Sie in den Referenzabschnitten zu den folgenden Anweisungen in Anhang B. Anweisungen in der Konfigurationsdatei:
Die Fernverwaltung von Caching Proxy kann mit den SSL-Sicherheitsfunktionen (Secure Sockets Layer) und der Kennwortauthentifizierung durchgeführt werden. Dadurch verringert sich das Risiko, dass nicht autorisierte Personen auf den Proxy-Server zugreifen.
Wenn Sie für die Fernverwaltung Ihres Servers SSL einsetzen möchten, verwenden Sie zum Öffnen der Konfigurations- und Verwaltungsformulare eine https://-Anforderung anstelle einer http://-Anforderung. Beispiel:
https://Name.Ihres.Servers/IhreFrontPage.html
Vor der Konfiguration von SSL müssen Sie eine Schlüsseldatenbank einrichten und ein Zertifikat abrufen oder erstellen. Zertifikate dienen der Authentifizierung von Servern. Verwenden Sie zum Definieren Ihrer Zertifizierungsdateien das Dienstprogramm IBM Key Management (auch iKeyman genannt). Dieses Dienstprogramm ist Teil des Java Development Kit (JDK). iKeyman enthält außerdem eine Java-basierte Grafikschnittstelle zum Öffnen von Zertifikatsdateien.
Nachfolgend sind die grundlegenden Schritte zum Definieren der SSL-Schlüssel und Zertifikate beschrieben:
Wenn das Zertifikat abgelaufen ist, wird Caching Proxy auf allen Betriebssystemen mit Ausnahme von Linux nicht ordnungsgemäß gestartet, und es erscheint eine Fehlernachricht, die Sie darauf hinweist, dass die Schlüsseldatenbank verfallen ist. Unter Linux scheint der Proxy-Server zu starten, aber der Prozess wird sofort wieder beendet, und es wird keine Fehlernachricht generiert.
Sie können dieses Problem auf Systemen mit Red Hat Enterprise Linux 3.0 verhindern, indem Sie sicherstellen, dass die GCC-Paket die folgenden Versionen (oder höher) haben:
Ihrem öffentlichen Schlüssel muss ein digital signiertes Zertifikat einer Zertifizierungsstelle (CA) zugeordnet sein, die als vertrauenswürdige Stamm-CA auf Ihrem Server festgelegt ist. Sie können ein signiertes Zertifikat erwerben, indem Sie eine Zertifikatanforderung an den Provider der Zertifizierungsstelle (CA) senden. Caching Proxy unterstützt die folgenden externen Zertifizierungsstellen:
Standardmäßig sind die folgenden Zertifizierungsstellen als Trusted-CAs definiert:
Dieser Abschnitt enthält eine Kurzübersicht über die Verwendung des Dienstprogramms IBM Key Management (iKeyman). Mit diesem Dienstprogramm erstellen Sie Ihre SSL-Schlüsseldatenbankdatei, öffentlich-private Schlüsselpaare und Zertifikatanforderungen. Nachdem Sie das von der Zertifizierungsstelle signierte Zertifikat empfangen haben, legen Sie es mit IBM Key Management in der Schlüsseldatenbank ab, in der Sie die ursprüngliche Zertifikatanforderung erstellt haben.
Weitere ausführliche Informationen finden Sie in der Dokumentation zu IBM Key Management und GSKit, die der GSKit-Software beiliegt.
Das System für die Ausführung von IBM Key Management konfigurieren
Gehen Sie vor dem Start der GUI von IKeyman wie folgt vor:
Aktualisieren Sie die Datei JAVA_HOME/jre/lib/security/java.security, indem Sie an den im Beispiel gezeigten Positionen die Providern IBM CMS und IBM JCE hinzufügen:
IBM Key Management starten
Starten Sie die grafische Benutzerschnittstelle von Key Management, indem Sie das Tool iKeyman aus dem JDK ausführen. Verwenden Sie beispielsweise den folgenden Befehl:
Bei einer Schlüsseldatenbank handelt es sich um eine Datei, in der der Server ein oder mehrere Schlüsselpaare und Zertifikate speichert. Für sämtliche Schlüsselpaare und Zertifikate können Sie entweder eine Schlüsseldatenbank verwenden oder mehrere Datenbanken erstellen. Mit dem Dienstprogramm IBM Key Management können Sie neue Schlüsseldatenbanken erstellen und die zugehörigen Kennwörter und Dateien zur Kennwortspeicherung festlegen.
So erstellen Sie eine Schlüsseldatenbank und eine Datei zur Kennwortspeicherung:
Das Kennwort, das Sie beim Erstellen einer neuen Schlüsseldatenbank angeben, schützt den privaten Schlüssel. Der private Schlüssel ist der einzige Schlüssel, der Dokumente signieren oder Nachrichten entschlüsseln kann, die mit dem öffentlichen Schlüssel verschlüsselt wurden.
Beachten Sie bei der Festlegung des Kennworts folgende Richtlinien:
Es wird empfohlen, das Kennwort der Schlüsseldatenbank regelmäßig zu ändern. Wenn Sie ein Verfallsdatum für das Kennwort festlegen, sollten Sie sich auf jeden Fall notieren, wann Sie das Kennwort ändern müssen. Sollten Sie das Verfallsdatum des Kennworts verpassen, wird eine Nachricht in das Fehlerprotokoll geschrieben. Der Server wird dann zwar gestartet, kann aber keine sicheren Netzverbindungen herstellen.
So ändern Sie das Kennwort für die Schlüsseldatenbank:
Wenn Sie zwischen einem Proxy-Server und einem LDAP-Server eine SSL-Verbindung herstellen möchten, müssen Sie das Kennwort für die Schlüsseldatenbank in der Datei pac_keyring.pwd speichern. (Die Datei pac_keyring.pwd ist nicht die verdeckte Datei, die von iKeyman generiert wird.)
Ein neues Schlüsselpaar und eine neue Zertifikatanforderung erstellen
In der Schlüsseldatenbank sind Schlüsselpaare und Zertifikatanforderungen gespeichert. So erstellen Sie ein öffentlich-privates Schlüsselpaar und eine Zertifikatanforderung:
Eine neue Zertifikatanfrage wurde erfolgreich in der Datei Name_der_Schlüsseldatenbankname erstellt.
Selbst signiertes Zertifikat erstellen
Erstellen Sie mit IBM Key Management ein selbst signiertes Serverzertifikat, um damit SSL-Sitzungen zwischen Clients und dem Proxy-Server zu aktivieren, während Sie auf die Ausstellung des angeforderten Zertifikats warten. Außerdem können Sie selbst signierte Zertifikate zu Testzwecken verwenden.
Gehen Sie wie folgt vor, um ein selbst signiertes Zertifikat zu erstellen:
Schlüssel exportieren
So exportieren Sie Schlüssel in eine andere Schlüsseldatenbank:
Schlüssel importieren
So importieren Sie Schlüssel aus einer anderen Schlüsseldatenbank:
Zertifizierungsstellen auflisten
So können Sie eine Liste mit vertrauenswürdigen Zertifizierungsstellen (Trusted-CAs) in einer Schlüsseldatenbank anzeigen:
Gehen Sie wie folgt vor, um ein Zertifikat zu empfangen, das Sie per E-Mail von einer Zertifizierungsstelle erhalten haben, die standardmäßig als Trusted-CA definiert ist (siehe die Liste im Abschnitt Zertifizierungsstellen). Wenn es sich bei der Zertifizierungsstelle (CA), die Ihr Zertifikat ausstellt, nicht um eine in der Schlüsseldatenbank gespeicherte vertrauenswürdige Zertifizierungsstelle handelt, müssen Sie zunächst das Zertifikat dieser Instanz speichern und die CA als vertrauenswürdige CA festlegen. Anschließend können Sie Ihr von der CA signiertes Zertifikat in die Datenbank laden. Sie können kein signiertes Zertifikat von einer Zertifizierungsstelle empfangen, die nicht als vertrauenswürdig eingestuft wurde (siehe Abschnitt Ein CA-Zertifikat speichern).
So laden Sie das von der Zertifizierungsstelle signierte Zertifikat in eine Schlüsseldatenbank:
Zum Aufbau sicherer Verbindungen werden nur Zertifikate akzeptiert, die von einer vertrauenswürdigen Zertifizierungsstelle signiert wurden. Wenn Sie der Liste der vertrauenswürdigen Stellen eine Zertifizierungsstelle hinzufügen möchten, müssen Sie ihr Zertifikat abrufen und als vertrauenswürdig abspeichern. Gehen Sie wie folgt vor, um ein Zertifikat von einer neuen Zertifizierungsstelle zu speichern:
Standardschlüssel in einer Schlüsseldatenbank anzeigen
Gehen Sie wie folgt vor, um den Eintrag für den Standardschlüssel anzuzeigen:
In der folgenden Tabelle sind die Verschlüsselungsalgorithmen und Hash-Verfahren aufgeführt, die für die SSL-Versionen 2 und 3 verwendet werden.
Generierung von Schlüsselpaaren: RSA 512–1024 (Größe von privaten Schlüsseln)
SSL Version 2
US-Version | Exportversion |
RC4 US | RC4 Export |
RC2 US | RC2 Export |
DES 56-Bit | nicht zutreffend |
Triple DES US | nicht zutreffend |
RC4 Export | nicht zutreffend |
RC2 Export | nicht zutreffend |
SSL Version 3
US-Version | Exportversion |
Triple DES SHA US | DES SHA Export |
DES SHA Export | RC2 MD5 Export |
RC2 MD5 Export | RC4 MD5 Export |
RC4 SHA US | NULL SHA |
RC4 MD5 US | NULL MD5 |
RC4 MD5 Export | NULL NULL |
RC4 SHA 56-Bit | nicht zutreffend |
DES CBC SHA | nicht zutreffend |
NULL SHA | nicht zutreffend |
NULL MD5 | nicht zutreffend |
NULL NULL | nicht zutreffend |
Diese SSL-Spezifikationen können auch direkt durch Editieren der Konfigurationsdatei des Proxy-Servers konfiguriert werden. Einzelheiten hierzu finden Sie in Anhang B. Anweisungen in der Konfigurationsdatei in den Referenzabschnitten zu den folgenden Anweisungen:
128-Bit-Verschlüsselung für Caching Proxy
Es wird nur eine 128-Bit-Verschlüsselungsversion von Caching Proxy bereitgestellt. Die 56-Bit-Version ist nicht mehr verfügbar. Wenn Sie eine ältere Version aktualisieren, können Sie Caching Proxy direkt in Ihrer derzeit installierten 128-Bit- oder 56-Bit-Version installieren. Falls Sie vorher einen 56-Bit-Browser (Export) verwendet haben, müssen Sie einen Upgrade auf einen 128-Bit-Browser durchführen, damit Sie die 128-Bit-Verschlüsselung im Proxy-Server nutzen können.
Falls nach dem Upgrade von einer 56-Bit-Version von Caching Proxy auf die 128-Bit-Version die für die Verschlüsselung von Zertifikaten verwendete Schlüsselgröße auf 1024 gesetzt ist, müssen keine Änderungen an der Konfiguration vorgenommen werden. Ist die Schlüsselgröße auf 512 gesetzt, müssen Sie neue Zertifikate mit einer Schlüsselgröße von 1024 erstellen, damit Sie die 128-Bit-Verschlüsselung des Proxy-Servers nutzen können. Erstellen Sie neue Schlüssel mit dem Dienstprogramm IBM Key Management (iKeyman).
Eine detaillierte Beschreibung des Dienstprogramms IBM Key Management finden Sie im Abschnitt Schlüssel- und Zertifikatverwaltung.
Beachten Sie, dass diese Produktversion unter SUSE Linux keine Verschlüsselung unterstützt.