Diskussion:Hypertext Transfer Protocol Secure/Archiv

message: Das Projekt "https everywhere" zu erwähnen wäre bestimmt eine gute Idee.
https://www.eff.org/https-everywhere
The plugin currently works for:
    * Google Search
    * Wikipedia
    * Twitter
    * Facebook
    * most of Amazon
    * GMX
    * Wordpress.com blogs
    * The New York Times
    * The Washington Post
    * Paypal
    * EFF
    * Tor
    * Ixquick
frogli -- 81.189.153.130 16:41, 3. Aug. 2010 (CEST)
thread_title:  https everywhere 

message: Der erste Satz ist mir irreführend bis falsch erschienen. https ist kein eigenes Protokoll sondern ganz einfaches HTTP mit SSL-Verschlüsselung in der Schicht drunter. Das "https" ist nur ein URI-Schema, dass das anzeigen soll (siehe auch die englische Wikipedia).
Eigentlich müsste man den Titel des Artikels auch noch anpassen. Er schreibt sich wohl eher "https" (siehe wieder den englischen Artikel).
--193.81.246.92 10:17, 9. Mai 2006 (CEST)
replies: text: So sollte es sein. Das hört sich gut an. Aber warum hat es ein eigenes URI-Schema, warum nicht SSL über das HTTP-Schema? Und warum ist der Standard-Port 443? --84.153.87.18 16:04, 14. Mär. 2008 (CET)
thread_title:  https ist kein Protokoll 

message: Hallo, habe fast den gleichen Text zu HTTPS unter folgender URL gefunden:
http://www.ilexikon.com/HTTPS.html
Einer scheint da abgekupfert zu haben...
: Das Übernehmen von Inhalten aus der Wikipedia ist ausdrücklich erlaubt, sofern die Lizenzbestimmungen eingehalten werden. ilexikon.com nennt zumindest die Quelle, verlinkt den Originalartikel und verweist auf die GNU FDL. Siehe auch Projekte, die die Wikipedia als Quelle benutzen. -- molily 22:07, 21. Jun 2005 (CEST)
thread_title:  Copyright-Verletzung?? 

message: Der beschriebene Ablauf des TLS Handshakes ist nicht korrekt dargestellt. Im Dokument http://www.ietf.org/rfc/rfc2246.txt ist die richtige Vorgehensweise dargestellt. Wärend den Hello Messages wird im Zertifikat die Schlüssel Spec übertragen. Dort ist entweder mittels RSA ein Secret Key verschlüsselt enthalten oder die DH Parameter.
Gruß,
duisentrieb 15:00, 25. Nov 2005 (CEST)
thread_title:  Ablauf des TLS Handshakes 

message: Hallo, 
Ich habe den Edit von 84.19.199.87 aus dem Artikel hierher verschoben, da die Form leider noch nicht in eine Enzyklopädie passt. Bitte hier fertigstellen, kommt nach Abschluss der ARbeiten wieder in den Artikel. --jha 16:42, 4. Mär 2006 (CET)
replies: text: So ist auch mein Verständnis, und daher sind auch solche eigens angefertigten Zertifikate nicht per se anfällig für Man-in-the-middle-Angriffe. Wenn mir das Zertifikat von einer Vertrauensperson persönlich überbracht wird, habe ich wenig Schwierigkeiten, ihm zu trauen. Johannes Hüsing 11:20, 15. Mai 2009 (CEST)

text: Diesen Diskuassinsabschnitt finde ich nicht verataendlich. Kann mal bitte jemand praeziese formulieren, was diskutiwert wird? (Nicht boese gemeint, nur nicht verstanden). Traute Meyer 22:27, 15. Mai 2009 (CEST)
replies: text:  Storno: nach nochmaligem 3x Lesen (glaube ich herauszulesen) geht es um das Vertrauen des Ausstellers des Zertifikats. Das ist natuergemaess Vertrauenssache. Das lassen sich die Zertifiziererer gegen EUR/USD bezahlen; das Vertrauen der Zertifikatsaussteller ist ihr Kapital. Falls sie das (auch nur einmalig) verspielen, haben sie ein (Vertrauens-) Problem, und sind nicht mehr des Vetrauens wuerdig. Die Zertifizierungsstellen, mit denen ich zu tun hatte, machen ihren Job professionell. Private / eigene Signaturen sind natuerlich nicht vertrauenswuerdig, da sie sich selbst bezeugen, und keinen Buergen haben. Traute Meyer 22:56, 15. Mai 2009 (CEST)
thread_title:  Allgemeinverständliche Erklärung 

