Diskussion:Hypertext Transfer Protocol Secure/Archiv

aus Wikipedia, der freien Enzyklopädie

https everywhere

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)

https ist kein Protokoll

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)

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)

Copyright-Verletzung??

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)

Ablauf des TLS Handshakes

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)

Ich gebe Herrn Duisentrieb Recht. Es wird beschrieben, dass die asymmetrischen Schlüssel zur Verschlüsselung eingesetzt werden. Dies ist falsch. Vielmehr wird aus Performancegründen zur Verschlüsselung der Nutzdaten ein symmetrisches Verfahren bzw. ein symmetrischer Sitzungsschlüssel eingesetzt, welches z.B. mit 128 Bit verschlüsselt. Siehe hierzu auch Transport Layer Security. Ein asymmetrisches Verfahren mit einer Breite von 128 Bit wäre zudem höchst unsicher. Symmetrische Verfahren werden im Allgemeinen vorzugsweise zur Authentifzierung, Signierung und als Transporthülle für performantere Verfahren verwendet. Unter http://www.softed.de/fachthema/Allgemeines/https.asp ist sehr schön dargestellt wie das funktioniert. Ich habe mich aus diesem Grund erdreistet den Artikel an besagter Stelle zu modifizieren.

Gruß Airmann 14:08, 20. Apr 2006 (CEST)

Bitte überarbeiten

Lieber Autor, die vorigen Kommentare sind korrekt. Der Artikel bedarf dringend einer Überarbeitung. ArminGraefe 17:19, 17. Jan 2006 (CET)

Das sehe ich genauso --212.80.239.231 12:46, 5. Mär 2006 (CET) - kritische Punkte sind:
  • TLS erlaubt Diffie-Hellman oder auch RSA
  • Es herrscht keine Klarheit über den Einsatz von asymm. Krypto und symm. Krypto


Der Ablauf gestaltet sich doch wie folgt (siehe RFC 2246 und RFC 2818):
  1. Client möchte einen HTTP-Request starten, dazu wird das darunterliegende TLS-Protokoll abgearbeitet:
    1. Client:
      • ClientHello - Protokollversion, Client-Zufallszahl, SitzungsID, Info zur Chiffrenmenge (CipherSuite), Kompressionsmethoden
    2. Server:
      • ServerHello - Protokollversion, Server-Zufallszahl, SitzungsID, Info zur Chiffrenmenge (CipherSuite), Kompressionsmethoden
      • (optional) ServerCertificate - enthält schon Kryptoinfo, wie RSA Public Key bis 512Bits, DH/DSS Keys
      • (optional) ServerKeyExchange - weiter Kryptoinfo falls notwendig
      • (optional) CertificateRequest - fordert vom Client ein Zert.
      • ServerHelloDone - der Server ist mit ServerHello fertig
    3. Client:
      • (falls Server dies verlangte/optional) ClientCertificate - zur ClientAuthentifizierung
      • ClientKeyExchange - bei Diffie-Hellmann der Clientteil zum Erzeugen des gemeinsamen Geheimnises oder bei RSA ein mit dem PublicKey des Servers verschlüsseltes Geheimnis (z.B. eine Zufallszahl); beide haben nun ein gemein. Geheimnis, das pre_master_secret (bis hier ist der Einsatz von asymmetrischer Krypto, ich zähle DH mal dazu, notwendig)
      • (optional) CertificateVerify - keine Ahnung was das macht; mir gibt die RFC 2246 in Absatz 7.4.8 wenig Aufschluß
      • ChangeCipherSpec - Minisubprotokoll: eine verschlüsselte Nachricht wird übertragen, die Änderungen bezüglich der Chiffrierung enthält
      • Finish - wird direkt nach ChangeCipherSpec übertragen, laut RFC 2246 Absatz 7.4.9 ist dies die erste mit der ausgehandelten Chiffrierung verschlüsselte Nachricht; ich nehme daher an, dass ChangeCipherSpec noch mit dem pre_master_secret verschlüsselt wird, Finish dann mit dem in ChangeCipherSpec gewählten Algorithmus (z.B. AES) und dem mastersecret = pseudorandomfunction(pre_master_secret, "mastersecret", clientRandom + serverRandom) verschlüsselt wird (ab hier wird aus Effizienzgründen sicher mit symmetrischer Krypto, z.B. DES/AES, weitergerechnet - prinzipiell kann mit ChangeCipherSpec aber auch asymmetrische vereinbart werden, da das Protokoll meiner Meinung nach keine Einschränkungen trifft?!)
    4. Server:
      • ChangeCipherSpec - siehe Client
      • Finish - siehe Client
  2. TLS Handshake ist beendet - Client und Server können verschlüsselt kommunizieren:
  3. Client
    • Encrypt(HTTP GET)
  4. Server
    • Decrypt(Encrypt(HTTP GET)) = HTTP GET
    • Encrypt(HTTP 200 OK content)
  5. Client
    • Decrypt(Encrypt(HTTP 200 OK content)) = HTTP 200 OK content
  6. usw.
