staging.inyokaproject.org

Hallo Zusammen.

Neulich habe ich eine alte Web-Comic-Seite aufgerufen, die aber eine 'http'-Adresse hat. Also kein httpS. Also alter Standard. Dort kann man nur lesen ... und blättern (Buttons halt, aber KEINE Eingabefelder etc.). Besonders auf Wikipedia liest es für mich die Infos zu solchen Seiten so, als wären diese Seiten sehr unsicher und es bestände extreme Gefahr für meinen Rechner, wenn man solche Seiten aufruft. Wie gefährlich ist es Eurer Meinung nach, so eine Seite aufzurufen? Was kann einem da alles passieren, oder in wie weit kann beim Aufruf solcher Seiten meinem Rechner bzw. FF-Browser und BS geschadet werden? Und/Bzw. welcher Art Schaden könnte angerichtet werden?

Danke.

Gruß, Erwin.

Man kann den Inhalt fälschen, ohne dass du es merkst. Zudem können die Daten mitgelesen werden. War bis so vor 5-6 Jahren im Web Standard. HTTPS gab es da nur in Ausnahmefällen wie bei Banken.

Erwin72 schrieb:

Hallo Zusammen.

Neulich habe ich eine alte Web-Comic-Seite aufgerufen, die aber eine 'http'-Adresse hat. Also kein httpS. Also alter Standard. Dort kann man nur lesen ... und blättern (Buttons halt, aber KEINE Eingabefelder etc.). Besonders auf Wikipedia liest es für mich die Infos zu solchen Seiten so, als wären diese Seiten sehr unsicher und es bestände extreme Gefahr für meinen Rechner, wenn man solche Seiten aufruft. Wie gefährlich ist es Eurer Meinung nach, so eine Seite aufzurufen? Was kann einem da alles passieren, oder in wie weit kann beim Aufruf solcher Seiten meinem Rechner bzw. FF-Browser und BS geschadet werden? Und/Bzw. welcher Art Schaden könnte angerichtet werden?

Danke.

Gruß, Erwin.

HTTPS ist in vielen Fällen nicht nötig, wenn es sich nicht um sensible Informationen handelt, auf deren Wahrheitsgehalt du angewiesen bist.

Selbst der bekannte Linux/Unix-Guru E. Raymond setzt kein https ein.
http://www.catb.org/~esr/
D.h. du musst immer damit rechnen, dass seine Inhalte, von wem auch immer, gefälscht wurden.

Also wenn du der Meinung bist, es hat jemand Interesse, die obige (nicht genannte) Webseite inhaltlich auf dem Weg vom Server zum Browser zu fälschen, dann würde ich mir Sorgen machen. Und wenn die Seite selbst nicht 'clean' ist, also u.U. Schadcode ausliefert, hilft https auch nicht.

rleofield

Bei rein statischen Seiten braucht es kein https. Da die Nutzer aber immer geneigt sind sich nicht zu informieren, wird einfach stur http als unsicher und https als Heilsbringer beworben. Da die meisten Seiten sich heute dem stalking, tracking und profiling verschrieben haben, solltest du das auch bevorzugen.

https brauchst du aber theoretisch nur, wenn du irgendwo Informationen eingeben sollst, wie Benutzername/Passwörter oder die Seite auf deine Informationen/Geräte zugreift, usw.

HTTPS nutzt TLS als Transportverschlüsselung - der Hauptzweck ist, dass Dritte nicht mitlesen können, was dein Browser und der Webseitenanbieter an Daten auf der Ebene von HTTP(s) austauschen. Solange du kein Zertifikatspinning betreibst, weißt du nur, dass ein als Vertrauenswürdig eingestufter CA das Zertifikat deines Gegenübers ausgestellt hat, aber nicht, ob das der Server von demjenigen betrieben wird, den du erreichen willst.

