Warum jede Internetseite per HTTPS (SSL/TLS) verschlüsselt sein sollte

[shortrange]

Hallo,

vor kurzem habe ich mich mit einigen Webmastern unterhalten, die der Meinung waren, die Verschlüsselung von Internetseiten per HTTPS sei nur vereinzelt sinnvoll. Damit dich diese Webmaster beim nächsten Gespräch mit Fakten überzeugen kann, ihre gesamte Website zu verschlüsseln, habe ich diesen Post erstellt. Sozusagen als Hilfe für mich selbst. Warum habe ich mir den Text nicht einfach selbst per E-Mail geschickt? Weil ich mir sicher bin, dass auch andere noch ein paar Argumente brauchen, um Menschen in den jeweiligen Positionen davon zu überzeugen, HTTPS zu verwenden und das Internet dadurch ein Stück weit sicherer zu machen.

Was ist HTTPS?

Hypertext Transfer Protocol Secure (HTTPS, englisch für „sicheres Hypertext-Übertragungsprotokoll“) ist ein Kommunikationsprotokoll im World Wide Web, um Daten abhörsicher zu übertragen. Es stellt eine Transportverschlüsselung dar.

Quelle: https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure

HTTPS basiert zum einen auf dem Übertragungsprotokoll HTTP (siehe https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol) sowie einer zusätzlich Verschlüsselung mittels TLS, besser bekannt unter der veralteten Bezeichnung SSL (siehe https://de.wikipedia.org/wiki/Transport_Layer_Security). HTTPS ist also „HTTP over TLS“.


Der Nutzen von HTTPS - Wikipedia

HTTPS wird zur Herstellung von Vertraulichkeit und Integrität in der Kommunikation zwischen Webserver und Webbrowser (Client) im World Wide Web verwendet. Dies wird unter anderem durch Verschlüsselung und Authentifizierung erreicht.

Ohne Verschlüsselung sind Daten, die über das Internet übertragen werden, für jeden, der Zugang zum entsprechenden Netz hat, als Klartext lesbar. Mit der zunehmenden Verbreitung von offenen (d. h. unverschlüsselten) WLANs nimmt die Bedeutung von HTTPS zu, weil damit die Inhalte unabhängig vom Netz verschlüsselt werden können.

Die Authentifizierung dient dazu, dass beide Seiten der Verbindung beim Aufbau der Kommunikation die Identität des Verbindungspartners überprüfen können. Dadurch sollen Man-in-the-Middle-Angriffe und teilweise auch Phishing verhindert werden.

Quelle: https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure#Nutzen

Warum HTTPS für jede Website sinnvoll ist - snowflake Blog

Die Annahme ist weit verbreitet, dass HTTPS nur bei Webseiten mit Logins oder sensiblen Daten sinnvoll ist. Warum soll ein Blog verschlüsselt übertragen werden, obwohl der Inhalt sowieso von jedem gelesen werden darf? Einerseits wird durch die Verschlüsselung ebenfalls der Zugriff auf die Administrationsoberfläche (TYPO3 Backend, WordPress Admin, usw.) verschlüsselt, andererseits stellt HTTPS nicht nur die Verschlüsselung von Inhalten sicher sondern garantiert auch die Echtheit der übertragenen Daten. Sprich: Es wird gewährleistet, dass beim Besucher auch die Daten ankommen, welche der Server wirklich abgeschickt hat.

Dass Inhalte während der Übertragung manipuliert werden, kommt dabei häufiger als vermutet vor. Beispielsweise sind Netzbetreiber bekannt, welche zusätzliche Cookies in die Übertragung einschleusen, um das Nutzerverhalten zu untersuchen. Oder es wird in öffentlichen WLANs, wie sie häufig in Cafés vorkommen, Malware in die Übertragung eingefügt. Auch freie Proxys welche häufig zum Einsatz kommen, um den User zu anonymisieren, sind eine potenzielle Gefahrenquelle.

Quelle: https://blog.snowflake.ch/2015/01/23/warum-https-fuer-jede-website-sinnvoll-ist/

Netzverschlüsselung: Mythen über HTTPS - Golem

Mythos: HTTPS-Verschlüsselung für reine Inhalte ist nutzlos
Mythos: Zertifikate sind zu teuer
Mythos: HTTPS ist viel zu langsam
Mythos: Bei HTTPS benötigt man eine eigene IP für jeden Domainnamen
Mythos: Die Zertifizierungsstellen geben alle privaten Schlüssel an Geheimdienste weiter
Mythos: Es ist wichtig, dass ich das Zertifikat bei einer vertrauenswürdigen Zertifizierungsstelle erhalte
Mythos: Das System der Zertifizierungsstellen ist korrupt, daher ist HTTPS nutzlos
Die wirklichen Gründe: Inhalte von Drittanbietern
Fazit: Die Zukunft ist verschlüsselt

Quelle: https://www.golem.de/news/netzverschluesselung-mythen-ueber-https-1412-111188.html

Google Online Security Blog: Moving towards a more secure web - Google Blog

Starting January 2017, Chrome 56 will label HTTP pages with password or credit card form fields as "not secure," given their particularly sensitive nature.

In following releases, we will continue to extend HTTP warnings, for example, by labelling HTTP pages as “not secure” in Incognito mode, where users may have higher expectations of privacy. Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS.

Quelle: https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html

Siehe auch: Website mit HTTPS sichern - Google Search Console-Hilfe


Pierre Far, ehemaliger Produktmanager bei Google - Y Combinator

I was involved in this launch and I want to address a very common misconception I'm seeing here and elsewhere.

Some webmasters say they have "just a content site", like a blog, and that doesn't need to be secured. That misses out two immediate benefits you get as a site owner:

1. Data integrity: only by serving securely can you guarantee that someone is not altering how your content is received by your users. How many times have you accessed a site on an open network or from a hotel and got unexpected ads? This is a very visible manifestation of the issue, but it can be much more subtle.

2. Authentication: How can users trust that the site is really the one it says it is? Imagine you're a content site that gives financial or medical advice. If I operated such a site, I'd really want to tell my readers that the advice they're reading is genuinely mine and not someone else pretending to be me.

On top of these, your users get obvious (and not-so-obvious) benefits. Myself and fellow Googler and HNer Ilya Grigorik did a talk at Google I/O a few weeks ago that talks about these and a lot more in great detail:

https://youtu.be/cBhZ6S0PFCY

Quelle: https://news.ycombinator.com/item?id=8146670

Official Google Webmaster Central Blog: HTTPS as a ranking signal

For these reasons, over the past few months we’ve been running tests taking into account whether sites use secure, encrypted connections as a signal in our search ranking algorithms. We've seen positive results, so we're starting to use HTTPS as a ranking signal. For now it's only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content — while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.

Quelle: https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html

Siehe auch: https://www.cekom.de/70n307/HTTPS-–-Warum-die-Verschluesselung-von-Websites-Sinn-macht.htm

Stimmt ihr soweit mit den oben genannten Inhalten und Argumenten überein? Habt ihr noch weitere Argumente? Ich freue mich über Eure Rückmeldungen und in Zukunft immer mehr verschlüsselte Websites!

 

[azereus]

welche argumente haben denn diese webmaster verwendet?
das würde uns alle mal interessieren.

als gegenargument kann gerne https://letsencrypt.org/docs/ genannt werden
ja da hat man dann alle 3 monate etwas aufwand
bei einem kostenpflichtigen zertifikat von einer zertifizierungsstelle hat man je nach gültigkeitsdauer den aufwand und etwas geld zu investieren

 

[brutzler]

ja da hat man dann alle 3 monate etwas aufwand

Naja den Aufwand hat cron nicht ich. Einfach alle 2 Monate Auto renew.

 

[shortrange]

welche argumente haben denn diese webmaster verwendet?

Es ging um die Internetseite einer Firma, die bereits zum Teil verschlüsselt ist. Die Login-Seite für das Intranet bzw. einen geschützten Bereich sowie der gesamte geschützte Bereich sind verschlüsselt.

Nur der öffentlich zugängliche Teil der Webseite müsse angeblich nicht verschlüsselt werden, weil dort ja kein sensibler Content sei. Etwaiger Wortlaut: "Es ist doch sowieso für die Öffentlichkeit bestimmt, da kann doch gerne jeder mitlesen."

 

[Evil E-Lex]

Die letzte Aussage (ist doch öffentlich und eh nichts sensitives drauf) wird hier widerlegt.

 

[coolmodi]

Nur der öffentlich zugängliche Teil der Webseite müsse angeblich nicht verschlüsselt werden, weil dort ja kein sensibler Content sei. Etwaiger Wortlaut: "Es ist doch sowieso für die Öffentlichkeit bestimmt, da kann doch gerne jeder mitlesen."

Also das ist dann irgendwie einfach dämlich

HTTPS bringt afaik auch Pluspunkte bei Google, neben den anderen Vorteilen, also wenn man eh ein Zertifikat hat macht es keinen Sinn es nicht zu verwenden.

 

[iGameKudan]

Andere Frage, wieso sollte man denn nicht HTTPS nutzen?
Im PCGH-Forum wird für die Nichtnutzung von HTTPS leider die liebe Werbung als Grund genannt, HTTPS-Werbung scheint wohl noch eher die Ausnahme zu sein. Ansonsten würde ich nur Faulheit sagen, sonst gibt es doch mittlerweile sogar kostenfreie Zertifikatsstellen?...

 

[RalphS]

Unser täglich Brot der SSL-Paranoia gib uns heute

JA, man *kann mit HTTPS ausrollen.

NEIN, man *muß es nicht.

Die verlinkten Texte sind gut und schön, bleiben aber leider eine plausible Erklärung schuldig. "HTTPS ist kein Nachteil" ist KEIN Argument für "nehmt das alle".

Nehmen wir uns nur mal ein Argument:
RICHTIG ist: technisch gibt es keinen Unterschied zwischen DV und EV.
FALSCH ist: Das hat keine Auswirkungen.

Aber das Lustigste - für mich -- ist, daß alle nach Datenschutz und Anonymität schreien... und, mh, dabei gar nicht zu merken scheinen, daß SSL/TLS insbesondere auf Authentifizierung und damit Identifizierung aufbaut. Das schließt sich also gegenseitig aus.


TLDR? Schluß mit der Überzeugungsarbeit. Wenn irgendwelche Admins -oder wer anders- SSL einsetzen will, okay. Wenn sie keins einsetzen wollen, auch okay. Dann kann man noch eine Diskussion anstoßen, was die Beweggründe waren... aber dann ist Schluß.

 

[shortrange]

Die letzte Aussage (ist doch öffentlich und eh nichts sensitives drauf) wird hier widerlegt.

Schöne Seite! (https://doesmysiteneedhttps.com/)

Nehmen wir uns nur mal ein Argument:
RICHTIG ist: technisch gibt es keinen Unterschied zwischen DV und EV.
FALSCH ist: Das hat keine Auswirkungen.

Was sind DV und EV?

Schluß mit der Überzeugungsarbeit. Wenn irgendwelche Admins -oder wer anders- SSL einsetzen will, okay. Wenn sie keins einsetzen wollen, auch okay. Dann kann man noch eine Diskussion anstoßen, was die Beweggründe waren... aber dann ist Schluß.

Was stört dich an der Überzeugungsarbeit so sehr?

 

[RalphS]

Domain Validation und Extended Validation.

Das ist die Überprüfung des Antragstellers. Ist der, der das Zertifikat haben will, auch der, der er behauptet, zu sein? In etwa vergleichbar mit dem Personalausweisantrag.

Diese Prüfung kann so simpel und so komplex ausfallen, wie man sichs nur vorstellen kann. Entweder ein kurzer Blick "ja könnt scho sei" (DV) oder eine eingehende Prüfung bis aufs Unterhemd, ob man nicht doch irgendwie...

Mit HTTPs bereitstellen heißt ein Zertifikat haben, und ein Zertifikat haben heißt, von der Zertifizierungsstelle beäugt und für vertrauenswürdig befunden zu sein.

Phisher "sollten" deshalb kein Zertifikat bekommen "können".

Note: Sollte(n), weil mit DV und Letsencrypt die Überprüfungen eher ad absurdum geführt werden und mein Gegenüber sonstwer sein könnte.

 

[snaxilian]

Siehe die Diskussion hier auf die du scheinbar nicht mehr reagierst: https://www.computerbase.de/forum/threads/guenstige-ssl-zeritifikate-empfehlenswert.1703752/page-2

Bei einem DV geht es nach wie vor nicht darum die Identität des Domainbesitzers zu überprüfen sondern nur die Identität der Domain (jaja unter der Voraussetzung, dass der private Schlüssel nicht kompromittiert ist).
Eben um sicherzustellen, dass https://www.computerbase.de wirklich Computerbase.de ist und nicht dass fremder Content eingeschleust wurde, z.B. durch einen Proxy oder eine böswillige Man in the Middle Attacke in einem öffentlichen WLAN im Cafe um die Ecke. Es stellt eben nur sicher, dass die von mir empfangenen Daten von Computerbase.de und dem dazugehörigen Server stammen. Natürlich unter der Annahme, dass niemand die Kontrolle über den Server oder die DNS-Einstellungen der Domain übernommen hat.

Ja mir ist völlig egal wer persönlich hinter computerbase.de steht aber nein es ist mir nicht völlig egal ob jemand in die Seite fremden Content einschleust. Ich "vertraue" daher der Domain, nicht der Person dahinter.
Ich empfehle dazu auch die Lektüre hiervon: https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas-phishing-lets-encrypt/

Und deine Abneigung ggü Let's Encrypt: Glaubst du wirklich, dass die ganzen anderen CAs tatsächlich eine manuelle und menschliche Überprüfung durchführen, die du ja anscheinend bei LE vermisst? Ich sehe auch keinen Unterschied darin ob ich den Prozess der Zertifikatausstellung und -erneuerung per ACME-Client automatisiert durchführe oder ob ich von Hand einmal im Jahr oder so auf die Mail von Symantec/Verisign/sonstige-CA klicke oder mir dies skripte?

Was sollte eigentlich Phisher davon abhalten sich bei einer CA entsprechende Zertifikate zu holen? Nur weil dann auch combuterbase.de ein Zertifikat hat. Ja, ich stimme dir dahingehend zu, dass mir so mein Vertipper ggf. nicht sofort auffällt aber bei interessanten Phishing-Seiten (Paypal, Amazon, Ebay, Banken, etc) werden die 15-20 € pro Domain kaum Phisher aufhalten. Den Mailserver entsprechend für eine Phishingdomain ist schnell aufgesetzt.
Fun Fact: Auch LE geht gegen Phishing-Zertifikate vor, siehe den von mir geposteten Link ein paar Zeilen höher.

 

[RalphS]

Mir ist es auch völlig egal. Das ist auch der Grund, warum ich mich "dort" ausgeklinkt hab.

Nur soviel: SSL basiert auf Vertrauen und wo kein Vertrauen, da kein Sinn, SSL zu verwenden. Solche Seiten wie die verlinkten suggerieren das ja schon.

Wenn ich meinem Gegenüber mißtraue... warum soll ich dann mit ihm ins Gespräch kommen?

Aber, wie schon angedeutet: Nur zu. SSL verwenden ist ja nicht per se schädlich. Aber man muß eben auch andere Meinungen akzeptieren. Niemand hat das Recht zu sagen: nimm das sonst bist Du XXX.

 

[snaxilian]

Ich unterhalte mich gern mit Menschen die ich nicht kenne oder denen ich nicht vertraue (eben weil ich sie ggf. nicht gut kenne), aber je nach Thema möchte ich mich vertraulich mit diesen neuen und mir unbekannten Menschen unterhalten ohne dass Dritte mithören oder -lesen können und genau das bietet ein SSL/TLS.

Beispiel: Ich gehe zu einem mir neuen Arzt und rede mit dem über eine mich betreffende Krankheit oder Diagnose. Ich kenne mein Gegenüber also noch nicht und gewähre ihm ein Vertrauensvorschuss. Ich unterhalte mich mit ihm über die Optionen und Auswirkungen div. Therapien. Nichtsdestotrotz möchte ich nicht, dass andere Patienten diese Unterhaltung mitbekommen. Daher geschlossene Tür des Besprechungsraums. Der Arzt hat nur sein Namensschild was identisch ist mit dem der an der Tür steht. Keine superduper Validierung wer mein Gegenüber ist aber die Kommunikation zwischen Sender und Empfänger ist vertraulich.

Zweites Beispiel: Ich möchte eine Unregelmäßigkeit melden die mir im Beruf auffällt. Also kontaktiere ich den Betriebsrat. Diesen kenne ich bis dato nicht persönlich. Damit aber mein Chef dies nicht direkt mitbekommt, rede ich nicht öffentlich mit ihm in der Kantine.
Ich schaue im Intranet wie die Mitglieder des Betriebsrates aussiehen und suche diese dann in ihren Büros auf. Mensch sieht ähnlich/identisch zu Foto aus Intranet aus. Ich rede leise bei geschlossener Tür in seinem Büro mit ihnen. Identität oberflächlich bestätigt (vergleichbar zu LE oder anderen kostenlosen Zertifikaten) aber die Kommunikation ist vertraulich.
Ich vertraue also den Büroräumen des Betriebsrates mehr oder weniger, nicht den nach jeder Wahl gefühlt wechselnden Personen. Wichtiger ist mir, dass diese Kommunikation zwischen mir und wer auch immer im Betriebsratsbüro sitzt vertraulich ist und nicht von Dritten mitgehört werden kann.

 

[Der-Orden-Xar]

Aber das Lustigste - für mich -- ist, daß alle nach Datenschutz und Anonymität schreien... und, mh, dabei gar nicht zu merken scheinen, daß SSL/TLS insbesondere auf Authentifizierung und damit Identifizierung aufbaut. Das schließt sich also gegenseitig aus.

Dann sag mal, wo genau der Widerspruch ist. Mir fallen nur zwei Möglichkeiten ein, via https jemanden zu tracken, Methode 1 setzt Mitarbeit des "Opfers" voraus, Methode 2 ist eher abstrakt und auffällig.
Sonst noch irgendwas, was du da siehst?

Wenn ich meinem Gegenüber mißtraue... warum soll ich dann mit ihm ins Gespräch kommen?

Aber man muß eben auch andere Meinungen akzeptieren. Niemand hat das Recht zu sagen: nimm das sonst bist Du XXX.

um den Text über mir zusammenzufassen: TLS hat auch nichts mit dem Vertrauen der Gegenstelle zu tun, sondern mit dem Weg dazwischen.

Hat dein ISP gerade Lust, dir seine Werbung unterzujubeln, egal auf welcher Seite du bist? Kein Problem ohne TLS (so bereits geschehen in den USA vor ein paar Jahren)?
Du meldest dich an einem öffentlichen Hotspot irgendwo an? Dann hoffentlich nur mit einem vertrauenswürdigem VPN oder via TLS.

Achja: Andere Meinungen wollen manchmal auch begründet sein und bisher sehe ich keinen Grund zu sagen "Bleib ruhig bei http"

 

[RalphS]

Ich weiß nicht, aber ich habe das unbestimmte Gefühl, daß da ein Mißverständnis vorliegt. Jedenfalls kriege ich den Eindruck, wenn ich mir Deine Beispiele anschaue.

Betriebsrat. Der befindet sich im Betrieb. Es gibt also eine gewisse Vertrauensbasis. Auch dadurch, daß andere im Betrieb den ja auch kennen - andere Kollegen, denen Du vertraust, wodurch Du mehr oder weniger implizit dieses Vertrauen überträgst (meine Kollegen sagen der ist gut, also vertrau ich dem einfach mal).

Ganz ähnliches gilt für den Arzt auch. Du läßt Dich ja nicht von jemandem behandeln, der sagt, er sei Arzt, wenn Du feststellst, daß er irgendwo im Hinterhof mit einer Kettensäge operieren will.

Im Netz gibt es diese Möglichkeit nicht. Es gibt keinen Gegenüber, den man pauschal identifizieren könnte. Wenn da also jemand ist, der mit mir (oder sonstwem) Geschäfte machen will, dann muß dieser Jemand zunächst dafür sorgen, daß er als legitimer Geschäftspartner erkennbar ist.

Achte einfach mal bissel drauf. Mehr und mehr Websites, die irgendwas mit "an den Mann bringen" zu tun haben, setzen auf EV. Ganz einfach deswegen, damit die Gegenüber wissen: aha, das ist ein *seriöser* Geschäftspartner.

Der Rest gehört natürlich integral dazu, untermauert das aber erst: Sinnlos, erst dafür zu sorgen, einen Unbekannten zunächst als legitimen Geschäftspartner zu identifizieren, wenn man dann nicht dafür sorgt, daß diese Identifikation erhalten bleibt.


Denn am Ende des Tages ist ein Zertifikat nicht so verschieden von dem erwähnten Personalausweis, der mich als Betreiber eines Angebotes identifiziert. Lasse ich es zu, daß mir "irgendjemand" einen PA ausstellt? Oder lasse ich das nur vertrauenswürdige Instanzen machen? Weiter: Wenn ich jemanden hab mit einem PA (= einem Zertifikat) und der baut Mist (=phisht oder was weiß ich) dann kann ich den anhand seines PAs (Zertifikats) identifizieren. Gut für uns als Endverbraucher; schlecht für denjenigen, der Mist bauen will.

Haken daran: Dazu muß ich das Vertrauen erstmal haben in das System. Und: ich muß dafür sorgen, daß dem Zertifikatsbesitzer auch klar ist, daß da mehr dranhängt als nur ein HTTPS vor dem URI

Oder ich drehe das rum und sage, jeder kann ein Zertifikat kriegen. Jeder kann sagen, das bin ich, aber überprüfen kann man es nicht mehr. Einfach deswegen, weil die Brücke real-zu-virtuell (also Webangebote) fehlt: Es gibt dann (zB mit DV) keine Bindung der 'realen' Legitimität an die 'virtuelle'.

Mit dem Ergebnis, daß Du https://mein.betriebsrat.de aufrufst, Dir aber trotzdem nicht sicher sein kannst, beim Betriebsrat zu landen. Das könnt ganz genausogut irgendein Kellerkind sein. Oder der Chef selber, den Du ja eigentlich 'umgehen' wolltest.


Nachtrag: Es spricht natürlich nichts dagegen, sich gegen irgendwelche Manipulationsversuche abzusichern. SSL leistet das - sozusagen als Abfallprodukt - auch. Aber am Ende bleibt es ein Mißbrauch des Systems.

Alternativ könnte man natürlich hergehen und sagen, die derzeitige einseitige Authentifizierung (nur des Servers) ist zu kurz gegriffen. Stattdessen: Jeder braucht eins. *Zum Bleistift* in Form des nPA, nicht weil der so toll ist, sondern weil da eine persönliche Überprüfung für den Einzelnen komplett unumgänglich ist.

Dann muß man nur noch dafür sorgen, daß jeder jeden erkennen kann. Das also, was man gemeinhin als Klarnamenpflicht kennt. Wenn dann der ISP versucht, was zu ändern, wäre es egal, ob es ihm gelingt oder nicht: denn man könnte ihn sofort als Urheber zweifelsfrei identifizieren und haftbar machen.

Nicht sehr anonym, aber es würde sogar das Internet per Design sicher machen.

PS. Mir fällt's grad schwer zu entscheiden, ob das mit dem "vertrauenswürdigen VPN" ironisch gemeint war oder nicht. Mit TLS hat es jedenfalls nicht (notwendigerweise) was zu tun: aber, ja! Natürlich! Denn der VPN-Anbieter kriegt doch alle meine Daten! Was nützt es mir, wenn ich mich irgendwo öffentlich einbuche, nicht will, daß "öffentlich" jeder meine Daten kriegen könnte, deswegen also auf VPN ausweiche - und der VPN-Anbieter transparent das auf Facebook postet? VPN-Anbieter sind, per definitionem, nicht vertrauenswürdig, bis sie mich als Nutzer vom Gegenteil überzeugt haben. Ausnahme: Ich betreib das VPN selber oder jemand, dem ich vertraue, tut es. Immerhin heißt VPN ja nicht mal notwendigerweise "verschlüsselt" (geschweige denn zuverlässig). L2TP-ohne-IPsec wäre auch VPN. PPTP wäre VPN. Beide kann man buchstäblich in Echtzeit mitlesen. Und selbst wenn das über SSTP laufen würde, weiß ich ja immer noch nicht, was der VPN-Anbieter mit meinen Daten macht, auch wenn dann kein anderer mitlesen kann.

 

[shortrange]

In Bezug auf den Originalpost kann ich noch diese beiden Tools empfehlen:

1.
https://www.jitbit.com/sslcheck/
"SSL Check scan your website for non-secure content."
Findet Mixed Content, also Inhalte, die in einer HTTPS-verschlüsselten Webseite noch über HTTP geladen. Meistens handelt es sich hier um Dienste von Dritten, z.B. Werbung oder Bilder.

2.
https://www.ssllabs.com/ssltest/
"This free online service performs a deep analysis of the configuration of any SSL web server on the public Internet."
Überprüft das Zertifikat auf Gültigkeit, Sicherheit, etc.

 

[Der-Orden-Xar]

Alternativ könnte man natürlich hergehen und sagen, die derzeitige einseitige Authentifizierung (nur des Servers) ist zu kurz gegriffen. Stattdessen: Jeder braucht eins. *Zum Bleistift* in Form des nPA, nicht weil der so toll ist, sondern weil da eine persönliche Überprüfung für den Einzelnen komplett unumgänglich ist.

Dann muß man nur noch dafür sorgen, daß jeder jeden erkennen kann. Das also, was man gemeinhin als Klarnamenpflicht kennt. Wenn dann der ISP versucht, was zu ändern, wäre es egal, ob es ihm gelingt oder nicht: denn man könnte ihn sofort als Urheber zweifelsfrei identifizieren und haftbar machen.

Nicht sehr anonym, aber es würde sogar das Internet per Design sicher machen.

Oh wow, eine Problemlösung mit Nachteil (keine Anonymität) sich Ausdenken, wo es schon längst eine Lösung ohne Nachteil (https) gibt...

PS. Mir fällt's grad schwer zu entscheiden, ob das mit dem "vertrauenswürdigen VPN" ironisch gemeint war oder nicht.

Das war ernst gemeint.
Solange die Daten verschlüsselt zum VPN gehen, ist das eine Lösung des aufgezeigten Problems - nur verschiebt es sich ggf.
Bei https gibt es - auch wieder einer vernünftigen Konfiguration vorausgesetzt - im Normalfall kein Problem mehr mit der vertrauenswürdig der Leitung.

In Bezug auf den Originalpost kann ich noch diese beiden Tools empfehlen:


2.
https://www.ssllabs.com/ssltest/
"This free online service performs a deep analysis of the configuration of any SSL web server on the public Internet."
Überprüft das Zertifikat auf Gültigkeit, Sicherheit, etc.

Ich ergänze um:
https://observatory.mozilla.org/
Prüft im 3rd party teil u.a. mit SSLLabs und ein paar anderen 8wobei ein Dienst meistens Verbindungsprobleme hat, dämliche Franzosen ^^), mit jeweils etwas anderen Schwerpunkten.

 

[RalphS]

Ah, okay. Problem dann nur insoweit, daß das "vertrauenswürdig" nicht aus SSL selber entsteht.

Und nein, die "Problemlösung" bezog sich doch nicht auf die Veränderlichkeit oder Nicht-Veränderlichkeit von Daten während des Transports. Es ging mir um die Implementierung von X.509 in HTTPs, die ja auf gegenseitige Authentifizierung verzichtet. Das schafft Sicherheit durch Identifizierbarkeit: wenn ich den Gegenüber rechtssicher belangen kann für sein Tun, dann hat das a) abschreckenden Effekt und b) ist es erfolgversprechender als "jemand hat aber...". IP-Adressen rausfinden für Verbindung Wasweißich wäre dann wumpe. SSL sichert den Rest.

