Diskussion:Transport Layer Security/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Transport Layer Security/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Transport_Layer_Security/Archiv#Thema_1

TLS

So wie ich diesen Artikel jetzt allerdings verstehe, kann ich mit TLS meine Mail nur auf dem Weg zwischen mir und Mail-Server verschlüsseln - ab dann habe ich keine möglichkeit mehr über die verschlüsselung, was damit prinzipiell heißt, dass ab hier die mail wieder unverschlüsselt gesendet wird (und damit tls recht unsinnig erscheinen lässt).

außerdem: woher bezieht mein internet-e-mail-programm die benötigte signatur, und den benötigten öffentlichen schlüssel des smtp-servers? geschieht das automatisch, ohne dass ich was mitbekomme? es wäre schön, wenn jemand also auch den ablauf des e-mail-versandes mal in einzelnen schritten erklären könnte. danke, --Abdull 18:55, 25. Jan 2005 (CET)

TLS hat nicht direkt mit Mails zu tun, es ist allgemein eine Methode, wie man eine Punkt zu Punkt-Verbindung via TCP absichern kann. Das kann jetzt zwischen Browser und Webserver oder zwischen zwei Mailservern erfolgen, für TLS selbst ist das egal. Wenn Du Mails verschlüsseln willst, verwende besser PGP oder S/MIME, wenn Du wissen wills, wie Mails versendet werden, schau' unter SMTP. --Euripides 18:53, 16. Feb 2005 (CET)

der secure tunnel mit ssl bringt dir bei unverschluesselten mails dann was, wenn du z.b. ueber ein nichtvertrauenswuerdiges netz an das internet angeschlossen bist (z.b. wlan/lan beim freund, oder bei einem kongress oder im hotel).

TLS und SSH

habe folgenden Absatz aus dem Artikel entfernt: Secure Shell (SSH) und TLS unterschieden sich von den theoritischen Fähigkeiten nicht groß. TLS wirde hauptsächlich für das HTTP Protokoll entwickelt und SSH hauptsächlich für telnet und FTP. Theoretisch können beide Protokolle auch die Funktion des anderen Übernehemen.

Grund: Keine Ahnung, ob TSL (im Besonderen SSL) ursprünglich für HTTP entwickelt wurde, ist aber gut möglich. SSH wurde aber nicht für telnet und ftp entwickelt, sondern höchsten als Ersatz. Das heisst SSH befindet sich auf der selben Ebene (nämlich der Anwendungsschicht) wie telnet und ftp. Es ist also primär eine Anwendung, die die Sicherung der Übertragung selbst übernimmt. Zusätzlich bietet SSH noch die Möglichkeit, TCP-Verbindungen verschlüsselt zu tunneln, bietet also einen Dienst der Transportschicht an (was die Sache wieder schwammiger macht). SSH könnte damit theoretisch einen Teil der SSL-Funktionalität übernehmen.

SSL hingegen ist eine reine Erweiterung der Transportschicht. Es kann nicht mehr als einen gesicherten und authentifizierten Stream zur Verfügung zu stellen. Es hat keine Filetransfer- oder Terminalfunktionalität, kann also die primären Aufgaben von SSH nicht übernehmen.

Ein weiterer Unterschied ist, dass SSL die Verschlüsselung beliebiger Verbindungen erlaubt, ohne dass sich die Teilnehmer vorher kennen. SSH setzt einen Account auf dem Zielrechner voraus. --Semper 00:10, 12. Mai 2006 (CEST)

Unter [1] ist der Unterschied und die Gemeinsamkeiten der beiden Protokolle erklärt. Ich finde ein Absatz über dieses Thema sollte in den Artikel. --213.39.152.52 17:05, 13. Mai 2006 (CEST)

Verständlichkeit

Hallo, wahrscheinlich ist der Artikel ganz prima, nur verstehe ich als Laie nicht wirklich, was denn nun SSL ist und wie es funktioniert. Ich steige bei den ersten Zeilen schon aus, z. B. bei dem Begriff "Transportschicht". Bisher bleibt als Aha-Effekt nur übrig, daß offenbar etwas verschlüsselt wird und daß es noch ein paar weitere Dinge gibt, die die Verschlüsselung noch sicherer machen. Das wußte ich vorher allerdings auch schon. Ich habe den Artikel ja angesteuert, um zu verstehen, wie es funtioniert. Kann sich nicht jemand erbarmen und vielleicht etwas oben im Artikel mit ganz einfachen Begriffen erklären, wie SSL funktioniert, so daß auch ein Laie begreift, was das ist? Grüße, Ludwig 11:52, 19. Mai 2006 (CEST)195.93.60.34

--217.210.0.63 10:56, 31. Aug 2006 (CEST): Ich kann mich dem nur anschließen. Zwar kann ich mit dem OSI-Modell etwas anfangen und weiss auch, was der Transport-Layer ist, doch nirgendwo wird beschrieben, was eigentlich ein pre-master-secret ist. Es fehlt eine kurze Zusammenfassung auf niedrigerem Niveau, das einfach nur beschreibt, wie SSL im Groben funktioniert.

--Tiggar 19:36, 3. Feb. 2007 (CET): Für den Otto-Normal-Verbraucher ist dieser Artikel tatsächlich nicht sonderlich hilfreich. In diesem Fall sollte man den ersten Absatz in der Einführung so gestalten, dass der Verbraucher umfassend informiert ist, jedoch nicht mit Details überhäuft wird.

Ich: Sehe ich genauso. Mir fehlt vollkommen der Teil "Einsatz". Nämlich warum SSL eigentlich eingesetzt wird (Übertragung sensibler Daten, wie Login oder Kreditkarte) und gegen was die SSL Verschlüsselung schützt. (z.B. bei Nutzern, die per WLAN Internetseiten besuchen)

User: Schade, dass auf diese Beiträge von 2006 bis 2007 keine Überarbeitung des Artikels erfolgte. Für mich als "normalen Computer-User" ist es so, dass der Text ab der ersten Zeile soviele Fachbegriffe enthält, dass ich nicht verstehe, was TLS/SSL eigentlich macht. Interessant wären für mich z.B. die Aspekte: 1. Wozu ist TLS/SSl gut? 2. Wie funktioniert es grob. 3. Welche Hardware wird benötigt? 4. Welche Software wird benötigt? 5. Welche Zertifikate sind nötig (für den Server? für die Domain? Für die jeweilige Anwendung?) 6. Wie funktioniert die Verwaltung dieser Zertifikate? Gibt es eine zentrale Stelle? Gibt es pro Land eine Stelle? Wenn ja wo? Und wie finanziert? Kosten die Zertifikate etwas? Nur einmal? Jedes Jahr? Pro Datenmenge? Oder läuft die Finanzierung über die Kosten für die Software? 7. sind Zertifikate zeitlich befristet? Falls ja, ist die Übertragung unsicher, wenn das Zertifikat abglaufen ist?

Habe gerade gesehen, dass ein Teil dieser Informationen im Artikel zu HTTPS zu finden ist. Es wäre daher sehr hilfreich, im Artikel zu TLS auf den Artikel zu HTTPS zu verweisen.

--80.150.2.134 16:17, 20. Nov. 2009 (CET)

