SSL und TLS

Secure Socket Layer (SSL) wurde 1993 von Netscape entwickelt. Der Grund für die Entwicklung war das die damals vorhandenen Security-Bibliotheken nicht alle bedürfnisse abdecken konnten die man fürs Web brauchte. Die meist verbreiteten Versionen von SSL sind v2 und v3. Wegen den bekannten Problemen mit der Kryptographie in v2 wird geraten nur noch v3 zu benutzen. Da SSL Protokoll Netscape gehört und per U.S. Patent geschützt ist hat die IETF begonnen etwas ähnliches zu entwickeln und entwickelten TLS. Transport Layer Security (TLS), welches im RFC2246 festgehalten wird, basiert sehr stark auf SSL v.3. TLS benutzt exakt das selbe Protokoll für greeting und version extensibility Nachrichten.

Beide Protokolle, SSL und TLS, sind nicht auf einen bestimmten Algorythmus angewisen. Für das erzeugen der Keys, die Datenverschlüsselung und die Authentication stehen jeweils verschiedene Algorithmen zur Verfügung. Allerdings funktionieren nicht alle der möglichen Kombinationen von Algorithmen, weshalb es empfohlene Kombinationen gibt. Die Möglichkeit die Algorithmen auszutauschen hat den Vorteil, dass man SSL/TLS je nach Bedürfnis mit stärkere oder schwächerer Kryptographie benutzen kann. Auch können so neue Algorithmen hinzugefügt werden ohne ein neues Protokoll entwickeln zu müssen. TLS erlaubt dem Client sich per RSA oder DSS public Key zu authentifizieren. Möchte ein Client aber eine andere Methode verwenden so muss er sich als anonym Anmelden und die Authentifizieren dann auf Applikationslevel bewerkstelligen. Ein Webserver z.B. meldet sich bei SSL/TLS anonym an und die HTTP basic authentification wird dann auf der Applikationsebene bewerkstelligt.

Auch wenn die beiden Protokolle sehr ähnlich sind, so sind sie im TCP/IP-Protokollstapel auf verschiedenen Ebenen angesiedelt. SSL wird, zusätzlich zu TCP, in die Transportschicht eingefügt. Es ist deshalb für die Applikationsschicht transparent und die Applikationen/Protokolle die SSL benutzen müssen kaum/gar nicht verändert werden. TLS dagegen ist in der Applikationsschicht angesiedelt. Dazu muss die Applikation und das Protokoll verändert werden. Das bringt einen Mehraufwand mit sich aber auch mehr Flexibilität.

Um SSL zu implementieren wird ein neuer Port benötigt. Über diesen Port dann ein verschlüsselter SSL-Tunnel aufgebaut. Durch dieses Tunnel wird dann das normale unverschlüsselte Protokoll gesprochen. Der grosse Vorteil dieser Technik besteht in der einfachen Implementierung. Sie kann sogar mit Hilfe von stunnel nachgerüstet werden ganz ohne am Client oder Server etwas zu verändern. Der Nachteil ist das man dafür ein extra Port braucht und es nur 1024 Port gibt die fest alloziert werden können.

Dem Protokoll wir ein neues Kommando hinzugefügt. Wenn dieses Kommando vom Client aufgerufen wird wird die aktuell laufende Verbindung verschlüsselt. ESMTP hat SSL/TLS auf diese weise implementiert. Die Verbindung wird erst verschlüsselt wenn der Client das mit dem Kommando STARTTLS fordert. Dies hat den Vorteil das man eine Verbindung öffnen kann und dann abklären ob beide TLS können und es dann aktivieren. Nachteil ist das man die Applikation und das Protokoll anpassen muss und beim Programmieren viel besser aufpassen muss das nichts unverschlüsselt gesendet wird.

Keine dieser Beiden Methoden ist perfekt. Die erste Methode ist zwar einfach zu implementieren, braucht aber einen der 1024 privilegierten Ports. Die TLS-Methode spart zwar einen Port, ist aber schwiriger zu implementieren. Auch bracht TLS ein Protokoll, welches es dem Server erlaubt mitzuteilen das er TLS anbietet. Welches die bessere Methode ist kommt sehr stark auf den Verwendungszweck an.

• SSL auf Wikipedia
• TLS auf Wikipedia