Seite des Deutschen Kupferinstitut Firefox misstraut der Seite

Dem Webmaster eine Mail schicken, denn das Zertifikat ist nicht nur 
selbst signiert, sondern auch abgelaufen. In diesem Falle muss der 
Browser die SSL Verbindung verweigern.

Kupferlos schrieb:
> Die Seite kann ich aber über einen Rechner im Firmennetzt bei meinen
> Arbeitgeber mit den Microsoft Explorer (Version ?) problemlos ansurfen.

Dein Arbeitgeber hat vermutlich so ein SSL Man-in-the-Middle "Firewall" 
Dings im Netz, oder der IE ist sehr unsicher konfiguriert. Es ist auch 
möglich dass Du auf Arbeit eine andere Seite erhältst als zu Hause (z.B. 
via fester IP).

Hm, bei https://kupferinstitut.de (Ohne WWW!) kommt in der Tat die 
Meldung. Und mit https://copperalliance.de/ geht es ganz schief ...

Wolfgang schrieb:
> Man muss schließlich nicht für jeden Sch..ß Alias ein
> Sicherheitszertifikat ausstellen.

Ein Wildcard-Zertifikat war den Herrschaften anscheinend zu teuer.

Das gilt dann nämlich für *.domain.tld


Übrigens zeigt auch Chromium einen Zertifikatsfehler an, wenn man
https://www.kupferinstitut.de:8443 aufruft.

Da kommt o.g. Selbstbastelzertifikat.

Lässt man das :8443 weg, wird hingegen das gültige Zertifikat von Comodo 
verwendet.


Nun ist interessant, warum ausgerechnet

https://www.kupferinstitut.de:8443

anstelle von

https://www.kupferinstitut.de

aufgerufen werden soll.

Woher kommt diese Vorgabe, bzw. diese URL?

(Hat das Kupferinstitut denn mittlerweile genügen Klicks, oder ist 
dessen Bandbreiter unter dieser DDOS-Attacke zusammengebrochen? ;) )

Hm, mal den Browser-Cache (ggf. nur für diese Seite) geleert?

Die Umleitung auf Port 8443 ist seehr seltsam.

Kupferlos schrieb:
> Es ist zum kotz.. warum will mir der schei.. Browser vorschreiben das
> ich nicht auf (angeblich) unsichere oder nicht zertifizierte Seiten
> darf?
Ganz einfach: um die Seitenbetreiber dazu zu zwingen, endlich mal 
gewisse standards umzusetzen, z.B. https, gültige zertifikate usw.

Wenn du die Meldung deines Browsers ignorierst, ist das dein Ding. Dann 
heul aber nachher nicht rum, weil deine Bankdaten mittels gefälschtem 
Zertifikat und MITM geklaut wurden...

Sagt der Browser nichts, heulen alle rum, das der Browser ja mal was 
hätte sagen können, und das ist ja alles unverantwortlich.
Meldet der Browser sich aber zu wort, ist es auch nicht recht...

Kannst dir ja überlegen, was dir lieber ist. Außerdem schreibt dir 
Browser nichts vor, er gibt dir einen Hinweis das da eventuell was 
nicht stimmt!

Überprüfe mal bitte Datum und Uhrzeit deines Rechners.

http://www.kupferinstitut.de wird bei meinem aktuellen SeaMonkey 2.38 
problemlos geladen, ebenso
https://www.kupferinstitut.de
Lobenswert, da unverschlüsselter Kram ja eigentlich nicht mehr ins Web 
gehört.

Da SeaMonkey die gleiche Engine wie FF benutzt, liegt das Problem 
vermutlich nicht beim Kupferinstitut.

Wolfgang schrieb:
> Man muss schließlich nicht für jeden Sch..ß Alias ein
> Sicherheitszertifikat ausstellen.

Man muss aber auch nicht für jeden Scheiß einen Alias haben.  Gute
Sitte wäre es wohl, dass das Zertifikat dann auch für alle Aliase
gilt, die man bevölkert hat.  Wenn die Nutzer zu faul sind, das
http://www zu tippen, dann nehmen ihnen das die meisten Browser doch
sowieso ab, wenn es keinen A-RR (oder AAAA) für die www-lose Domain
gibt.

Kaj G. schrieb:
> Ganz einfach: um die Seitenbetreiber dazu zu zwingen, endlich mal
> gewisse standards umzusetzen, z.B. https, gültige zertifikate usw.