message: Der Ablauf beginnt damit, dass ein "Zertifikat" übermittelt und anschließend eine verschlüsselte Verbindung eingerichtet wird.
==== Zertifikat ====
Wichtig ist dabei, dass der Server (z.B. www.XYZ.de) dem Browser und damit dem Benutzer zunächst ein Zertifikat vorweist. Dieses sollte der Benutzer prüfen! Es handelt sich hierbei vergleichsweise um ein Dokument auf dem steht, dass der Server www.XYZ.de tatsächlich der Organisation XYZ zugehört. Dieses Dokument kann zunächst jeder beliebig erzeugen. Damit dieses auch vertrauenswürdig ist wird es von jemanden (z.B. Signierer) digital signiert/unterschrieben. Beispielsweise ist die Firma Verisign jemand, der solche digitalen Unterschriften leistet.
Die Unterschift muss nicht zwangsweise von einer großen Firma geleistet werden, sondern kann durch eine beliebige "Instanz" (Person oder Computer) erfolgen.
Ein Zertifikat ist also ein Dokument mit einer Unterschrift (informell gesprochen).
D.h. der Benutzer bekommt mit dem Zertifikat angezeigt WEN (z.B. XYZ) er kontaktiert hat und WER (z.B. Signierer) bestätigt, dass dies auch wirklich so ist (Signierer bestätigt, das XYZ tatsächlich XYZ ist).
Der Knackpunkt ist also: "Ist Signierer vertrauenswürdig" - sprich hat Signierer geprüft ob XYZ auch wirklich XYZ ist.
Dies sollte in Zweifel gezogen werden, wenn Signierer unbekannt oder gar XYZ selbst ist (man kann sich selbst immer bescheinigen, dass man derjenige ist, der man vorgibt zu sein).
::So ist auch mein Verständnis, und daher sind auch solche eigens angefertigten Zertifikate nicht per se anfällig für Man-in-the-middle-Angriffe. Wenn mir das Zertifikat von einer Vertrauensperson persönlich überbracht wird, habe ich wenig Schwierigkeiten, ihm zu trauen. Johannes Hüsing 11:20, 15. Mai 2009 (CEST)
replies: text: Diesen Diskuassinsabschnitt finde ich nicht verataendlich. Kann mal bitte jemand praeziese formulieren, was diskutiwert wird? (Nicht boese gemeint, nur nicht verstanden). Traute Meyer 22:27, 15. Mai 2009 (CEST)
replies: text:  Storno: nach nochmaligem 3x Lesen (glaube ich herauszulesen) geht es um das Vertrauen des Ausstellers des Zertifikats. Das ist natuergemaess Vertrauenssache. Das lassen sich die Zertifiziererer gegen EUR/USD bezahlen; das Vertrauen der Zertifikatsaussteller ist ihr Kapital. Falls sie das (auch nur einmalig) verspielen, haben sie ein (Vertrauens-) Problem, und sind nicht mehr des Vetrauens wuerdig. Die Zertifizierungsstellen, mit denen ich zu tun hatte, machen ihren Job professionell. Private / eigene Signaturen sind natuerlich nicht vertrauenswuerdig, da sie sich selbst bezeugen, und keinen Buergen haben. Traute Meyer 22:56, 15. Mai 2009 (CEST)
thread_title:  Umgangssprachliche Beschreibung 