die Kennzeichnung "optional" ist eigentlich nicht 100prozentig korrekt - RFC 2246: optionale oder situationsbedingte Nachrichten, die nicht immer gesendet werden (z.B. wenn der Server keinen Public Key sendet oder seinen Teil des DH-Schlüsselaustausch nicht erfüllt kann der Client nicht für den Server verschlüsseln bzw. beide besitzen kein gemeinsames Geheimnis)

Allgemeinverständliche Erklärung

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)

  • Re: *dumm gefragt* in welcher Form passt er dann ins Wiki - ich bin der Meinung, dass der fachliche background wichtig ist, aber es sollte auch mal für jedermann verständlich erklärt werden (mit Analogien kann man da viel tun - muss natürlich hervorgehoben werden) PS: onlineverfügbare quelle ist das Skript von Andreas Pfitzmann: Sicherheit in Rechnernetzen


Umgangssprachliche Beschreibung

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

Verschlüsselte Verbindung

Vertraut man darauf, dass www.XYZ.de zu XYZ gehört, dann schickt der Server dem Browser einen Kasten mit einem offenem Schnappschloß (z.B. Schloß1) zu dem nur der Server den Schlüssel (z.B. Schlüssel1) besitzt (das Schnappschloß repräsentiert sogenannte asymmetrische Kryptographie/Algorithmen; z.B. RSA). In diesen Kasten legt der Browser einen Schlüssel (z.B. Schlüssel2), den zunächst nur der Browser besitzt, und ein passendes Schloß (z.B. Schloß2) und schließt das Schnappschloß. Diesen verschlossenen Kasten überträgt er zurück an den Server, denn nur dieser kann das Schnappschloß (Schloß1) mit seinem Schlüssel (Schlüssel1) öffnen und an den Inhalt des Kasten gelangen. Nun haben Browser und Server ein gemeinsames Schloß (Schloß2) und beide den passenden Schlüssel (Schlüssel2); (das gemeinsame Schloß repräsentiert sogenannte symmetrische Kryptographie/Algorithmen; z.B. AES oder DES). Der Browser kann nun seine Daten in einen Kasten packen und mit dem Schloß (wenn beide das Schloß haben können sie es beliebig oft kopieren) verschließen und verschicken. Dabei kann nur er oder der Server den Kasten öffnen. Ebenso kann der Server mit seinen Daten verfahren.

Alternativ könnten beide auch mit (dann jeweils verschiedenen) Schnappschlössern arbeiten, allerdings sind diese nicht sehr schnell (die Mathematik, die den asymmetrischen Verfahren zugrunde liegt, ist wesentlich aufwändiger!) und daher wird das Schnappschloß nur zum Austausch der (schnellen) gleichen Schlüssel und Schlösser verwendet. Dieses Verwenden von symmetrischer und asymmetrischer Kryptographie wird auch Hybride Kryptographie genannt.

Häufiger Vandalismus

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)

Link-Update: Wikipedia:Vandalensperrung/Archiv/2006/11/16–30#Hypertext_Transfer_Protocol_Secure --Bernd vdB 14:03, 24. Nov. 2006 (CET)

Vergleich mit E-Mail

Im Artikel steht der Satz:

Damit ist, anders als etwa bei eMail (S/MIME oder PGP), SSH oder SFTP, die Installation gesonderter Software durch den Anwender nicht notwendig.