wie zwinge ich AVM ein gültiges Zertifikat für meine Fritzbox 3270 
auszustellen, der will mir doch lieber neue Fritzboxen verkaufen.

Kupferlos schrieb:
> Es ist zum kotz.. warum will mir der schei.. Browser vorschreiben das
> ich nicht auf (angeblich) unsichere oder nicht zertifizierte Seiten
> darf?
> Wenn ich bewusst das Risiko eingehe sollte das doch meine Sache sein ob
> sich der Computer eventuell etwas einfängt.

sehe ich genauso!

Joachim B. schrieb:
> Kupferlos schrieb:
>> Es ist zum kotz.. warum will mir der schei.. Browser vorschreiben das
>> ich nicht auf (angeblich) unsichere oder nicht zertifizierte Seiten
>> darf?

Das ist natürlich Schwachsinn. Der Browser schreibt hier gar nichts vor, 
er warnt nur sehr deutlich davor, Seiten mit gefälschten Zertifikaten 
aufzurufen.

Zertifikate sind ein grundlegender und wichtiger Sicherheitsmechanismus, 
die man entsprechend ernstnehmen sollte.

Gibt es den Knopf "Ich kenne das Risiko" denn im FF41 nicht mehr?

Rufus Τ. F. schrieb:
> Das ist natürlich Schwachsinn. Der Browser schreibt hier gar nichts vor,
> er warnt nur sehr deutlich davor, Seiten mit gefälschten Zertifikaten
> aufzurufen.

nein er verweigert meine fritzbox.net Adresse zu verbinden!

auch wenn ich die Ausnahme bestätige, ein neues Zertifikat wird der 3270 
nicht ausgestellt. Der alte IE akzeptiert diese Adresse weiterhin nur FF 
eben nicht, von AVM keine Reaktion, ich kann die ja nicht zwingen der 
Box ein Update zu verpassen.

1

Fehler: Gesicherte Verbindung fehlgeschlagen

2

3

Ein Fehler ist während einer Verbindung mit xxxxx.myfritz.net aufgetreten. SSL hat einen schwachen kurzlebigen Diffie-Hellman-Schlüssel in der Handshake-Nachricht "Server-Schlüsselaustausch" empfangen. (Fehlercode: ssl_error_weak_server_ephemeral_dh_key)

4

5

    Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.

6

7

    Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren.

Das ist ja wohl ein Witz!

Rufus Τ. F. schrieb:
> Ein Wildcard-Zertifikat war den Herrschaften anscheinend zu teuer.
> Das gilt dann nämlich für *.domain.tld

*.eu und *.de waren vermutlich nicht mehr frei. ;-)

Bei kupferschluessel.de, kupferinstitut.de, kupferschluessel.de, 
kupferseminar.de und copperalliance.eu läppert sich das.

Joachim B. schrieb:
> (Fehlercode: ssl_error_weak_server_ephemeral_dh_key)
> Das ist ja wohl ein Witz!

Nein, ernst gemeint und sinnvoll.

Man kann bei Firefox in about:config schwache Verschlüsselung wieder 
zulassen, wenn man das unbedingt benötigt. Mam muss dann aber mit 
einkalkulieren, dass eine angezeigte Verschlüsselung auch bei anderen 
Webseiten trotz https entsprechend schwach bis wertlos sein kann.

A. K. schrieb:
> Man kann bei Firefox in about:config schwache Verschlüsselung wieder
> zulassen, wenn man das unbedingt benötigt.

ist mir nie gelungen, vielleicht war die Anleitung zu schwach oder ich.

A. K. schrieb:
> Mam muss dann aber mit
> einkalkulieren, dass eine angezeigte Verschlüsselung auch bei anderen
> Webseiten trotz https entsprechend schwach bis wertlos sein kann.

wieso wenn ich nur meine Seite als Ausnahme hinzufügen will soll FF das 
natürlich umsetzen, da interessieren mich andere nicht und auch FF hat 
es nicht zu interessieren.

Dein Problem mit schwacher Verschlüsselung hat mit dem hier aufgeführten 
Problem ungültiger Zertifikate nichts zu tun. Zertifikate sind auf die 
Seite bezogen. Füe erlaubte oder nicht erlaubte 
Verschlüsselungsverfahren hingegen gibt es m.W. keine seitenbezogene 
Behandlung, sondern nur globale Einstellungen.