Meiner Ansicht nach betrifft das vor allem das Kapitel "Funktionsweise". In diesem Kapitel werden irgendwelche abstrakten Voraussetzungen zusammengestellt, mit denen wahrscheinlich SSL funktioniert. Stattdessen wünschte man sich eine kurze Erklärung, was von wem verschlüsselt wird, und warum es denn überhaupt wieder jemand lesen kann. Dieses Kapitel sollte meiner Ansicht nach als unzureichend markiert werden. Hoffentlich findet sich jemand, der das verstanden hat und Lust hat, es verständlich zu vermitteln. -- Chactory (Diskussion) 15:38, 29. Apr. 2012 (CEST)

ich habe zu dem abschnitt eine hoffentlich verstaendlichere einleitung geschrieben. --Mario d 16:06, 29. Apr. 2012 (CEST)

SSL als Freibrief für privates Surfen am Arbeitsplatz?

Hallo, ich habe gehört, dass es bei SSL-verschlüsselten Verbindungen für ein Rechenzentrum nicht möglich ist, zu überwachen, was der User tut. Folgerung: somit könne man ja über https:// seiten gefahrlos surfen!?

Jetzt lese ich da aber, dass SSL auf TCP/IP aufbaut, d.h. jedes Rechenzentrum kann ja dann imho problemlos überwachen, welche Nutzer z.B. zu https://web.de eine Verbindung aufgebaut haben. Somit weiss das RZ, wer privat webmail nutzt, aber nicht, was er genau schreibt. Ist diese Folgerung richtig?? Danke & Gruß Pprian 16:14, 29. Jun 2006 (CEST)

Stimmt, man kann Verbindungen bis zum Server verfolgen, aber keine Inhalte lesen. Ob also jemand wirklich Webmail nutzt, oder sich nur die web.de-Startseine ansieht, kann man eigentlich nicht unterscheiden. --Euripides 08:46, 5. Sep 2006 (CEST)

und Informationen über https-Verbindungen landen normalerweise auch nicht im Browser-Cache --Kwoid (Benutzername geändert, siehe Spezial:Log/renameuser) 18:38, 10. Sep 2006 (CEST)

Mit speziellen SSL-Proxy-Servern, die sich zwischen Endbenutzer und Server klemmen, ist es gerade für Firmen ein Leichtes den SSL-Traffic eines Mitarbeiters zu kontrollieren, als ob er unverschlüsselt wäre. --Nomori 20:50, 10. Sep 2006 (CEST)

Google mal nach 'Tommy SSL Proxy' --Nomori 20:53, 10. Sep 2006 (CEST)

Ich habe einmal danach gegoogelt und es wird offenbar eingesetzt, um Firmennetze vor Virusinfektionen zu bewahren. Dies ist jedoch m.E. nur dann möglich, wenn auf dem Rechner des entsprechenden Mitarbeiters bereits eine Software installiert ist, die immer zuerst eine Verbindung zum Tommy SSL Proxy herstellt, bevor die Verbindung weiter ins Internet geleitet wird. Siehe die Grafik auf der ersten Seite dieses Dokuments.

In erster Linie scheint es also eine Art „Versicherung“ gegen die Leichtgläubigkeit mancher nicht computer- und internetaffiner Mitarbeiter zu sein, dass man sich mit einer SSL-Verbindung keine Viren mehr einfangen kann, was natürlich völliger Schwachsinn ist, da Viren ja auch verschlüsselt versendet werden können; nur dann erkennt sie der Virenscanner nicht mehr. Deshalb der Tommy SSL Proxy.--129.187.209.166 14:35, 25. Jul. 2013 (CEST)

Weisst du welche Programme auf deiner Firma, im Internetcaffee oder sonstwo installiert sind, die eh die Benutzereingaben aufzeichnen? Nein? Aha... Warum überall gesagt wird, nimm HTTPS und mach dir keine Gedanken mehr, ist mir unverständlich. --Lastwebpage 10:03, 19. Feb. 2012 (CET)

SSL im TCP/IP-Schichtenmodell

Läuft SSL nicht zwischen Anwendung und Transport? - dauton, 16. November 2006

Das ist richtig so. Und zwar befindet sich SSL/TLS auf dem Session Layer. Die grafische Darstellung des Protokoll-Stacks oben rechts auf der Seite berücksichtigt diesen Teil des ISO/OSI Schichtenmodells aus irgend einem Grund nicht. --Tiggar 19:31, 3. Feb. 2007 (CET)

Der Teil des ISO/OSI-Schichtenmodells wird nicht berücksichtigt, weil es sich bei der Darstellung um das TCP/IP-Referenzmodell und eben nicht um das OSI-Schichtenmodell handelt. Allerdings heißt die Netzwerkschicht dort Internetschicht. Vielleicht sollte man das ändern. Markus -voks- Henn 23:47, 26. Jun. 2007 (CEST)

Müsste auf der Anwendungsschicht nicht HTTP (statt HTTPS) stehen, wenn SSL als eigene Schicht darunter liegt? - hema, 13. Juni 2007

Doch, sehe ich genauso, sonst wäre es ja doppelt gemoppelt. Aber vielleicht denken dann manche "und wo ist jetzt HTTPS?". Markus -voks- Henn 23:47, 26. Jun. 2007 (CEST)

Wichtig ist doch die Korrektheit. Zumal da HTTPS und IMAP (ohne S) steht. Deinem Argument zufolge müsste dann wenigstens auch IMAPS da stehen. Ich habe das auf HTTP korrigiert, aber verlinkt auf HTTPS/IMAPS. Ist auf den ersten Blick vielleicht wiki-untypisch, dafür aber inhaltlich und logisch absolut richtig, da man in der Grafik nicht das Wort isoliert betrachten darf. Ist in den Artikeln ja dann auch erklärt. Ich habe unter Funktionen versucht das in zwei Sätzen zu erklären. --Merlissimo 14:39, 10. Mai 2008 (CEST)

SSL hat nichts mit dem OSI-Modell zu tun, bitte das TCP/IP Modell verwenden 5.7.09 Wolfgang (nicht signierter Beitrag von 84.160.221.68 (Diskussion | Beiträge) 12:21, 5. Jul 2009 (CEST))

Auf TCP/IP-Referenzmodell steht, TLS wäre eine Erweiterung von TCP/IP und damit auf der TCP-Schicht. Hier steht, es liege über TCP/IP. Was stimmt denn nun? --Benutzer:Nixnick 12:21, 30. November 2010 (CEST)

TLS liegt auf jeden Fall ueber TCP. Eigentlich zieht der Standard zwischen der Transportschicht und der Anwendungsschicht eine neue Schicht ein, die "TLS record layer". Ich weiss nicht, warum man diese neue Schicht entweder der Transport- oder der Anwendungsschicht zuschlagen will, wohl um das Ganze um jeden Preis in ein Modell zu quetschen. --Mario d 22:42, 30. Nov. 2010 (CET)

Messengerdienste

Mir fehlt hier irgendwie ein deutlicher Hinweis das SSL/TSL NICHT sicher ist. Viele User von Messengerdiensten, seien es jetzt klassische wie MSN/ICQ oder aber auch Jabber/IRC meinen mit SSL eine zusätzlich Sicherheit zu erhalten. Da der jeweilige Server die übertragenen Daten aber eh wieder in "plain text" vorliegen hat, ist der "Sicherheitsgewinn" aus meiner Sicht eher minimal bis gar nicht vorhanden, besonders bei Jabber und IRC, da hier ja jeder, also auch derjenige der evtl. Daten ausspionieren will, einen eigenen Server einrichten kann. --Lastwebpage 13:17, 30. Jun. 2007 (CEST)

