SSL oder TLS - Was ist der Unterschied ? - Was ist eingendlich HTTPS ?

und wie funktioniert das SSL (Secure Sockets Layer) Verschlüsselungsverfahren?

Für den normalen Anwender sieht beides gleich aus.
Er sieht im Browser nur das HTTPS anstelle das herkömmliche HTTP.


Ob es sich jedoch nun um eine alte SSL
oder doch um eine neue TLS Verbindung handelt?
Und was genau der Unterschied ist,
das möchte ich hier kurz und knapp erklären.

In Bezug auf HTTPS SSL und TLS ist auch das folgende Thema zu empfehlen:

Der client key exchange im SSL-Handshake

Beim herkömmlichen (alten) SSL Standardverfahren,
wird zwischen Client und Server eine HTTPS-Authentifizierung durchgeführt.
Die Letzte SSL-Version war 3.0.

Der Client fragt eine Webseite beim Server an (baut eine Verbindung auf)
und der Webserver antwortet mit seinem Zertifikat, dass auch er wirklich der Service (Server) ist.
Da bezeichnet man als Server-Authentifizierung.
Hierzu liegt beim Server ein Zertifikat zu Grunde,
welches man bei einer Zertifizierungstelle beantragt hat und auch eine zeitliche Begrenzung (Ablaufdatum) besitzt.

Jetzt muss nur noch eine verschlüsselte Datenübertragung aufgebaut werden.
Dazu werden im sogenannten Handshake-Verfahren - symentrische Sitzungsschlüssel erzeugt.

Damit nun der Client seine Sitzungschlüssel an den Server senden kann,
ohne dass dieser unterwegs abgefangen, bzw. gelesen werden kann,
(also auf einem sicherem verschlüsseltem Weg dort hin gelangt)
nutzt der Client dem öffentlichen Schlüssel vom Server.

Damit verschlüsselt der Client seinen eigenen Schlüssel
und sendet den verschlüsselten Sitzungsschlüssel an den Server.
Diesen Vorgang bezeichnet man auch als Client Key Exchange bezeichnet.

Würde jemand den verschlüsselten Sitzungschlüssel abfangen,
welcher vom Client zu Server geschickt wird,
könnte er die Nachricht nicht lesen,
da nur der zuvor authentifizierte Server, mit seinen privaten Schlüsel,
die Nachricht vom Client entschlüsseln kann.

Wenn also der Server den empfangen Sitzungsschlüssel
mit seinem privaten Schlüssel erfolgreich entschlüsselt hat,
schickt der Server eine Bestätigung zum Client,
dass er nun über den geheimen Sitzungschlüssel verfügt.

Mit diesem prozedere "SSL-Handshake", wurde nun ein verschlüsselter Verbindungsaufbau erstellt.
Alle Daten, welche vom Client oder vom Server über das HTTP-Protokoll geschickt werden,
sind nun verschlüsselt und können nur von dem jeweiligen Empfänger entschlüsselt werden.

Daher nennt sich das nun HTTPS (secured)
Oder anders gesagt ein:

  • Verschlüsselter HTTP-Response und -Request = HTTPS (HyperText Transfer Protocol Secure)

Was ist nun beim neuen TLS anders oder sichererer?

Zunächst der Name TLS (Transport Layer Security) ist neu und löst das alte SSL Verfahren ab.
Wie schon oben gesagt,
war beim SSL die letzte Version 3.0.
Beim TLS gibt es nun derzeit 1.2 (Stand August 2016)
In Fachkreisen wird daher auch das neue TLS 1.2 als SSL 3.12 bezeichnet.

Das neue TLS ist im Grundprinzip ähnlich wie das SSL.
Das TLS Handshake Protokol beeinhaltet ebenso die Authentifizierung und Key-Exchange Schritte, wie beim SSL-Handshake.
Jedoch gibt es im TLS neue Funktionen,
die einige Schwachstellen bei der SSL Verschlüsseltung abschalten sollen.

Der Sicherheitsstandard hat sich beim TLS wesentlich erhöht.
Um also das Nachfolgeprotokoll vom SSL noch sichererer zu machen,
wurden folgende Verbesserungen im TLS eingeführt:

  • Mit TLS werden mehrere Unterprotokolle zusammengefasst - Handshake-, Record-, Change-, Cipher-, Spec- und Alert-Protokoll. Da ein Angreifer alle Unterprotokolle benötigt, um wirksam anzugreifen, sind höhere Hürden gesetzt.
  • Die eingesetzten Algorithmen für die Verschlüsselung sind schwieriger zu knacken, als dies bei SSL der Fall war - bei TLS kommt der aufwendige Diffie-Hellmann Algorithmus zum Einsatz.
  • Dem Master-Secret liegt eine aufwendigere Berechnung zu Grunde, so dass dieses schwerer geknackt werden kann.
Durch die Verbesserung, bzw. Erhöhung des Sicherheitstandard beim TLS
werden zwangsläufig auch mehr Daten zwischen Client und Server ausgetauscht.
Das führt dazu,
dass die aufwendigeren Verschlüsselungsverfahren, mehr Rechenkapazität und Bandbreite benötigen.

Schwachstellen im Handshake Verfahren vom SSL/TLS mit Man-In-The-Middle Hacking Attacke

Leider gibt es auch im HTTPS wieder Schwachstellen,
die zum hacken einer vermeindlich sicheren HTTP Verbindung missbraucht werden könnten.

Wenn der Handshake beim SSL oder TLS erfolgreich war,
und die Daten nur noch verschlüsselt übertragen werden,
ist SSL und das neue TLS schon eine sichere Sache.

Besonders das TLS,
da hier höhere encryptions (Verschlüsselungen) zur Anwendung kommen,
die man kaum knacken - decryption - entschlüssen) kann.

Die Schwachstelle beim HTTPS und somit im SSL oder TLS Verfahren,
liegt schon bei der Zertifizierungsstelle.
Welche die Zertifikate für die Server bereit stellt.
Denn theoretisch kann jede Zertifizierungsstelle,
bliebige Zertifikate für "jeden beliebigen Hostnamen" ausstellen.
Also die Vertauenswürdigkeit der Zertifikate, bzw. in die Zertifizierungsstellen geht leider verloren.

Mit diesem falschen Zertifikaten kann ein so genante:
man-in-the-middle hacking attacke durchgeführt werden.

Dabei wird dem Client ein falsches Zertifikat untergejubelt.
Der Client merkt nicht,
dass das Zertifikat gefälscht war und akzeptiert dies im Handshake verfahren.

Damit kann der man-in-the-middle die Daten zwischen Client und Server abfangen / abhören und problemlos entschlüsseln,
da ja mit seinem gültigen Schlüsselzertifikat die Daten gesendet, empfangen de- und encrypted werden.

Um diese "man-in-the-middle hacking attacken" zu verhindern,
werden im TLS neue Methoden zur Verifizierung implementiert,
die sicherstellen sollen, dass die Zertifikate auch wirklich vertrauensvoll sind.


Comments

No comments yet.

Add Comment

* Required information
(never displayed)
 
Bold Italic Underline Strike Superscript Subscript Code PHP Quote Line Bullet Numeric Link Email Image Video
 
Smile Sad Huh Laugh Mad Tongue Crying Grin Wink Scared Cool Sleep Blush Unsure Shocked
 
1000
What is the day after Friday?
 
Enter answer:
Captcha
Refresh
 
Enter code:
 
Notify me of new comments via email.
 
Remember my form inputs on this computer.
 
I have read and understand the privacy policy. *
 
I have read and agree to the terms and conditions. *
 
 
Powered by Commentics