Firefox 52 -- Warnung -- kein https

Hier haben Anregungen und Kritik zum Eisenbahnforum ihren Platz
Antworten
AndiFant

Beitrag von AndiFant »

Hallo,
firefox 52 "meckert", weil die Benutzername/Passworteingabe bei www.eisenbahnforum.de nicht verschlüsselt übertragen wird. Wenn ich versuche, das eisenbahnforum mit https://www.eisenbahnforum.de aufzurufen, gibt firefox eine Fehlerseite aus, die meldet:
"Your connection is not secure.
The owner of www. eisenbahnforum.de has configured their webite improperly. To protect your information from being stolen, Firefox has not connected to this website."

Muss ich mir jetzt Gedanken machen?
Mark8031
Lebende Forenlegende
Beiträge: 3422
Registriert: 09 Apr 2012, 01:35
Wohnort: MBAL

Beitrag von Mark8031 »

Nein. Sofern du die allgemeinen Empfehlungen, für alles ein separates Passwort zu verwenden, beherzigst. Und auch wenn du das nicht tust, ist es nur halb so schlimm. Das EF ist 1. mit so einer alten Software unterwegs, dass es nicht mehr im Fokus von kriminellen steht und 2. ein zu kleines Licht um im Fokus von Kriminellen zu stehen. Nichtsdestotrotz würde ein Umstieg auf SSL gut tun, insbesondere im Hinblick auf die Bestrafung von Suchmaschinen, die bald für "unsichere" Websites ansteht
Diese Menschen, die in einem Eisenbahnforum pro Auto argumentieren und in ihrer Kleinsichtigkeit ständig für das Auto Werbung machen, finde ich hier schon etwas deplaziert.
Didy
Lebende Forenlegende
Beiträge: 3602
Registriert: 26 Jul 2006, 10:11

Beitrag von Didy »

Mark8031 @ 14 Mar 2017, 01:10 hat geschrieben: Und auch wenn du das nicht tust, ist es nur halb so schlimm. Das EF ist 1. mit so einer alten Software unterwegs, dass es nicht mehr im Fokus von kriminellen steht und 2. ein zu kleines Licht um im Fokus von Kriminellen zu stehen.
Die Aussage ist so nicht ganz korrekt.

Du spielst jetzt auf einen Angriff auf die Forensoftware an. Das hat aber nichts mit der Übertragung per http oder https zu tun.

Die Frage http oder https betrifft hingegen: Kann jemand, der sich in die Übertragung einklinkt, das Passwort im Klartext mitlesen (http) oder nicht (https).

Daher ist es grundsätzlich empfehlenswert, für jede Anwendung ein eigenes Passwort zu haben (-> Angriff auf das Forum), bei Übertragung mit http aber besonders (-> Jeder "unterwegs" kann das Passwort im Klartext mitlesen).
Benutzeravatar
FloSch
Lebende Forenlegende
Beiträge: 4506
Registriert: 28 Mär 2003, 11:30
Wohnort: München
Kontaktdaten:

Beitrag von FloSch »

Didy @ 14 Mar 2017, 10:36 hat geschrieben: -> Jeder "unterwegs" kann das Passwort im Klartext mitlesen
Insbesondere in öffentlichen WLANs...
Bild
Mastodon: muenchen.social/@ubahn | Instagram: @muenchnerubahn
Benutzeravatar
Iarn
*Lebende Forenlegende*
Beiträge: 23968
Registriert: 20 Jul 2007, 13:22

Beitrag von Iarn »

Das größte Risiko sehe ich eigentlich wenn irgendein Spammer, Spinner, Scherzkeks etc mal Boris Passwort abfängt und damit richtig Unsinn anstellt.
Autonome Volksfront für die Wiedererrichtung der klassischen 22er Tram in München
Nicht zu verwechseln mit der Populären Front
Bayernlover
*Lebende Forenlegende*
Beiträge: 13808
Registriert: 02 Aug 2009, 16:49
Wohnort: Dresden (4, 6, 10, 12, 65, 85)

Beitrag von Bayernlover »

Iarn @ 14 Mar 2017, 13:48 hat geschrieben: Das größte Risiko sehe ich eigentlich wenn irgendein Spammer, Spinner, Scherzkeks etc mal Boris Passwort abfängt und damit richtig Unsinn anstellt.
Gegen die Löschung von ein paar Trollen hätte ich allerdings nix :ph34r:
Für mehr Administration. Gegen Sittenverfall. Für den Ausschluss nerviger Weiber.
Benutzeravatar
218 466-1
"Lebende Forenlegende"
Beiträge: 7771
Registriert: 02 Aug 2010, 15:13
Wohnort: Red Bank NJ, ex-Ingolstadt

Beitrag von 218 466-1 »