Naja, eine Ende-zu-Ende-Verschlüsselung ersetzt es nicht. Aber meine Zugangsdaten möchte ich nicht unverschlüsselt übertragen. Und wenn ich dem Serverbetreiber trauen kann (vielleicht, weil ich es selbst bin), dann ist das mitunter gar nicht so sehr problematisch. Ein Sicherheitsgewinn ist es allemal. In den meisten Fällen ist aber zusätzlich (!) eine Ende-zu-Ende-Verschlüsselung angebracht, ja. Im Falle meines Passworts ist ja der Server das andere Ende und dafür hat man eben SSL/TLS. – 91.4.12.74 19:05, 19. Okt. 2007 (CEST)

Man-in-the-middle-Angriff

In dem Abschnitt "SSL in der Praxis" steht zu dem "Man-in-the-middle"-Angriff folgendes: "Ist der Man-In-The-Middle vor der Übergabe des Schlüssels aktiv, kann er mit beiden Seiten den Schlüssel tauschen und so den gesamten Datenverkehr im Klartext mitschneiden." Das ist so meineswissens aber nicht richtig, denn es wird lediglich der Public-Key übertragen, den Private-Key kennt aber nur der Server. Deshalb ist es bei dem angegebenen Szenario zwar möglich, alles was vom Server Richtung Client geht im Klartext mitzulesen, was vom Client zum Server geht bleibt aber verschlüsselt, da sich dies nur mit dem Private-Key des Servers (der nie an irgendjemanden übertragen wird) entschlüsseln lässt. --TobYBrain 12:37, 4. Apr. 2009 (CEST)

Das sehe ich auch so. Vielleicht ist das richtige gemeint aber "schwammig" ausgedrueckt. Ich bin fuer eine Klarstellung / Ueberarbeitung der Autoren oder eine Entfernung des Abschnitts. Traute Meyer 18:24, 9. Apr. 2009 (CEST)

Hier ist ein Fall gemeint, wo der MITM eigene Schüssel einführt. D.h. der Client verschlüsselt mit dem Öffentlichen-Schlüssel, den der MITM vorher erstellt und dem Client mitgeteilt hat. Der MITM kann somit die Nachricht entschlüsselt, lesen und schickt sie anschließend mit den richtigen Serverzertifikat verschlüsselt weiter. (und analog in Gegenrichtung). Deshalb sollten die Serverzertifikate von einer vertrauenswürdigen dritten Partei unterschrieben sein, damit der Client verifizieren kann, dass er wirklich den Schlüssel von Originalserver erhalten hat. -- Merlissimo 19:27, 9. Apr. 2009 (CEST)

Wer zu einer MITM (= sich in die Verbindung hängen) fähig ist, der kann auch eine der unzähligen "vertrauenwürdigen" CAs dazu bringen, ihm auf Zuruf Wunschzertifikate für Alice und Bob zu erstellen. Alice und Bob können sich dagegen nur schützen, indem sie ihre public keys auf sicheren Kanälen "pre-sharen". Insofern gibt der Absatz

SSL ist ohne eine zertifikatsbasierte Authentifizierung problematisch, wenn ein Man-In-The-Middle-Angriff erfolgt: Ist der Man-In-The-Middle vor der Übergabe des Schlüssels aktiv, kann er mit beiden Seiten den Schlüssel tauschen und so den gesamten Datenverkehr im Klartext mitschneiden. Allerdings wird seit Anfang 2010 die Sicherheit von SSL im Zusammenhang von HTTPS mit Hinweis gerade auf die möglicherweise mangelnde Vertrauenswürdigkeit der zertifizierenden Stellen (CAs) angezweifelt.[4][5][6][7]

den Sachstand nicht richtig wider. Wenn die Leitung nur angezapft aber nicht unterbrochen wird, sind überhaupt keine Zertifikate erforderlich (Diffie-Hellman-Schlüsselaustausch). Wird sie unterbrochen (MITM) darf nicht auch noch eine einzige unsichere von Alice und Bob blind vertraute CA hinzutreten, die entsprechende Wunschzertifikate ausstellt.--87.183.156.108 09:23, 28. Jan. 2011 (CET)

Das habe vielleicht noch nicht klar verstanden. Der MITM Angriff kann zwar nicht verhindert werden, aber er ist doch leicht festzustellen: Nachdem die Leitung steht (d.h. die Schlüssel ausgetauscht wurden) müssen sich die Kommunikationspartner nur noch die Hashcodes ihrer public Keys zusenden und mit den Hashcodes der verwendeten public Keys vergleichen. Wenn jemand in der Mitte sitzt hat, er jetzt ein kleines Problem. Er müsste erkennen, dass diese Nachricht jetzt mit den Hashcodes der zwischengeschalteten Spiegelkeys zu ersetzen ist (was man technisch fast bis zur Unmöglichkeit verkomplizieren kann). Andernfalls sehen die Kommunikationspartner, dass die Hashcodes ihrer public Keys nicht übereinstimmen und wissen von dem MITM Angriff, oder? (nicht signierter Beitrag von 176.198.133.69 (Diskussion) 11:20, 2. Jun. 2012 (CEST))

ich sehe nicht, wo fuer den angreifer das problem liegen soll, beiden das zu schicken, was sie zu sehen erwarten. er kennt ja die beiden schluessel, die er mit den beiden ausgetauscht hat, kann also die nachrichten beliebig manipulieren und die hashwerte durch die seiner eigenen public keys ersetzen. --Mario d 12:13, 2. Jun. 2012 (CEST)

Wie ich schon sagte, man kann diese Manipulation ziemlich/beliebig schwer machen. Ein Weg wäre z.B. den Hashcode des public Key mit einem Timeserver (die gibt es rund um die Welt und können nicht alle kontrolliert werden) abzustempeln und dann eine definierte Zeit (die ebenfalls übermittelt wird, aber vorher nicht bekannt war) zu warten. Und nu? Wo soll der MITM den Stempel von vor z.B. 5 Minuten für "seinen" Key jetzt so schnell herbekommen?

Das wäre nur eine Möglichkeit. Der Phantasie sind da keine Grenzen gesetzt. (nicht signierter Beitrag von 176.198.133.69 (Diskussion) 13:34, 2. Jun. 2012 (CEST))

da der angreifer die kommunikation kontrolliert, gibt es auch keine moeglichkeit, diese definierte zeit sicher zu uebermitteln. nach moeglichkeit sollte phantasie beim artikelschreiben auch aussen vor bleiben und nur belegbare informationen verwendet werden. --Mario d 13:49, 2. Jun. 2012 (CEST)

Sie haben nicht genau gelesen: Steht da, dass die Zeit, die zu Vergehen hat, als Challenge über die Leitung geht? Nein, da steht, dass die Zeit eben nicht bekannt ist. Weder der Zeitpunkt zu dem der Hashcode vom Timeserver gestempelt wird noch die Zeit, die bis zum Senden gewartet wird, sind dem MITM bekannt. Worauf es ankommt ist, dass ein Element, das als Infrastruktur im Netz vorhanden ist und über welches der MITM nicht verfügt (in diesem Fall der Timeserver) die Spiegelung der Zertifikate enttarnt.