message: Wichtig ist dabei, dass der Server (z.B. www.XYZ.de) dem Browser und damit dem Benutzer zunächst ein Zertifikat vorweist. Dieses sollte der Benutzer prüfen! Es handelt sich hierbei vergleichsweise um ein Dokument auf dem steht, dass der Server www.XYZ.de tatsächlich der Organisation XYZ zugehört. Dieses Dokument kann zunächst jeder beliebig erzeugen. Damit dieses auch vertrauenswürdig ist wird es von jemanden (z.B. Signierer) digital signiert/unterschrieben. Beispielsweise ist die Firma Verisign jemand, der solche digitalen Unterschriften leistet.
Die Unterschift muss nicht zwangsweise von einer großen Firma geleistet werden, sondern kann durch eine beliebige "Instanz" (Person oder Computer) erfolgen.
Ein Zertifikat ist also ein Dokument mit einer Unterschrift (informell gesprochen).
D.h. der Benutzer bekommt mit dem Zertifikat angezeigt WEN (z.B. XYZ) er kontaktiert hat und WER (z.B. Signierer) bestätigt, dass dies auch wirklich so ist (Signierer bestätigt, das XYZ tatsächlich XYZ ist).
Der Knackpunkt ist also: "Ist Signierer vertrauenswürdig" - sprich hat Signierer geprüft ob XYZ auch wirklich XYZ ist.
Dies sollte in Zweifel gezogen werden, wenn Signierer unbekannt oder gar XYZ selbst ist (man kann sich selbst immer bescheinigen, dass man derjenige ist, der man vorgibt zu sein).
::So ist auch mein Verständnis, und daher sind auch solche eigens angefertigten Zertifikate nicht per se anfällig für Man-in-the-middle-Angriffe. Wenn mir das Zertifikat von einer Vertrauensperson persönlich überbracht wird, habe ich wenig Schwierigkeiten, ihm zu trauen. Johannes Hüsing 11:20, 15. Mai 2009 (CEST)
replies: text: Diesen Diskuassinsabschnitt finde ich nicht verataendlich. Kann mal bitte jemand praeziese formulieren, was diskutiwert wird? (Nicht boese gemeint, nur nicht verstanden). Traute Meyer 22:27, 15. Mai 2009 (CEST)
replies: text:  Storno: nach nochmaligem 3x Lesen (glaube ich herauszulesen) geht es um das Vertrauen des Ausstellers des Zertifikats. Das ist natuergemaess Vertrauenssache. Das lassen sich die Zertifiziererer gegen EUR/USD bezahlen; das Vertrauen der Zertifikatsaussteller ist ihr Kapital. Falls sie das (auch nur einmalig) verspielen, haben sie ein (Vertrauens-) Problem, und sind nicht mehr des Vetrauens wuerdig. Die Zertifizierungsstellen, mit denen ich zu tun hatte, machen ihren Job professionell. Private / eigene Signaturen sind natuerlich nicht vertrauenswuerdig, da sie sich selbst bezeugen, und keinen Buergen haben. Traute Meyer 22:56, 15. Mai 2009 (CEST)
thread_title:  Zertifikat 

message: Wegen des - im Verhältnis zu den relativ seltenen Änderungen am Artikel - häufigen Vandalismus habe ich einen Antrag auf Halbsperrung gestellt, der aber erstmal nicht fruchtete: Wikipedia:Vandalensperrung#Hypertext_Transfer_Protocol_Secure --Bernd vdB 21:47, 21. Nov. 2006 (CET)
replies: text: Link-Update: Wikipedia:Vandalensperrung/Archiv/2006/11/16%E2%80%9330#Hypertext_Transfer_Protocol_Secure --Bernd vdB 14:03, 24. Nov. 2006 (CET)
thread_title:  Häufiger Vandalismus 

