Manche Applikationen erfordern aus Sicherheitsgründen eine höhere Sicherheitsstufe bei der Netzwerk-Kommunikation eines Clients mit dem DBAccess-Server. Daher bietet der DBAccess Server die Möglichkeit, sogenannte "Sichere Verbindungen" durch Nutzung von SSL zu verwenden.
Dabei hat man folgende Konfigurationsmöglichkeiten (s. Initialisierungsdatei):
- Der Server kann wie bisher als Server ohne die Möglichkeit für SSL Verbindungen konfiguriert werden
(im weiteren abkürzend als "NoSSL Server" bezeichnet). - Der Server kann so konfiguriert werden, dass er ausschliesslich SSL Verbindungen akzeptiert
(im weiteren abkürzend als "SSL Server" bezeichnet). - Der Server kann so konfiguriert werden, dass er beide Verbindungstypen akzeptiert; in diesem Fall wird der Server immer eine SSL Verbindung wählen, wenn ihm vom Client die Wahl des Verbindungstyps überlassen wird
(im weiteren abkürzend als "SSL/NoSSL Server" bezeichnet).
Der DBACCESS-Server benötigt ein Server-Zertifikat (s. Initialisierungsdatei); über dieses kann bei sicheren Verbindungen der Algorithmus für die Verschlüsselung des Netzverkehrs zwischen Client und Server ausgehandelt werden (schliesslich müssen beide Partner einen gemeinsamen Verschlüsselungsalgorithmus beherrschen).
Zertifikate kann man sich über offizielle Zertifikatsstellen beschaffen (genauer: man schickt ein Zertifikat und ein CSR, d.h. ein Certificate Signing Request an eine derartige Stelle, die das Zertifikat dann offiziell signiert); in diesem Fall werden sie dort hinterlegt und können über eine URL, d.h über einen Webzugriff, verwendet werden oder sie sind als lokale Dateien verfügbar.
Man kann sich aber auch selbst(-signierte) Zertifikate erzeugen; dafür wird im BS2000 die Prozedur make.cert in der Bibliothek $TSOS.SYSSPR.TCP-IP-AP.0nn ausgeliefert.
Die Verwendung dieser Prozedur ist im Manual "interNet Services User Guide" beschrieben.
Man beachte, dass ein Zertifikat mindestens aus zwei Teilen besteht: Der eigentlichen Zertifikats-Datei und einer Datei mit dem privaten Schlüssel für die Verschlüsselung (das natürlich nicht allgemein zugänglich gemacht werden sollte). Beide Teile werden für die Konfiguration eines SSL bzw. SSL/NoSSL Servers benötigt
(s. Initialisierungsdatei).
Ein Client kann bei einer Verbindungsanforderung an den DBACCESS-Server fordern, dass
- eine gewöhnliche, also unsichere Verbindung aufgebaut wird (unsecure)
- eine sichere Verbindung aufgebaut wird (secure)
- eine sichere Verbindung aufgebaut wird, wenn der Server dies unterstützt, oder eine unsichere, wenn der Server keine sicheren Verbindungen unterstützt (prefer secure)
Siehe dazu auch die readme-Datei des jeweiligen Clients (JDBC, ADO.Net, PHP/PDO).
Dann ergibt sich folgende Matrix für die Art der tatsächlich aufgebauten Verbindung zwischen Client und Server:
Servertyp Clientanforderung | NoSSL | SSL | SSL/NoSSL |
|---|---|---|---|
| unsecure | unsecure | error | unsecure |
| secure | error | secure | secure |
| prefer secure | unsecure | secure | secure |
Verschlüsselung und Entschlüsselung kosten CPU sowohl auf Client- als auch auf Server-Seite; insbesondere ist der Aufbau einer sicheren Verbindung wesentlich teuerer (bzgl. CPU und v.a. auch bzgl. Netzverkehr) als der Aufbau einer gewöhnlichen, d.h. unsicheren Verbindung.
Aus diesem Grund wird die Verwendung von Connection Pooling für sichere Verbindungen empfohlen, sofern die Client Schnittstelle dies anbietet. Bei den Sesam Clients wird Connection Pooling nur für die JDBC Schnittstelle angeboten (s. readme-Datei des JDBC Clients).