A. K. schrieb:
> Dein Problem mit schwacher Verschlüsselung hat mit dem hier aufgeführten
> Problem ungültiger Zertifikate nichts zu tun. Zertifikate sind auf die
> Seite bezogen.

OK als das "Problem" erstmalig mit FF 31 auftrat sahe es nach 
Zertifikatsfehler aus, die letzte "Fehlermeldung" mit dem schwachen 
Schlüssel stammt vom FF 41, auch die Häufigkeit der sogenannten Updates 
in diesem Zeitraum von FF 31 bis FF 41 zeigt mir doch das da globale 
Probleme im FF stecken.

Ich wusste schon immer updates nur in der Not zu machen, mit jedem 
behandeltem Fehler kommen 10 Neue hinzu.

Joachim B. schrieb:
> auch die Häufigkeit der sogenannten Updates
> in diesem Zeitraum von FF 31 bis FF 41 zeigt mir doch das da globale
> Probleme im FF stecken.

Änderungen im Bereich von Verschlüsselung hängen beispielsweise mit SSL 
Problemen wie POODLE zusammen und sind damit nicht nur auf den Firefox 
bezogen.

A. K. schrieb:
> Änderungen im Bereich von Verschlüsselung hängen beispielsweise mit SSL
> Problemen wie POODLE zusammen und sind damit nicht nur auf den Firefox
> bezogen.

für mein XP gibt es kein IE Update mehr und ich komme problemlos auf 
meine Fritzbox, die anderen Probleme mit ssl sind mir nicht im IE 
begegnet nur auf dem rasPI hat mich ne Menge recherche Zeit gekostet die 
SSL updates zu finden.

Joachim B. schrieb:
> für mein XP gibt es kein IE Update mehr und ich komme problemlos auf
> meine Fritzbox,

Yep. Aber dafür kann möglicherweise jeder zwischen dir und deiner Bank 
den Inhalt mitlesen und ggf. ändern, wenn er will. Mozilla hat das ja 
nicht rausgeschmissen um dich zu ärgern. Der IE ist eines der 
schlimmsten Produkte, was Sicherheit angegeht. Kein anderes Produkt 
taucht häufiger in Intrusion Prevention Massnahmen auf als der IE (nicht 
einmal Adobe, und das will was heissen). Selbst Microsoft hat 
mittlerweile dieses Produkt entnervt aufgegeben.

Sicherheit ist das moderne Gegenteil von Bequemlichkeit.

Es ist nicht weiter ungewöhnlich, dass man für ältere per Webseite 
konfigurierte Geräte auch einen Browser aus der Ära des Gerätes 
benötigt, weil neuere damit nicht zurecht kommen. Gerne auch bei Java. 
Browser müssen sich weiterentwickeln und auch mal alte Zöpfe 
abschneiden.

Einem Pferd nagelt man auch keine Autoreifen an die Hufe. ;-)

A. K. schrieb:
> Yep. Aber dafür kann möglicherweise jeder zwischen dir und deiner Bank
> den Inhalt mitlesen und ggf. ändern, wenn er will.

für die Bank nutze ich ja FF und Angriff in the middle, sorry so 
interessant bin ich nicht und es gibt genug "Spione" die sowieso alles 
von mir oder der Kanzlerin belauschen können wobei ich weniger glaube 
das die sich auf mich konzentrieren, glücklicherweise hilft in dem fall 
der Abbau der Arbeitsstellen im öff. Dienst, oder werden die nun alle 
als Lauscher bei der NSA oder beim Bundesverfassungsschutz beschäftigt? 
Die Arbeitslosenstatistik sagt was anderes.

Na also. Dann nimm den IE für Fritz und den FF für die Bank.
Ist doch alles in bester Ordnung.

A. K. schrieb:
> Einem Pferd nagelt man auch keine Autoreifen an die Hufe. ;-)

Die Ureineinwohner der USA hatte keine Hufe an den Pferden und wir 
wechseln noch oft Sommer wie Winter die Reifen.

A. K. schrieb:
> Na also. Dann nimm den IE für Fritz und den FF für die Bank.
> Ist doch alles in bester Ordnung.

mach ich doch, in Ordnung finde ich das trotzdem nicht das der FF mir 
signalisiert ich darf ne Ausnahme hinzufügen und mir dann den 
Stinkefinger zeigt.