Für die Nichtveränderlichkeit der Daten reicht allerdings bereits irgendeine halbwegs vernünftige Prüfsumme oder Signatur oder was weiß ich, die dann auch end-to-end sein könnte und dann mit "unterwegs" nichts mehr zu tun hat. Dazu muß man nicht die Basis von SSL/TLS unterwandern.

Tatsache ist natürlich, daß SSL Möglichkeiten eröffnet, die ohne SSL nicht zu erreichen wären. Aber sie sind nicht inhärent. Ohne HTTPs gibts keine Integrität und Authentifizieren und Privatsphäre wahren geht auch nicht. MIT https kann man das machen.

Frei nach dem Motto: ich hab erst gar kein Türschloß; oder ich hab ein Türschloß, sperr aber nicht ab; oder ich hab ein Türschloß, sperr auch ab, geb aber jedem den Schlüssel; oder ich hab ein Türschloß, sperre ab, behalte den Schlüssel und keiner kommt rein außer ggf diejenigen, denen ich einen Schlüssel freiwillig und ohne Nötigung ausgehändigt hab.

Entsprechend kann jemand in meine Wohnung, entweder wirklich jeder (http) oder immer noch jeder (https ohne Prüfung) oder nur die richtigen (https mit Prüfung).

---

Back to topic: Es geht ja darum, besagte Webmaster von SSL zu überzeugen. Ich stell mich da gerne als Versuchskarnickel zur Verfügung.