Das wäre ebenfalls möglich, wenn die public Keys irgendwo als Datenbank (oder besser mehreren) publiziert wären. PGP macht das seit Jahren so. Wie gesagt, es gibt dazu Massen publizierter und praktizierter Ansätze. Streichen Sie das mit der Phantasie. Für mich stellt sich einfach die Frage: Ist es nur Dummheit oder gibt es "handfeste" Gründe, diesen Angriff zuzulassen?(nicht signierter Beitrag von 176.198.133.69 (Diskussion) 14:42, 2. Jun. 2012 (CEST))

zitat: "eine definierte Zeit (die ebenfalls übermittelt wird". geht es hier um ein konkretes problem mit dem artikel? falls nicht, empfehle ich, die frage in einem darauf spezialisierten forum zu stellen. nebenbei: in der wikipedia ist es ueblich, seine beitraege zu signieren: Hilfe:Signatur. --Mario d 14:59, 2. Jun. 2012 (CEST)

Ja, sicher habe ich ein Problem mit dem Artikel. Ich frage mich, wieso dort leichthin

zitat: "SSL ist ohne eine zertifikatsbasierte Authentifizierung problematisch, wenn ein Man-In-The-Middle-Angriff erfolgt"

steht. Ich würde es als Schmiererei betrachten, Passagen in einem Artikel erst zu ändern, um sie dann zu diskutieren. Es geht zunächst darum zu klären, ob ich ein Statement überhaupt richtig verstanden habe, bevor ich es "korrigiere" und ggf. mit entsprechenden Quellen belege.

Besser wäre meiner Meinung: "SSL ist ohne gesicherte, vertrauenswürdige Schlüsselübermittlung bzw. -verifikation problematisch, wenn ein Man-In-The-Middle-Angriff erfolgt"

Vielen Dank, dass Sie sich die Zeit und die Geduld genommen haben meine Bedenken zu prüfen. Vollständig überzeugt bin ich noch nicht, dass SSL/TSL vollständig interessenfrei entwickelt wurde und wird, aber diese Diskussion gehört nicht hier her. (nicht signierter Beitrag von 176.198.133.69 (Diskussion) 16:29, 2. Jun. 2012 (CEST))

wenn ich richtig verstehe, geht es um das wort "zertifikatsbasiert"? der satz ist in der tat missverstaendlich. jede form der schluesselauthentifizierung ist ausreichend, aber die einzige, die bei TLS verwendet wird, ist eben zertifikatsbasiert. grundsaetzlich gibt es zwei moeglichkeiten der authentifizierung: kommunikation ueber einen zweiten, authentifizierten, kanal wie bspw. beim mTAN-verfahren, oder durch bestaetigung einer vertrauenswuerdigen dritten partei wie hier bei der PKI. fuer TLS ist aus verschiedenen gruenden die zweite methode praktikabler. ob das derzeitige verfahren ausreichend ist, wird, wie im artikel erwaehnt, gerade diskutiert. bei wikipedia darf aber gerne jeder mitarbeiten und editieren, er muss nur akzeptieren, dass auch seine version wiederum editiert wird. inhaltliche konflikte sollten dann auf den diskussionsseiten geloest werden. --Mario d 17:17, 2. Jun. 2012 (CEST)

Fast: Ich störe mich eigentlich nicht an zertifikatsbasiert. Zertifikate sind ein Teil der TLS Infrastruktur und sie sind hilfreich. Aber wer blind auf Zertifikate vertraut, hat das eigentliche Problem nicht verstanden: Die Verifikation des public Key über einen anderen Kommunikationskanal oder ein weiteres Element, das der MITM nicht kontrolliert. Mich wundert bis heute, dass z.B. Banken ihr öffentliches Zertifikat nicht als Annex zum Impressum veröffentlichen.

Vielleicht: "SSL ist ohne eine zertifikatsbasierte Authentifizierung problematisch, wenn ein Man-In-The-Middle-Angriff erfolgt. Effektiven Schutz gegen diesen Angriff erhält man nur, wenn die verwendeten Zertifikate auf einem anderen Weg geprüft und verifiziert werden."(nicht signierter Beitrag von 176.198.133.69 (Diskussion) 18:40, 2. Jun. 2012 (CEST))

dazu muesste man evtl. mehr schreiben. bei einem normalen MITM sind zertifikate ja ausreichend, weil davon ausgegangen wird, dass die CAs vertrauenswuerdig sind und nicht kompromittiert werden. die probleme treten ja erst auf wenn der angreifer beim MITM gleichzeitig noch die CA kompromittiert. --Mario d 18:52, 2. Jun. 2012 (CEST)

SSL Record Protocol - hier: Authentizität

Im Abschnitt wird der Einsatz kryptografischer Hashes beschrieben mit Sicherung der Integrität und Sicherung der Authentizität.

Nach meinem Verständnis ist die Formulierung zumindest unglücklich: zum Nachweis der Authentizität ist der Einsatz kryptographischer Hashes alleine nicht ausreichend. S. dazu die Wikipedia-Artikel zur Authentizität bzw. zur Digitalen Signatur.

--82.139.211.41 20:46, 10. Apr. 2009 (CEST)

Ich ziehe meinen Einwand beschämt zurück nach RFC-Studium (RFC 4346 - Kapitel 6). Es handelt sich um MAC-Algorithmen zur Sicherung der Nachrichten-Authentizität (und Integrität). Hoffentlich habe ich keine Verwirrung gestiftet...

-- 82.139.211.41 21:01, 10. Apr. 2009 (CEST)

Das Bild ist nicht korrekt?

Im Bild fehlt doch das Signieren vom gesamten Traffic seitens des Servers. Das muss in der 4. Phase mit dem Private Key des Servers geschehen. So wird dieser im Bild nie benutzt. (nicht signierter Beitrag von Stasik (Diskussion | Beiträge) 20:30, 15. Apr. 2009 (CEST))

Außerdem passiert der Schritt "PMS encrypted with server puplic key" vor dem Schritt "hash over all previous messages (signed with client private key)" --Roidal (Diskussion) 11:12, 2. Mär. 2013 (CET)

das wurde vor 3 jahren bereits auf der disk des bilds bemaengelt: commons:File talk:SSL handshake with two way authentication with certificates.svg. da wird sich nichts aendern, es muss ein neues bild her. in der TLS kat auf commons habe ich kein geeignetes gefunden. ich koennte eins erstellen, aber das wird nicht so huebsch wie dieses. --Mario d 20:15, 3. Mär. 2013 (CET)

Wenn man das aktuelle svg bearbeiten würde (die Elemente einfach nur verschieben) wäre das OK? Oder gibt es da Lizenztechnisch probleme? --Roidal (Diskussion) 19:37, 4. Mär. 2013 (CET)

kannst du gerne machen, die lizenz ist ja auf der dateiseite angegeben. --Mario d 21:08, 4. Mär. 2013 (CET)

Explizite / Implizite Verschlüsselung

