Hallo
mein Mozilla 41.0.1 misstraut der Seite vom deutschen Kupferinstitut www
kupferinstitut de :
"Dieser Verbindung wird nicht vertraut
Sie haben Firefox angewiesen, eine gesicherte Verbindung zu
www.kupferinstitut.de aufzubauen, es kann aber nicht überprüft werden,
ob die Verbindung sicher ist.
..."
wenn ich "Ich kenne das Risiko" wähle und dann "zu den Ausnahmen
hinzufügen" und die weiteren Schritte klicke klappt es leider auch
nicht, ich gelange dann zu einen LogIn der Seite vom Deutschen
Kupferinstitut.
Die Seite kann ich aber über einen Rechner im Firmennetzt bei meinen
Arbeitgeber mit den Microsoft Explorer (Version ?) problemlos ansurfen.
Es baut sich ganz normal die Seite auf, ohne jegliches LogIn Gedöns.
Weder der Inhalt der Seite, noch die Tatsache das das Firmennetz ehr
besser abgesichert ist als mein Privater Einzelplatzrechner zu Hause
noch das die Seite der erste Suchtreffer bei Google ist deutet darauf
hin das der Seite tatsächlich misstraut werden müsste.
Derweiteren erscheint bei der Google Suche auch (rechts neben den ersten
Suchtreffer) direkt durch Google eine echte Deutsche Postadresse, eine
Kartendarstellung und ein Streeviewbild des Gebäudes mit verlinkung zu
StreetView ("Haus der Metalle").
Ist Mozilla eventuell bei der Seite überempfindlich? Oder ist die Seite
nachweisliche (Quellenangabe, keine Meinung oder Vermutung) in
irgendeiner Weise "verseucht"?
Meine Google Suche:
https://www.google.de/search?q=dEUTSCHES+kUPFERINSTITUT&ie=utf-8&oe=utf-8&gws_rd=cr&ei=3qoSVuqiAqShyAOjoqfoAQ
Was kann (muß) ich mit meinen Mozilla machen machen um die Seite normal
ansurfen zu können?
mfg
Kupferlos
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).
Also das deutsche Kupferinstitut ist eine Institution mit der ich auf dem Kupfersymposium im Rahmen der Metallographietagung vor ein paar Jahren in Rostock auch schon persönlich zu tun hatte. Also das ist genauso echt wie der VDI oder ähnliche Interessengemeinschaften. Warum FF41 dem nicht vertraut? Vielleicht haben sie kein nach FF's Regeln zertifiziertes SSL? Ich kenne die Seite um die PDF-Broschüren von dort zu laden und mein FF auf Android meckert auch gerade nicht. Hast vielleicht eine Internet Security die dazwischen funkt? Oder eine dieser "alles nur nocn über https-Erweiterungen? Das könnte auch die Login-Aufforderung erklären, vielleicht benutzen die dort https für Mitglieder/Eingeweihte zum einloggen und leiten deshalb den Aufruf um? Ich würd das mal probehalber abschalten wenn vorhanden und die normale http-Seite ansurfen. Viel Erfolg
Angehängte Dateien:
-
sicherheitskupfer.png
40 KB
Jim M. schrieb: > eine andere Seite erhältst Bei mir kommt eine Seite mit gültigem Zertifikat.
Jim M. schrieb: > 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. Kann ich nicht bestätigen. Bei mir hat die Seite ein gültiges Zertifikat von COMODO CA Limited, Ablaufdatum 31.12.2016. Alles geht tadellos.
Hm, bei https://kupferinstitut.de (Ohne WWW!) kommt in der Tat die Meldung. Und mit https://copperalliance.de/ geht es ganz schief ...
Achim H. schrieb: > Hm, bei https://kupferinstitut.de (Ohne WWW!) kommt in der Tat die > Meldung. Klar. Wenn das Zertifikat für den Adresse nicht gilt, kommt eine entsprechende Fehlermeldung. Und dann wird das wohl so sein.
1 | "Das Zertifikat gilt nur für folgende Namen: |
2 | standalone.kupferschluessel.de, www.kupferinstitut.de, www.kupferschluessel.de, www.kupferseminar.de" |
Achim H. schrieb: > Und mit https://copperalliance.de/ geht es ganz schief ... Auch kein Wunder.
1 | "Das Zertifikat gilt nur für folgende Namen: |
2 | secure.copperalliance.eu, www.secure.copperalliance.eu" |
Man muss schließlich nicht für jeden Sch..ß Alias ein Sicherheitszertifikat ausstellen.
Hallo wenn ich bei der Mozilla "Fehler"-meldung Technische Details anklicke erhalte ich folgende Meldung: "www.kupferinstitut.de:8443 verwendet ein ungültiges Sicherheitszertifikat. Dem Zertifikat wird nicht vertraut, weil es vom Aussteller selbst signiert wurde. Das Zertifikat gilt nur für Parallels Panel. Das Zertifikat ist am 15.09.2015 23:16 abgelaufen. Die aktuelle Zeit ist 05.10.2015 20:06. (Fehlercode: sec_error_unknown_issuer)" Betriebsystem ist Win7 auf aktuellen Stand und Avira Antivir (Kostenlose Version) auf ebenfalls aktuellen Stand. Add-ons die eventuell einen Einfluss haben könnten (?) habe ich folgende Adblock Plus Better Privacy Ghostery die anderen meiner Add-Ons können meiner Meinung nach keinesfalls einen Einfluss haben.(Add ons für Video download, Serverinfo,Bildersuche u.ä.) mfg Kupferlos
Neben dem RICHTIGEN Namen sollte aber auch Datum und Uhrzeit genau sein. Obige Fehlermeldung (Fehlercode: ssl_error_bad_cert_domain) wird ein Problem mit dem Namen sein. Evtl. ist auch bei DNS was faul?
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?
oszi40 schrieb: > Obige Fehlermeldung (Fehlercode: ssl_error_bad_cert_domain) wird ein > Problem mit dem Namen sein. Evtl. ist auch bei DNS was faul? Mit dem Namen eher nicht. Aber mit dem Port:
1 | www.kupferinstitut.de:8443 |
Rufus Τ. F. schrieb: > Woher kommt diese Vorgabe, bzw. diese URL? Das scheint eine Plesk Login Seite zu sein. Also vermutlich der Administratorzugang vom Hoster (http://www.odin.com/).
Hallo "Woher kommt diese Vorgabe, bzw. diese URL?" Tja das würde ich auch gerne Wissen... Gebe ich die URL händisch per Tatatur ein komme ich zur schon angespochenen "Fehler"-Meldung vom Firefox. Wird gezielt http://www.kuperinstitut.de ein (also nicht https://....) "macht" Mozila automatisch "https://www.kupferinstitut.de:8443/"; daraus was aber eben auch die "Fehler"-Meldung hervorruft. 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. mfg Kupferlos (Mittlerweile doch schon leicht frustriert) Ich möchte letztendlich diesen Beitrag von der Homepage ansurfen https://www.kupferinstitut.de/de/werkstoffe/anwendung/e-mobilitaet/schienenverkehr/bahn-energie.html
Kupferlos schrieb: > Ich möchte letztendlich diesen Beitrag von der Homepage > ansurfen Also ich kann den Link in Deinem Beitrag problemlos direkt im FF (41.0.1) aufrufen. Könntest mal versuchen Browserhistory und Caches zu löschen. Oder hast Du eventuell irgendwelche Plugins installiert?
(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.
Test ging hier problemlos mit FF. Evtl. nochmals Cache leeren und DNS vergleichen? https://www.kupferinstitut.de/de/werkstoffe/anwendung/e-mobilitaet/schienenverkehr/bahn-energie.html
Hallo, liegt an irgendeine Einstellung im meinen Router :-O Habe mich über einen Surfstick mit den Internet verbunden und damit klappt es :-) Danke für die Unterstüzung. (Was falsch ist muss ich noch herausfinden - aber nicht mehr heute) mfg Kupferlos
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.
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
ff28.gif
10 KB
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!
:
Bearbeitet durch User
ich hatte auch mal das Problem, dass ich Aufgrund eines ungültigen Zertifikates, obwohl ich geklickt hab „ich kenne das Risiko“ (egal), nicht auf eine spezielle Seite meiner Hochschule kam. Ich habe dann rausgefunden das es nicht der Browser war, welcher blockierte, sondern mein Antiviren Web Schutz. Hab ich diesen deaktiviert (da gibt es so Buttons für 10 min deaktivieren) ging es. gr
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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. ;-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
Banksicherheit.JPG
29 KB
> jeder zwischen dir und deiner Bank den Inhalt mitlesen
Ja liebe Leser, Bankwahl ist Vertrauenssache. Wie meinte schon der CCC:
"Wir sind alle Simulanten"! Deshalb ist es nicht sehr schlau, jeden
Zertifikats-Dreck ohne nachdenken UNgeprüft zu erlauben.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Dieses Zertifikat wurde für die folgenden Verwendungen verifiziert: SSL-Client-Zertifikat SSL-Server-Zertifikat Ausgestellt für Allgemeiner Name (CN) kein Teil Organisation (O) <kein Teil des Zertifikats> Organisationseinheit (OU) Domain Control Validated Seriennummer OO:B6:FB:D9:55:DA:49:EC:E2:67:36:29:F6:CD:51:73:D4 Ausgestellt von Allgemeiner Name (CN) COMODO RSA Domain Validation Secure Server CA Organisation (O) COMODO CA Limited Organisationseinheit (OU) <kein Teil des Zertifikats> Gültigkeitsdauer Beginnt mit 07.10.2014 Läuft ab am 31i2.2016 Fingerabdrücke SHA-256-Fingerabdruck D6:17:7D:4E:21:5B:AC:71:FO:F2:9F:22:EB:C2:03:EO: 89:FD:C8:1A:30:F3:3C:99:74:C8:SA:F4:EE:D9:9D:15 SHA1-Fingerabdruck 53:C8:88:18:53:57:AC:BB:D3:72:28:74:1D:C0:87:80:84:10:BD:33 comodo stellt zertifikate aus für hmmmm... UNBEKANNT???
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.
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.
:
Bearbeitet durch User
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. Der Fehler liegt übrigens in der IPV6 Konfiguration der Seite www.kupferinstitut.de (91.250.86.202:80) liefert die richtige Seite. Da wohl auch mit SSL das gültige Zertifikat. www.kupferinstitut.de ([2a01:488:67:1000:5bfa:56ca:0:1]:80) dagegen liefert eine Umleitung auf https://www.kupferinstitut.de:8443
1 | HTTP/1.1 302 Found |
2 | Date: Tue, 06 Oct 2015 11:27:52 GMT |
3 | Server: Apache |
4 | Location: https://www.kupferinstitut.de:8443 |
5 | Cache-Control: max-age=0 |
6 | Expires: Tue, 06 Oct 2015 11:27:52 GMT |
7 | Vary: Accept-Encoding |
8 | Content-Length: 289 |
9 | Content-Type: text/html; charset=iso-8859-1 |
10 | |
11 | <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
12 | <html><head>
|
13 | <title>302 Found</title> |
14 | </head><body>
|
15 | <h1>Found</h1> |
16 | <p>The document has moved [hier kommt noch mal der Link, entfernt wegen spamfilter hier]</p> |
17 | <hr>
|
18 | <address>Apache Server at www.kupferinstitut.de Port 80</address> |
19 | </body></html>
|
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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.
Der Server des deutsche Kupferinstitut verweigert bestimmt Anfragen die über Glasfaserleitungen einlaufen :) Die Konkurrenz muss nicht noch zusätzlich gestärkt werden.
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.