message: Performance(?), erster Absatz: „Auch aus diesem Grunde hat sich HTTPS bisher nur bei einem kleinen Teil der Websites durchgesetzt, bei denen es aus Sicht des Datenschutzes sinnvoll wäre.“ – hat es sich nun durchgesetzt und wird genutzt oder wäre die Nutzung sinnvoll, wird aber nicht genutzt?
: Darüber darf sich gestritten werden... ich hab es jetzt geändert, damit es zumindest Sprachlich korrekt ist. --vwm 17:59, 5. Mär. 2007 (CET)
replies: text: Was daran sprachlich nicht korrekt sei, kann ich nicht erkennen. Der zitierte Satz ist IMHO nur in der zweiten Bedeutung zu verstehen: Wäre sinnvoll, wird aber leider nicht eingesetzt. Mir scheint, dir ist der Konjunktiv per se suspekt, richtig? --Bernd vdB 12:47, 6. Mär. 2007 (CET)
thread_title:  Konjunktiv oder Indikativ? 

message: In dem Artikel wird viel über die verschiedenen Varianten der Certifizierung gesprochen, aber mit was kann verschlüsselt werden? DES, AES, 3DES 40-256 bit? Wird das auch im Cert festgelegt oder ist das serverabhängig? --Shaun72 22:26, 26. Jul. 2007 (CEST)
thread_title:  Verschlüsselung 

message: Entschuldigung dass ich dieses Thema nochmal aufwärme, aber folgender Satz stört mich:
:Es stellt dabei das einzige Verschlüsselungsverfahren dar, das ohne gesonderte Softwareinstallation auf allen Internet-fähigen Computern unterstützt wird.
Was ist eine gesonderte Softwareinstallation? Normalerweise ist ein Browser nicht unbedingt im System von Anfang an enthalten. Die meisten UNIX-Systeme beinhalten bereits einen Client für SSH
Es stellt sich auch die Frage, was ein "Internet-fähiger Computer" ist. Sind das per se alle Computer mit einem Betriebssystem, dass einen TCP/IP-Stack besitzt oder nur die, auf denen ein gängiger (graphischer) WWW-Browser installiert ist? Bei ersteren, braucht man trotzdem eine gesonderte Installation. Hätte jemand einen Vorschlag, wie man diesen Satz ausdrücken kann, so dass er seinen Inhalt in etwa beibehält aber nicht irreführend ist?  Etwa:
:Es stellt dabei das einzige Verschlüsselungsverfahren dar, das von allen gängigen Browsern ohne zusätzliche Erweiterungen unterstützt wird.
Da gibt es zwar immer noch die Frage, was ein gängiger Browser ist, aber es ist schon ein wenig genauer. Kommentare? -- Mathias bla? 17:25, 31. Aug. 2007 (CEST)
replies: text: Man kann nicht immer gleichzeitig a) verständlich sein und b) nur 100% präzise Aussagen machen. Die Formel "gängig" wäre idealerweise durch eine Studie zu untermauern. Aber praktisch dürften die allermeisten Leser durchaus verstehen, was gemeint ist. Und die verstehen auch, dass sich "Internet-fähiger Computer" auf Client-PCs (oder -Geräte) bezieht und nicht auf Server. Und auch die Linux-Betreiber verstehen das IMHO. Also nicht allzu Pharisäer-haft werden bitte ... --Edoe 17:43, 3. Mär. 2008 (CET)
thread_title:  Und nochmal... 

message: Aus dem Artikel:
:Um bei hohem Datenverkehr Rechenzeit zu sparen, werden neben den möglichen 128-Bit-Schlüsseln teils noch 40-Bit-Schlüssel verwendet. Diese sind aber vergleichsweise einfach zu „knacken“, gelten nicht mehr als sicher und werden daher kaum noch benutzt.
Sollte man noch etwas verallgemeinern. Beispielsweise kommen ja auch 56 und 256 Bit zum Einsatz. Dazwischen gibt es sicher auch noch was (80 Bit?). Und auch die unterschiedlichen Verfahren unterscheiden sich im Rechenaufwand. Ich benutze für meine private Website AES mit 256 Bit, meine Banken nutzen RC4 mit 128 Bit. – 91.4.15.226 21:58, 26. Mär. 2008 (CET)
thread_title:  Schlüssellänge 