Im Artikel sollte mal noch erklärt werden, was der Unterschied ist zwischen expliziter und impliziter SSL- bzw. TLS-Verschlüsselung. FTP-Clients wie z. B. FileZilla oder WinSCP unterscheiden nämlich zwischen expliziter und impliziter Verschlüsselung.--Stegosaurus Rex 18:26, 20. Dez. 2010 (CET)

Das sind zwei Arten von FTPS, TLS zu verwenden. Das sollte dann auch unter FTPS erklaert werden, wie z.B. in der englischen WP. --Mario d 16:36, 28. Jan. 2011 (CET)

Keine Hinweise auf praktische Umsetzung?

Ich vermisse ein "Kochrezept", was ein Betreiber einer Internetseite praktisch machen muss, um eine SSL/TLS-Verschlüsselung einzuführen. - Weder im Artikel, noch bei den Links und auch nicht in der Diskussion ist darüber etwas zu erfahren. (nicht signierter Beitrag von 217.224.65.186 (Diskussion) 07:15, 28. Nov. 2011 (CET))

das liegt daran, dass WP eine enzyklopaedie ist, kein ratgeber. hilfe, wie du sie suchst, findest du ueber die suchmaschine deiner wahl oder in einer buecherei. --Mario d 11:13, 28. Nov. 2011 (CET)

Neben Nachrichten-Integrität und Authentizität fehlt die VERTRAULICHKEIT

Meines Erachtens fehlt im ersten Abschnitt "Funktionsweise" die Vertraulichkeit (im letzten Satz).

"Dieser Schlüssel wird in der Folge benutzt um alle Nachrichten der Verbindung mit einem symmetrischen Verschlüsselungsverfahren zu verschlüsseln und zum Schutz von Nachrichten-Integrität und Authentizität durch einen Message Authentication Code abzusichern." (nicht signierter Beitrag von 80.143.23.102 (Diskussion) 18:32, 15. Mai 2012 (CEST))

der satz erwaehnt doch, dass verschluesselt wird. --Mario d 23:00, 15. Mai 2012 (CEST)

Merkwürdig

Der Artikel kombiniert SSL mit TLS, erwähnt nicht die Unterschiede, nicht die Geschichte, noch die unterschiedlichen Versionen. Dazu interpret. er den Standard, welche Version? SSL wurde bei Netscape entwickelt und war nur in deren Produkten zu finden. Ziel war es die Authentizität des Server(Bank, Online-Shop, etc.) zu sichern. Die ersten Versionen boten die Möglichkeit des unverschlüsselten Verkehrs, Vertraulichkeit war also nicht gegeben. TLS ist eine Standardisierung eines Protokolls, größtenteils identisch mit SSL. Der Server kann, muss aber nicht, darauf bestehen, dass auch der Client sich authorisieren muss. SSL listet unterstützte Verschlüsselungen auf, der Client kann sich davon eine aussuchen. Bei diesen Artikel bekommt man das Gefühl, viele Autoren und wenig fundierte Quellen. Wer mehr darüber wissen will, Network-Security von Günter Schäfer oder mal ins RFC bzw. SSL 1.0 schauen.--95.91.62.194 09:35, 28. Mai 2012 (CEST) Ach noch was, der Aufbau ist auch so eine Sache, die mich stört. Wieso ist die Geschichte der Protokolle am Ende und in Stichwortform geschrieben?--95.91.62.194 09:40, 28. Mai 2012 (CEST)

ich sehe dafuer keinen grund, du kannst es gerne aendern. --Mario d 10:05, 28. Mai 2012 (CEST)

HTTPS-Verbindung auch bei Zertifikatfehler verschlüsselt?

Was mir nicht klar ist:

Wenn der Browser eine Zertifikat-Fehlermeldung ausspuckt, man diese aber ignoriert und weiterklickt, ist die aufgerufene Seite dann (möglicherweise) unverschlüsselt?

Oder ist jede im URL mit "https" beginnende Seite in jedem Fall verschlüsselt, und die Fehlermeldung bedeutet nur, dass man keine Sicherheit über die Identität des Servers hat? -84.155.102.74 12:53, 29. Aug. 2012 (CEST)

das kommt auf die fehlermeldung an. wenn dort nur steht, dass die zertifikatskette nicht bis zu einer bekannten root-CA zurueckverfolgt wurden konnte, dann ist die verbindung trotzdem verschluesselt. --Mario d 11:17, 31. Aug. 2012 (CEST)

Secure Server Line

Secure Server Line ist eine Weiterleitung auf diesen Artikel. Wird die Abkürzung SSL neben Secure Sockets Layer auch für Secure Server Line verwendet? --Fomafix (Diskussion) 13:56, 7. Feb. 2013 (CET)

das habe ich noch nie gehoert, in der en.WP gibt es das nicht und google scheint da auch nichts zu finden. ich bin fuer loeschen. --Mario d 23:00, 7. Feb. 2013 (CET)

Ich habe die Weiterleitung löschen lassen. --Fomafix (Diskussion) 12:38, 25. Mär. 2013 (CET)

Site Seals

Wer spricht denn davon, dass Trustcenter "nutzlose Site Seals" verkaufen? Die verkaufen mir doch ein Zertifikat, was dank der Bemühungen des Anbieters auf möglichst vielen Plattformen (Browsern) läuft und keine Site Seals, die sind doch nur eine Art Dreingabe. Also ich finde diese Aussage einfach schlicht falsch. (nicht signierter Beitrag von 84.176.249.242 (Diskussion) 19:57, 12. Apr. 2007 (CEST))

Ich würde sogar soweit gehen und sagen das der ganze Satz "Zusammen mit SSL-Zertifikaten versuchen die Trust Center häufig, nutzlose Site Seals zu verkaufen.", was ist bitteschön ein "Site Seals"? Also entweder man schreibt auf der Seite "Site Seals" auch wirklich was hin; da wurden nur mehrfach Beiträge gelöscht, z.Zt. befindet sich dort kein Artikel; oder man lässt den Link ganz weg. --Lastwebpage 12:59, 30. Jun. 2007 (CEST)

Länge der Random Zahl im Client Hello

Laut RFC4346 und diversen Büchern die ich darüber gelesen habe, ist die Random Zahl nicht 32Bit lang, sondern ist eine Datenstruktur aus einem 32 Bit langem Timestamp und einer 28 Byte großen Zufallszahl.

struct {
  uint32 gmt_unix_time;
  opaque random_bytes[28];
} Random;

Client Hello auf RFC

(nicht signierter Beitrag von 92.228.67.215 (Diskussion) 10:24, 21. Mai 2008 (CEST))

Ist mir soeben auch aufgefallen; hab's in 32 Byte abgeaendert. AmiUhle 12:44, 14. Okt. 2008 (CEST)

4 Phasen

Bild:SSL handshake with two way authentication with certificates.svg Wenn ich mich nicht irre, besteht der Handshake aus vier Phasen. Am rechten Rand des Bildes steht aber vier mal "Phase 1". Da ist doch ein Fehler in der Grafik. MfG Raffy (nicht signierter Beitrag von 217.86.10.95 (Diskussion) 00:18, 13. Okt. 2008 (CEST))

Vollkommen richtig das ist mir auch gerade aufgefallen als ich das Thema nochmals für meine Prüfung durchgegangen bin. Es müsste bei der 2. Klammer Phase 2 bei der 3. Phase 3 und bei der 4. Phase 4 heissen.