Ich finde den Vergleich irreführend. Bei HTTPS wird wie bei SMTP over SSL der Transportweg zwischen Client (Webbrowser bzw. Mail-Client) und Server (Webserver, MTA) verschlüsselt. In beiden Fällen ist keine Zusatzsoftware notwendig, da SSL in die üblichen Clients bereits integriert ist. Allerdings kann ein MTA eine E-Mail unverschlüsselt an einen weiteren MTA weiterleiten. Ebenso kann ein HTTPS-Webserver eine Anfrage unverschlüsselt von einem anderen Webserver oder einer Datenbank herholen. Die Ende-zu-Ende-Absicherung ist somit Betrachtungsweise. --Fomafix 10:15, 27. Nov. 2006 (CET)

Wenn keine Einsprüche kommen werde ich den Satz entfernen. --Fomafix 21:24, 4. Dez. 2006 (CET)
Mein Guta, der Einspruch kam, indem ich den Satz wieder mit Begründung einsetzte. Aber gerne nochmal hier: Die Aussage des Satzes ist nicht, dass HTTPS mit den genannten Techniken zu "vergleichen" sei, sondern dass HTTPS im Browser sofort funktioniert, die genannten Protokolle aber nicht (in den entsprechenden Anwendungen). Entscheidend ist, dass ein HTTPS-Server _überwiegend_ keine unverschlüsselte Verbindung zu einem anderen Server im Internet aufbaut - warum sollte ein Server-Betreiber in rechenaufwändiges HTTPS investieren, um dann hintenrum diese Sicherheit wieder zu verschenken? - während _überwiegend_ email aus den von dir genannten Gründen auf dem Weg zum Empfänger im Klartext übertragen wird.
Anders gesagt: Wer eine verschlüsselte Anwendung im Internet anbietet, muss bei allen anderen Techniken als HTTPS seine Kommunikationspartner dafür gewinnen, zusätzliche Software und/oder Zertifikate zu installieren. Ich denke also, diese Aussage macht durchaus Sinn bei einem solchen Artikel. Daher hab ich den Satz wieder eingesetzt, bin aber auch für klärende Ergänzungen o.ä. zu haben. --Bernd vdB 20:25, 22. Dez. 2006 (CET)

Konjunktiv oder Indikativ?

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

Verschlüsselung

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)

Und nochmal...

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)

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)

Schlüssellänge

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)

Energieverschwendung?

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)

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)

Zertifikat notwendig

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

--Bernd vdB 15:39, 9. Feb. 2009 (CET)

Nutzen

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

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)

Authentifizierung und Wlan-Kontext

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)

selbst-signierte Zertifikate verwundbar für einen Man-in-the-middle-Angriff

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)

1) Adress-Anfrage ebenfalls verschlüsselt? 2) Artikel für Laien nur teilweise verständlich.

Hallo! Ich bin leider nicht vom Fach und suche nach einer Information, die mir der - für mich zu weiten Teilen unverständliche - Artikel nicht gegeben hat. Vielleicht kann das jemand hier beantworten? Vielleicht fühlt sich auch jemand berufen, einen Abschnitt in den Artikel einzuarbeiten, durch den auch normale Menschen das Prinzip HTTPS verstehen (und vielleicht sogar die wichtigsten Abläufe nachvollziehen) können - dafür schon mal danke!

Die Frage lautet ganz einfach: an welcher Stelle wird die aufgerufene HTTPS-Adresse (Adresszeile des Browsers: "https://...") verschlüsselt und entschlüsselt? Ich verstehe zwar, dass die *Inhalte* einer solchen Kommunikation (Seitentext) verschlüsselt sind, sobald sie den lokalen Rechner verlassen. Aber ich frage mich, ob der Administrator meines Uni-Netzwerkes oder irgendeines Providers nicht zumindest sehen kann, dass ich - mal nur beispielsweise - die Seite "https://secure.wikimedia.org/wikipedia/de/wiki/Hypertext_Transfer_Protocol_Secure" aufgerufen habe.

Über eine baldige und kompetente Antwort würde ich mich sehr freuen, und mehr noch, wenn diese Antwort dann auch zum Teil des Artikels wird. Grüße! -- 195.71.226.87 15:31, 15. Sep. 2010 (CEST)

