Diskussion:Transport Layer Security

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Automatische Archivierung
Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 180 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten.
Archiv-Tabelle Archiv
Zum Archiv
Wie wird ein Archiv angelegt?

SSL_Symbol.png[Quelltext bearbeiten]

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)

Unterschied zwischen SSL und TLS[Quelltext bearbeiten]

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

Server Identifizierung (Phase 2)[Quelltext bearbeiten]

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)

Server Certificate Message[Quelltext bearbeiten]

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)

Abschnitt "Vor- und Nachteile"[Quelltext bearbeiten]

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

Quelle zu Angriffen durch staatliche Stellen[Quelltext bearbeiten]

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

CyaSSL[Quelltext bearbeiten]

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)

Vor- und Nachteile[Quelltext bearbeiten]

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

Gefährlichkeit von HTTPS?[Quelltext bearbeiten]

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)

Stichwort "Client Authentication"[Quelltext bearbeiten]

Das Stichwort "Client Authentication" sollte im Text explizit vorkommen, weil es ein wichtiger technischer Fachbegriff ist. Im englischsprachigem Artikel ist es mehrfach auffindbar. (nicht signierter Beitrag von 194.121.11.21 (Diskussion) 14:22, 31. Aug. 2012 (CEST))

POODLE?[Quelltext bearbeiten]

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

Inzwischen durch NSA gebrochen?[Quelltext bearbeiten]

Vor dem Hintergrund eines Vortrags von Jacob Applebaum und Laura Poitras beim 31C3 und Veröffentlichungen auch durch SpiegelOnline...: http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html http://www.spiegel.de/international/world/nsa-documents-attacks-on-vpn-ssl-tls-ssh-tor-a-1010525.html ...stellt sich die Frage, ob es inzwischen gebrochen ist. (nicht signierter Beitrag von 95.90.70.190 (Diskussion) 22:29, 28. Dez. 2014 (CET))

wrong direction[Quelltext bearbeiten]

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

Anmerkung zu TLS 1.0[Quelltext bearbeiten]

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.

Initialer Absatz[Quelltext bearbeiten]

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)