Gruss Jan (nicht signierter Beitrag von 84.147.80.176 (Diskussion) 19:54, 24. Nov. 2008 (CET))

SSL kaputt?

Bei Golem heisst es:

"Für das kommende Jahr ist einiges zu befürchten, da grundlegende Infrastruktursysteme als kaputt eingestuft werden können, wie GSM und die Datenverbrechen rund um SSL-Zertifikate, vor denen lange gewarnt wurde. Dass SSL wirklich kaputt ist, erkannten viele erst, nachdem der Iran die Schwachstellen des Systems ausgenutzt hatte. Die Hacker nennen das "Broken by Design" und fragen sich, welche Infrastruktur als nächstes kaputt gehen wird."

http://www.golem.de/1112/88727-2.html (nicht signierter Beitrag von 188.45.191.205 (Diskussion) 07:40, 1. Jan. 2012 (CET))

"So ist in 2011 bekannt geworden, dass ein offenbar iranischer Hacker in eine holländische Registratur eingedrungen ist und z.B. für GoogleMail falsche Zertifikate ausgestellt hat. Das hat vermutlich unter anderem dazu geführt, dass die iranische Regierung alle Kommunikation von Regimegegnern über GoogleMail selbst dann mitlesen konnte, wenn die Nutzer Berschlüsselung (hier.: https) gewählt hatten. Kurz: Ein Skandal, ein GAU.

Natürlich hat mal alle Zertifikate dieser Firma sofort für ungültig erklärt da man nicht weiss welche Anbieter noch korrumpiert sind. Auf Dauer ist die Beibehaltung des alten Systems jedoch keine Lösung. Es gäbe technisch bessere, dezentrale Lösungen aber deren Umsetzung wird noch dauern. Und es gibt viele Regierungen, die an so viel Sicherheit gar kein Interesse haben!"

http://dellekom.de/info/ssl (nicht signierter Beitrag von 188.45.191.205 (Diskussion) 07:53, 1. Jan. 2012 (CET))

ich geb mal als Gegenmeinung folgendes dazu:

http://serpentsembrace.wordpress.com/2011/04/10/tutor-ssl-im-visier-nicht-immer-liegt-es-am-protokoll/ (nicht signierter Beitrag von 188.45.191.205 (Diskussion) 07:45, 1. Jan. 2012 (CET))

sowas in der art kann man sicherlich noch in den artikel einbauen. --Mario d 16:53, 3. Jan. 2012 (CET)

Kapitel zu Heartbleed-Erweiterung fehlt (für Korrektur der "Weiterleitung Heartbleed auf OpenSSL")

Aktuell gibt es sehr viel Presse zum Bug in OpenSSL durch die TLS-Erweiterung "Heartbleed". Zur Zeit gibt es irrtümlich eine Weiterleitung von Heartbleed auf OpenSSL. Das ist fachlich falsch, weil Heartbleed ist eine Technik von TLS und muss hier behandelt werden. Ich zitiere kurz folgenden Satz aus Golem: „Die Sicherheitslücke steckt im Code für die sogenannte Heartbeat-Erweiterung von TLS. Sie wurde vor zwei Jahren in OpenSSL 1.0.1 eingeführt und soll langlebige, TLS-gesicherte Verbindungen erleichtern. Genutzt wird sie nur selten, aber in der Standardeinstellung von aktuellen OpenSSL-Versionen ist die Erweiterung aktiv.“ (Quelle http://www.golem.de/news/sicherheitsluecke-keys-auslesen-mit-openssl-1404- 105685.html)
Es kann nicht Aufgabe vom Artikel OpenSSL sein zu beschreiben für was Heartbleed dient und wo es angewendet werden soll in der Praxis. TLS ist nicht mein Spezialgebiet und daher habe ich keine zugehörige Sammlung von passenden Einzelnachweise für eine qualifizierte Ergänzung eines neuen Unterkapitels. Ich bitte die üblichen Artikelschreiber von TLS hier aktiv zu werden. --ocrho (Diskussion) 10:58, 9. Apr. 2014 (CEST)

der name der TLS-erweiterung ist heartbeat, der name des bugs in OpenSSL ist heartbleed. die weiterleitung ist daher korrekt. --Mario d 11:09, 9. Apr. 2014 (CEST)

Hallo d,

danke für den Hinweis - da ist mir ein Tippfehler unterlaufen: Könnt Ihr bitte ein Kapitel zur "Heartbeat-Erweiterung" schreiben? --ocrho (Diskussion) 00:30, 10. Apr. 2014 (CEST)

probleme beim ssl- bzw. tls-email-verkehr mit unverschlüsselten mails bzw. empfängern ohne ssl?!

der laie (z.b. von t-online genötigt, seinen mail-verkehr auf ssl umzustellen) fragt sich, ob es zu problemen kommt, wenn man selber mit ssl kommuniziert, jemand anderes aber unverschlüsselte mails schickt?? bzw. ob ein empfänger, der ohne ssl arbeitet, mails lesen kann, die per ssl versendet wurden??! bitte um antwort! danke! --HilmarHansWerner (Diskussion) 17:05, 9. Apr. 2014 (CEST)

die mails werden ja nicht auf dem ganzen weg verschluesselt, nur fuer den transport zum t-online-server. ab da ist alles wieder im klartext, es kann sie also jeder lesen, auch der empfaenger. --Mario d 19:00, 9. Apr. 2014 (CEST)

danke mario! falls es auch für andere von interesse ist: ich frage mich, warum t-online mich mit emails bombardiert, ich solle auf ssl umstellen, obwohl ich nirgends (auf keinem mail-programm) ein t-online-konto eingerichtet habe. ich habe nur eine weiterleitung auf einer t-online-email-adresse liegen. dennoch behaupten die: "Sie erhalten diese Nachricht, da Sie vor kurzem unverschlüsselt auf Ihre @t-online.de E-Mails zugegriffen haben." versteht der laie nicht... --HilmarHansWerner (Diskussion) 19:49, 10. Apr. 2014 (CEST)

Vier Möglichkeiten fallen mir ein: 1) Die Telekom irrt sich 2) Die E-Mails sind gar nicht von der Telekom, sondern eine Betrugsmasche 3) Jemand anderes greift unverschlüsselt auf Deine E-Mails zu 4) Du hast doch, möglicherweise per Webmail o.ä. und nicht über ein Mail-Programm auf Deinem Rechner, einen unverschlüsselten Zugriff eingerichtet. --84.130.179.200 20:41, 10. Apr. 2014 (CEST)

mutual TLS

ich habe diese aenderung wieder zurueckgesetzt. das wenige, was ich dazu finden konnte, laesst mich glauben, dass MS einen neuen namen fuer TLS mit client authentication gefunden hat. gibt es da unterschiede? --Mario d 12:45, 9. Sep. 2014 (CEST)

Laut http://linuxconfig.org/apache-web-server-ssl-authentication#h4-two-way-ssl-authentication it Mutual TLS ein anderer Name für die 2-Wege Authentifizierung. Also keine reine MS Erfindung. In der englischen Wikipedia hat der Begriff auch einen eigenen Eintrag. (nicht signierter Beitrag von 213.160.31.11 (Diskussion) 15:42, 9. Sep. 2014 (CEST))