Kurz: mit Transportverschlüsselung sehen Dritte nur, mit welchem Server du auf TCP-Ebene kommunizierst (ob der FDQN unverschlüsselt übertragen wird, hängt davon ab, was Server und Client können: https://stackoverflow.com/a/38727920), aber nicht welche Informationen du im Detail mit ihm austauscht.

Dazu kommt, dass der FQDN vorher - unbhängig von HTTP oder HTTPS - per DNS aufgelöst werden muss. Der genutzte DNS-Resolver wird es also definitiv erfahren. Wenn du kein DNSoderTLS/HTTPS nutzt, dann kann es zudem jeder mitlesen.

Danke für all die Antworten.

DJKUhpisse schrieb:

Man kann den Inhalt fälschen, ohne dass du es merkst. Zudem können die Daten mitgelesen werden. War bis so vor 5-6 Jahren im Web Standard. HTTPS gab es da nur in Ausnahmefällen wie bei Banken.

Wie darf ich mir das fälschen des Inhalts vorstellen? Das mich am Rechner etwa z.B. ein anderes Bild erreicht, als es auf der Adresse vom Ersteller eingestellt wurde, also vorhanden ist? Und kann man auch hergehen, und das so manipulieren, dass sogar Programme bzw. Schadcode anstelle von Bilder bei mir auf dem Browser/Rechner ankommen?

rleofield schrieb:

HTTPS ist in vielen Fällen nicht nötig, wenn es sich nicht um sensible Informationen handelt, auf deren Wahrheitsgehalt du angewiesen bist.

Selbst der bekannte Linux/Unix-Guru E. Raymond setzt kein https ein.
http://www.catb.org/~esr/
D.h. du musst immer damit rechnen, dass seine Inhalte, von wem auch immer, gefälscht wurden.

Also wenn du der Meinung bist, es hat jemand Interesse, die obige (nicht genannte) Webseite inhaltlich auf dem Weg vom Server zum Browser zu fälschen, dann würde ich mir Sorgen machen. Und wenn die Seite selbst nicht 'clean' ist, also u.U. Schadcode ausliefert, hilft https auch nicht.

Zum Ausliefern von Schadcode spielt es also keine Rolle, ob es eine HTTP- oder HTTPS-Seite ist? Generell, oder kann es sein, dass bei HTTPS der Seiten-Ersteller selbst den Schadcode in die Seite einstellen muss, während bei HTTP ein Dritter mir den dazwischen unterjubeln kann? Kann man irgendwie feststellen, ob eine Seite Clean ist?

ChickenLipsRfun2eat schrieb:

Bei rein statischen Seiten braucht es kein https. Da die Nutzer aber immer geneigt sind sich nicht zu informieren, wird einfach stur http als unsicher und https als Heilsbringer beworben. Da die meisten Seiten sich heute dem stalking, tracking und profiling verschrieben haben, solltest du das auch bevorzugen.

https brauchst du aber theoretisch nur, wenn du irgendwo Informationen eingeben sollst, wie Benutzername/Passwörter oder die Seite auf deine Informationen/Geräte zugreift, usw.

Also Dritte können mitlesen, was ich auf einer HTTP-Seite mache? Aber auf Seiten, wo man eh nichts einträgt (sondern nur eben mittels Button herumblättert) gibt es ja dann eh kaum interessantes mit zu lesen? Und wenn ich das Ganze insgesamt verstehe, kann es durchaus auch sein, dass mehr Gefahr von einer extrem schlecht gemachten HTTPS-Seite ausgeht, als auf einer sehr gut gemachten HTTP-Seite, voraus gesetzt, man gibt auf beiden Seiten-Arten keine Daten ein? Oder kann sich bei HTTP immer ein Dritter dazwischen drängen, um auf meine Information (auf dem Rechner?) und Geräte zuzugreifen?

seahawk1986 schrieb:

HTTPS nutzt TLS als Transportverschlüsselung - der Hauptzweck ist, dass Dritte nicht mitlesen können, was dein Browser und der Webseitenanbieter an Daten auf der Ebene von HTTP(s) austauschen. Solange du kein Zertifikatspinning betreibst, weißt du nur, dass ein als Vertrauenswürdig eingestufter CA das Zertifikat deines Gegenübers ausgestellt hat, aber nicht, ob das der Server von demjenigen betrieben wird, den du erreichen willst.

Kurz: mit Transportverschlüsselung sehen Dritte nur, mit welchem Server du auf TCP-Ebene kommunizierst (ob der FDQN unverschlüsselt übertragen wird, hängt davon ab, was Server und Client können: https://stackoverflow.com/a/38727920), aber nicht welche Informationen du im Detail mit ihm austauscht.

Also ein Dritter kann bei HTTP dessen Inhalt mitlesen, aber was die Verbindungsdaten betrifft (Sender und Empfänger), ist die Gefahr und Umfang der Daten, die ein Dritter lesen könnte, bei beiden gleich?

Fälschen kann alles sein, es kann ein komplett anderes HTML sein, es können komplett andere Dateien sein, du merkst das nicht, außer es ist offensichtlich. Zum Mithören: https findet innerhalb von TLS statt, daher kannst du als Angreifer da das HTTP nicht mitlesen. Alles andere aber schon, also IPv6/IPv4 und TCP. Da kann man dann sehr wohl sehen, mit wem du ne Verbindung aufbaust.

Bei HTTP ist das Fälschen der Daten viel einfacher, Dritte können sehr einfach Schadcode per MITM unterjubeln. Bei HTTPS geht das nicht so einfach, denn das Zertifikat muss passen. Wenn die aber ein gültiges haben, was von einer CA kommt, der der Browser traut, wird das in den meisten Fällen unbemerkt bleiben (du müsstest sonst das Zert immer prüfen). Wenn Schadcode auf dem eigentlichen Server ist, ist es egal ob TLS im Spiel ist oder nicht.

Stell es dir so vor: Du bekommst und versendest Briefe im offenen Umschlag. Du weißt nicht, ob jemand reingesehen hat oder den Inhalt ausgetauscht/verändert. Bei https liegt dieser offene Umschlag in einer verschlossenen Box. Auf diesem Transportweg können Briefträger natürlich auch Inhalte manipulieren/austauschen, den Brief in einer Zwischenstation abgeben, etc. weil sie den Schlüssel haben, aber Außenstehende können nicht mehr einfach so an den Umschlag gelangen.

Mir fällt leider gerade kein passenderes Bild ein.

ChickenLipsRfun2eat schrieb:

Stell es dir so vor: Du bekommst und versendest Briefe im offenen Umschlag. Du weißt nicht, ob jemand reingesehen hat oder den Inhalt ausgetauscht/verändert. Bei https liegt dieser offene Umschlag in einer verschlossenen Box. Auf diesem Transportweg können Briefträger natürlich auch Inhalte manipulieren/austauschen, den Brief in einer Zwischenstation abgeben, etc. weil sie den Schlüssel haben, aber Außenstehende können nicht mehr einfach so an den Umschlag gelangen.

Mir fällt leider gerade kein passenderes Bild ein.

Das habe ich, denke ich, auch ohne diesem Beispiel verstanden. Dennoch: Danke. Aber mir geht es einfach auch darum, einzuschätzen, wie unsicher HTTP ist. Kann man, wenn in dem Schreiben/Briefkuvert nur einen bereits vorhanden Brief gegen einen anderen Brief austauschen, oder auch einen Brief gegen einen Skorpion? Oder zu dem Brief einen Skorpion tun? Hm... vermutlich wohl alles möglich?

DJKUhpisse schrieb:

Fälschen kann alles sein, es kann ein komplett anderes HTML sein, es können komplett andere Dateien sein, du merkst das nicht, außer es ist offensichtlich.

Alles? Also nicht nur Bild-Dateien auf der Seite gegen anderen Bild-Dateien (um Werbung zu machen) austauschen? Sondern auch Bild-Dateien gegen Schadsoftware? Oder gar zu den bereits vorhanden Bild-Dateien, Text-Dateien etc. zusätzlich Schadsoftware 'rein packen'. Bzw. ist das ja dann genau genommen dazwischen? Dateien auf dem Weg vom Server zu mir auf den Computer kann ein Angreifer dann also alles an Daten austauschen/verändern?

Zum Mithören: https findet innerhalb von TLS statt, daher kannst du als Angreifer da das HTTP nicht mitlesen. Alles andere aber schon, also IPv6/IPv4 und TCP. Da kann man dann sehr wohl sehen, mit wem du ne Verbindung aufbaust.

Also die Daten, wer sich mit wem verbindet, kann ein Angreifer bei allen ohne weiteres feststellen? Mitlesen heißt aber nicht gleich verfälschen? Verfälschen benötigt einen extra Aufwand, oder? Oder geht das verfälschen auch so einfach, wie das mitlesen?

Bei HTTP ist das Fälschen der Daten viel einfacher, Dritte können sehr einfach Schadcode per MITM unterjubeln. Bei HTTPS geht das nicht so einfach, denn das Zertifikat muss passen. Wenn die aber ein gültiges haben, was von einer CA kommt, der der Browser traut, wird das in den meisten Fällen unbemerkt bleiben (du müsstest sonst das Zert immer prüfen). Wenn Schadcode auf dem eigentlichen Server ist, ist es egal ob TLS im Spiel ist oder nicht.

Da bekomme ich langsam den Eindruck, dass es ein Wunder ist, dass mit HTTP damals nicht viel mehr passiert ist? Also kurz zusammen gefasst: HTTP ist, was dem mitlesen betrifft, so gut wie gar nicht sicher. Aber was das Fälschen betrifft, ist es zwar auch sicher, zumindest gegen über Laien, aber ist bei weitem nicht so sicher wie HTTPS. Hm... . Muss dann wohl Jeder für sich wissen, ob er sich auf HTTP-Seiten traut, oder nicht?

Anders gefragt: Wie schätzt Ihr die Gefahr von HTTP ein? Lieber total die Finger davon lassen? Oder besteht mit aktuellem BS und Browser kaum eine Gefahr (außer dass halt von mir übertrage Eingabedaten mitgelesen werden)?

Bei HTTP kann alles ersetzt werden - auch das gesamte HTML und damit auch beliebiges JavaScript eingefügt werden.

Also die Daten, wer sich mit wem verbindet, kann ein Angreifer bei allen ohne weiteres feststellen?

ja, auch bei HTTPS

Da bekomme ich langsam den Eindruck, dass es ein Wunder ist, dass mit HTTP damals nicht viel mehr passiert ist?

Da ist viel passiert. Transparente Proxies an Firewalls und Co sind/waren da Gang und Gäbe.

Muss dann wohl Jeder für sich wissen, ob er sich auf HTTP-Seiten traut, oder nicht?

HTTPS hilft nur, wenn MITM versucht wird. Wenn der Server selbst versucht ist ist es egal.

Hm... also einfach zusammen gefasst? Die Daten und Möglichkeiten der Manipulation liegen nicht offen herum. Auch bei HTTP-Seiten muss man erst mal angreifen (MITM), die Leitung knacken/unterbrechen etc., wozu ein Aufwand nötig ist. Aber bei HTTP geht das halt viel einfacher als bei HTTPS (was aber nun wirklich keine Überraschung ist). Und was deren Unterschied betrifft, dazu kann man scheinbar (weil dazu nichts konkretes geäußert wurde) schwer eine Einschätzung abgeben? Z.B. wie ... ok, merke selbst, dass mir da sogar kein wirkliches Vergleichsbeispiel einfallen will, ist doch recht abstrakt das Ganze. Muss ich also selber wissen, ob mir das leichter zu knackende HTTP dennoch sicher genug ist, oder nicht?

HTTPS packt gegenüber HTTP eine Transportverschlüsselung um die Nutzdaten, die im Zuge von HTTP-Requests hin und her gesendet werden. Das schützt die Vertraulichkeit des Inhalts so lange die niemand die Transportverschlüsselung aufbrechen kann. Mit der Sicherheit des Servers und des Clients hat das wenig zu tun (beide können trotzdem Sicherheitslücken haben, die es Angreifern ermöglichen Schadcode auszuführen), das soll nur Dritte davon abhalten mitzulesen - was z.B. in einem WLAN möglich sein kann, wenn das entweder komplett ungesichert ist (Stichwort öffentlicher Hotspot) oder die Verschlüsselung des WLAN darauf baut, dass alle Clients das selbe Passwort nutzen, wodurch andere Teilnehmer mit einem Netzwerksniffer ebenfalls in der Lage wären die Daten mitzulesen.

https baut ja auf Zertifikate auf, die Browsernutzer vertrauen dann diesen Zertifikaten. Irgendwann beim updaten oder Upgrade kommen dann auch mal neue Zertifizierungsstellen dazu, die eigentlich verbürgen sollten, dass man dem https Konstrukt vertrauen soll. Aber wie sicher ist das wirklich? Mal ein Beispiel:

• https://groups.google.com/g/mozilla.dev.security.policy/c/_A7OX4Tz65k

Diese Zertifizierungsstelle kommt irgendwann bei einem Update oder Upgrade hinzu. Die Incidents sind durchaus beachtlich. So viel also zur Vertrauenswürdigkeit von https. Beim Upgrade auf Jammy Jellyfish ist mir Certum gerade aufgefallen.

Also das mitlesen ist bei HTTP sozusagen kein Problem? Aber das Abfangen und Daten aus tauschen ist bei beiden mit Aufwand (aber eben unterschiedlicher Art) verbunden?