message: Ich erinnere mich dunkel, mal einen Artikel (ct?) über Beispiele unnötiger Verschlüsselung gelesen zu haben und welcher zusätzlicher - vermeidbarer - Strombedarf dadurch entsteht. Habe entsprechende Belege bislang nicht gefunden -- weiß jmd mehr dazu? (evtl. auch als Aspekt von "Green IT") --Webverbesserer 09:21, 20. Nov. 2008 (CET)
replies: text: Hmm, nenn doch mal eine (deutschsprachige) Site, die dMn unnötigerweise verschlüsselt arbeitet. Ich kenne da eigentlich nur umgekehrte Beispiel ... --Bernd vdB 15:39, 9. Feb. 2009 (CET)
thread_title:  Energieverschwendung? 

message: Dieser Satz wurde aus dem Text entfernt:
:Weiterhin ist ein Digitales Zertifikat für SSL notwendig..
.. und ersetzt durch den Satz:
:Ein Digitales Zertifikat für SSL ist optional. 
Sorry, aber natürlich ist das Zertifikat notwendig, andernfalls der SLL-Server nicht in Betrieb genommen werden kann. Habe den ursprünglichen Text wieder eingesetzt, ergänzt um die Information, dass auch selbst-erstellte Certs möglich sind - das war es wohl, das man hier meinte. Vgl.:
* http://httpd.apache.org/docs/2.0/ssl/ssl_intro.html#certificates
--Bernd vdB 15:39, 9. Feb. 2009 (CET)
thread_title:  Zertifikat notwendig 

message: "[https] stellt dabei das einzige Verschlüsselungsverfahren dar, das ohne gesonderte Softwareinstallation auf allen Internet-fähigen Computern unterstützt wird."
Im Artikeltext erschliesst sich mir die Aussage mir nicht. Bin gespannt auf Links. --Traute Meyer 17:32, 13. Nov. 2009 (CET)
replies: text: https ist in allen verfügbaren Browsern auf allen Plattformen bereits installiert. Für welches andere Verschlüsselungsverfahren gilt das dMn? --Bernd vdB 12:56, 29. Dez. 2009 (CET)
thread_title:  Nutzen 

message: Habe hier den Satz wieder eingefügt, dass HTTPS auch der Authentifizierung dient - mindestens des Servers, teils auch der Clients (spezielle Client-Certs); siehe etwa :en:HTTPS.
Weiterhin ist auch die Aussage richtig, dass https mit _im Kontext von WLAN an Bedeutung gewinnt_ - was sich mit der Aussage "HTTPS ist nicht netwerkverbunden" ja nicht widerspricht. 
--Bernd vdB 12:56, 29. Dez. 2009 (CET)
thread_title:  Authentifizierung und Wlan-Kontext 

message: Es ist weiterhin auch möglich, selbst-signierte Zertifikate (self-signed certificate) zu verwenden, die ohne Beteiligung einer gesonderten Instanz erstellt wurden. Diese müssen ebenfalls manuell bestätigt werden. Damit wird zwar die Verschlüsselung, nicht aber die Authentifizierung erreicht; solche Verbindungen sind damit verwundbar für einen Man-in-the-middle-Angriff.
Meinem sehr begrenzen Verständnis nach ist es möglich ein Zertifikat auch zu erhalten, ohne es vorher über eine unsichere Verbindung runterzuladen. (zB übergabe per CD) Behauptung: Solche Zertifikate sind dann allerdings nicht mehr für die erwähnte Schwäche verwundbar. 
Sofern das stimmt, wird hier stillschweigend davon ausgegangen, dass ein selbst-signiertes Zertifikat immer über eine unsichere Verbindung, und eventuell auch in Zeitintervallen immer wieder neu erhalten wird.
:Vielleicht auch eine Lösungsmöglichkeit: Nicht das selbst-signierte Zertifikat ist anfällig für MITM, sondern lediglich die Übertragung des Zertifikats.
85.183.47.159 12:22, 15. Jul. 2010 (CEST)
thread_title:  selbst-signierte Zertifikate verwundbar für einen Man-in-the-middle-Angriff 