Kurz dargelegt, um zu sehen, ob sich das in etwa mit der Meinung der Webmaster aus dem OP deckt:
- SSL ja, nämlich dann, wenn es wichtig ist, daß ich weiß, wer mein Gegenüber ist. Webshop und kein SSL? Da kann ich ja gleich jemanden auf der Straße ansprechen, ob ich ihm mein Geld in den Rachen werfen darf, ohne eine Gegenleistung zu erwarten.
- Wenn SSL, dann kostenpflichtig mit Validierung (nicht daß der Kostenfaktor springender Punkt wäre, aber wenn die CA mich überprüfen soll, dann kostet das natürlich was - zumindest Arbeitszeit für die.)
- SSL nicht, wenn es eh keinen interessiert, was da passiert. Heißt: kann man natürlich auch machen, ist dann aber verschwendete Liebesmüh.
- "Ressourcenbedarf" zählt tatsächlich nicht. Wir sind doch nicht mehr in den 90ern.

So und nun darf geübt werden für den Ernstfall mit den zu überzeugenden Webmastern. Warnung: Ich werd mich wahrscheinlich sträuben. Aber es wäre imo vermessen anzunehmen, daß besagte Webmaster nach einmal "aber SSL ist doch..." sofort "achsooo na dann machen wir das doch sofort!" sagen.

 

[shortrange]

Hier eine weitere Website:
https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https

TL;DR

• Intruders both malignant and benign exploit every unprotected resource between your websites and users.
• Many intruders look at aggregate behaviors to identify your users.
• HTTPS doesn't just block misuse of your website. It's also a requirement for many cutting-edge features and an enabling technology for app-like capabilities such as service workers.

 

[chrigu]

es gibt nur einen grund, die verschlüsselung (https) auf selben webserver nur auf sensible seiten zu aktivieren und auf den öffentlichen sein zu lassen.... riesengrosse faulheit...