Dein Provider kann sehen, dass Du eine Verbindung mit der IP 208.80.152.134 aufgenommen hast, und "irgendwas" über diese Verbindung gemacht hast. Er kann sogar eventuell rausfinden, das 208.80.152.134 der Host "secure.wikimedia.org" ist. Aber mehr nicht. --P.C. ✉ 15:35, 15. Sep. 2010 (CEST)
Mann dankt :) -- 195.71.226.87 15:37, 15. Sep. 2010 (CEST)

Mir stellt sich die selbe Frage. Die erste angefragte Adresse kann doch eigentlich noch nicht verschlüsselt sein, denn die Verbindung ist ja noch gar nicht hergestellt. Damit würde sich aber der Gewinn an Privatsphäre ziemlich relativieren. Zur Zeit würde mir nur einleuchten, dass nach dem ersten Verbindungsaufbau die Adressen von aufgerufene Unterseiten verschlüsselt werden. Oder mache ich da einen Denkfehler? Jedenfalls sollte das Thema im Artikel behandlet werden. --84.155.102.164 19:25, 28. Okt. 2010 (CEST)

  1. Die Fragestellung ist durchaus berechtigt.
  2. Der Artikel sollte dahingehend deutlicher gefasst werden und explizit darauf eingehen. Die Antwort steht zwar momentan bereits drin, aber so implizit, dass man sie nur herauslesen kann, wenn man sie schon kennt.
  3. Vor dem gleichen Problem standen die Entwickler von HTTPS damals auch. Es wäre nicht nur der "Dateipfad" wie in der Fragestellung, sondern könnte ja auch mit HTTP #GET lauten
    https://example.com/login.php?kundenr=4711;pw=GEHEIM
    Dies offen zu übertragen wäre schon doof.
  4. Es wird zunächst nur der "Tunnel" zwischen Browser und Server aufgebaut ("SSL-Handshake", Hello-Hello) mittels SSL. Kam dies zustande, beginnt die weitere Kommunikation und es wird der Pfad-Anteil der URL (HEAD, GET), POST-Daten und die Antwort etc. hin und her übertragen.
    Fachidiotisch ausgedrückt: Protokollschichten anschauen,
    • Tunnelbau ist TLS=OSI/4
    • HTTP mit dem GET-Dialog und die damit transportierte Pfad-Übermittlung geschieht bereits in der verschlüsselten Schicht (OSI > 4).
  5. Wenn der Tunnel im Browser erstmal aufgebaut ist, bleibt er meist einige Minuten (je nach Sicherheitsempfinden von Server und Browser; Keep-Alive) für weitere Kommunikation offen. Hat man im Browser weitere Fenster zum selben Server offen, wird der einmal aufgebaute Tunnel dann parallel von allen benutzt, bis er nach einiger Untätigkeit geschlossen wird.
  6. Die Antwort auf die Ursprungsfrage lautet also: Nur der Name der Domain bzw. ab dem ersten DNS die IP ist unterwegs sichtbar; außerdem ist den Relaisstationen klar, dass es sich um HTTPS-Verkehr handelt. Man kann im eigenen Rechner den Domain-Namen des Servers bereits in eine IP umwandeln (hosts); das bringt aber zurzeit wenig, weil bislang jeder Host eine feste eindeutige IP-Adresse haben musste. Wer es will, bekommt aber zu jeder HTTPS-IP-Adresse die Domain und den Betreiber heraus; allerdings könnte das erstmal ein anonymer Dienstleister (etwa Strato AG) sein. Neuere Angebote senden den Hostname offen mit, um mehrere HTTPS-Domains auf einem Server mit einer IP-Adresse zu ermöglichen.
  7. Heißt zusammengefasst: Es lässt sich immer herausfinden, wer mit wem kommuniziert; es lässt sich nicht mitlesen, was; es lässt sich aber sehen, wieviel, und auch einkreisen, wo.
HGZH --PerfektesChaos 12:51, 29. Okt. 2010 (CEST)

Ablauf

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

Abschnitt Technik

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)

Session Hijacking beim HTTP-Cookie