Joachim B. schrieb:
> Die Ureineinwohner der USA hatte keine Hufe an den Pferden

Stimmt insoweit, als sie vor den Spaniern auch keine Pferde hatten. Aber 
Hufe werden die armen Viecher danach hoffentlich schon gehabt haben. Nur 
nicht unbedingt mit Eisen dran, aber Strassen hatten sie ja auch keine.

Matthias S. schrieb:
> Da SeaMonkey die gleiche Engine wie FF benutzt, liegt das Problem
> vermutlich nicht beim Kupferinstitut.

Hä? In dem Zertifikat steht "Expired 15/9/15". Das ist mindestens 
deshalb ungültig. Was der Firefox macht ist korrekt, die Admins der 
Seite haben's verkackt, das ist allein deren Schuld. Wenn andere Browser 
das akzeptieren, ist das ein Bug in den Browsern.

Ich schreib seitenbetreibern mit ungueltigen Zertifikaten eine email. 
Sie koennen das SSL ja auch weglassen, dann gibt es diese Probleme alle 
nicht. Allerdings greife ich dann auf heikle Services nicht mehr zu.

Oder D. schrieb:
> Ich schreib seitenbetreibern mit ungueltigen Zertifikaten eine email.

Das ist der richtige Ansatz. Shit happens. Letzthin hatte Google mal 
kurz seine Domain verloren, weil wohl jemand gepennt hatte.

SSL für öffentliche Inhalte ist eh von fraglicher Nützlichkeit ... ich 
bin mir nichtmal sicher, ob das im Endeffekt nicht eher schadet. 
Mechanismen wie Caching, was verhinden kann dass jeder Request durch die 
ganze Welt fließt, werden dadurch jedenfalls verhindert.

Sven B. schrieb:
> SSL für öffentliche Inhalte ist eh von fraglicher Nützlichkeit ... ich
> bin mir nichtmal sicher, ob das im Endeffekt nicht eher schadet.

Wenn du nicht grad auf den Unterschied zwischen SSL und TLS anspielst 
ist es deine Entscheidung - aber auch die deiner Bank, denn die macht es 
hoffentlich nicht ohne.

Man sollte bei allem NSA/BND-Geschwurbel aber auch ab und zu an die 
(anderen) Internet-Gauner denken, die gerne Geld kassieren wollen.

A. K. schrieb:
> Man sollte bei allem NSA/BND-Geschwurbel aber auch ab und zu an die
> (anderen) Internet-Gauner denken, die gerne Geld kassieren wollen.

ich frage mich halt was ich gegen Angriff in-the-middle tun kann?
Ich komme doch maximal bis zu meiner TK Dose, weiter sind andere 
zuständig auf die ich keinen Einfluß habe. Hat sich der Internet-Gauner 
in die VST reingelassen oder ist der gar der Anbieter habe ich eh 
verloren.

A. K. schrieb:
> Sven B. schrieb:
>> SSL für öffentliche Inhalte ist eh von fraglicher Nützlichkeit ... ich
>> bin mir nichtmal sicher, ob das im Endeffekt nicht eher schadet.
>
> Wenn du nicht grad auf den Unterschied zwischen SSL und TLS anspielst
> ist es deine Entscheidung - aber auch die deiner Bank, denn die macht es
> hoffentlich nicht ohne.

Ach so, ne, TLS und SSL ... ich hab mich noch nicht dran gewöhnt TLS zu 
sagen ;)

Es ging mir eher darum dass heutzutage viele Seiten mit rein 
öffentlichem Inhalt (sagen wir, Wikipedia), TLS anbieten. Das heißt 
alles was verschlüsselt wird ist eh öffentlich zugänglich. Ob das 
zielführend ist ist fraglich.

Dass TLS Pflicht ist, sobald Logindaten oder irgendwas übertragen werden 
ist selstverständlich. Bei Banken fände ich es sogar sinnvoll, nicht auf 
die blöden CAs zu vertrauen, sondern dem Kunden einfach einen Brief mit 
dem Fingerprint zu schicken und dann Certificate Pinning zu machen.

Joachim B. schrieb:
> A. K. schrieb:
>> Man sollte bei allem NSA/BND-Geschwurbel aber auch ab und zu an die
>> (anderen) Internet-Gauner denken, die gerne Geld kassieren wollen.
>
> ich frage mich halt was ich gegen Angriff in-the-middle tun kann?