AndiFant @ 14 Mar 2017, 00:34 hat geschrieben:Hallo,
firefox 52 "meckert", weil die Benutzername/Passworteingabe bei www.eisenbahnforum.de nicht verschlüsselt übertragen wird. (...) Fehlerseite aus, die meldet:
"Your connection is not secure.
The owner of www. eisenbahnforum.de has configured their webite improperly. To protect your information from being stolen, Firefox has not connected to this website."

Muss ich mir jetzt Gedanken machen?
Nein. Das ist nur ein neues Feature, das bei allen Logins ohne https angezeigt wird.

Wer diese Warnung nicht will, gibt im URL Feld "about:config" ein, akzeptiert den Risiko-Hinweis, scrollt hinuter zu "security.insecure_field_warning.contextual.enabled" (einfacher das hier ohne "" kopieren und dort oben im Suchfeld einfügen) und stellt das per Doppelclick von "true" auf "false" um.
Keine Alternative zum Transrapid MUC
Bild
Benutzeravatar
Boris Merath
*Lebende Forenlegende*
Beiträge: 16123
Registriert: 18 Nov 2002, 23:57
Wohnort: München

Beitrag von Boris Merath »

Also grundsätzlich habe ich den Umstieg auf https schon geplant und hatte auch auf einer anderen Domain schon einen Testlauf. Das Problem war hier die regelmäßige Erneuerung der Zertifikate, was nicht so lief wie ich es gerne hätte - der offizielle lets encrypt-Client war mir da einfach zu selbstständig - ich mag es nicht, wenn Programme als root automatisiert ausgeführt werden wollen, dabei selbstständig in der Konfiguration des Servers rumpfuschen und sich auch noch selbst updaten/Code aus dem Internet nachladen.

Aber gut, wenn Firefox es jetzt "erzwingt" (was ja grundsätzlich sinnvoll ist) weiß ich ja, womit ich dann mein Wochenende verbringe, und inzwischen hat sich auf dem Bereich der Zugriffsmöglichkeiten durch weitere Clients/Scripte etc. ja auch einiges getan.
Bis zur vollzogenen Anbringung von ausreichenden Sandstreuapparaten an allen Maschinen haben die Bahnwärter bei aufwärtsgehenden Zügen auf stärkeren Steigungen die Schienen ausgiebig mit trockenem Sand zu bestreuen und für die Bereithaltung eines entsprechenden Vorrathes zu sorgen.

Fahrdienstvorschrift bayerische Staatsbahnen 1876
AndiFant

Beitrag von AndiFant »

Danke, Boris für die Erklärung und die viele Zeit, die du investiert, das Forum am Laufen zu halten!
Rev
Lebende Forenlegende
Beiträge: 3323
Registriert: 28 Nov 2011, 20:15

Beitrag von Rev »

Boris Merath @ 14 Mar 2017, 17:09 hat geschrieben:Also grundsätzlich habe ich den Umstieg auf https schon geplant und hatte auch auf einer anderen Domain schon einen Testlauf. Das Problem war hier die regelmäßige Erneuerung der Zertifikate, was nicht so lief wie ich es gerne hätte - der offizielle lets encrypt-Client war mir da einfach zu selbstständig - ich mag es nicht, wenn Programme als root automatisiert ausgeführt werden wollen, dabei selbstständig in der Konfiguration des Servers rumpfuschen und sich auch noch selbst updaten/Code aus dem Internet nachladen.

Aber gut, wenn Firefox es jetzt "erzwingt" (was ja grundsätzlich sinnvoll ist) weiß ich ja, womit ich dann mein Wochenende verbringe, und inzwischen hat sich auf dem Bereich der Zugriffsmöglichkeiten durch weitere Clients/Scripte etc. ja auch einiges getan.
Ich verstehe nicht ganz warum du da ein wochende einplanst aber ich helfe ja gern bei sowas ;).

Das hier in nen Crontab von einem X beliebiegen user den man einsperren kann

Code: Alles auswählen

/certbot/certbot-auto certonly --keep-until-expiring --quiet --webroot -w /www/pfad/zum/boad -d eisenbahnforum.de -d www.eisenbahnforum.de
Damit pfuscht dir Letsencrypt auch nicht in deiner config rum sondern legt lediglich das fertig cert unter /etc/letsencrypt/live/eisenbahnforum.de ab da kann man den apache dann direkt drauf zugreifen lassen oder man verschiebt es nochmal um es "sichere" zu machen... certonly ist hier das Stichwort
/etc/init.d/apache2 reload
Den Apache einmal am tag durch laden


Und hier die saubere vohost config damit auch keine user versehentlich in irgendwelche unsicheren netzt noch auf HTTP geht und der Client trotzdem weiter verifizieren kann....

Code: Alles auswählen

