»SSL«¹⁾ (Secure Socket Layer) ist ein Verschlüsselungsprotokoll und wird idR zum sicheren Übertragen von Daten in Netzwerken verwendet. »SSL« wurde bis zur Version 3.1 entwickelt und danach in »TLS« weiter entwickelt, wo es heute bei Version 1.2 angekommen ist. Eine bekannte Implementierung ist zB »OpenSSL«²⁾.

»SSL« findet häufig Verwendung bei der Verschlüsselung der Datenübertragung von Webseiten, wie zB bei der Eingabe von Login Informationen oder anderen sensiblen Daten. Mittlerweile wird aber auch ganz gewöhnlicher HTTP-Traffic verschlüsselt, unterstützt wird dies nicht zuletzt durch immer leistungsfähigere Rechnerhardware. Man erkennt eine verschlüsselte Webseite uA durch die Angabe des »HTTPS« Protokolls in der »URL«. Ein weiteres Einsatzgebiet mit zunehmender Verbreitung ist die Verschlüsselung des E-Mail Verkehrs »SMTP«. »SSL« ist jedoch nicht exklusiv für »HTTP« oder »SMTP« entwickelt, wird jedoch von diesen beiden Technologien am meisten benutzt.

»SSL« zieht zwischen der »Transportschicht« und der »Anwendungsschicht« eine weitere Schicht ein, den »Secure Socket Layer«, wodurch im Prinzip jedes höhere Protokoll »SSL« nutzen könnte.

Warum wird verschlüsselt? Bei »HTTP« und »SMTP« ohne »SSL« wird die gesamte Kommunikation unverschlüsselt in Plain Text übertragen. Ein Datenstrom durchläuft vom Sender zum Empfänger etliche Stationen, wo an jeder mitgehört bzw. mitgelesen werden kann ohne irgendeinen Aufwand betreiben zu müssen. Eine E-Mail zB kann unverschlüsselt mit einer Postkarte verglichen werden die jeder lesen kann, der sie in die Finger bekommt. Würde man sich unverschlüsselt über das Internet an irgendeiner Webseite anmelden (Ebay, Amazon, Banken etc) würde das Passwort ebenfalls unverschlüsselt übertragen werden. Die Technik des meist unbefugten Mitlesens von Datenverkehr in Netzwerken nennt man »Man-In-The-Middle-Angriff«³⁾. Es liegt auf der Hand, dass dies kein erstrebenswerter Zustand sein kann.

Ein weiterer Bestandteil von »SSL« ist die zertifikatsbasierte Server- und Clientauthentifizierung, wobei die Serverauthentifizierung sehr häufig und die Clientauthentifizierung eher in Ausnahmefällen zum tragen kommt. Damit sichergestellt werden kann, dass zB ein Server auch der ist für den er sich ausgibt, werden digitale Zertifikate verwendet. Diese Zertifikate werden von beglaubigten »CAs« (Certification Authority) ausgestellt. Damit eine »CA« ein Serverzertifikat ausstellt muss der Antragsteller beweisen, dass er derjenige ist für den er sich ausgibt. Das kann verschiedenste Maßnahmen mit sich bringen aber im Grunde weiß die »CA« wem sie da für was ein Zertifikat ausstellt und beglaubigt das ausgestellte Zertifikat in dem es digital signiert, quasi unterschrieben wird. Ein Internet-Browser hat nun eine Liste vertrauenswürdiger »CAs« und überprüft das Serverzertifikat, welches der Server dem Client beim Verbindungsaufbau zur Überprüfung sendet. Dadurch soll zB verhindert werden, dass jemand den Login Ihres Onlinebanking Portals auf seine eigene Seite umleitet die genau so aussieht wie die echte und sie ahnungslos Ihre Zugangsdaten eintippen, die der Angreifer dann abgreifen kann. Diesen Angriff nennt man »Phishing«⁴⁾ und gehört heute zu einem der am häufigsten verwendeten Angriffen.

Da »SSL« eine Implementierung in das Netzwerk Subsystem ist kann es auch nur Daten verschlüsseln, welche diesen Stack durchlaufen. Sitzt der Angreifer entweder auf dem Client- oder auf dem Server-System selbst, können dort die Daten auch gestohlen werden. Gespeicherte Daten sind ohne weitere Maßnahmen ebenfalls unverschlüsselt abgelegt. Auch auf dem Transportweg zwischen zwei Rechnern kann der »SSL« verschlüsselte Datenstrom entschlüsselt, abgegriffen, wieder verschlüsselt und weitergeleitet werden, was allerdings zu einer Zertifikatswarnung führt, was dem aufmerksamen Anwender sofort skeptisch werden lässt. Meine Experimente mit »Man-In-The-Middel-Angriffen« sind nun schon eine Weile her aber schon damals war es zB mit »Ettercap«⁵⁾ möglich eine »SSL« verschlüsselte Kommunikation zu belauschen, was zumindest damals aber eine Menge "Lärm" verursacht hat. Man blieb dabei nicht unbemerkt.

Des Weiteren kann »SSL« nicht die Adresse Ihres Kommunikationspartners verschleiern. Das bedeutet, dass ein Angreifer der nur Ihren Netzwerkverkehr belauscht ohne dabei selbst aktiv einzugreifen, in der Lage ist festzustellen mit wem Sie verschlüsselt kommunizieren, was ja auch schon mal nützlich sein kann. Das liegt zum einen daran, dass »SSL« erst nach der Transportschicht, also nach dem TCP-Protokoll Anwendung findet und im TCP-Header bereits ausreichend Informationen vorhanden sind um beide Kommunikationsendpunkte zu identifizieren und zum anderen an der Tatsache dass einem »HTTPS« Verbindungsaufbau meist eine DNS Abfrage vorausgeht, welche per se ja nicht »SSL« verschlüsselt wird.

Durch das Design von »SSL«, dass der »HTTP-Header« vollständig verschlüsselt wird, resultiert zB die Problematik, das Namens-basierte vHosts in Webservern nicht so ohne weiteres funktionieren bzw. nur einer pro Server IP-Adresse. Der Webserver kann den SSL Traffic keinem bestimmten vHost in Form eines »FQDNs« zuordnen, weil dieser noch im verschlüsselten »HTTP-Header« steht.