Genau dafür ist ja TLS eigentlich gut. Solange die CAs vertrauenswürdig 
sind (was sie nicht wirklich sind), werden solcherart Angriffe effektiv 
verhindert. Der Benutzer bekommt dann genau so eine Meldung wie in 
diesem Thread diskutiert. Und ignoriert die wahrscheinlich, womit der 
Schutz wieder dahin ist ;P

Joachim B. schrieb:
> ich frage mich halt was ich gegen Angriff in-the-middle tun kann?

Verschlüsselung mit PFS (perfect forward secrecy). Zertifikate mit 
Pinning, d.h. die gültigen Server-Zertifikate sind deinem System bereits 
a priori bekannt und der Server kann dir kein gefälschtes unterschieben.

Das dürfen die Leute zwischendrin ruhig mitlesen und auf Halde legen. 
Nützen tut es ihnen nach bisher bekanntem Stand nichts.

Man kann auch routinemässig HTTPS statt HTTP verwenden, wenn angeboten. 
Ohen den eben beschriebenen Firlefanz. Per Browser-Plugin funktioniert 
das sogar automatisch. Beispielsweise bei mikrocontroller.net - das zu 
verschlüsseln ist zwar nicht ganz so wichtig, schadet aber nicht. Muss 
ja nicht jeder auf dem Zwangsproxy deines Providers rein aus Neugierde 
mitlesen können.

oszi40 schrieb:
> Ein tracert nach irgendwo hat oft > 10 Rechner dazwischen.

Und ggf. noch ein paar dazwischen die du nicht siehst, wenn auch 
unterhalb von IP geroutet wird, z.B. per MPLS. Da kann es schon mal 
vorkommen, dass die dramatisch steigende Latenz zwischen zwei Traceroute 
Hops teuflisch nach einer Route über Big Brother aussieht, aber keiner 
der Hops schweflig riecht.

oszi40 schrieb:
> Weißt Du, ob Du immer genau daaaaaa ankommst, wo Du wirklich hin
> wolltest?

Außerdem geht es ja auch keinen was an, ob du dich auf Wikipedia
nun gerade für den Aufbau einer Bombe, die Zusammensetzung von
Schlagsahne oder die Grundideen des Maosimus interessierst.

oszi40 schrieb:
> Sven B. schrieb:
>> öffentlichem Inhalt (sagen wir, Wikipedia), TLS anbieten. Das heißt
>> alles was verschlüsselt wird ist eh öffentlich zugänglich. Ob das
>> zielführend ist, ist fraglich.
>
> ... ist nicht so fraglich. Weißt Du, ob Du immer genau daaaaaa ankommst,
> wo Du wirklich hin wolltest? Ein tracert nach irgendwo hat oft > 10
> Rechner dazwischen. Weißt Du GENAU, ob da unterwegs böse Geister eine
> Kiste davon so verbiegen und Dir ein paar faule Eier mitgeben?
> Verschlüsslung erhöht den Aufwand wesentlich.

Verschlüsselung erhöht den Aufwand gar nicht. Die Signatur ist das, 
was den Aufwand erhöht. Signierte Wikipedia-Artikel? Bitteschön, bin ich 
dabei. Aber bei verschlüsselt bin ich mir nicht sicher, ob das 
zielführend ist. Nimm mal an, hier um die Ecke steht ein Rechenzentrum, 
was mir den Artikel cached. Dann geht mein Request gar nicht quer durch 
Europa, sondern bleibt vielleicht innerhalb meiner Heimatstadt. Das ist 
doch ein Vorteil.

Sven B. schrieb:
> Nimm mal an, hier um die Ecke steht ein Rechenzentrum, was mir den
> Artikel cached.

Woher würdest du von diesem Rechenzentrum denn erfahren, um dessen
Cache auch tatsächlich zu benutzen?

Ich glaube, genau scheiterte es zu Zeiten, als die Leitungen noch
viel dünner waren, vor allem.  Ist ja nicht so, dass es solche Versuche
nicht schon mal gegeben hätte.

Kommt dazu, dass in aller Regel die Leitung zum Rechenzentrum bei dir
um die Ecke keineswegs so geradlinig sein dürfte, wie man sich das
wünschen würde.