<VirtualHost 176.9.90.201:80>
        ErrorLog /var/log/apache2/domains/eisenbahnforum.de-error.log
        CustomLog /var/log/apache2/domains/eisenbahnforum.de-access.log common
        ServerName eisenbahnforum.de
        DocumentRoot /www/domains/eisenbahnforum
        RewriteEngine On
        # Redirect all hits except for Let's Encrypt's ACME Challenge verification to example.com
        RewriteCond %{REQUEST_URI} !^.well-known/acme-challenge
        RewriteRule ^(.*) https://eisenbahnforum.de/$1 [R=301,L]
</VirtualHost>

<VirtualHost 176.9.90.201:80>
        ErrorLog /var/log/apache2/domains/eisenbahnforum.de-error.log
        CustomLog /var/log/apache2/domains/eisenbahnforum.de-access.log common
        ServerName www.eisenbahnforum.de
        DocumentRoot /www/domains/eisenbahnforum
        RewriteEngine On
        # Redirect all hits except for Let's Encrypt's ACME Challenge verification to example.com
        RewriteCond %{REQUEST_URI} !^.well-known/acme-challenge
        RewriteRule ^(.*) https://www.eisenbahnforum.de/$1 [R=301,L]
</VirtualHost>

<VirtualHost 176.9.90.201:443>
        ServerName eisenbahnforum.de
        ServerAlias www.eisenbahnforum.de
        ServerAdmin webmaster@eisenbahnforum.de
        DocumentRoot /www/domains/eisenbahnforum
        ErrorLog /var/log/apache2/domains/eisenbahnforum.de-error.log
        CustomLog /var/log/apache2/domains/eisenbahnforum.de-access.log common
        SSLEngine on
        Header always set Strict-Transport-Security max-age=15768000
        SSLCertificateFile /etc/letsencrypt/live/eisenbahnforum.de/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/eisenbahnforum.de/privkey.pem
</VirtualHost>

Das Auto update kannst du verhindern in dem du den client von den debian backports reps lädst... wobei das automatisch nachladen von Code nichts schlimmes ist wenn es von einer sicheren quelle kommt... man weiß eh nicht was bei nem Update vom z.b dem OS passiert da kann auch weiß Gott was installiert werden nur weil man den befehl selber eintippt gibt einen das nicht mehr Sicherheit... Es kommt immer auf die quelle an nicht das man es manuell macht...

Sache von 10 Minuten ...bei fragen helfen ich gern
Benutzeravatar
Boris Merath
*Lebende Forenlegende*
Beiträge: 16123
Registriert: 18 Nov 2002, 23:57
Wohnort: München

Beitrag von Boris Merath »

Zu dem Zeitpunkt meiner Tests damals war der letsencrypt-client ziemlich störrisch, und hat sich ziemlich massiv gegen Einschränkungen gewehrt. Aber wie ich ja geschrieben habe, seitdem hat sich einiges getan, von daher bin ich zuversichtlich dass das jetzt besser läuft.
Das Auto update kannst du verhindern in dem du den client von den debian backports reps lädst...
Na dann bin ich mal gespannt - vor einigen Monaten hat zumindest bei mir auch der Client der über Debian kam als erstes angefangen irgendwelche zusätzlichen Scripte runterzuladen und auszuführen. Das fand ich persönlich jedenfalls nicht so lustig.

Das Problem war nicht das Erstellen der Apache-Config (das ist in der Tat in 10 Minuten gemacht), sondern zu sehen was dieses Programm macht und negative Auswirkungen auszuschließen. Und da überzeuge ich mich doch lieber selber dass das kein Eigenleben entwickelt das ich nicht möchte.
Bis zur vollzogenen Anbringung von ausreichenden Sandstreuapparaten an allen Maschinen haben die Bahnwärter bei aufwärtsgehenden Zügen auf stärkeren Steigungen die Schienen ausgiebig mit trockenem Sand zu bestreuen und für die Bereithaltung eines entsprechenden Vorrathes zu sorgen.

Fahrdienstvorschrift bayerische Staatsbahnen 1876
Rev
Lebende Forenlegende
Beiträge: 3323
Registriert: 28 Nov 2011, 20:15

Beitrag von Rev »

