Diskussion:Transport Layer Security/Archiv

message: 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)
replies: text: Unter  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)
thread_title:  TLS und SSH 

message: 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)
replies: text: ich habe zu dem abschnitt eine hoffentlich verstaendlichere einleitung geschrieben. --Mario d 16:06, 29. Apr. 2012 (CEST)
thread_title:  Verständlichkeit 

message: 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)
replies: text: 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)

text: 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)

text: 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)

text: Google mal nach 'Tommy SSL Proxy' --Nomori 20:53, 10. Sep 2006 (CEST)
replies: text:  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)

text: 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)
thread_title:  SSL als Freibrief für privates Surfen am Arbeitsplatz? 

message: 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)
replies: text: 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)

text: 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)
replies: text:  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)

text: 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)
thread_title:  SSL im TCP/IP-Schichtenmodell 

message: 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)
replies: text: 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)
thread_title:  Messengerdienste 

message: 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)
replies: text: 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)
replies: text: das wurde vor 3 jahren bereits auf der disk des bilds bemaengelt: . 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)
replies: text: 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)
replies: text: kannst du gerne machen, die lizenz ist ja auf der dateiseite angegeben. --Mario d 21:08, 4. Mär. 2013 (CET)
thread_title:  Das Bild ist nicht korrekt? 

message: 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)
replies: text: 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)
thread_title:  Explizite / Implizite Verschlüsselung 

message: 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)
replies: text: 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)
thread_title:  Keine Hinweise auf praktische Umsetzung? 

message: 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)
replies: text: der satz erwaehnt doch, dass verschluesselt wird. --Mario d 23:00, 15. Mai 2012 (CEST)
thread_title:  Neben Nachrichten-Integrität und Authentizität fehlt die VERTRAULICHKEIT 

message: 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)
replies: text: ich sehe dafuer keinen grund, du kannst es gerne aendern. --Mario d 10:05, 28. Mai 2012 (CEST)
thread_title:  Merkwürdig 

message: 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)
replies: text: 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)
thread_title:  HTTPS-Verbindung auch bei Zertifikatfehler verschlüsselt? 

message: 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)
replies: text: 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)
replies: text:  Ich habe die Weiterleitung löschen lassen. --Fomafix (Diskussion) 12:38, 25. Mär. 2013 (CET)
thread_title:  [[Secure Server Line]] 

message: 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. 
: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)
thread_title:  Site Seals 

message: 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
: Ist mir soeben auch aufgefallen; hab's in 32 Byte abgeaendert. AmiUhle 12:44, 14. Okt. 2008 (CEST)
thread_title:  Länge der Random Zahl im Client Hello 

message: 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 
:::"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 
ich geb mal als Gegenmeinung folgendes dazu:
http://serpentsembrace.wordpress.com/2011/04/10/tutor-ssl-im-visier-nicht-immer-liegt-es-am-protokoll/ 
:sowas in der art kann man sicherlich noch in den artikel einbauen. --Mario d 16:53, 3. Jan. 2012 (CET)
thread_title:  SSL kaputt? 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  probleme beim ssl- bzw. tls-email-verkehr mit unverschlüsselten mails bzw. empfängern ohne ssl?! 

message: 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)
replies: text:  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)
replies: text: 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)
thread_title:  mutual TLS 

message: "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)
replies: text: 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)
thread_title:  Funktionsweise 

message: 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)
replies: text: 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)
thread_title:  SSL 3.1? 

message: 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)
replies: text: Langsamer als ein unverschlüsselter Verbindungsaufbau. --P.C. ✉ 18:06, 5. Dez. 2014 (CET)
thread_title:  langsamer als ...? 

message: 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)
thread_title:  Ende-zu-Ende 

message: 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. 
: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)
thread_title:  Server Identifizierung (Phase 2) 

message: Ist die Sache mit POODLE relevant? --88.69.205.252 14:11, 24. Okt. 2014 (CEST)
replies: text: Ja, ist auch mittlerweile im Artikel erläutert. --Matthäus Wander 20:06, 15. Jan. 2020 (CET)

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

message: 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)
replies: text: Archivierung dieses Abschnittes wurde gewünscht von: Matthäus Wander 20:11, 15. Jan. 2020 (CET)
thread_title:  wrong direction 

message: 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)
replies: text: Da kein Widerspruch zu lesen war, habe ich den Satz nun entfernt. --Matthäus Wander 20:48, 15. Jan. 2020 (CET)
thread_title:  Initialer Absatz 

message: Das könnte der Artikel noch mehr herausarbeiten, darauf wird bisher gar nicht eingegangen. :-( --RokerHRO 18:01, 8. Mai 2006 (CEST)
replies: text: Nach fast 14 Jahren:  es ist letztendlich nur die Bezeichnung, die sich geändert hat. --Keks Ping mich an! 12:24, 16. Jan. 2020 (CET)

text: Archivierung dieses Abschnittes wurde gewünscht von: --Keks Ping mich an! 12:24, 16. Jan. 2020 (CET)
thread_title:  Unterschied zwischen SSL und TLS 

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)
replies: text: Ist erledigt. --Matthäus Wander 18:49, 2. Feb. 2020 (CET)
thread_title:  Server Certificate Message 

message: * EFF zweifelt an Abhörsicherheit von SSL, 25-März 2010, heise.de. Nemissimo  RSX 19:01, 25. Mär. 2010 (CET)
replies: text: Pre-Snowden Altmeldung kann ins Archiv. --Matthäus Wander 18:51, 2. Feb. 2020 (CET)
thread_title:  Quelle zu Angriffen durch staatliche Stellen 

message: 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)
replies: text: Erledigt, Relevanz mittlerweile durch eigenen Artikel belegt: wolfSSL --Matthäus Wander 18:52, 2. Feb. 2020 (CET)
thread_title:  CyaSSL 

message: @Wissenslustiger ()
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)
replies: text: 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)
thread_title:  Ende-zu-Ende 

message: 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)
replies: text: Archivierung dieses Abschnittes wurde gewünscht von: Matthäus Wander 19:58, 15. Jan. 2020 (CET)
thread_title:  SSL_Symbol.png