Jörg W. schrieb:
> Sven B. schrieb:
>> Nimm mal an, hier um die Ecke steht ein Rechenzentrum, was mir den
>> Artikel cached.
>
> Woher würdest du von diesem Rechenzentrum denn erfahren, um dessen
> Cache auch tatsächlich zu benutzen?

Naja, da ist ein Router, der meinen Request weiterleitet. Wenn der 
sieht, "oh, das ist ein GET auf de.wikipedia.org/blabla" und "so einen 
hab ich vor 30 Millisekunden schonmal weitergeleitet und das hier war 
die Antwort" ... dann kann der mir die einfach zurückschicken, ohne den 
Request nochmal weiterzuschicken.

Jörg W. schrieb:
> Kommt dazu, dass in aller Regel die Leitung zum Rechenzentrum bei dir
> um die Ecke keineswegs so geradlinig sein dürfte, wie man sich das
> wünschen würde.

Yep. Schweizer Unternehmen zu süddeutschem Unternehmen läuft über die 
USA, weil Provider sich im Peering-Krieg befinden.

Sven B. schrieb:
> Naja, da ist ein Router, der meinen Request weiterleitet. Wenn der
> sieht, "oh, das ist ein GET auf de.wikipedia.org/blabla"

Ein normaler Router interessiert sich nicht für den Inhalt, also "GET". 
Ein Proxy schon. Und Schnüffelgeräte (deep packet inspection).

> hab ich vor 30 Millisekunden schonmal weitergeleitet und das hier war
> die Antwort" ... dann kann der mir die einfach zurückschicken, ohne den
> Request nochmal weiterzuschicken.

Nur wenn Caching zulässig ist, war heute meist nicht der Fall ist.

Sven B. schrieb:
> Naja, da ist ein Router, der meinen Request weiterleitet.

Du schmeißt hier kräftig die Layers durcheinander.

Routing: Layer 3 (IP)
HTTP: Layer 4

Das, was du willst, nennt sich transparenter Proxy, und der müsste
dann bei deinem Provider stehen.  (Das Rechenzentrum neben dir hat
sehr wahrscheinlich einen anderen Provider als du, das kommt also
netztopologisch gar nicht dafür in Frage.)

Kann man machen, aber kostet Aufwand, den würde sich jemand bezahlen
lassen wollen.  Mittlerweile sind die Kosten für den Datentransport
so viel geringer, dass sich der zusätzliche Aufwand für den Proxy
nicht lohnt.  Früher hatten die großen Provider (wie die Telekom)
noch (nicht-transparente) Proxies, die zumindest an netztopologisch
sinnvoller Stelle saßen, die du allerdings hättest explizit in
deinem Browser konfigurieren müssen (oder noch besser: du betreibst
in deinem Netz gleich selbst einen Squid, der den Proxy des ISP als
Upstream-Proxy nimmt).  Aber die Zeiten sind vorbei.

Ganz unabhängig davon bliebe noch der juristische Aspekt: normalerweise
beauftragst du deinen ISP, deine IP-Pakete passend zum Ziel zu leiten
und die Antworten zurück.  Dass er sich in die höheren Ebenen einmischt,
ohne sich vorher deine Genehmigung dazu zu holen, ist normalerweise
nicht erwünscht.

Jörg W. schrieb:
> Mittlerweile sind die Kosten für den Datentransport
> so viel geringer, dass sich der zusätzliche Aufwand für den Proxy
> nicht lohnt.

Es lohnt allein schon deshalb nicht, weil das eingesparte Datenvolumen 
relativ gering ist. Das Web verwendet mittlerweile überwiegend 
dynamische Seiten, die einem Proxy mitteilen, dass er den Kram jedesmal 
neu holen soll.

> Ganz unabhängig davon bliebe noch der juristische Aspekt: normalerweise
> beauftragst du deinen ISP, deine IP-Pakete passend zum Ziel zu leiten
> und die Antworten zurück.

Das steht wo?

> Dass er sich in die höheren Ebenen einmischt,
> ohne sich vorher deine Genehmigung dazu zu holen, ist normalerweise
> nicht erwünscht.

Zwangsproxies sind im Mobilfunk nicht weiter ungewöhnlich.

Probier auf Handy/Tab mal http://www.meine-aktuelle-ip.de aus. Und schau 
dir an, ob was unter HTTP_X_FORWARDED_FOR IP steht.

A. K. schrieb:
> Zwangsproxies sind im Mobilfunk nicht weiter ungewöhnlich.

