nicht angemeldet
Kann man Webseiten "abfangen"?
Hallo,
kann ein anderer, den Inhalt von Seiten "abfangen", d.h. ich habe einen passwortgeschützten Bereich, in dem Adresslisten stehen. Ist es nun möglich für Angreifer, die Inhalte zu sehen, während der User die Adressen sieht.
Ich meine damit nicht: Passwort knacken, oder so, sondern ob es möglich ist die HTML-Ausgabe des Servers irgendwie umzuleiten bzw. zu einem anderen User gleichzeitig zu führen.
Man könnte natürlich auch SSL verwenden, allerdings benötigen die Listen erheblich mehr Zeit dargestellt zu werden.
Gruss
stut
-
Man könnte natürlich auch SSL verwenden, allerdings benötigen die Listen erheblich mehr Zeit dargestellt zu werden.
na, um genau das zu verhindern gibt es schließlich SSL.
gib einfach als Adresse https://... statt wie üblich http://... ein, dann sollte das ein Angreifer nicht mehr lesen können. Ansonsten schon.
Gruß,
KonRad ---
"Was Gott zusammengeführt hat ..." :: polithink.org -
the politicultural e-zine :: http://www.polithink.org-
moin!
gib einfach als Adresse https://... statt wie üblich http://... ein, dann sollte das ein Angreifer nicht mehr lesen können. Ansonsten schon.
der server muss aber auch ssl unterstützen sonst bringt das s vor dem http gar nichts.
tschau
-
moin!
gib einfach als Adresse https://... statt wie üblich http://... ein, dann sollte das ein Angreifer nicht mehr lesen können. Ansonsten schon.
der server muss aber auch ssl unterstützen sonst bringt das s vor dem http gar nichts.
tja, logo. Aber die meisten geläufigen Server unterstützen das.
Gruß,
KonRad ---
"Was Gott zusammengeführt hat ..." :: polithink.org -
the politicultural e-zine :: http://www.polithink.org-
moin!
tja, logo. Aber die meisten geläufigen Server unterstützen das.
jo, nur viel provider habs nicht aktiviert ;).
tschau
-
Hallo,
gib einfach als Adresse https://... statt wie üblich http://... ein, [...]
der server muss aber auch ssl unterstützen sonst bringt das s vor dem http gar nichts.Wenn schon _nach_ dem http. ;-)
tja, logo. Aber die meisten geläufigen Server unterstützen das.
Die Serversoftware vielleicht schon.
Aber die wenigsten mir bekannten Server haben auch
effektiv ein Zertifikat und den ganzen Klimbim, den
es fuer SSL braucht.Hab Deinen Vorschlag mal auf ein paar zufaelligen Servern
ausprobiert:https://selfhtml.teamone.de/ => keine Reaktion
("Verbindung zum Server konnte nicht hergestellt werden")
https://www.google.com/ => Umleitung (302) auf
http://www.google.ch/ oder http://www.google.com/
(oder so, je nach IP-Nummer des Clients)
https://www.bundestag.de/ => keine Reaktion
("Verbindung zum Server konnte nicht hergestellt werden")
https://www.amazon.de/ => 302-Umleitungen auf http://...
https://www.tu-berlin.de/ => Fehlermeldung
(Server nicht gefunden oder so)
https://www.ebay.de/ => keine Reaktion
("Verbindung zum Server konnte nicht hergestellt werden")Ein einziges funktionierendes Beispiel habe ich auf die Schnelle gefunden (um ehrlich zu sein, wusste ich bereits, dass es
auf diesem Server so funktioniert):
https://www.unizh.ch/ liefert das gleiche wie http://www.unizh.ch/Dein toller Tip, einfach https:// vor die URLs zu schreiben,
funktioniert also nur in seltenen Ausnahmefaellen.Gruesse,
Thomas
-
Moin!
Dein toller Tip, einfach https:// vor die URLs zu schreiben,
funktioniert also nur in seltenen Ausnahmefaellen.Und ein wichtiger Grund dafür dürfte sein, dass man für SSL ein Zertifikat benötigt - so ein Zertifikat macht aber nur Sinn, wenn die Besucher ihm vertrauen können. Und das Vertrauen wird durch die digitale Unterschrift einer Zertifizierungsstelle hergestellt.
Alle aktuellen Browser werden mit den öffentlichen Zertifikaten aller möglichen Stellen ausgeliefert, die der Browserhersteller als vertrauenswürdig einstuft. Der Sinn: Signierte SSL-Zertifikate werden vom Browser ohne Sicherheitshinweis akzeptiert (und genau so sollte es eben sein, denn wenn beispielsweise beim Besuch der Online-Banking-Seite so ein Sicherheitshinweis auftaucht, dann ist höchste Alarmstufe gegeben!). Damit aber die Zertifizierungsstelle die Unterschrift unter das SSL-Zertifikat setzt, will sie Geld sehen.
Mit anderen Worten: Der vernünftige Betrieb eines SSL-Servers kostet extra Geld. Das sind durchaus 100 Euro und mehr im Jahr.
Mit einem selbstgemachten Zertifikat kriegt man zwar immerhin Verschlüsselung, aber der zweite Nachteil bei SSL ist auch nicht von der Hand zu weisen: SSL benötigt eine eigene IP-Adresse je Domainname. Und weil viele Domains als virtuelle Hoste auf einem einzigen Server liegen, der nur insgesamt eine IP-Adresse hat, ist es logisch, dass es für all diese Domains gar keinen SSL-Zugang geben _kann_.
Die grob 46,9 Millionen Domainnamen, die registriert sind (laut http://www.denic.de/de/domains/statistiken/domainvergleich_tlds/index.html) würden logischerweise 46,9 Millionen IP-Adressen verbrauchen, wenn sie alle SSL anbieten würden. Wobei das die _Mindestzahl_ ist. "example.org" und "www.example.org" sind zwei verschiedene Domainnamen, also brauchen sie auch zwei verschiedene SSL-Server und damit zwei IPs.
Da der IP-Adressraum nur maximal 224*16 Millionen IP-Adressen insgesamt zuläßt (abzüglich einiger Reservierungen, die in RFC 3330 ftp://ftp.rfc-editor.org/in-notes/rfc3330.txt zusammengefaßt wurden), würde der Adressraum also schon zu 1% ausgenutzt.
Da es unwahrscheinlich ist, dass IP-Adressen "dicht" zusammenliegend genutzt werden, dürften geschätzt die Hälfte aller Adressen sowieso ungenutzt sein. Macht also schon einen Anteil von 2%.
Irgendwie wollen die User ja aber auch ins Internet rein. Dynamische IPs helfen hierbei zwar, aber trotzdem kann man irgendwie erwarten, dass für jede Server-IP vielleicht 99 Nutzer-IPs bestehen. Und schon wäre der IP-Adressraum zu 200% ausgenutzt.
:)
Wie gut, dass es virtuelle Hosts gibt. ;)
- Sven Rautenberg
--
"Beim Stuff für's Web gibts kein Material, was sonst das Zeugs ist, aus dem die Sachen sind."
(fastix®, 13. Oktober 2003, 02:26 Uhr -> </archiv/2003/10/60137/#m338340>)-
Moin,
Der Sinn: Signierte SSL-Zertifikate werden vom Browser ohne Sicherheitshinweis akzeptiert (und genau so sollte es eben sein, denn wenn beispielsweise beim Besuch der Online-Banking-Seite so ein Sicherheitshinweis auftaucht, dann ist höchste Alarmstufe gegeben!).
Das Zertifikat einer Zertifizierungsstelle beweist in der Regel nur, dass diese Zertifizierungsstelle das Zertifikat ausgestellt hat. Nicht mehr und nicht weniger. Insbesondere sagt es nichts über die Vertrauenswürdigkeit des Zertifikats aus, ich erinnere hier mal an die falschen Microsoft-Zertifikate von Verisign.
Der korrekte Weg ein Zertifikat zu überprüfen, zumindest wenn es darauf ankommt, ist den Fingerabdruck über einen sicheren Kanal zu vergleichen. Bei dem Online-Banking-Beispiel sollte man also mindestens bei der Bank anrufen und sich den Fingerabdruck vorlesen lassen, am besten macht man das sogar persönlich am Schalter.
Wobei das die _Mindestzahl_ ist. "example.org" und "www.example.org" sind zwei verschiedene Domainnamen, also brauchen sie auch zwei verschiedene SSL-Server und damit zwei IPs.
Nein. Sieh dir zum Beispiel das Zertifikat von www.informatik.hu-berlin.de Port 443 oder sigma.informatik.hu-berlin.de Port 995 an.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
-
-
-
-
-
Hallo,
ich habe ein SSL-Zertifikat, ohne dieses ist dies auf dem Server auch nicht sinnvoll möglich auf https zuzugreifen.
Man benötigt wirklich zwei, wenn man www.name.de und name.de verwenden will.
Allerdings ist das für mich eine Frage der Geschwindigkeit. Da mit den Adressen viel gearbeitet wird - was auch ohne SSL sehr gut funktioniert - ist das ganze mit SSL immer einer "Warterei".
Gruss
stut-
Moin!
ich habe ein SSL-Zertifikat, ohne dieses ist dies auf dem Server auch nicht sinnvoll möglich auf https zuzugreifen.
Man benötigt wirklich zwei, wenn man www.name.de und name.de verwenden will.
In diesem Punkt bin ich mir ziemlich sicher. Das sind schließlich zwei verschiedene Namen, die zwei verschiedene Rechner bezeichnen können. Da ein Zertifikat immer auf einen bestimmten Namen ausgestellt wird, brauchst du je Namen eines.
Wie Henryk in [pref:t=64563&m=367513] ganz richtig bemerkt, ist je SSL-Server nicht eine eigene IP notwendig, sondern "nur" ein eigener Port. Das Problem ist, dass man dann alle vom Standard (bei HTTPS ist das 443) abweichenden Portnummern explizit angeben muß. Du kannst also nicht neben "https://www.example.org" auch "https://example.org" auf demselben Rechner betreiben, wohl aber "https://example.org:123".
Unter http kannst du das sehr wohl - und sowohl beide Namen auf denselben Webspace verweisen lassen, als auch auf unterschiedliche Inhalte.
Allerdings ist das für mich eine Frage der Geschwindigkeit. Da mit den Adressen viel gearbeitet wird - was auch ohne SSL sehr gut funktioniert - ist das ganze mit SSL immer einer "Warterei".
Mehr Power in die CPU packen. :)
- Sven Rautenberg
--
"Beim Stuff für's Web gibts kein Material, was sonst das Zeugs ist, aus dem die Sachen sind."
(fastix®, 13. Oktober 2003, 02:26 Uhr -> </archiv/2003/10/60137/#m338340>)-
Moin,
Man benötigt wirklich zwei, wenn man www.name.de und name.de verwenden will.
Nein.
Wie Henryk in [pref:t=64563&m=367513] ganz richtig bemerkt, ist je SSL-Server nicht eine eigene IP notwendig, sondern "nur" ein eigener Port.
Nein, das habe ich nicht bemerkt. Hast du dir die Zertifikate angesehen? Oder wenigstens die IP-Addressen aufgelöst?
Also, damit auch die ganzen Faulpelze meinem Punkt folgen können:
Der Webserver auf www.informatik.hu-berlin.de verwendet als CN in seinem Zertifikat "(www.informatik|www2.informatik|www.math-natII).hu-berlin.de", damit gilt das Zertifikat sowohl für www.informatik.hu-berlin.de, als auch für www2.informatik.hu-berlin.de als auch für www.math-natII.hu-berlin.de. Der Mailserver auf sigma verwendet in seinem Zertifikat als CN "(sigma|sigma2|mailslv1).informatik.hu-berlin.de", womit das Zertifikat auch zusätzlich für sigma2 und mailslv1 gilt.Du brauchst also nur verschiedene IP-Addressen (oder Ports) wenn du _verschiedene_ Zertifikate verwenden willst. Solange die Zertifikate gleich sein können, kommst du mit einer IP-Addresse und einem Port aus, auch wenn dahinter verschiedene Virtual Hosts stecken.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~-
Moin!
Also, damit auch die ganzen Faulpelze...
... so wie ich... :)
... meinem Punkt folgen können:
Der Webserver auf www.informatik.hu-berlin.de verwendet als CN in seinem Zertifikat "(www.informatik|www2.informatik|www.math-natII).hu-berlin.de", damit gilt das Zertifikat sowohl für www.informatik.hu-berlin.de, als auch für www2.informatik.hu-berlin.de als auch für www.math-natII.hu-berlin.de. Der Mailserver auf sigma verwendet in seinem Zertifikat als CN "(sigma|sigma2|mailslv1).informatik.hu-berlin.de", womit das Zertifikat auch zusätzlich für sigma2 und mailslv1 gilt.Interessant, das war mir bislang noch nicht bekannt. Wobei ich gerne zugebe, dass ich mich so tief mit SSL dann doch noch nicht beschäftigt habe.
- Sven Rautenberg
--
"Beim Stuff für's Web gibts kein Material, was sonst das Zeugs ist, aus dem die Sachen sind."
(fastix®, 13. Oktober 2003, 02:26 Uhr -> </archiv/2003/10/60137/#m338340>)
-
-
-
-
-
Hallo,
kann ein anderer, den Inhalt von Seiten "abfangen", d.h. ich habe einen passwortgeschützten Bereich, in dem Adresslisten stehen. Ist es nun möglich für Angreifer, die Inhalte zu sehen, während der User die Adressen sieht.
Da die Daten ueber diverse Wege fliessen, muesste der
"boese Bube" AFAIK sehr nahe am Benutzer bzw. am Webserver
sitzen, um _saemtlichen_ Verkehr "mitzuhoeren".Trotzdem gilt: HTTP ist "unsicher".
Bei jeder einzelnen Abfrage wird das Passwort unverschluesselt
uebertragen.Und es reicht ja, wenn der Hacker das Passwort herausfindet.
Dann kann er sich jederzeit als der Benutzer ausgeben.Man könnte natürlich auch SSL verwenden, allerdings benötigen die Listen erheblich mehr Zeit dargestellt zu werden.
SSL (HTTPS) waere die einzige Moeglichkeit.
Du musst halt abwaegen, was Du willst:
Sicherheit oder Geschwindigkeit.
Wobei auf einem anstaendigen Rechner und bei einer
guten Leitung das SSL wohl den kleinsten Teil
an der gesamten Wartezeit ausmacht.Gruesse,
Thomas
-
Hallo,
Trotzdem gilt: HTTP ist "unsicher".
Bei jeder einzelnen Abfrage wird das Passwort unverschluesselt
uebertragen.Und es reicht ja, wenn der Hacker das Passwort herausfindet.
Dann kann er sich jederzeit als der Benutzer ausgeben.Der Passwortschutz wird mit Sessions gemacht, so dass das Passwort nicht jedesmal übertragen würde.
Wobei auf einem anstaendigen Rechner und bei einer
guten Leitung das SSL wohl den kleinsten Teil
an der gesamten Wartezeit ausmacht.Ich konnte jetzt nur mit ISDN testen und da ist die Seite wesentlich langsamer mit SSL als ohne.
Übrigens sind alle SSL Seiten SEHR langsam, z.B. auch die Konfigurationsseiten von Schlund, ... meiner Meinung nach.
Gruss
stut
-