in der en.WP steht MTLS fuer en:Multiplexed Transport Layer Security, sonst habe ich da nichts gefunden. die abkuerzung wuerde ich daher lieber weglassen. das mit den zwei servern klingt seltsam, client und server sind hier zwei rollen: der initiator ist der client, der responder der server. ich habe eine anmerkung eingefuegt, ist das so ok fuer dich? --Mario d 18:19, 9. Sep. 2014 (CEST)

Funktionsweise

"Für gewöhnlich authentifiziert sich zuerst der Server gegenüber dem Client mit einem Zertifikat." Und wie prüft der Client, ob das Zertifikat gültig ist?

Fragt Harald Wehner (Diskussion) 13:14, 16. Sep. 2014 (CEST)

Der Client verfügt über eine Liste von Root-Zertifikaten von vertrauenswürdigen Zertifizierungsstellen. Ist das Server-Zertifikat durch eine dieser Zertifizierungsstellen signiert, vertraut der Client dem Server-Zertifikat. --Matthäus Wander 18:10, 16. Sep. 2014 (CEST)

SSL 3.1?

Inwiefern ist es relavant, dass TLS 1.0 irgendwann aus irgendwelchen Gründen SSL 3.1 heißen sollte? Mir fällt spontan keine Quelle dafür ein und es ist sicher nicht wichtig genug, im ersten oder zweiten Absatz erwähnt zu werden, oder? 89.1.39.100 09:29, 1. Dez. 2014 (CET)

Die entscheidende Information ist hierbei, dass TLS und SSL eine eigene Versionszählung haben. Anstatt "... wobei TLS-Version 1.0 der SSL-Version 3.1 entspricht" (was nicht ganz stimmt, da es kein SSL 3.1 gibt) könnte man auch sagen "... wobei auf SSL-Version 3.0 die TLS-Version 1.0 folgte" oder "... wobei TLS-Version 1.0 den Nachfolger von SSL-Version 3.0 darstellt". --Matthäus Wander 19:12, 1. Dez. 2014 (CET)

langsamer als ...?

Der Nachteil der TLS-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite rechenintensiv und deshalb langsamer ist. -- langsamer als was?

PS: Fast alle Diskussionsanstöße seit 2010 haben weder Änderungen im Artikel nach sich gezogen noch sind Antworten gefolgt. Also, für den interessierten, kompetenten Artikel(qualitäts)verbesserer: es gäb da n paar Anregungen. --84.59.254.47 18:05, 5. Dez. 2014 (CET)

Langsamer als ein unverschlüsselter Verbindungsaufbau. --P.C. ✉ 18:06, 5. Dez. 2014 (CET)

Ende-zu-Ende

Im Artikel ist die Rede von einer Ende-zu-Ende Verschlüsselung unter "SSL Record Protocol". TLS bietet aber lediglich eine Punkt-zu-Punkt Verschlüsselung, richtig? --Z0rn42 (Diskussion) 13:32, 11. Jul. 2012 (CEST)

Nicht zwingend. Es ist möglich, HTTP Proxies so zu konfigurieren, dass sie zwar auf TCP-Ebene in der Mitte stehen, die eigentlichen Inhalte allerdings direkt weiterleiten. Das bedeutet auch, dass des gesamte TLS-Handshake Ende-zu-Ende stattfindet, anstatt Ende-zu-Proxy-zu-Ende. Siehe auch https://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_tunneling --93.159.251.2 11:12, 13. Sep. 2017 (CEST)

Server Identifizierung (Phase 2)

Unter Phase 2 ist beschrieben, daß sich hier der Server identifiziert, nur das Bild zum SSL-Handshake paßt nicht dazu. Dazu müßte der Server (wie der Client in Phase 3) sein Zertifikat mit seinem privaten Schlüssel verschlüsseln (signieren). Oder kann es sein, daß der Server sein Zertifikat grundsätzlich signiert rausgibt? Dann sollte das in der Beschreibung und im Bild klarer herausgestellt sein. (nicht signierter Beitrag von 217.91.108.102 (Diskussion) 09:20, 15. Feb. 2008 (CET))

Ich finde, nach über 10 Jahren hast du eine Antwort verdient: Der Server signiert beim RSA-Schlüsselaustausch sein Zertifikat nicht. Das ist nicht notwendig, da der Client in Phase 3 das PMS mit dem öffentlichen Schlüssel des Servers verschlüsselt. Authentizität wird implizit hergestellt, da nur der Inhaber des zugehörigen privaten Schlüssels Zugriff auf das PMS erhält und den Handshake protokollkonform abschließen kann. Anders ist es beim DH-Schlüsselaustausch, der aber in der Grafik nicht abgebildet ist. --Matthäus Wander 21:43, 15. Jan. 2020 (CET)

POODLE?

Ist die Sache mit POODLE relevant? --88.69.205.252 14:11, 24. Okt. 2014 (CEST)

Ja, ist auch mittlerweile im Artikel erläutert. --Matthäus Wander 20:06, 15. Jan. 2020 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Matthäus Wander 20:06, 15. Jan. 2020 (CET)

wrong direction