message: Ist der Ablauf nicht falsch? 
Wieso sollte da erst ein Diffi Hellman Schlüsselaustausch geamcht werden?
Um danach Zertifkate zu verschicken, das macht doch gar keinen Sinn: ein Zertifikat darf doch jedermann sehen.
Und danach die Kommunikation asymmetrisch zu verschlüsseln wäre zu aufwendig.
Ich denke es ist eher so richtig.
:1. Server schickt sein Zertifikat an den Browser.
:2. Browser überprüft das Zertifkat mittels des CA Zertifkats. 
:3. Wenn es OK ist, generiert der Browser einen symmetrischen Sitzungsschlüssel und verschlüsselt diesen mit dem öffentlichen Schlüssel aus dem Zertifikat. 
:4. Browser schickt den verschlüsselten Sitzungschlüssel an dern Server, der packt ihn aus.
:5. Die Kommunikation ist durch einen symmetrischen Schlüssel gesichert. (nicht signierter Beitrag von 84.56.37.64 (Diskussion | Beiträge) 16:47, 13. Jun. 2005 (CEST)
thread_title:  Ablauf 

message: Ich kann nicht erkennen, welche »Nutzdaten« verschlüsselt werden. Nur meine Anfragen an den Server oder bekommt der Browser auch verschlüsselten HTML-Code vom Server? Mag das jemand, der das weiß, ergänzen? -- Bodil 02:35, 18. Jun. 2011 (CEST)
thread_title:  Abschnitt Technik 

message: Ich hab' das ganze mal auf den Ist-Stand gebracht, aber irgendwas ist immer noch faul. Wenn man nämlich SubjectAltName verwendet, braucht man kein SNI mehr, weil dann ein Zertifikat für alle Domains gültig ist. SNI macht es dagegen möglich, verschiedene Zertifikate pro vHost zu verwenden. Ich habe die Formulierung dahingehend angepasst, bin aber nicht sicher, ob "SubjectAltName" überhaupt unter die Überschrift SNI gehört, und nicht eher unter TLS 1.2. --Bachsau 04:45, 23. Feb. 2012 (CET)
thread_title:  SNI 

message: In dem Artikel steht nicht was genau verschlüsselt wird. Laut Forenpostings werden auch die URL Parameter und die URL selbst verschlüsselt. Wenn jemand also einen Wikipedia Artikel aufruft, dann ist für einen Dritten nur die IP ersichtlich zu dem Kontakt aufgenommen wurde. Durch Reverse DNS kann dieser dann maximal herausfinden das diese IP ausschließlich zB nur von der Wikipedia verwendet wird.
https://www.tutorials.de/threads/https-url-sicher.400442/ (nicht signierter Beitrag von 195.71.186.66 (Diskussion) 10:45, 17. Mär. 2016 (CET)
replies: text: Steht schon im ersten Satz, zumindest wenn man ihn versteht: Die HTTP-Nachrichten vollständig. Also auch der URL, ja. Jedoch wird für SNI der Hostname doch wieder im Klartext hinzugefügt. Das könnte aber wirklich WP:OMA-tauglicher beschrieben werden. Vorschläge bitte :-) --nenntmichruhigip (Diskussion) 07:24, 18. Mär. 2016 (CET)
thread_title:  Was wird denn verschlüsselt? 

message: Sollte dieser Begriff hier vorkommen? Ich denke ja. (nicht signierter Beitrag von 2001:470:7969:0:C958:9EFF:BD46:57E0 (Diskussion | Beiträge) 01:17, 28. Dez. 2014 (CET)
replies: text: Warum jetzt, wo spielt das bei HTTPS eine Rolle? --Bernd.Brincken (Diskussion) 00:25, 10. Mär. 2017 (CET)
thread_title: Fingerprint

message: Was bitte sind „Root-Chains“? Wird im Abschnitt Zertifikat erwähnt. Wer das weiss, sollte es doch auch bitte im Artikel ändern. Grüße, --Joschi71 (Diskussion) 14:40, 4. Dez. 2015 (CET)
replies: text: Done. --Bernd.Brincken (Diskussion) 00:24, 10. Mär. 2017 (CET)
thread_title:  Root-Chains