Verbindungklassen

Verbindungsklassen können TCP- oder UDP-Sockets sein. Die Verbindungen sind in der Regel zu verschlüsseln. Unverschlüsselte Sockets können für “localhost”-Verbindungen, für Testzwecke oder (eingeschränkt, Ausnahme) in einem LAN verwendet werden.

Für verschlüsselte Verbindungen haben nach dem EI-Schema sowohl Client als auch Server jeweils Zertifikate zu präsentieren. Da mit X.509 kooperiert wird, muss für eine Reihe von Anwendungszwecken aber auch zugelassen werden, dass sich der Client nicht mit einem Zertifikat verbindet.

Wir konzentrieren die Diskussion hier auf verschlüsselte Sockets.

TCP - Server - Sockets

In der Initialisierungsphase wird die Socketkonfiguration bis zur listen-Funktion ausgeführt. Da accept blockiert, wird diese Funktion in einen eigenen Thread verlagert, um weitere Verbindungen initiieren zu können. Wir ein Client-Ruf empfangen, wird die weitere Verarbeitung in einen weiteren Thread verlagert, während accept auf die nächste Verbindung wartet.

Im Client-Thread übernimmt zunächst ein Botan::TLS::Server-Objekt die Datenauswertung, die sich in die Handshake-Phase und die Arbeitsphase unterteilt. Das Server-Objekt ist nur für die laufende Sitzung zuständig und erfordert die Definition mehrerer Callback-Funktionen, die auch auf Daten der laufenden Sitzung zurück greifen müssen. Aus diesem Grund läuft der Client-Thread nicht mit Funktionen des TCP_Servers (die Attribute wären sonst für alle Clients die gleichen), sondern auf Funktionen eines TLS_Worker-Objektes, das für jede Sitzung individuell erzeugt wird. Jede Sitzung besitzt eine TLS_Session_ID, die es dem TLS::Server-Objekt in Zusammenarbeit mit einem TLS::Session-Objekt erlaubt, unterbrochene Sitzungen fortzusetzen.

Die TLS_Session_ID erlaubt es wiederum einem ManagerBase-Objekt, Arbeitssitzungen zu organisieren. Es auch hier sinnvoll, dass das ManagerBase-Objekt individuelle Daten für die Sitzung besitzt. Aus diesem Grund wird zusammen mit den sitzungsindividuellen TLS_Worker- und Botan::TLS::Server-Objekten das an das TCP_Server-Objekt gebundene ManagerBase-Objekt geklont. Mittels eines Session-Objektes für den ManagerBase-Bereich können auch hier Informationen für Sitzungsfortsetzungen fortgeschrieben werden. Wir haben somit die Objektstruktur:

TCP_Server:
  Attribut ManagerBase           mb
  Attribut TLS::SessionManager   sm
  Attribut Session               se

  function accept:  -> new TLS_Worker
                       Attribut new TLS::Server
                       Attribut clone(mb)
                       Attribut TLS::SessionManager   sm
                       Attribut Session               se

                       Callback-Funktionen (4 Funktionen) -> TLS::Server

und die Sitzungsinformationen:

  • TLS::Server für die Zeit der Verbindung
  • TLS::SessionManager mit den Informationen aus TLS::Server für eine Wiederaufnahme der Verbindung
  • ManagerBase(clone) mit Arbeitsdaten, erhält TLS_Session_ID und Client-Zertifikat
  • Session wie TLS::SessionManager