The historic version order (#Versionen) seems to be upside down.

They're not (in current article revision). --Matthäus Wander 20:11, 15. Jan. 2020 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Matthäus Wander 20:11, 15. Jan. 2020 (CET)

Initialer Absatz

Im ersten Absatz könnte man "Bekannte Implementierungen des Protokolls sind OpenSSL, LibreSSL und GnuTLS." ersatzlos streichen, da es meiner Meinung nach redundant ist da die Liste noch mal unter Implementierungen zu finden ist. Fabianfrz (Diskussion) 14:28, 28. Dez. 2018 (CET)

Da kein Widerspruch zu lesen war, habe ich den Satz nun entfernt. --Matthäus Wander 20:48, 15. Jan. 2020 (CET)

TLS 1.3

Der Abschnitt Transport Layer Security#TLS Handshake Protocol beschreibt derzeit TLS 1.2. TLS 1.3 bringt größere Abweichungen mit sich, die sich schlecht in den bestehenden Abschnitt integrieren lassen → neuer Abschnitt erforderlich. Haben wir eine Grafik des 1.3 Handshakes? --Matthäus Wander 22:56, 15. Jan. 2020 (CET)

Ich hab dir mal zwei Kategorien zusammengestellt und generell aufgeräumt:

• Category:TLS 1.2 handshake
• Category:TLS 1.3 handshake

Kannst du mir grad sagen, ob die Datei File:TLS_False_Start.svg TLS 1.2 abbildet? Ich hab das jetzt erst mal so erkannt und eingeordnet. Bin raus für heute. --Keks Ping mich an! 23:40, 15. Jan. 2020 (CET)

Danke fürs Sortieren. Die Grafik beschreibt 1.2. Bei 1.3 gibt es kein ChangeCipherSpec mehr. --Matthäus Wander 09:58, 16. Jan. 2020 (CET)

Unterschied zwischen SSL und TLS

Das könnte der Artikel noch mehr herausarbeiten, darauf wird bisher gar nicht eingegangen. :-( --RokerHRO 18:01, 8. Mai 2006 (CEST)

Nach fast 14 Jahren: @RokerHRO: es ist letztendlich nur die Bezeichnung, die sich geändert hat. --Keks Ping mich an! 12:24, 16. Jan. 2020 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Keks Ping mich an! 12:24, 16. Jan. 2020 (CET)

Anmerkung zu TLS 1.0

Anmerkung zu Abschnitt 1.1 Versionen: TLS 1.0 wird als "nicht mehr unterstützt" markiert. Dies ist m. M. nicht korrekt bzw. irreführend. Es stimmt zwar, dass TLS 1.0 nicht mehr im PCI DSS vorhanden ist (ein Standard für Unternehmen mit Kreditkartentransaktionen); Ein (allgemeines) "deprecated" sollte durch eine RFC kommen? (was wohl in naher Zukunft kommt, aber noch ist es nicht soweit, oder?...) TLS 1.0 wird nach meiner Info von den gängigen Browsern bis Anfang 2020 unterstützt. (nicht signierter Beitrag von Himmax (Diskussion | Beiträge) 11:44, 30. Nov. 2018‎)

Das sehe ich auch so. PCI DSS ist der Standard einer Interessenvereinigung für einen bestimmten Anwendungsfall, keine allgemeingültige Aussage. Ähnlich verhält es sich mit der BSI-Empfehlung, die von TLS 1.1 abrät. Bei Bundesbehörden und einigen Industriezertifizierungen ist das bindend, ansonsten haben die BSI-Empfehlungen keine direkten Auswirkungen.

Das entscheidende Kriterium ist, ob die IETF TLS 1.0 und 1.1 für "deprecated" erklärt (nicht nur "obsolete", denn das verbietet nicht die Weiternutzung alter Versionen), so wie sie es bei SSL 3.0 gemacht hat. Dafür ist ein Internet-Draft in Arbeit. Solange der nicht veröffentlicht ist, haben 1.0 und 1.1 weiterhin Gültigkeit. Zusätzlich erwähnenswert finde ich die Praxis der Browser-Hersteller, denn wenn diese 1.0 oder 1.1 rauswerfen, gilt das de facto für den Großteil der Welt. --Matthäus Wander 20:46, 15. Jan. 2020 (CET)

Nun ich finde wir sollten dann aber trotzdem einen Farbe für "veraltet" einführen. Welche Unterstützung will die IETF denn einstellen? Für ihren eigenen Webservice? Dem Ansatz mit den Browsern stimme ich nur teilweise zu. Die Hersteller wollen ja möglichst viele Menschen erreichen. Und es ist doch aus wissenschaftlicher Sicht nachvollziehbar, dass SHA-1 als Signaturalgorithmus keine ausreichende Sicherheit bietet und TLS 1.1 da mit im Boot sitzt. --Keks Ping mich an! 20:57, 15. Jan. 2020 (CET)

Die IETF ist das Standardisierungsgremium von TLS. Sie bestimmt, welche TLS-Version gültig ist und welche nicht.

Ich verstehe nicht, bei welchem Teil mit den Browsern du widersprichst.

Der Abschnitt Transport Layer Security#Versionen bewertet nicht die Sicherheit von TLS, sondern listet die aktuellen und veralteten Versionen auf. Das ist keine wissenschaftliche Fragestellung. --Matthäus Wander 22:44, 15. Jan. 2020 (CET)

Aber es ist doch etwas offensichtlich veraltet, wenn es kryptographisch nicht mehr gegenhalten kann oder? Wegen der Browser: „Zusätzlich erwähnenswert finde ich die Praxis der Browser-Hersteller, denn wenn diese 1.0 oder 1.1 rauswerfen, gilt das de facto für den Großteil der Welt.“ → Das werden die wenigsten einfach mal ebenso tun, die warten, bis ein anderer damit anfängt denn „Die Hersteller wollen ja möglichst viele Menschen erreichen“ und sie nicht aus der komfortzone locken... --Keks Ping mich an! 23:20, 15. Jan. 2020 (CET)

Zur Diskussion steht, ob TLS 1.0 und 1.1 in die Kategorie "Ältere Version; nicht mehr unterstützt" oder in "Ältere Version; noch unterstützt" einzuordnen sind. Es geht nicht um "noch sicher" oder "nicht mehr sicher". Die Browser-Hersteller haben bereits angekündigt 1.0 und 1.1 rauszukicken. Solange sie es nicht tun, wird es de facto "noch unterstützt". --Matthäus Wander 09:51, 16. Jan. 2020 (CET)

Dann würde ich eine zweite Tabelle oder Spalte vorschlagen, in dem die Sicherheit unabhängig von der IETF-Unterstützung bewertet wird. --Keks Ping mich an! 12:22, 16. Jan. 2020 (CET)

Server Certificate Message

Gemäss RFC 2246 (Punkt 7.4.2) und dem neuen RFC 5246 (Punkt 7.4.2) ist der Versand des Server Zertifikats BENÖTIGT, und kann nur ausnahmsweise bei Annonymem DH Keyagreement weggelassen werden. Dies geht aus dem Satz "Phase 2: Diese Phase ist optional." jedoch zuwenig deutlich hervor ...

--152.96.235.228 16:00, 5. Jan. 2009 (CET)

Ist erledigt. --Matthäus Wander 18:49, 2. Feb. 2020 (CET)

Quelle zu Angriffen durch staatliche Stellen

• EFF zweifelt an Abhörsicherheit von SSL, 25-März 2010, heise.de. Nemissimo RSX 19:01, 25. Mär. 2010 (CET)

Pre-Snowden Altmeldung kann ins Archiv. --Matthäus Wander 18:51, 2. Feb. 2020 (CET)

CyaSSL

offenbar gibt es unstimmgkeiten, ob CyaSSL eine "bekannte implementierung" von TLS ist. das koennte man hier diskutieren, bevor sinnlos reverted wird. --Mario d 18:45, 23. Aug. 2011 (CEST)

Erledigt, Relevanz mittlerweile durch eigenen Artikel belegt: wolfSSL --Matthäus Wander 18:52, 2. Feb. 2020 (CET)

Ende-zu-Ende

@Wissenslustiger ([2])

Die Übertragung, Verschlüsselung und Entschlüsselung findet dabei über Teilstrecken statt (Zwischenstationen; z.B. Funkrelaisstation) und ist somit unsicherer als über Direktverbindung (E2E mittels E2EE).

Das scheint so nicht korrekt verallgemeinert worden zu sein. Bei einer HTTPS-Verbindung zu einer Informationsquelle stellt TLS eine Ende-zu-Ende-Verschlüsselung sicher. Zwischenstationen, insbesondere "Funkrelaisstation"en, haben eben keinen Zugriff auf die Daten. Das ist der Sinn von HTTPS. Zudem fehlen Belege, und in der Einleitung wirkt es fehlplatziert. ~ ToBeFree (Diskussion) 13:14, 12. Mai 2022 (CEST)

Schon mal was von MITM-Attack und SSL-/ bzw. der Nachfolger TSL-Stripping, Certificate Authority Hack (CA-Hack), Server Name Indication (SNI)-Spying, ... gehört ? --2.247.250.80 09:57, 23. Jul. 2022 (CEST)

SSL_Symbol.png

Das am Anfang in den Artikel eingefügte Bild scheint mir da etwas fehlplatziert. Wenn, dann würde ich es in den Abschnitt SSL in der Praxis einbauen. Wie siehst Du das? --Saibo (Δ) 10:17, 19. Mär 2006 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Matthäus Wander 19:58, 15. Jan. 2020 (CET)