Wenn man nur die Anmeldung über HTTPS vollzieht und die eigentliche Sitzung über HTTP läuft, hat ein Angreifer (bei offenen oder gehackten WLANs bzw. als Man In The Middle) sehr leicht, die Cookies für sich zu übernehmen und die Session zu hijacken. --77.4.68.20 12:20, 4. Sep. 2011 (CEST)

Das ist richtig; was möchtest du uns damit sagen?
Die Idee ist natürlich, dass man nach der Anmeldung in HTTPS bleibt.
Deswegen sind auch eingebundene Ressourcen über http problematisch; neben unmittelbarer Angriffsmöglichkeit über eine manipulierte http-Ressource kann ein Lauscher auch schon aus der Art abgerufener http-Ressourcen Rückschlüsse darauf ziehen, was in der Sitzung passiert. Deshalb melden Browser standardmäßig, wenn in einer https-Seite Einbindungen oder Aufrufe nach http (insbesondere der gleichen Domäne) erfolgen.
--PerfektesChaos 14:13, 4. Sep. 2011 (CEST)

Zum Punkt Leistung

"Die Verschlüsselung auf Serverseite ist rechenaufwändig und belastet die Server-CPU häufig stärker als etwa die Errechnung des HTML-Codes aus einer Skriptsprache inklusive Datenbank-Zugriff. Auch aus diesem Grunde hat sich HTTPS bisher nur bei einem kleinen Teil der Websites durchgesetzt, bei denen es aus Sicht des Datenschutzes sinnvoll ist."

Das ganze ist doch ein, nunja, doch etwas schwer-vorstellbares Beispiel. Da wäre es wohl angemessener das Ganze an einem normalen HTTP-Request ohne SSL zu messen. (nicht signierter Beitrag von 84.130.90.49 (Diskussion | Beiträge) 16:02, 11. Aug. 2008 (CEST))

Aus welchem Jahr und für welche Prozessoren stammt eigentlich die Aussage, die CPU würde durch die Verschlüsselung "häufig stärker" belastet; und kann man dafür vielleicht eine Referenz anführen? Von Admins habe ich mal gehört, der Gewinn durch die Datenkompression sei höher als der Verlust durch Rechenaufwand (auf beiden Seiten!) für die Ver-/Entschlüsselung, die HTTPS-Verbindung somit schneller als die HTTP-Verbindung. Aber ausprobiert habe ich es noch nie. -- 15:17, 14. Jun. 2011 (CEST)
Außerdem errechnet der Server kein HTML Code aus einer Skriptsprache, grundsätzlich.--78.43.167.176 18:09, 12. Sep. 2011 (CEST)
Seit wann wird bei SSL/TLS was komprimiert? Verwechselst du das mit Gzip? --Bachsau 04:48, 23. Feb. 2012 (CET)
IP bezieht sich auf RFC 2246 (Abschnitt 6.2.2.). Richtig ist die Beobachtung, dass in den vom Server oder im Umfeld des Client aus beobachtbaren Datenvolumina HTTPS regelmäßig geringeren Umfang hat als aussichtsreich komprimierbare Daten per HTTP.
Die Aussage ist insofern nicht Stand der Technik, als etwa via Compression Control Protocol bei HTTP eine auf Anwenderebene nicht sichtbare Kompression der später real durch die Leitung flutschenden Datenmenge erfolgt. Wo es möglich ist, wird immer Kompression versucht.
Was im Artikel die Darlegung „Errechnung des HTML-Codes aus einer Skriptsprache“ soll, und was insbesondere die ‚Skriptsprache‘ hier meint, bleibt mir aber auch verborgen. Was man uns sagen will, ist „Generierung des Content“, und der Aufwand für Datenbankzugriffe. Somit die unvermeidliche Serverbelastung auch schon für HTTP.
VG --PerfektesChaos 10:02, 23. Feb. 2012 (CET)

SNI

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)

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.121.23 16:50, 19. Aug. 2012 (CEST)