Bevor eine Verbindung zu Stande kommt, sind eine Reihe von Prüfungen zu durchlaufen. Der TLS::Server enthält das Server-Zertifikat und den privaten Schlüssel des Servers. Falls dem TLS::Server vertrauenswürdige Root-CA-Zertifikate vorhanden sind, fordert er automatisch ein Client-Zertifikat an. Die in Botan vorhandene Funktionalität führt zunächst sämtliche nach X.509 vorgesehenen Prüfungen durch. Mögliche Ergebnisse:

  • ENCRYPTION_ONLY: der TLS::Server besitzt kein Root-CA-Zertifikat und fordert kein Client-Zertifikat an. Die Verbindung wird nur verschlüsselt. Als Sitzungs-Identifikation wird eine TLS_Session_ID generiert. Kompatibilitätsmodus mit X.509.
  • ARBITRARY: der TLS::Server besitzt ein Root-CA-Zertifikat (oder mehrere) und fordert ein Client-Zertifikat an. Der kann eines senden oder nicht, falls er keines hat.
    • Kein Client-Zertifikat: der Zustand entspricht ENCRYPTION_ONLY
    • Client-Zertifikat: wenn ein Zertifikat übermittelt wird, sollte es den Mindestanforderungen genügen, d.h. nicht abgelaufen nach X.509-Formalismus sein. Weitere Kriterien:
      • Das Zertifikat ist selbstsigniert. EI-Zertifikate sind i.d.R. selbstsigniert. Selbstsignatur ist kein Ablehnungsgrund; X.509-Meldungen sind als unkritisch zu markieren
      • Das Root-Zertifikat ist unbekannt. Auch dies ist kein Ablehnungsgrund; X.509-Meldungen sind als unkritisch zu markieren
      • Das Root-Zertifikat besitzt eine CRL. Optional kann gegen die CRL geprüft werden. Dazu ist allerdings notwendig, dass die CRL der CA regelmäßig abgerufen wird und auf dem System zur Verfügung steht. Wir lassen das als Option offen, da es sich um eine X.509-Angelegenheit handelt, die nur bedingt auf EI übertragbar ist.
      • Das Root-Zertifikat besitzt einen OCSP-Eintrag. Dieser ist nur online überprüfbar. Wir lassen auch dies vorläufig als Option offen, da es erweiterter Mechanismen bedarf, um das umzusetzen.
  • MANDATORY: ein Client-Zertifikat ist zwingend notwendig. Verfahren wird wie unter ARBITRARY/Client-Zertifikat
  • EI_LOCAL_NET: das Server-Zertifikat ist ein durch ein EI-Zertifikat fremdsigniertes EI-Zertifikat oder ein selbst signiertes Zertifikat (das gleichzeitig auch die vertrauenswürdige CA darstellt). Reine X.509-Zertifikate werden nicht berücksichtigt. Dies ist durch die Konfiguration sicher zu stellen. Das Client-Zertifikat ist dann und nur dann zu akzeptieren, wenn es gültig UND CA-signiert ist [1]

Ab ARBITRARY/Client-Zertifikat ist neben der TLS_Session_ID das komplette Client-Zertifikat Steuerungsparameter.

Sofern das Client-Zertifikat die Prüfungen nicht übersteht, wird der Verbindungsaufbau mit einer kritischen TLS-Meldung abgebrochen. Wenn die X.509-Prüfungen bestanden werden, ist eine zusätzliche EI-Prüfung notwendig. Hierzu wird das Server-Zertifikat, das Client-Zertifikat, der X.509-Status und die Anwendungskennung an ein Objekt einer Kontrollklasse übertragen:

  • Das Client-Zertifikat ist nicht in der lokalen Datenbank und wird eingetragen und dabei überprüft.
  • Der Status des Zertifikats wird aus der Datenbank ausgelesen. Es muss die EI-Regeln bezüglich der Generation/des Siblings erfüllen und darf nicht aus einem anderen Grund gesperrt oder unsicher sein.
  • Der Verbindungsversuch wird im Log-Bereich der Datenbank gespeichert.

Diese Kontrolle wird immer durchgeführt, sobald ein Client-Zertifikat vorliegt. Dies ist auch bei EI_LOCAL_NET notwendig, um ungültig gewordene Zertifikate zu erkennen. Zertifikate, die hier abgelehnt werden, führen ebenfalls zu einer TLS-Meldung auf der Gegenseite.

Optional kann nach diesen Prüfungen eine weitere durch die Anwendung durchgeführt werden. Diese erhält immer die TLS_Session_ID sowie, falls verfügbar, das Client-Zertifikat, bevor die ersten Anwendungsdaten mit dem Client ausgetauscht werden. Im Modus APP_BASED wird der Rückgabewert der Anwendung ebenfalls ausgewertet und kann zu einem TLS-Abbruch vor Aufnahme des Datenverkehrs führen, sofern die Anwendung dies vorgibt. APP_BASED entsprich ARBITRARY mit einer zusätzlichen Prüfung durch den Client.

[1]Es ist noch zu klären, welche X.509-Meldungen in diesem Zusammenhang anfallen können.