Zu dem Zeitpunkt meiner Tests damals war der letsencrypt-client ziemlich störrisch, und hat sich ziemlich massiv gegen ein Einsperren geweigert. Aber wie ich ja geschrieben habe, seitdem hat sich einiges getan, von daher bin ich zuversichtlich dass das jetzt besser läuft.
Er braucht halt die recht für das eigene Verzeichnis und für das Verzeichnis wo er die ACME Challenge ablegt bei letzterem muss der Apache auch noch drauf können....
Na dann bin ich mal gespannt - vor einigen Monaten hat zumindest bei mir auch der Client der über Debian kam als erstes angefangen irgendwelche zusätzlichen Scripte runterzuladen und auszuführen. Das fand ich persönlich jedenfalls nicht so lustig.
Das kenneich nur vom GIT client. Der Debian installiert zwar auch nach aber über apt ...das hat man nur etwas sub optimal ohne nachfrage gemacht... aber wie gesagt die quelle ist sauber das Läuft mittlerweile auf zig hunderttausend seiten.... da hätte ich derzeit eher angst das jemand sich nen debian mirror unter den nagel reist und darüber sein Unwesen treibt...

Wenn du ganz paranoid bist kannst das sogar auf nem anderen Server laufen lassen der nur das macht... hab ich auch bei einigen Sachen im Einsatz...
Benutzeravatar
Boris Merath
*Lebende Forenlegende*
Beiträge: 16123
Registriert: 18 Nov 2002, 23:57
Wohnort: München

Beitrag von Boris Merath »

Rev @ 14 Mar 2017, 18:59 hat geschrieben: Der Debian installiert zwar auch nach aber über apt ...das hat man nur etwas sub optimal ohne nachfrage gemacht...
Gut, das kann natürlich sein dass ich das übersehen habe - allerdings frage ich mich wieso und wie ein Programm, das im Idealfall nicht als root läuft, etwas über apt nachinstalliert? Klar, damit kann man natürlich dafür sorgen, dass bei jedem Aufruf ein Update eingespielt wird, macht aber über diesen weiteren nicht regulären Updatemechanismus ein weiteres prinzipielles Einfallstor auf.

Ich hatte damals versucht zu verstehen was das Ding genau macht, die Details weiß ich jetzt nach einigen Monaten aber auch nicht mehr.
da hätte ich derzeit eher angst das jemand sich nen debian mirror unter den nagel reist und darüber sein Unwesen treibt...
Selbstverständlich ist das eine Gefahr, die habe ich aber so oder. Wenn jetzt aber einzelne Programme anfangen sich über irgendwelche abweichenden Wege selbst upzudaten, hat man pro Programm ein weiteres Einfallstor.
Bis zur vollzogenen Anbringung von ausreichenden Sandstreuapparaten an allen Maschinen haben die Bahnwärter bei aufwärtsgehenden Zügen auf stärkeren Steigungen die Schienen ausgiebig mit trockenem Sand zu bestreuen und für die Bereithaltung eines entsprechenden Vorrathes zu sorgen.

Fahrdienstvorschrift bayerische Staatsbahnen 1876
Rev
Lebende Forenlegende
Beiträge: 3323
Registriert: 28 Nov 2011, 20:15

Beitrag von Rev »

Na ja die Installation / first run an sich macht man schon über root das ist halt der Easy way das mann nicht selbst nachinstallieren muss...

Das upgrade kann man auch verbieten das gibt es mindest schon seit nem Jahr oder so... dann wird auch kein apt-get mehr ausgeführt... das ohne sudo etc natürlich sonst auf die fresse fliegt....
  --no-self-upgrade                         do not download updates
  --os-packages-only                        install OS dependencies and exit
Ich hatte damals versucht zu verstehen was das Ding genau macht, die Details weiß ich jetzt nach einigen Monaten aber auch nicht mehr.
Das ding ist eigentlich relativ simpel /certbot/certbot-auto certonly ist sogar nur ein bash script ... und der rest ist in Python geschrieben...

Vereinfacht gesagt legt das teil ne Datei in das web Verzeichnis damit wird geprüft ob dir die Datei gehört anschließend lässt der client das csr vom letsencrypt signieren und legt es auf dem eigenen Server ab...



Die Einfallstore würde ich nicht überbewerten. Mit veralteter Software hat man auch genug davon... so gesehen dürfte es im gesamten und über alle Server sichere sein wenn das Automatisch gemacht wird... und nicht einmalig bei der Installation und dann nie wieder auf tausenden von Servern...
Benutzeravatar
Lobedan
Kaiser
Beiträge: 1466
Registriert: 01 Jan 2016, 15:02

Beitrag von Lobedan »

218 466-1 @ 14 Mar 2017, 15:47 hat geschrieben: Nein. Das ist nur ein neues Feature, das bei allen Logins ohne https angezeigt wird.

Wer diese Warnung nicht will, gibt im URL Feld "about:config" ein, akzeptiert den Risiko-Hinweis, scrollt hinuter zu "security.insecure_field_warning.contextual.enabled" (einfacher das hier ohne "" kopieren und dort oben im Suchfeld einfügen) und stellt das per Doppelclick von "true" auf "false" um.
Ja genau, ignorieren von Sicherheitsproblemen war schon immer der Königsweg. :rolleyes:
Antworten