Habe ich ein Sicherheitsproblem im Forum RN ?

[oberallgeier]

Seit einiger Zeit sehe ich beim Aufruf des RoboterNETZes im Firefox-Fenster links oben eine Seiteninformation; Win7pro, Firefox 52.0.

Der "leere" Browser - siehe Bildteil A) - zeigt das übliche Fester einer gesicherten Verbindung an mit dem grünen Vorhängeschloss-Symbol. Nach Aufruf des Forums - ohne Anmeldung - kommt das rot durchgestrichene, dunkelgraue Vorhängeschloss - siehe Bildteil B). Schließlich, nach der Anmeldung, verschwindet das dunkelgraue Vorhängeschloss mit der roten Schärpe. Aber nach Klick auf den kleinen (i)-Button erhalte ich dann doch die Warnung "Verbindung ist nicht sicher", siehe Bildteil C).

......Bild hier  

Was ist schuld daran? Habe ich eine unsichere Mozillaversion, eine nicht-geupdatete Forumssoftware, bekomme ich eine Site ohne Zertifikat oder woran liegts?

Vielen Dank für ne Erklärung und evtl für Hinweise auf Abstellen der Fehlermeldung(en).

[shedepe]

Nein das ist nur der Hinweis, dass Roboternetz nicht über eine verschlüsselte Verbindung (https) läuft. Eventuell könnte Frank, das ja mal bei Gelegenheit einrichten.

[.:Sebastian:.]

Moin,

Problem wird vermutlich sein, dass das Zertifikat was https://roboternetz.de liefert nur für *.kasserver.com und kasserver.com gilt.
Wahrscheinlich benutzt der Webserver das falsche Zertifikat oderso.

Grüße,
Sebastian

[i_make_it]

Ja, Zertifikat für die falsche Domäne und läuft Mitte diesen Jahres ab.

Geht man von einem öffentlichen WLAN aus ins Forum hat man definitiv ein Sicherheitsproblem, da jeder mit ein paar Tools dann den TCP stream capturen kann und so an User und PW kommt, da ja in Klartext übertragen werden.
Hat man ein LAN in dem noch andere (nicht vertrauenswürdige) Clients hängen, hat man auch ein Sicherheitsproblem, Wenn jemand ARP Spoofing betreibt, bekommt der selbst in einem geswitchten Netz alle Pakete mit.
Bei einem ISP der nur Bridging betreibt, hat man auch ein Problem.
Bei den anderen ISPs kommt es darauf an wie die monitoren und ob die merken wenn jemand ARPspoofing betreibt.

Also hier am besten nur ein PW nutzen das man nirgendwo sonst nutzt.
Grade oberallgeier, der ja durch Archie auch mit seinem Realnamen in Verbindung gebracht werden kann, steigt da das Risiko das jemand auch andere Accounts zuordnen kann und so mit einem abgefangenen Passwort gezielt diese Accounts attackiert.

Bei einem No Name User der nicht ohne weiteres zu anderen Accounts und einer realen Person zugeordnet werden kann, ist das Schadenspotential geringer.

[oberallgeier]

Ja, Zertifikat für die falsche Domäne und .. steigt da das Risiko das jemand auch andere Accounts zuordnen kann ..

Danke; ausführlich und verständlich für mich. Im Moment nicht sooo dringlich (Zentralalpen und Wintersport) aber wenn ich zurück bin, dann werd ich mich mal hinsetzen um ein bisschen System reinbringen. Danke nochmals.

[oberallgeier]

Die Meldung/das fehlende "Grün" kommt viel öfter als mir früher aufgefallen war. Angefangen bei der FRITZ!Box

......Anhang 32506
......(Das Browserfenster wurde hier möglichst klein gezogen)

auch bei Händlern (z.B. EXPTech u.a.), eben dann, wenn http://.. aufgerufen wird/wurde. Eben wie von i_make_it oben dargestellt.
Sichere Verbindungen sind mikrocontroller.net, Wikipedia, DHL Sendungsverfolgung, youtube uva. - meist über https://.. aufzurufen.
ABER wenn ich die
https://www.roboternetz.de/community...etdaily&days=3
als
https://www.roboternetz.de/community...etdaily&days=3
aufrufe, dann ist die Verbindung ebenfalls unsicher.

Nun habe ich also wirklich ein Sicherheitsproblem und mir ist nicht klar, wie ich das lösen kann. Denn die Lücke besteht ja trotz eingeschalteter firewall, funktionierendem Virenscanner etc. Mannnoohhhmann. Diese Geschichte klingt mir doch ziemlich weit verbreitet - also eine RICHTIG große Sicherheitslücke (siehe z.B. hier oder hier). Bahhhh.

Wie löst ihr dieses Problem?
Danke für Antworten und Hilfen.

[i_make_it]