OK, Mobilfunk war für mich jetzt kein ISP. ;-)

Allerdings dürfte es selbst dort darüber laufen, dass das in den
Browser eingetragen wird, oder?

(OT: was versprechen sie sich davon?  Weniger offene NAT-Ports, damit
ihnen die maximal 64 KiPorts für den Absender nicht zu knapp werden?)

> Das Web verwendet mittlerweile überwiegend dynamische Seiten, die einem
> Proxy mitteilen, dass er den Kram jedesmal neu holen soll.

Es gibt schon durchaus auch noch Inhalte, bei denen das nicht der
Fall ist, wie das schon genannte Wikipedia.  Allerdings dürften die
im gesamten Datenvolumen keine so große Rolle spielen.  Wenn Atmel
für sein x-hundert-MB-Studio ein automatisches Mirrornetz aufsetzen
würde, wäre das wohl deutlich hilfreicher, als ein paar Kilobyte eines
Wiki-Artikels zu cachen.

timowi schrieb:
> michi42 schrieb:
>> comodo stellt zertifikate aus für hmmmm... UNBEKANNT???
>
> ja, warum auch nicht. Entscheidend hier ist "Domain Control Validated".
> D.h. nur dir Kontrolle über die Domain wird geprüft. Namen und weiteres
> dürfen dann nicht Teil des Zertifikates sein.
>
Das procedere für "Domain Control Validated" ist Dir bekannt oder?


Ernst nehmen würde ich solche "Zertifikate" nicht.

Jörg W. schrieb:
> Sven B. schrieb:
>> Naja, da ist ein Router, der meinen Request weiterleitet.
>
> Du schmeißt hier kräftig die Layers durcheinander.
>
> Routing: Layer 3 (IP)
> HTTP: Layer 4
>
> Das, was du willst, nennt sich transparenter Proxy, und der müsste
> dann bei deinem Provider stehen.  (Das Rechenzentrum neben dir hat
> sehr wahrscheinlich einen anderen Provider als du, das kommt also
> netztopologisch gar nicht dafür in Frage.)

Jaja, weiß ich doch alles. Trotzdem gibt es diese Möglichkeit, und es 
ist aus diversen Gründen eigentlich sinnvoll die zu nutzen (auch gerade 
aus Privacy-Gesichtspunkten).
https://en.wikipedia.org/wiki/Content_delivery_network#Emergence_of_telco_CDNs

Sven B. schrieb:
> SSL für öffentliche Inhalte ist eh von fraglicher Nützlichkeit

Das Browse-Verhalten eines Nutzers ist kein öffentlicher Inhalt.

Bernd K. schrieb:
> Sven B. schrieb:
>> SSL für öffentliche Inhalte ist eh von fraglicher Nützlichkeit
>
> Das Browse-Verhalten eines Nutzers ist kein öffentlicher Inhalt.

Das verbirgst du aber durch Verwendung von TLS eh nur zu einem kleinen 
Teil. Oder du bewirkst dadurch im schlimmsten Fall sogar das Gegenteil 
(siehe Caching).

Sven B. schrieb:
> Das verbirgst du aber durch Verwendung von TLS eh nur zu einem kleinen
> Teil.

Inwiefern? Dein PC kennt es, zumindest eine Weile lang. Der jeweilige 
Server kennt es. Und sonst? Ohne TLS kennt es jede Zwischenstation mit 
Protokollierung, mindestens was die Domains angeht.

> Oder du bewirkst dadurch im schlimmsten Fall sogar das Gegenteil
> (siehe Caching).

Dass komplette Webseiten gecached werden und deshalb der Zugriff dort 
deshalb überhaupt nicht mehr auftaucht ist recht wenig wahrscheinlich.

A. K. schrieb:
> Sven B. schrieb:
>> Das verbirgst du aber durch Verwendung von TLS eh nur zu einem kleinen
>> Teil.
>
> Inwiefern? Dein PC kennt es, zumindest eine Weile lang. Der jeweilige
> Server kennt es. Und sonst? Ohne TLS kennt es jede Zwischenstation mit
> Protokollierung, mindestens was die Domains angeht.

Auch mit TLS kennt jede Zwischenstation die meisten Meta-Informationen, 
also Domain und Zeitpunkt des Zugriffs. Das ist außer für wenige Domains 
(vielleicht Wikipedia) schon alles, was man zum Schnorcheln wissen muss.