Kannst Du einfach selber ausprobieren. Einfach eine x-beliebige Seite mit https aufrufen (bei mir ging es gerade z.B. auch mit der WAZ. Dann kommt die Abfrage (hier Firefox, IE & Co arbeiten synonym).
  • Neues Zertifikat.jpg

    Anzeige SSL-Server-Zertifikat

    • Du hast nur die Wahl, das Zert. anzunehmen (temporär oder dauerhaft) oder mit "Diese Seite verlassen" auf Deine im Browser eingestellte Seite zurückgelegt zu werden.
    Allerdings kann es auch passieren, dass nur Teile der Kommunikation verschlüsselt werden, was dann aber auch vom Browser gemeldet wird. Grundsätzlich kannst Du aber mit dem kleinen Vorhängeschloss in der Adresszeile des Browswer erkennen, ob Du noch verschlüsselt unterwegs bist. Bei WAZ z.B. ist nach dem Aufruf der Seite schon wieder Schluß mit der Verschlüsselung. Beantwortet das Deine Frage? --Dipl-Ingo (Diskussion) 08:12, 19. Okt. 2012 (CEST)
    Auch wenn Du das fehlerhafte Zertifikat akzeptierst ist die gesamte Verbindung zu diesem Server verschlüsselt. Es kann sein, dass das Zertifkat abgelaufen ist, der Server einen Namen hat der nicht im Zertifikat steht oder das Zertifikat nicht von einer gültigen Zertifizierungsstelle kommt (z.B. selbst erstellt). Wenn Du ein Zertifikat annimmst in dem ein anderer Servername steht dann läufst Du Gefahr Dich mit einem Server zu unterhalten den Du nicht ansprechen wolltest. Dies ermöglich einem Dritten einen Man-in-the-middle-Angriff sofern Dein Traffic auf Netzwerkkomponenten vorbeikommt auf die er Zugriff hat oder die er per ARP-Spoofing manipulieren kann. Unabhängig davon kann die angefragte Seite aber immer auch Inhalte enthalten die (von einem anderen Server kommen und) nicht verschlüsselt sind. In diesem Fall warnt der Browser aber mit einer Meldung. Viele Grüße --Marsupilami (Disk|Beiträge) 08:49, 19. Okt. 2012 (CEST)
    Stellt sich mir die Frage, ob das nicht noch ein paar Sätze in einem Kapitel "Sicherheit" (o.Ä.) angebracht wären. Die Frage war ja nun nicht gerade exotisch. --Dipl-Ingo (Diskussion) 09:44, 19. Okt. 2012 (CEST)
    • Die inhaltliche Textstelle beginnt bereits mit Um diese sehen zu können, muss der Anwender dann explizit eine „Ausnahme hinzufügen“. (was FF-lastig ist bei IE; allgemeiner formulieren)
    • Den Artikel kann man gern ergänzen. Zwar behandelt er laut Überschrift das technische Protokoll, aber die Auswirkungen auf den Normalanwender und seinen Browser kann man durchaus darstellen. (Dass „client“ meint: „Browser“, ist auch nicht jedem Normal-Leser der WP klar; könnte an dieser Stelle mal wieder deutlicher gemacht werden.) Die vor zwei Monaten gestellte Frage ist durchaus für unsere Leser interessant (Lebenshilfe); nur sollte man für diese ganze Situation einen neuen Absatz beginnen und ihn nicht auf IE beschränken.
    • Technisch ist es durchaus so, dass je nach Implementierung auf dem Server der weitere Verkehr auch ohne ein Zertifikat unverschlüsselt oder verschlüsselt oder teils/teils weiterlaufen kann. Es ist lediglich die Frage, mit wem man da kommuniziert. Die Gültigkeit von Zertifikaten ist nur ein Service der Browser-Programmierer, dem Endanwender mitzuteilen, dass diese Verbindung einen sicheren Eindruck macht. Ob bei fehlendem Zertifikat der Browser dem Anwender die weitere Kommunikation erlaubt oder nicht, ist letztlich eine Konfigurationsfrage, mit der man ahnungslose Anwender vor Angriffen schützen möchte. Es ist schon ganz okay, in dieser seltsamen Situation nur auf besondere Anweisung eine weitere Verbindung zu ermöglichen. – Nett ist übrigens auch, das Systemdatum zu verstellen und ein Jahr in der Zukunft zu sein; hatte mich dabei mal vertippt und staunte, warum ich nirgendwo mehr rankam.
    Grüße --PerfektesChaos 10:18, 19. Okt. 2012 (CEST)
    So, denn man ran an den Speck. Ich habe mal vorgelegt, bin aber noch nicht zufrieden mit den Formulierungen. Ihr dürft das jetzt noch sezieren. --Dipl-Ingo (Diskussion) 13:44, 19. Okt. 2012 (CEST)
    Die WP ist ja eine Enzyklopädie - und keine Stelle, wo alle (sei es sinnvollen) Fragen beantwortet werden, denn dafür gibt es FAQs und Experten-Hilfe-Seiten im Netz zuhauf; auch Screenshots für einzelne Bedienschritte sind in der WP nicht sinnvoll. Hier geht es darum, die Fakten zusammenhängend darzustellen.
    Sorry, in dem Kapitel "Sicherheit im Browser" wurde einfach vieles wiederholt, was anderer Stelle schon stand, offenbar ohne vorher den Artikel durchzulesen. Einige Aussagen daraus und ref aus diesem Kapitel habe ich an diesen Stellen eingefügt, dann aber den Absatz wieder entfernt.
    Grundsätzlich bitte sorgfältiger vorgehen, bevor man einen fachlich gut abgehangenen Text erweitert. Nix für ungut --Bernd.Brincken (Diskussion) 00:14, 31. Dez. 2012 (CET)

    Browser, die https nicht unterstützen

    Ich lese derzeit häufiger, dass der https-Zwang durch den Server häufig nicht "eingeschaltet" wird, weil angeblich manche Browser damit nicht umgehen können. Da es https schon ewig gibt, kann ich mir nicht vorstellen, dass das wirklich von Bedeutung ist. Oder gibt es wichtige Nischenbrowser/-anwendungen, die nicht ausgesperrt werden sollen? Welche wären das? Gruß, IP 92.231.217.233 02:48, 11. Jan. 2014 (CET)

    Es mag sein, dass es irgendwelche Nischenmaschinen gibt, die das nicht können.
    Praxisrelevant ist das nicht; der wirksame Bestand kann das zu 99,9 +X Prozent.
    Mobilgeräte hatten vor etlichen Jahren mal Probleme, die in die von dir skizzierte Richtung gingen. Das hat sich erledigt; Mobilgeräte haben kurze Lebensdauer, und die fragliche Generation ist lange verschrottet und nimmt nicht mehr relevant am Geschehen teil.
    LG --PerfektesChaos 23:03, 26. Feb. 2014 (CET)

    Anderes Beispiel als die Hauptseite von Wikipedia möglich?

    Hallo zusammen,

    wäre es evtl. möglich im Abschnitt Varianten der HTTPS-Anwahl (vierter Punkt) ein anderes Beispiel als die Hauptseite der Wikipedia zu verwenden?

    Ich frage deshalb, weil die WP:WPSK-Prüfung immer diesen Artikel moniert und zwar den Fehler mit der ID 90, siehe hier.

    Unwissenderweise habe ich das vor ein paar Tagen mittels WPCleaner schon mal geändert (also in die internen Links [[Wikipedia:Hauptseite|Hauptseite]]) und es wurde natürlich revertiert, weil das Beispiel ja sonst keinen Sinn machen würde.

    Es müsste aber doch durchaus möglich sein, eine Wikipedia-fremde Seite als Beispiel zu nehmen, oder?

    Gruß --Udo T. (Diskussion) 19:34, 4. Sep. 2014 (CEST)

    WP ist so eine art standardbeispiel, das finde ich auch gut so. ich faende es seltsam, wenn wir uns das beispiel von einem tool diktieren lassen. der bessere weg waere, in dem tool eine ausnahme einzufuegen. --Mario d 21:18, 4. Sep. 2014 (CEST)
    Habe nun eine Ausnahme für diese Seite hinterlegt, siehe hier. Ich hoffe mal, dass das dort niemand wieder rückgängig macht.
    Gruß --Udo T. (Diskussion) 11:43, 20. Sep. 2014 (CEST)

    Überarbeiten: IP-Adresse

    Bitte den Abschnitt mal überarbeiten. Der ist 1. irreführend, weil offenbar zweimal das gleiche gesagt wird (?) und außerdem nicht auf der Höhe der Zeit ("der neueren Spezifikation Transport Layer Security 1.2" - Stand 2008). --2A02:908:EB21:D100:C8AE:A638:3CFC:EEFC 01:05, 1. Okt. 2015 (CEST)

    • Wenn es dir nur um die Vokabel „neueren“ ging – okay, das war mal neu, als unser Autor den Abschnitt eingefügt hatte; jetzt nicht mehr und ersetzt.
    • Deinen anderen Punkt habe ich nicht verstanden. Es geht einmal um verschlüsselte und einmal um unverschlüsselte Verbindungen.
    VG --PerfektesChaos 10:33, 1. Okt. 2015 (CEST)

    Was wird denn verschlüsselt?

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

    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)

    Fingerprint

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

    Warum jetzt, wo spielt das bei HTTPS eine Rolle? --Bernd.Brincken (Diskussion) 00:25, 10. Mär. 2017 (CET)

    Root-Chains

    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)

    Done. --Bernd.Brincken (Diskussion) 00:24, 10. Mär. 2017 (CET)

    Self-Signed Certs

    Der Abschnitt zu selbst-signierten Zertifikaten wurde geändert auf: "Bei einem so erstellten Zertifikat garantiert nicht unmittelbar ein Dritter die Authentizität des Anbieters, wodurch durch falsches Benutzerverhalten ein Erfolg eines Man-in-the-middle-Angriffs wahrscheinlicher ist." Die Begründung erscheint mir zu kompliziert. 1. Wozu "unmittelbar"? Ein Dritter (CA) ist nicht im Spiel, nicht mittel- und auch nicht unmittelbar. 2. Wieso wird die Gefahr eines MTM-Angriffs durch falsches Benutzerverhalten größer? Ohne Prüfung der Authentizität hat der Nutzer schlicht keine Sicherheit, wer ihm gegenüber sitzt. Sein Verhalten spielt dafür keine Rolle. Der Autor der Änderung hat offenbar ein bestimmtes Szenario im Hinterkopf, das aber nicht erklärt wird. Dann kann man dazu einen eigenen Artikel schreiben, und den dann hier verlinken. --Bernd.Brincken (Diskussion) 09:41, 29. Jul. 2017 (CEST)

    Trifft so auch schlicht nicht alle Anwendungszenarien. Der Nutzer kann auch eine eigene CA aufsetzen und diese auf den legitimen Clients hinzufügen. Ist in Firmen ein weit verbreiteter Mechanismus. Das Risiko eines Man-in-the-middle-Angriffs wird dadurch sogar noch reduziert, wenn gleichzeitig Zertifikatspinning genutzt wird (da die CA unter eigener Kontrolle steht und sich nicht auf einen Dritten verlassen werden muss). Anders sieht es natürlich bei öffentlichen Diensten aus. --Häuslebauer (Diskussion) 14:21, 29. Jul. 2017 (CEST)
    1. Ein Dritter kann auch bei selbst signierten Zertifikaten bestätigen, dass das Zertifikat wirklich vom Anbieter stammt. Das geht dann eben nicht über Zertifizierungsstellen, sondern zum Beispiel, indem jemand, der den Anbieter persönlich kennt und das Zertifikat darüber verifiziert hat (oder sogar einfach der Anbieter selbst), den Fingerprint des Zertifikats über einen bestehenden sicheren Kommunikationsweg (z.B. per Veröffentlichung auf einer anderen, ausreichend gesicherten Website) dem Nutzer bekannt gibt.
    2. Das Auslassen der Prüfung ist bereits falsches Benutzerverhalten. Wenn jemand bei einem CA-signierten Zertifikat bei einem MitM-Angriff eine entsprechende Fehlermeldung ignoriert ist das genauso auch "nur" falsches Benutzerverhalten. Die Frage ist eher andersrum: Wieso wird ein MitM-Angriff wahrscheinlicher erfolgreich, wenn sich der Nutzer korrekt verhält?
    3. Die Version nach deiner Änderung ist also für mich diesbezüglich in Ordnung, lediglich stört mich das „kostenlos“ etwas: Oh, ich kann Textdokumente auf meinem eigenen Rechner kostenlos erstellen? Wie überraschend! Nein, kann ich nicht, kostet Strom, leider.
    --nenntmichruhigip (Diskussion) 21:01, 29. Jul. 2017 (CEST)
    Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Hypertext_Transfer_Protocol_Secure/Archiv&oldid=210782285“