Das Problem ist nicht durch uns Nutzer lösbar.
Nur durch den Server Administrator.
Es gibt 3 Möglichkeiten.
1- Damit jeder Browser auf Anhieb das Zertifikat erkennt, eines für die Domäne kaufen. (so ab 10€ im Jahr)
2- Sich ein Zertifikat über cercert.org erstellen und bei Veranstaltungen wie Ce-Bit etc. einen CACert-Assurer besuchen um sich zu Authentifizieren. (Man kann sich auch an den CCC wenden)
4- Self Signed Zertifikat erstellen. Hierbei kennt kein Browser das Zertifikat und es könnte genauso von einem Man in the Middle Angriff eingeschleust sein wie vom Server Admin erstellt. Da hängt es davon ab ob der User dem vertraut (Sicherheitsausnahme im Browser eintragen und ggf. die CA von Hand in die Liste der vertauenswürdigen CA's aufnehmen), aber die Kommunikation ist genauso verschlüsselt wie bei den Methoden 1 und 2.(auch bei CAcert muß man erst dessen Root-Ca in den eigenen Browser aufnehmen, da die als non Profit Org nicht automatisch in jedem Browser vorinstalliert sind - http://wiki.cacert.org/FAQ/BrowserClients/DE)

Momentan werden bei jeder Anmeldung die Usernamen und Passwörter jeden RN Users im Klartext übertragen und sind so potentiell kompromitiert.
Die einzige Schutzmaßnahme die wirkt ist, nicht mehr anmelden bis wieder eine sichere SSL Komunikation gegeben ist.

Ich selbst nutze momentan, Prinzip Hoffnung und eine User/PW Kombination die ich sonst nirgendwo einsetze, als Schadensminimierung.

[Frank]

Hi,

das Problem ist eigentlich kein Problem. Bis vor kurzem war es üblich das die meisten Webseiten nicht verschlüsselt waren, es wurde von vielen Providern/Hostern sogar abgeraten da die Verschlüsselung Performance kostet - sprich ein Forum wird dadurch langsamer!

Das es jetzt einigen ins Auge gefallen ist liegt nur daran das Google und andere Browserhersteller seit kurzem anzeigen das die Seite nicht verschlüsselt ist, man möchte damit zukünftig die Webseiten Betreiber animieren alles zu verschlüsseln. In vielen Fällen macht es gar keinen Sinn, denn Informationen die sowieso öffentlich sind braucht man nicht verschlüsseln. Es hat lediglich einen Nutzen (zusätzliche Sicherheit) wenn private Daten auf einen Webseite abgelegt werden, also bei Foren Login-Daten. Die Webseiten sind aber ohne Verschlüsselung nicht unsicherer als in den letzten 15 Jahren - also keine unnötige Panik

Der Roboternetz-Server hat ein eigenes gültiges Zertifikat, es wäre ein leichtes das Forum selbst auch zu verschlüsseln. Allerdings gibt es das Problem das in Foren oft auch externe Scripte, Bilder, Dateien von anderen Webseiten eingebunden sind, diese können dann vom Betreiber (also mir) nicht verschlüsselt werden. Die hätte dann aber zur Folge das die Browser nach wie vor den selben Warnhinweis bringen. Wenn nur eine einzige Datei auf der Seite von extern nicht verschlüsselt ist, bleibt es bei der Warnung. Es wäre also nahezu unmöglich ein Forum dieser Größe komplett verschlüsselt anzuzeigen nur damit die Browser die Leser nicht verunsichern.
Das das stimmt was ich schreibe könnt ihr prüfen wenn ihr zum Beispiel eine Roboternetz Seite in verschlüsselter Form aufruft, dazu müsst ihr nur ein https:// statt http:// voranstellen. Zum Beispiel diese Seite: https://www.roboternetz.de/community/forum.php
Ihr seht das die Seite dann nicht mehr richtig dargestellt wird, da das Forum einige externe Scripte nutzt die auch nicht verschlüsselt sind. In Chrome habt ihr dann zusätzlich rechts oben in der Eingabezeile eine Schaltfläche die Euch erlaubt die externe Scripte freizugeben. Wenn Ihr das macht, wird die Seite wieder korrekt dargestellt, aber der Warnhinweis bleibt wegen der Scripte. Die Scripte könnte man zum Teil sicher durch verschlüsselte ersetzen, aber alle anderen Bilder und Dateien die User verlinkt haben halt nicht.

Von daher wird das Roboternetz.de, wie auch fast alle anderen großen Foren und Webseiten sicherlich die nächste Zeit nicht verschlüsselt werden können. Aber wie gesagt, das Roboternetz ist heute genauso sicher wie die letzten 10 Jahre - der Hinweise der Browser sollte nicht überbewertet werden. In Foren sollte man generell nie das wichtigste Masterpasswort nutzen das man vielleicht auch in Shops nutzt, empfehlenswert ist ein eigenes Passwort - den maxmalen Schaden kann jeder dadurch selbst minimieren.

Ich hoffe ich konnte etwas aufklären und beruhigen.

[oberallgeier]

Hallo Frank,
danke für Deine Ausführungen. Den "Trick" mit dem "https://.." hatte ich natürlich schon versucht, das Ergebnis war lausig:

......Bild hier  

und die Warnung blieb.

.. das Problem ist eigentlich kein Problem .. also keine unnötige Panik ..
.. aber der Warnhinweis bleibt wegen der Scripte ..

Der Hinweis auf die Warnungen in >letzter> Zeit war mir selbst eingefallen - solche und ähnliche Lösungen sind ja mittlerweile oft Standard um mögliche Schadenersatzforderungen zu umgehen. Ich werde die Ratschläge beherzigen und ansonsten gemütlich weitermachen (müssen).

[i_make_it]

Das Problem sind halt die Anmeldedaten, vor allem das Passwort, das so unverschlüsselt übers Netz geht. Eine Möglichkeit ohne SSL wäre ein Client Script in die Anmeldung einzubauen, das den öffentlichen Schlüssel enthält und das PW chiffriert bevor es an die POST Variable übergeben wird. Das kann dann nur der Server mit dem privaten Schlüssel entschlüsseln oder einfacher alle PW's werden verschlüsselt in der Datenbank gespeichert, dann wird das Chiffrat einfach mit dem Chiffrat in der Datenbank verglichen und der private Schlüssel muß auch nicht auf dem Webserver liegen. Auf den Clients muß dann hat Scriptausführung erlaubt sein. Geht ab auch wenn das Script per Zertifikat signiert ist.