Diskussion:Transport Layer Security

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).

Das am Anfang in den Artikel eingefügte Bild Vorhängeschlosssymbol für SSL/TSL in Mozilla Firefox 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)

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

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) Beantworten

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) Beantworten

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.Beantworten

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) Beantworten

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) Beantworten

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

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)

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) Beantworten

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) Beantworten

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) Beantworten

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) Beantworten

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) Beantworten

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) Beantworten

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) Beantworten

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) Beantworten

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) Beantworten

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.

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{
uint32gmt_unix_time;
opaquerandom_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) Beantworten

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

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

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) Beantworten

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) Beantworten

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) Beantworten

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. -- Merl issimo 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) Beantworten

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) Beantworten

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) Beantworten

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)) Beantworten

Da steht:

"SSL verschlüsselt nur die Kommunikation zwischen zwei Stationen. Es sind jedoch auch Szenarien (insbesondere in serviceorientierten Architekturen) denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird. Wenn jede dieser Stationen aber nur einen Teil der Nachricht lesen darf, reicht SSL nicht mehr aus, da jede Station alle Daten der Nachricht entschlüsseln kann. Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann."

Wenn die Kommunikation über mehrere Stellen läuft, manche der beteiligten Stellen aber nur einen Teil der übertragenen Daten lesen dürfen, müssen die übertragenen Daten eben entsprechend verschlüsselt werden - bevor sie mittels SSL bzw. TLS übertragen werden. Es ist daher kein Nachteil von SSL bzw. TLS, sondern eine Anforderung an das Design der Kommunikation. (nicht signierter Beitrag von 93.219.169.243 (Diskussion | Beiträge) 13:03, 10. Jan. 2010 (CET)) Beantworten

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

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) Beantworten

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) Beantworten

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) Beantworten

• quellen waeren schoen.
• wie rechenintensiv ist verschluesselung wirklich? gibt es dazu studien? (wird mittlerweile ja viel genutzt, s. webmaildienste, google search)
• der naechste satz ist widerspruechlich: man kann auf hoeherer ebene nicht kompromieren, in TLS schon, aber da macht man es dann wegen des rechenaufwands nicht?
• was sind das fuer szenarien im letzten abschnitt? der ganze abschnitt ist unklar. --Mario d 15:09, 20. Sep. 2011 (CEST) Beantworten

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)) Beantworten

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) Beantworten

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/ (ohne Benutzername signierter Beitrag von 188.45.191.205 (Diskussion) )

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

Es gibt genug Anwender die das bei Facebook aktiviert haben und sich jetzt "sicher" fühlen (dies betrifft dann z.B. ein "Sicherheitsgefühl" bei der Ausführung von FB-Apps oder dem aufruf externer FB Seiten mit PayPal-Button...) oder HTTPS**//franz-seine-tolle-erste-homepage.org (meistens dann auch noch mit einem Hinterhof SSL Zertifikat, was der Leser der Seite dann installiert oder die Warnung im Browser dauerhaft abschaltet...), usw. usw. es fehlt mir hier eine eindeutige Warnung davor, was SSL eindeutig nicht ist, und wo SSL sogar gefährlich wird. --Lastwebpage 10:14, 19. Feb. 2012 (CET) Beantworten

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)) Beantworten

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

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) Beantworten

• Wikipedia:Seite mit Syntaxhervorhebungsfehlern