Announcement: there is an English version of this forum on 
Seit neuestem klinkt Firefox bei jeder GUI-Anmeldung, die nur über HTTP statt HTTPS läuft, diesen dämlichen Hinweis (s. Screenshot) unter das Eingabefeld fürs Passwort. Das nervt extrem, vor Allem als Admin bei diversen internen Geräten wie GUIs von Routern, NAS usw. Zumal der blöde "Lappen" oftmals das darunter befindliche Eingabefeld verdeckt und man immer erst auf den Hintergrund klicken mus, damit er verschwindet. Kann man das irgendwie abstellen? Wenn man im Web nach "Hinweis, HTTPS, Anmeldung" sucht, finde ICH immer nur Beiträge über Meldungen zu abgelaufenen oder ungültigen Zertifikaten, jedoch nichts zu dem beschrieben Fall. Vlt. verwende ich aber auch nur die falschen Suchbegriffe. Danke für Tips.
Angehängte Dateien:
-
firefox-nerv.jpg
39 KB
:
Bearbeitet durch User
Frank E. schrieb: > Das nervt extrem, vor Allem als Admin bei diversen internen Geräten wie > GUIs von Routern, NAS usw. Naja, gegenueber einem Popup, das mit einem Klick bestaetigt werden will, doch eher angenehm. Ich wuerde das einfach nur ignorieren. lkhxfgh
Here’s how to disable Firefox insecure password warnings:
1. Open a new tab, paste about:config into the address bar and hit
enter.
2. If you see the “This Might Void Your Warranty” page, click the
blue “I accept the risk!” button. Understand we are manually modifying
Firefox’s default settings.
3. In the Search box at the top, paste
insecure_field_warning.contextual.enabled
4. Double click the setting to change it to “false”, to disable
Firefox’s insecure password warning.
5. Done! Now when you visit pages with HTTP login forms, the warning
will no longer appear.
If you also want to restore autofill functionality, so that your saved
login/password automatically populates in an HTTP form, keep the
configuration page open and follow the next step.
Optional. In the Search Box on the about:config page, paste
signon.autofillForms.http
Double click the setting to change it to “true,” this will
enable autofill.
ff52 schrieb: > insecure_field_warning.contextual.enabled Danke! "insecure password warnings:" Das waren die richtigen Suchbegriffe ... !
:
Bearbeitet durch User
ff52 schrieb: > insecure_field_warning.contextual.enabled > > 4. Double click the setting to change it to “false” das schaltet die Funktion aber global ab, nicht nur für Server im LAN. Gibt es auch eine Möglichkeit das nur für eine bestimmte Liste an Servern/URLs abzuschalten, für den Rest aber an zu lassen?
Gerd E. schrieb: > ff52 schrieb: >> insecure_field_warning.contextual.enabled >> >> 4. Double click the setting to change it to “false” > > das schaltet die Funktion aber global ab, nicht nur für Server im LAN. > > Gibt es auch eine Möglichkeit das nur für eine bestimmte Liste an > Servern/URLs abzuschalten, für den Rest aber an zu lassen? Interessante Frage, eine Antwort darauf findet sich evtl. hier: How does Firefox determine if a password field is secure or not? https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/ verweist auf: https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy
Frank E. schrieb: > Vlt. verwende ich aber auch nur die falschen Suchbegriffe. Es ist in der Tat ziemlich schwierig, den Text der Warnmeldung bei Google einzutippen. Aber wenn man diese Hürde überwunden hat, bekommt man erstaunlicherweise sofort brauchbare Suchergebnisse. Wer hätte das gedacht...
Ich verstehe nicht, warum man das abschalten wollen könnte. Wozu sollte man einen Passwort-Schutz, aber kein HTTPS wollen? Gibt es überhaupt Geräte, die eine Passwort-Eingabe verlangen, aber kein HTTPS können?
Rolf M. schrieb: > Gibt es überhaupt > Geräte, die eine Passwort-Eingabe verlangen, aber kein HTTPS können? Aber klar doch. Die sind unter anderem die Grundlage für die ganzen BOT-Netze. Weiter Hilfen für BOT-Netze sind schwache oder standard Passwörter und das Abschalten der Warnmeldungen im Browser.
Rolf M. schrieb: > Ich verstehe nicht, warum man das abschalten wollen könnte. Wozu > sollte > man einen Passwort-Schutz, aber kein HTTPS wollen? Gibt es überhaupt > Geräte, die eine Passwort-Eingabe verlangen, aber kein HTTPS können? Ganz schön weltfremd. Ja, es gibt hunderte GUIs von Druckern, Routern, Switche, Webcams, div. Maschinen usw. in Büros und Firmen, die kein HTTPS können oder nicht so eingestellt sind. Und dann nervt es. Es steht doch garnich tin frage, dass die sicherer ist, aber es ist eben (noch) nicht verbreitet.
Rolf M. schrieb: > Ich verstehe nicht, warum man das abschalten wollen könnte. Wozu sollte > man einen Passwort-Schutz, aber kein HTTPS wollen? Gibt es überhaupt > Geräte, die eine Passwort-Eingabe verlangen, aber kein HTTPS können? Vermutlich ziemlich jedes private nicht-öffentliche Netz. Erstmal Kein Domain-Name, kein CA. Alternative 'Self Signed Certificate' dann hat man zwar https, was man intern evtl. garnicht braucht, aber der aufrufende Browser meckert trotzdem erstmal.
Rolf M. schrieb: > Ich verstehe nicht, warum man das abschalten wollen könnte. Wozu sollte > man einen Passwort-Schutz, aber kein HTTPS wollen? Es steht oft nicht in der Macht der Nutzer wie irgendwelche Webseitenbetreiber ihre Server oder ihre Appliances zu konfigurieren belieben. Daher ist es vollkommen daneben wenn die durchgeknallten fundamentalistischen Mozilla-Entwickler meinen ihren Frust darüber daß die Welt immer noch nicht bedingungslos nach ihrer Pfeife tanzt und ihren Dogmen huldigt ausgerechnet an den Anwendern auslassen mit nervigen kleinen Gängeleien überall, also ausgerechnet an denjenigen die überhaupt nichts dafür können. Der Schuss wird hoffentlich nach hinten losgehen, ich zum Beispiel bin schon dabei mir einen Chromium passend einzurichten für den baldigen endgültigen Umstieg, das Faß fängt schon an überzulaufen.
:
Bearbeitet durch User
so in der Art schrieb: > Alternative 'Self Signed Certificate' dann hat man zwar https, was man > intern evtl. garnicht braucht, aber der aufrufende Browser meckert > trotzdem erstmal. Wenn man HTTPS nicht braucht, braucht man aber auch kein Passwort. Bernd K. schrieb: > Rolf M. schrieb: >> Ich verstehe nicht, warum man das abschalten wollen könnte. Wozu sollte >> man einen Passwort-Schutz, aber kein HTTPS wollen? > > Es steht oft nicht in der Macht der Nutzer wie irgendwelche > Webseitenbetreiber ihre Server oder ihre Appliances zu konfigurieren > belieben. Den meisten Benutzern ist ohne so eine Warnung aber nicht mal bekannt, welcher Murks die Webseite ist. Die Warnung gibt ihnen die Möglichkeit, das zu erkennen und zu verstehen - und hoffentlich in Zukunft zu vermeiden. > Daher ist es vollkommen daneben wenn die durchgeknallten > fundamentalistischen Mozilla-Entwickler meinen ihren Frust darüber daß > die Welt immer noch nicht bedingungslos nach ihrer Pfeife tanzt und > ihren Dogmen huldigt ausgerechnet an den Anwendern auslassen mit > nervigen kleinen Gängeleien überall, also ausgerechnet an denjenigen die > überhaupt nichts dafür können. Was für eine absurde Schlussfolgerung. Das ist etwa so, als ob ich den Herstellern von Nagivationssysteme vorwerfe, dass sie doch tatsächlich die Unverfrorenheit besitzen, uns zu warnen, wenn wir die Geschwindigkeitsbegrenzung übertreten. Was fällt denen eigentlich ein, uns mit sowas zu gängeln und uns ihr Verständnis von "angepasster Geschwindigkeit" mit Gewalt aufzuzwingen?
Rolf M. schrieb: > Ich verstehe nicht, warum man das abschalten wollen könnte. Wozu sollte > man einen Passwort-Schutz, aber kein HTTPS wollen? Gibt es überhaupt > Geräte, die eine Passwort-Eingabe verlangen, aber kein HTTPS können? Leider ja. Ich habe hier zuhause einen Accesspoint von TP-Link (TL-WA701N), für den es keinen Support mehr gibt und der kein SSL/TLS für die Konfiguration unterstützt. Das gleiche gilt für den Telekom-Router Speedport W724V. Traurig, dass es heutzutage noch so etwas gibt ...
Rolf M. schrieb: > Herstellern von Nagivationssysteme vorwerfe, dass sie doch tatsächlich > die Unverfrorenheit besitzen, uns zu warnen, wenn wir die > Geschwindigkeitsbegrenzung übertreten. Äpfel <-> Birnen Wenn ich die Geschwindigkeit übertrete bin ich selber schuld und kann das selber korrigieren, das kann kein anderer für mich tun, allein ich bin dafür zuständig, also bin ich der richtige Ansprechpartner. Wenn irgendeine Webseite oder ein Gerät das angeblich "falsche" Protokoll verwendet dann kann ich nichts dafür und kann auch nichts daran ändern. Ich bin nicht der Ansprechpartner für dieses "Problem". Und ich will auch nicht die Schachfigur sein die durch Zufügen von Schmerzen dazu motiviert wird andern Leuten zu sagen was die Mozilla-Leute gerne von von ihnen wollen, es aber nicht auf die Reihe bringen ihnen selbst zu sagen. > Den meisten Benutzern ist ohne so eine Warnung aber nicht mal bekannt, > welcher Murks die Webseite ist. Oben ist ganz deutlich entweder ein Schloss in der Adressleiste oder nicht. Die Zusammenhänge kann man dem Benutzer einmal erklären und dann reicht das. Wenn ein Benutzer es dann trotzdem ignorieren will ist das ganz allein seine Angelegenheit.
:
Bearbeitet durch User
Bernd K. schrieb: > Wenn irgendeine Webseite oder ein Gerät das angeblich "falsche" > Protokoll verwendet dann kann ich nichts dafür und kann auch nichts > daran ändern. Ich bin nicht der Ansprechpartner für dieses "Problem". Doch der bist du. Es sind deine Daten, die ungeschützt übertragen werden. Das solltest du also wissen. Und daran ändern kannst du natürlich auch etwas indem du https verwendest, falls es angeboten wird, die Seite nicht mehr verwendest oder mit dem Seitenbetreiber in Kontakt trittst.
Bernd K. schrieb: > Daher ist es vollkommen daneben wenn die durchgeknallten > fundamentalistischen Mozilla-Entwickler meinen ihren Frust darüber daß > die Welt immer noch nicht bedingungslos nach ihrer Pfeife tanzt und > ihren Dogmen huldigt ausgerechnet an den Anwendern auslassen mit > nervigen kleinen Gängeleien überall, also ausgerechnet an denjenigen die > überhaupt nichts dafür können. Kannst Du denn nicht den Mozilla-Quellcode für Deine Zwecke umschreiben? Ich meine -Du bist doch sonst auch ein Fan von Hack und Crack, wie Du hier unter Beweis stellst: Beitrag "Re: Geheimes Protokoll - Alternativprodukt" MfG Paul
WaMin schrieb: >> daran ändern. Ich bin nicht der Ansprechpartner für dieses "Problem". > > Doch der bist du. Nein, der bin ich nicht. Derjenige der den Webserver konfiguriert hat ist der Ansprechpartner. Dem sollen sie meinetwegen bei jedem einzelnen Zugriff Elektroschocks verpassen. Aber nicht mir. Ich hab das nicht verbockt und auch nicht in Auftrag gegeben. > Es sind deine Daten, die ungeschützt übertragen > werden. Das solltest du also wissen. Ich weiß es. Ich habe es schon beim ersten Mal zur Kenntnis genommen und beschlossen daß es in diesem Falle irrelevant ist. Warum also muß er mir es dann dennoch jedesmal wieder und wieder mitteilen und mir wieder und wieder mit der selben dummen Meldung auf die Nerven gehen?
Bernd K. schrieb: > Warum also muß er mir es dann dennoch jedesmal wieder und wieder > mitteilen und mir wieder und wieder mit der selben dummen Meldung auf > die Nerven gehen? So sehe ich das auch! Interne Hardware, wir haben zb eun Switch der ein selbst erstelltes Zertifikat hat, was regelmäßig erneuert wird. Da macht eine Installation im Browser keinen Sinn, der mault nach nem Monat wieder. Also sollte die Meldung abgeschaltet werden. Oben steht ja glücklicherweise die Lösung. Wird morgen gleich eingepflegt. Danke an ff52
Ich finde, das passt hier gerade so schoen rein :D Unsicheres Log-in-Feld: Webseiten-Betreiber beschwert sich bei Firefox über Warnung https://www.heise.de/newsticker/meldung/Unsicheres-Log-in-Feld-Webseiten-Betreiber-beschwert-sich-bei-Firefox-ueber-Warnung-3660544.html
ff52 schrieb: > click the blue “I accept the risk!” button. Es gib so viele Meldungen, die der gewöhnliche User aus Unkenntnis einfach wegklickt, daß es eigentlich mal an der Zeit ist, dies Übel an der WURZEL abzustellen, statt die Augen zu verbinden! Wenn ein Zertifikat abgelaufen oder unsicher geworden ist, so ist es die Aufgabe des Betreibers der Seite für Ordnung zu sorgen oder sein Zertifikate für 30 Jahre auszustellen (in der Hoffnung daß es keiner knackt).
oszi40 schrieb: > ff52 schrieb: >> click the blue “I accept the risk!” button. > > Es gib so viele Meldungen, die der gewöhnliche User aus Unkenntnis > einfach wegklickt, daß es eigentlich mal an der Zeit ist, dies Übel an > der WURZEL abzustellen, statt die Augen zu verbinden! > Der “I accept the risk!” Button kommt bei der Spassmeldung das die Garantie verfallen wuerde wenn man im FF erstmals die aubout:config Seite aufruft. Ernstgemeinte Sicherheitswarnungen gestaltet man anders. > Wenn ein Zertifikat abgelaufen oder unsicher geworden ist, so ist es die > Aufgabe des Betreibers der Seite für Ordnung zu sorgen oder sein Wenn du keinen registrierten Domainnamen hast und deine private Webseite temporaer oder auch permanent via dyn. DNS und freier subdomain zugaenglich machst bekommt jeder Erstbesucher fuer den Fall man verwendet https mit selbsterstelltem Zertifikat vom FF gesagt diese Seite sei unsicher. Da fuehrt kein Weg dran vorbei das der Besucher das Zert. akzeptiert. Manche kapieren das aber erst garnicht.
Alex W. schrieb: > So sehe ich das auch! Interne Hardware, ok, interne Hardware. Interne Hardware ist ja per default sicher. Und es gibt ganz bestimmt keine 'internen' Geräte die jemals für ein Botnetz gekapert wurden...
ff52 schrieb: > temporaer oder auch permanent via dyn. DNS Wahrscheinlich wäre es heute günstiger, ein Zertifikat an einem statischen Punkt zu erzeugen und zu stationieren? Dann stimmt auch die Zuordnung. Früher haben die Schildbürger als sie die Glocke im See versenkten einen Ritz ans Boot gemacht um sie sicher wiederzufinden :-) https://de.wikipedia.org/wiki/Schildb%C3%BCrger
Da D. schrieb: > Interne Hardware ist ja per default sicher. Und es gibt ganz bestimmt > keine 'internen' Geräte die jemals für ein Botnetz gekapert wurden... Soll ich jetzt wegen dir meine Konfiguration überdenken, oder welche Message hast du für mich? Du weist schon, wie interne Netze konfiguriert werden? Und ja, man kann das selbsterstellte Zertifikat des switches herunterladen und installieren, macht aber kein Sinn wenn am nächsten Tag ein anderer zum Konfigurieren drann ist! Weil da wieder die Meldung kommt!
Alex W. schrieb: > Weil da wieder die Meldung kommt! Ja und? Dann ignoriere die Meldung halt, wenn du weißt, was du tust. Die Passwortwarnung ist nur dazu da dir klarzumachen, dass der Passworttransfer unsicher ist. Nicht mehr und nicht weniger. Das kannst du ohne weiteres und in dem Fall eines lokalen Geräts auch gefahrlos ignorieren. Wo ist das Problem?
ff52 schrieb: > Wenn du keinen registrierten Domainnamen hast und deine private Webseite > temporaer oder auch permanent via dyn. DNS und freier subdomain > zugaenglich machst bekommt jeder Erstbesucher fuer den Fall man > verwendet https mit selbsterstelltem Zertifikat vom FF gesagt diese > Seite sei unsicher. > Da fuehrt kein Weg dran vorbei das der Besucher das Zert. akzeptiert. > Manche kapieren das aber erst garnicht. Seit let's encrypt hat sich das ja glücklicherweise erledigt.
Rolf M. schrieb: > Ich verstehe nicht, warum man das abschalten wollen könnte. Wozu > sollte > man einen Passwort-Schutz, aber kein HTTPS wollen? Gibt es überhaupt > Geräte, die eine Passwort-Eingabe verlangen, aber kein HTTPS können? Naja, wenn das in einem LAN ist, dann verstehe ich schon, dass das unverschlüsselt ist. Da müsste sich die NSA schon ein Kabel zum Swich ziehen, um das abzufangen... Bei Logins bei Webseiten macht die Warnung aber schon Sinn. Beispiel: http://www.nexusmods.com/games/? Hat mich schon etwas geschreckt. Ich hab mich da zum Glück wie immer mit einem einzigartigen Passwort und einer meiner Wegwerfadressen angemeldet. Wer aber Passwörter und email-Adressen mehrfach verwendet, der hat hier ein echtes Sicherheitsproblem. Da das doch eine Seite mit eher einer größeren Community ist, ist das schon etwas erschreckend. Daher: Wertvoll, die Warnung.
Aha schrieb: > Naja, wenn das in einem LAN ist, dann verstehe ich schon, dass das > unverschlüsselt ist. Da müsste sich die NSA schon ein Kabel zum Swich > ziehen, um das abzufangen... Es ging mir nicht darum, ob unverschlüsselte Übertragung an sich sinnvoll ist, sondern ob sie in Kombination mit einer Passwortabfrage sinnvoll ist. Das bringt mir ja nur dann was, wenn ich in einem lokalen Netz bin, dort zwar andere aussperren möchte, aber sicher davon ausgehen kann, dass diese keine Tools wie Wireshark kennen und benutzen können. Ein Passwort, das im Klartext übertragen wird, ist für mich einfach etwas absurdes. So wie wenn ich im Haus ein Zimmer abschließe, aber den Schlüssel einfach offen und für jeden zugänglich rumliegen lasse.
Rolf M. schrieb: > Aha schrieb: >> Naja, wenn das in einem LAN ist, dann verstehe ich schon, dass das >> unverschlüsselt ist. Da müsste sich die NSA schon ein Kabel zum Swich >> ziehen, um das abzufangen... > > Es ging mir nicht darum, ob unverschlüsselte Übertragung an sich > sinnvoll ist, sondern ob sie in Kombination mit einer Passwortabfrage > sinnvoll ist. > Das bringt mir ja nur dann was, wenn ich in einem lokalen Netz bin, dort > zwar andere aussperren möchte, aber sicher davon ausgehen kann, dass > diese keine Tools wie Wireshark kennen und benutzen können. > Ein Passwort, das im Klartext übertragen wird, ist für mich einfach > etwas absurdes. So wie wenn ich im Haus ein Zimmer abschließe, aber den > Schlüssel einfach offen und für jeden zugänglich rumliegen lasse. Das ist alles richtig. Aber es ist halt so, dass der Aufwand für die Sicherheit angemessen sein muss. Nicht alles muss man perfekt absichern. Will man z.B. nur die Routereinstellungen vor seinen Kindern schützen, ist es kein Beinbruch, wenn die Übertragung zwischen PC und Router nicht geschützt ist. Ein anderes Beispiel wäre: Unser Gartentor hat auch nur eine Klinke und kein Schloss. Die Rehe und den Hund der Nachbarn hält es trotzdem erfolgreich draußen.
Rolf M. schrieb: > Seit let's encrypt hat sich das ja glücklicherweise erledigt. Dau weiß aber wo die Leute sitzen? .de wäre besser. 1 Letterman Drive, Suite D4700, San Francisco, CA 94129
Hurra schrieb: > Will man z.B. nur die Routereinstellungen vor seinen Kindern schützen, > ist es kein Beinbruch, wenn die Übertragung zwischen PC und Router nicht > geschützt ist. Mit der Einschaetzung gehe ich nicht mit. lkknsdgf
oszi40 schrieb: > Rolf M. schrieb: >> Seit let's encrypt hat sich das ja glücklicherweise erledigt. > > Dau weiß aber wo die Leute sitzen? .de wäre besser. > 1 Letterman Drive, Suite D4700, San Francisco, CA 94129 Was willst du uns damit sagen?
Hurra schrieb: > Aber es ist halt so, dass der Aufwand für die Sicherheit angemessen sein > muss. Nicht alles muss man perfekt absichern. > Will man z.B. nur die Routereinstellungen vor seinen Kindern schützen, > ist es kein Beinbruch, wenn die Übertragung zwischen PC und Router nicht > geschützt ist. Vollkommen richtig. Mich nervt die Meldung auch bei den Anwendungen im eigenen Netz. Bei externen Webseiten mag das hingegen sinnvoll sein. Die Entwickler hätten ja einfach eine Möglichkeit "Warnung auf dieser Seite nicht mehr anzeigen" vorsehen können (so wie das beim RDP Client immer schon gemacht wird oder by putty, wenn das Zertifikat nicht installiert ist). Oder einfach Netzbereiche von der Warnung ausschließen können.
oszi40 schrieb: > Rolf M. schrieb: >> Seit let's encrypt hat sich das ja glücklicherweise erledigt. > > Dau weiß aber wo die Leute sitzen? .de wäre besser. > 1 Letterman Drive, Suite D4700, San Francisco, CA 94129 Mmh, spielt keine Rolle da es nur mit eigener Domain funktioniert. letsencrypt funkt. aber nicht mit freien (idR. Sub-)Domain-Namen. Der Service selber ist im Gegensatz zu herk. CAs kostenlos. Wenn man -unabhängig von Dritten- einem Besucher seiner privaten auf dem eigenen Computer gehosteten Seite/Webanwendung SSL verschlüsselten Zugang via HTTP gewähren will muss ein Besucher gewillt sein ein selbsterstelltes Zertifikat zu akzeptieren bzw. lokal zu speichern. Das schreckt viele ab schon in der Art und Weise wie der ff das präsentiert. Das annehmen selbstertellter Zertifikate birgt nat. prinzipiell das Risiko das der Austeller erstmal nicht der ist für den man ihn hält ob das wirklich wichtig ist hängt aber auch von der Art der angedachten Kommunikation und den Inhalten ab.
"Mich nervt die Meldung auch bei den Anwendungen im eigenen Netz." ca. 80% aller Angriffe kommen aus dem eigenen Netz ...
Klaus P. schrieb: > Die Entwickler hätten ja einfach eine Möglichkeit "Warnung auf dieser > Seite nicht mehr anzeigen" vorsehen können (so wie das beim RDP Client > immer schon gemacht wird oder by putty, wenn das Zertifikat nicht > installiert ist). Oder einfach Netzbereiche von der Warnung ausschließen > können. Dann mach doch einen Bug auf. Wenn du dich hier beschwerst, liest das sicher keiner der Entwickler...
ff52 schrieb: > letsencrypt funkt. aber nicht mit freien (idR. Sub-)Domain-Namen. Was tut denn bei dir nicht? Bei mir geht's jedenfalls ohne Probleme.
Rolf M. schrieb: > ff52 schrieb: >> letsencrypt funkt. aber nicht mit freien (idR. Sub-)Domain-Namen. > > Was tut denn bei dir nicht? Bei mir geht's jedenfalls ohne Probleme. 'rate-limits' (zu wenige Zertif.) Bei allen moeglichen third-level-domains. Wenn sie es jetzt hingekriegt haben, gut! Mal bei gelegenheit wieder probieren. ---
ff52 schrieb: > 'rate-limits' (zu wenige Zertif.) > Bei allen moeglichen third-level-domains. Ja, das kann wohl passieren. Bei mir ging's aber auf Anhieb mit ddns.net.
Ich möchte mich bei dir herzlich bedanken FF52 für deine Unterstützung mit: insecure_field_warning.contextual.enabled change it to “false”, to disable und signon.autofillForms.http change it to “true”, to disable Ich lasse mich nur ungern von Mozilla drangsalieren. Leider befürchte ich, das about:config auch bald gesperrt wird. Somit ist es wohl über kurz oder lang notwendig, nach einem anderen Browser ausschau zu halten, bei dem man in Zukunft nicht auf die Willkür von Mozilla angewiesen ist. Wer weiß, vielleicht wird dieser ja auch bald kostenpflichtig wie FreeTV.
> Ich lasse mich nur ungern von Mozilla drangsalieren. Leider befürchte > ich, das about:config auch bald gesperrt wird. Somit ist es wohl über > kurz oder lang notwendig, nach einem anderen Browser ausschau zu halten, > bei dem man in Zukunft nicht auf die Willkür von Mozilla angewiesen ist. > Wer weiß, vielleicht wird dieser ja auch bald kostenpflichtig wie > FreeTV. Ehrlich gesagt kann ich da vielen Ausführungen auch deiner nicht folgen. Wenns stört machs weg (hab ich auch gemacht), die Mglkt. gibt es doch. Ja das ist nirgends in einer Hilfsdatei beschrieben oder in der Oberfläche als zu oder abschaltbare Eigenschaft verankert aber wie sollte das auch gehen bei etlichen hundert nötigen Knöpfen um solche Sache einstellbar zu gestalten. Das könnte man auch finden wenn man in der config mit den Stichworten sucht, vorausgesetzt man verwendet eine englischsprachige Version. Und ja es nervt schon das man erst mal eine weile schrauben muss bis alles wieder passt aber das hat man doch überall. --- Es gäbe auch andere Mgklt. das selektiv wegzubekommen schliesslich ist das dann auch blos HTML welches man parsen kann. Mittels addon wie z.B. Custumizeyourweb (mouseless.de) oder eines Greasemonkeyscripts welches die Meldung rausnimmt wenn man auf bestimmten Seiten ist wäre nicht schwer. guck mal ob es "Custumizeyourweb" noch gibt für den aktuellen ff damit kannst du dir deine öfters besuchten Seiten recht leicht so zurechtstutzen wie es dir passt.
ff52 schrieb: Möööp, error. > guck mal ob es "Custumizeyourweb" noch gibt für den aktuellen ff damit > kannst du dir deine öfters besuchten Seiten recht leicht so > zurechtstutzen wie es dir passt. "Customize Your Web (CYW)" Aber ob es mit dem aktuellen ff noch geht kann ich grad nicht sagen.
Beitrag #4950775 wurde von einem Moderator gelöscht.
WaMin schrieb im Beitrag #4950775: > Findest du nicht, dass du etwas überreagierst? > Es ist eine Meldung, die dich in keiner Weise in deiner bisherigen > Arbeitsweise behindert. Es ist nur eine Information. Das hört man hier doch in letzter Zeit öfter. Da wird irgendeine Warnung in Firefox eingebaut, und gleich kommt einer und beschwert sich über die tyrannischen Firefox-Entwickler, die ihre Macht ausnutzen, ihrer Willkür freien Lauf lassen und die Benutzer traktieren und niederzwingen, aus Frust über ihre Unzufriedenheit mit der Welt. Wie absurd das klingt, merkt er wahrscheinlich gar nicht.
Rolf M. schrieb: > tyrannischen Firefox-Entwickler, die ihre Macht ausnutzen, ihrer Willkür :) Leider wird es aber im laufe des Jahres zu echten Verlusten kommen. Das alte plugin u. extensions System hat wohl ausgedient. So viele Erweiterungen und Möglichkeiten als normaler Benutzer "seinen Browser" so zu verändern wie es noch bis vor der zertifizierung ein paar Versionen zurück gab, da sind auch schon etliche weggefallen, wird es auf absehbare wohl Zeit nicht mehr geben. So manches plugin wird einfach wegfallen wenn der Autor das nicht in geeigeneter Weise portiert. https://tech.slashdot.org/story/17/02/17/1635216/mozilla-will-deprecate-xul-add-ons-before-the-end-of-2017 exff52
Einführung -signierter- addons war gemeint (nicht zertifizierter) --- hier gehts zum aktuellen linux 'pale moon' 27.2.1 sse build falls das jemanden auf alter Büchse ohne sse2 interessieren sollte. https://forum.palemoon.org/viewtopic.php?f=40&t=13530&sid=e08781abed59e72a8437a98e2bf0dd85&start=20
Beitrag #4951670 wurde von einem Moderator gelöscht.
Beitrag #4951673 wurde von einem Moderator gelöscht.
MaWin schrieb im Beitrag #4951673: > MaWin schrieb im Beitrag #4951670: >> Aber solch eine nützliche und wichtige Fehlermeldung schlecht zu finden, >> ..., ist doch eine gute Sache. > > ich sollte weniger Bier trinken. Nicht nötig, solange man "don't drink and post" befolgt. ;-) In der Sache selbst: Yep, jeder will mehr Performance ("Warum nutzt der Brwoser nicht alle Kerne ???") und Stabilität (Extension stürzt ab - egal der Browser läuft weiter), aber wenn dafür notwendige Änderungen schrittweise umgestezt werden (die Plugin-Entwickler haben dafür ja noch ein dreiviertel Jahr Zeit), dann wird auch rumgeheult. :-( Ichrgendwie werde ich das Gefühl nicht los, daß keiner der Meckernden mal ein etwas größeres Software-Projekt über ein Jahrzehnt oder länger betreuen "durfte".
Auch von mir vielen Dank FF52. Dieses lästige Problem nervt(e) mich ebenfalls hunderte Male täglich. Du hast mein Leben und meinen Arbeitsalltag gerade erheblich verbessert. @WaMin und Rolf Magnus Es ist gut, dass ihr kein Problem damit habt und es euch recht ist diese Meldung regelmäßig wegzuklicken oder den entsprechenden Dienst nicht zu nutzen. Aber stellt euch mal vor ihr habt z.B. diese Freiheit der Wahl nicht oder es ist euch egal wie sicher Daten übertragen werden ... warum solltet ihr dann "jedes Mal" Zeit verschwenden diese Meldung zu bestätigen/wegzuklicken. Das ist purer Wahnsinn.
Ein Problem, das ich bei dieser Meldung auch sehe, ist, daß es anscheinend vom Protokoll, das zum Laden des Login-Forms abhängt, ob die Meldung gezeigt wird, oder nicht. Ich kenne Seiten, bei denen wird das Formular ber HTTP geladen (wozu verschlüsseln, wenn's eh für jeden gleich aussieht beim Seitenaufruf), beim Absenden des Formulars geht der Request aber über HTTPS raus, das Paßwort wird also nicht im Klartext übertragen. Trotzdem kommt die Meldung. Wie es beim umgekehrten Szenrio aussieht(Laden per HTTPS, Request per HTTP) müßte ich mal ausprobieren...
geste schrieb: > hunderte Male täglich Okay... Ein Tag hat 1440 Minuten. Zieht man 9 Stunden fuer Schlafen, Klo, etc. ab, bleiben noch 900 Minuten. Wenn ich diese "hunderte Male" einfach mal auf 100 setze, dann hast du ca. alle 9 Minuten so eine Meldung... Bei einem 8 Stunden (480 Minuten) Arbeitstag also alle 4,8 Minuten. Wenn so dein Arbeitstag aussieht wuerde ich mir mal Gedanken machen... Sorry, aber du erzaehlst Bullshit, und davon ziemlich viel! geste schrieb: > Das ist purer Wahnsinn. Der pure Wahnsinn ist es, wenn > euch egal ist wie sicher Daten übertragen werden DAS ist purer Wahnsinn.
geste schrieb: > @WaMin und Rolf Magnus > > Es ist gut, dass ihr kein Problem damit habt und es euch recht ist diese > Meldung regelmäßig wegzuklicken oder den entsprechenden Dienst nicht zu > nutzen. Aber stellt euch mal vor ihr habt z.B. diese Freiheit der Wahl > nicht oder es ist euch egal wie sicher Daten übertragen werden ... warum > solltet ihr dann "jedes Mal" Zeit verschwenden diese Meldung zu > bestätigen/wegzuklicken. Das ist purer Wahnsinn. Hör auf hier rum zu nevern. Geh dem Betreiber wer Webseite(n) auf die nerven.
geste schrieb: > Aber stellt euch mal vor ihr habt z.B. diese Freiheit der Wahl > nicht oder es ist euch egal wie sicher Daten übertragen werden ... warum > solltet ihr dann "jedes Mal" Zeit verschwenden diese Meldung zu > bestätigen/wegzuklicken. Das ist purer Wahnsinn. Dann stellt man die Meldung einfach ab. So einfach ist das.
Nachdenklicher schrieb: > Ich kenne Seiten, bei denen wird das Formular ber HTTP geladen (wozu > verschlüsseln, wenn's eh für jeden gleich aussieht beim Seitenaufruf), Natürlich muss die Meldung dann kommen, weil das Formular evtl. unterwegs verändert wurde und somit das eingegebene Passwort abgefangen werden kann.
ff52 schrieb: > Here’s how to disable Firefox insecure password warnings: > > 1. Open a new tab, paste about:config into the address bar and hit > ent................ vielen dank. hat mir auch sehr geholfen. wusste nicht mehr wie das aufzurufen ist. danke
Here’s how to disable Firefox insecure password warnings:
1. Open a new tab, paste about:config into the address bar and hit
enter.
2. If you see the “This Might Void Your Warranty” page, click the
blue “I accept the risk!” button. Understand we are manually modifying
Firefox’s default settings.
3. In the Search box at the top, paste
insecure_field_warning.contextual.enabled
4. Double click the setting to change it to “false”, to disable
Firefox’s insecure password warning.
5. Done! Now when you visit pages with HTTP login forms, the warning
will no longer appear.
If you also want to restore autofill functionality, so that your saved
login/password automatically populates in an HTTP form, keep the
configuration page open and follow the next step.
Optional. In the Search Box on the about:config page, paste
signon.autofillForms.http
Double click the setting to change it to “true,” this will
enable autofill.
lkhxfgh schrieb: > Frank E. schrieb: >> Das nervt extrem, vor Allem als Admin bei diversen internen Geräten wie >> GUIs von Routern, NAS usw. > > Naja, gegenueber einem Popup, das mit einem Klick bestaetigt werden > will, doch eher angenehm. > Ich wuerde das einfach nur ignorieren. > > lkhxfgh Genau die Art Hilfe die man sich wünscht.
Mir ist dieser Thread ehrlich gesagt ein Rätsel. Wen die Meldung stört, kann sie abschalten, warum also Gemeckere? Wer die Meldung braucht, lasse sie bitte aktiv, höre aber auf, die eigene Meinung anderen aufzuzwingen. Wir entwickeln z.B. Intranet-Umgebungen auch ohne SSL für lokale Netze Die Sicherheit wird neben Passwort auch auf andere Weise gewährt. Wer nun behauptet, ein Passwort hätte ohne Verschlüsselung keinen Sinn, kann über seinen Tellerrand einfach nicht hinausblicken. Browser werden eben nicht nur genutzt um Facebook & Co. zu besuchen. Ihre Einsatzmöglichkeiten sind ebenso vielfältig wie die damit verbundenen Konfigurationen.
Manni schrieb: > Wir entwickeln z.B. Intranet-Umgebungen auch ohne SSL für lokale Netze > Die Sicherheit wird neben Passwort auch auf andere Weise gewährt. Wer > nun behauptet, ein Passwort hätte ohne Verschlüsselung keinen Sinn, kann > über seinen Tellerrand einfach nicht hinausblicken. Wer behauptet, im lokalen Netzwerk wär eh alles immer sicher und flauschig, auch nicht. Wer dann auch noch Software in diesem Bereich entwickelt, handelt fahrlässig.
Ja, genau das habe ich gemeint mit dem Tellerrand. Andere Meinungen werden ohne Hinterfragen abgeschmettert. Wir reden hier von einer Meldung die stört und für Anwender sogar problematisch sein kann. Der Grund: Der Inhalt wird möglicherweise als Fehler interpretiert und das Anklicken hat gar den ungewollten Aufruf einer Webseite (Mozilla) zur Folge. Also: Weg damit! Und die Behauptung, lokale Netze seien per Se sicher, habe ich weder angedeutet noch ausgesprochen. Stattdessen habe ich andere Sicherheitsvorkehrungen zumindest angedeutet.
Welche anderen Sicherheitsvorkehrungen, außer Verschlüsselung, verhindern mitlesen wirksam?
vn n. schrieb: > Manni schrieb: >> Wir entwickeln z.B. Intranet-Umgebungen auch ohne SSL für lokale Netze >> Die Sicherheit wird neben Passwort auch auf andere Weise gewährt. Aha. Und wie? Indem nur Leute an das Netz kommen, die das Passwort sowieso kennen? >> Wer nun behauptet, ein Passwort hätte ohne Verschlüsselung keinen Sinn, >> kann über seinen Tellerrand einfach nicht hinausblicken. > > Wer behauptet, im lokalen Netzwerk wär eh alles immer sicher und > flauschig, auch nicht. Vor allem ist es immer noch totaler Blödsinn, ein Passwort zu verlangen und das dann so durch's Netz zu schicken, dass es jeder lesen kann. Entweder braucht man ein Passwort, dann muss es aber auch sicher übertragen werden, oder man kann sich das gleich ganz schenken. Ist, als ob ich den Haustürschlüssel auf (nicht unter) die Fußmatte lege. Da kann ich die Tür auch gleich offen lassen. Deshalb nutzt man heute auch kein Telnet mehr. Bei dem meldet man sich auch meist mit Passwort an, aber ohne Verschlüsselung. In den 60ern des letzten Jahrhunderts war das auch noch ok, aber heute nicht mehr.
Die Ignoranz mancher Thread-Teilnehmer ist wirklich herzallerliebst. 1. Der Hinweis ist eben nicht "einfach" abzuschalten, weil man dazu das passende Kommando bzw. den Eintrag in about:config erst mühselig irgendwo suchen muss (oder aus dem Forum erfährt :-) ) 2. Der Hinweis ist aufdringlich und lästig, wenn man sein täglich Brot mit dem Browser verdienen muss. Wie bereits weiter oben erwähnt, gibts z.B. endlos Netzwerk-Infrastruktur mit WebGUI, z.B. Switche, TK-Anlagen oder Drucker, die eben kein SSL können und deshalb aber nicht weggeschmissen werden. 3. Offenbar hat niemand der anderen Threadschreiber Kundenkontakt oder Service-Erfahrung. Die Zahl der Anrufe, dass da jetzt plötzlich " ... so eine komische Fehlermeldung ..." stehe, und " ... ob da jetzt was kaputt ist? ..." geht in die Hunderte! Es ist, wie oft bei selbstverliebten Programmierern, man hat den Eindruck, die haben nie mit ihren eigenen Produkten wirklich gearbeitet (und nicht nur getestet). Ich will ja den Sinn des Hinweises garnicht völlig negieren, aber es wäre sicher auch etwas weniger nervig und trotzdem Aufmerksamkeit erregend gegangen. Das blöde Pulldown verdeckt zudem meist die Passworteingabe.
Danke. Die Änderung in about:config war die Lösung des Problems. An einem Arbeitsplatz mit lokalem Netz, der nur von mir genutzt wird, brauche ich den Hinweis nicht jedesmal, das nervt gewaltig. Gegen Überwachung, das Schüren von Terrorhysterie machts legal, hilft das https im übrigen auch nicht. Da spare ich mir den Aufwand, Jetzt-Und-Sofort auf https prinzipiell zu beharren, gleich. Es wird nach und nach kommen, was auch gut so ist.
Genau DAS, was Frank sagt! Euch anderen sei mal gegöhnt, dass 3x am Tag jemand anruft und sagt, dass das Feld zur Passworteingabe verschwunden ist! =)
Manni schrieb: > Wir entwickeln z.B. Intranet-Umgebungen auch ohne SSL für lokale Netze > Die Sicherheit wird neben Passwort auch auf andere Weise gewährt. Genau. Der Punkt ist nämlich, dass es im LAN keinen MITM-Angriff geben kann. Dafür sorgt schon allein das Verhalten der Switches. Von dem dem Login-Prozess kriegen nur die zwei Peers etwas mit, die daran beteiligt sind. Schließlich sind das alles Unicast-Pakete, die erreichen genau nur den Port des Switches, an dem der Peer hängt, an den sie gerichtet sind. Klar: wenn man administrativen Zugang zu den Switches hat, könnte man den Login mithören, z.B. indem man sich einen Monitor-Port einrichtet. Wenn ein Angreifer allerdings diese Möglichkeit bereits hat, ist eh' schon alles viel zu spät, dann spielt das Mithören dieses Logins kaum noch eine Rolle, denn dann gibt es für den Angreifer ganz sicher auch noch viele andere Möglichkeiten, um an diese Informationen zu kommen... Kurzfassung: 1) diese Warnung ist in einem (korrekt aufgebauten) LAN ziemlicher Schwachsinn. 2) Firefox könnte ziemlich problemlos ermitteln, ob der Peer im "LAN" ist und für diesen Fall die Warnung automatisch unterdrücken. 3) Das wäre überaus sinnvoll, denn dann würde die Warnung in den wirklich gefährlichen Fällen wenigstens vielleicht die gewünschte Wirkung haben...
c-hater schrieb: > Manni schrieb: >> Wir entwickeln z.B. Intranet-Umgebungen auch ohne SSL für lokale Netze >> Die Sicherheit wird neben Passwort auch auf andere Weise gewährt. Ohne Encryption? LOL. > Genau. Der Punkt ist nämlich, dass es im LAN keinen MITM-Angriff geben > kann. Dafür sorgt schon allein das Verhalten der Switches. Ja, das denken viele, die noch nie etwas von den schönen Möglichkeiten des ARP-Protokolls gehört haben. Wie viele Einträge kann die ARP-Tabelle Deines Switches denn fassen? Ist das denn ein professioneller Managed Switch oder schaltet er -- wie so viele billige Consumergeräte -- einfach in einen Hub-Modus, wenn die ARP-Tabelle voll ist? Und wie genau widersteht Dein Switch einem Angriff mit ARP-Spoofing?
So, also mal angenommen ich würde mich der Nötigung beugen und aus diesem Grund meinem Intranet-Thing SSL spendieren wollen: Wer stellt mir ein offizielles Zertifikat für https://* aus?
Bernd K. schrieb: > So, also mal angenommen ich würde mich der Nötigung beugen und aus > diesem Grund meinem Intranet-Thing SSL spendieren wollen: > > Wer stellt mir ein offizielles Zertifikat für https://* aus? Brauchst du denn ein "offizielles" Zertifikat? Reicht dir ein selbst signiertes, das du dem Browser als vertrauenswürdig angibst, nicht?
Rolf M. schrieb: > Brauchst du denn ein "offizielles" Zertifikat? Reicht dir ein selbst > signiertes, das du dem Browser als vertrauenswürdig angibst, nicht? Was ist wenn ich das Produkt verkaufen will, kein Nutzer quält sich durch das halbe dutzend verworrene Dialoge um das Zertifikat zu installieren und die Fehlermeldungen sind noch weitaus abschreckender (und inhaltlich falscher) als bei einem einfachen input type="password". Ich denke der vernünftigste Weg ist es einfach einem normalen input einen passwort-font zu verpassen der nur aus Punkten besteht und weiterhin bei http zu bleiben.
Letsencrypt mit certbot (oder direkt das ACME Protokoll wenns embeddet is). Wer das nicht bedienen kann, der sollte auch nix mit Netzwerkanschluss programmieren.
:
Bearbeitet durch User
Mw E. schrieb: > Letsencrypt mit certbot das Netzwerk wo das "thing" installiert ist hat keine route ins Internet. Ich brauche also eine offline-Lösung die einfach nur funktioniert, nicht so einen Krampf wie diesen certbot. Außerdem geben die eh keine Zertifikate für beliebige private Adressen raus. Es muss mit allen privaten IP-Adressen funktionieren und auch mit beliebigen DNS-Namen die ein interner DNS-Server dem Ding evtl vergeben könnte.
:
Bearbeitet durch User
Bernd K. schrieb: > das Netzwerk wo das "thing" installiert ist hat keine route ins > Internet. Hi, wozu braucht man dann einen Browser ala ff52+ ? Also solche auf dem neuesten Stand, die alles koennen sollen das man u.U. garnicht braucht. Gibt ja auch ältere oder abgespeckte die sich bestens als Dokumenten/Handbuch-viewer oder sonstiges intern gebrauchen lassen.
c-hater schrieb: > Genau. Der Punkt ist nämlich, dass es im LAN keinen MITM-Angriff geben > kann. Das ist ein ziemlich weit verbreiteter Irrtum, das geswitchtes Netzwerke per se sicher sind.
FFx schrieb: > Bernd K. schrieb: > >> das Netzwerk wo das "thing" installiert ist hat keine route ins >> Internet. > > Hi, wozu braucht man dann einen Browser ala ff52+ ? Weil das Voraussetzen eines veralteten Browsers mit der Begründung die "Sicherheits"-Warnungen zu vermeiden noch mal zwei Größenordnungen lächerlicher wäre als jedwede andere Verrenkung die einem jemals noch einfallen könnte um das Problem auf andere Weise zu vermeiden vielleicht?
Bernd K. schrieb: > FFx schrieb: >> Bernd K. schrieb: >> >>> das Netzwerk wo das "thing" installiert ist hat keine route ins >>> Internet. >> >> Hi, wozu braucht man dann einen Browser ala ff52+ ? > > Weil das Voraussetzen eines veralteten Browsers mit der Begründung die > "Sicherheits"-Warnungen zu vermeiden noch mal zwei Größenordnungen > lächerlicher wäre als jedwede andere Verrenkung die einem jemals noch > einfallen könnte um das Problem auf andere Weise zu vermeiden > vielleicht? Vorraussetzen? Nö. Wenn jmd. dein vorhandenes Ding das eben anscheinend keinen ssl-server eingebaut hat eben weiterbetreiben soll musst du eben klassisch eine geeigte Steuersoftware bspw. in Form eines modifierten Browsers oder was selbtgeschriebenes nachliefern. Oder stampfe das Teil ein.
Bernd K. schrieb: > das halbe dutzend verworrene Dialoge Es ist ein einziger Dialog, bei dem man auf OK klicken muss. Das "permanently store" checkbox ist bereits angewählt.
Ma W. schrieb: > Es ist ein einziger Dialog, bei dem man auf OK klicken muss. > Das "permanently store" checkbox ist bereits angewählt. Nein, das ist nicht der Dialog zum Installieren des Zertifikats. Das konfiguriert lediglich eine Ausnahmeregelung für diese Webseite, der Browser betrachtet die Seite weiterhin als "Unsicher" (erkennbar an dem Warndreieck am Vorhängeschloss) und außerdem ist der Dialog von dem Du sprichst erst noch hinter mindestens zwei modalen und leider noch dazu inhaltlich falschen Warnmeldungen versteckt durch die man sich durchklicken mus. Chrome erfordert ebenfalls 2 Klicks durch modale und inhaltlich falsche Meldungen und erlaubt dabei ebenfalls nicht die Installation des Zertifikats,
Angehängte Dateien:
-
Auswahl_151.png
4,9 KB -
Auswahl_152.png
3,2 KB
FFx schrieb: > Nö. Wenn jmd. dein vorhandenes Ding das eben anscheinend > keinen ssl-server eingebaut Es geht nicht darum einen SSL-Server einzubauen. Das ist ein Kinderspiel. Es geht darum daß man keine Zertifikate bekommt die einen Betrieb im privaten Netz ermöglichen ohne jeden Nutzer mit abschreckenden Warnmeldungen zu bombardieren oder Installationsorgien vollführen zu lassen.
Bernd K. schrieb: > Nein, das ist nicht der Dialog zum Installieren des Zertifikats. Das weiß ich. > Das > konfiguriert lediglich eine Ausnahmeregelung für diese Webseite, Richtig. Das ist auch ausreichend. > der > Browser betrachtet die Seite weiterhin als "Unsicher" (erkennbar an dem > Warndreieck am Vorhängeschloss) Und wo ist jetzt das Problem?
Bernd K. schrieb: > Betrieb im privaten Netz ermöglichen ohne jeden Nutzer mit > abschreckenden Warnmeldungen zu bombardieren oder Installationsorgien > vollführen zu lassen. Schau halt ob man mit den "certutils" einen Zertifikatsinstaller bauen oder skripten kann. Ob das dann mit FF57 ff. auch noch funktioniert? https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Tools/certutil
Ma W. schrieb: >> der >> Browser betrachtet die Seite weiterhin als "Unsicher" (erkennbar an dem >> Warndreieck am Vorhängeschloss) > > Und wo ist jetzt das Problem? Das Problem ist daß man sowas keinem verkaufen kann. Auch wenns perfekt sicher ist, auch wenn das Zertifikat dann im Browser an diese IP gepinnt und somit sogar unter dem Strich noch weitaus sicherer wäre als ein automatisch "vertrautes" cert von irgendeiner externen CA. Solange der handelsüblche Browser bei einem explizit persönlich vertrauten und manuell gepinnten Zertifikat so dämliche grundlose Warnungen und Falschbehauptungen anzeigt kann man das nicht ernsthaft verkaufen. Auch wenns noch so sicher ist. Oder stellst Du Dich dann hin und erklärst den Kunden immer und immer wieder warum diese jedes Jahr immer bedrohlicher wirkende Warnmeldung nur fälschlicherweise erfolgt aber leider dennoch nicht abzustellen ist? Ich hätte darauf sicherlich keinen Bock. Aber irgendwelche Gadgets die einfach von sich aus ins Internet gehen und die man dann nur indirekt über die Hersteller-Webseite konfiguriert, die verkaufen sich prächtig. Die sind dann "sicher". Denn eine direkte Kommunikation mit dem Ding im lokalen Netz ginge ja nicht, die wäre ja "unsicher" sagt der Browser.
FFx schrieb: > Schau halt ob man mit den "certutils" einen Zertifikatsinstaller bauen > oder skripten kann Sag mir erst mal wie ich überhaupt ein Cert generiere das für alle 10/8 und 172.16/12 und 192.168/16 und DNS:* gültig wäre.
Dann ist das Problem aber nicht die Sicherheitswarnung, sondern das Konzept, das keine einfache Nutzung lokaler SSL-Server ermöglicht.
Bernd K. schrieb: > Sag mir erst mal wie ich überhaupt ein Cert generiere das für *alle* > 10/8 und 172.16/12 und 192.168/16 und DNS:* gültig wäre. Das Zertifikat interessiert es nicht auf welche Adresse der Hostname auflöst.
Bernd K. schrieb: > Solange der handelsüblche Browser bei einem explizit > persönlich vertrauten und manuell gepinnten Zertifikat so dämliche > grundlose Warnungen und Falschbehauptungen anzeigt kann man das nicht > ernsthaft verkaufen. Kann es sein, dass du "etwas" überreagierst? Der Browser zeigt nur ein winziges Ausrufezeichen in der Adresszeile an. Und wenn man mit der Maus drauffährt, bekommt man direkt erklärt, was Sache ist. Schreibe in deine Doku rein, dass das so OK ist, und gut.
Bernd K. schrieb: > Sag mir erst mal wie ich überhaupt ein Cert generiere das für alle > 10/8 und 172.16/12 und 192.168/16 und DNS:* gültig wäre. Gar nicht. Du hast TLS nicht verstanden.
Hi, gibt afaik in FF über about config einen unbestätigten workaround: security.insecure_field_warning.contextual.enabled oder eben disabled. ciao gustav
Rolf M. schrieb: > Dann ist das Problem aber nicht die Sicherheitswarnung, sondern das > Konzept, das keine einfache Nutzung lokaler SSL-Server ermöglicht. Genau. Leider haben die Browserhersteller diesen Use-case komplett unter den Tisch fallen lassen als sie auf den unseligen Trichter mit dem SLL-Zwang gekommen sind. Es bräuchte wenigestens ein UI mit dem man einem bislang unvertrauten Zertifikat explizit das Vertrauen aussprechen kann (nicht Sicherheits-"Ausnahme" mit Warndreieck sondern explizit vertraut(!) und daher als 100% sicher einstuft) und ein UI welches beim Durchklicken nicht suggeriert man würde gerade von einer wilden Horde von "Hackern" angegriffen, der Serverbetreiber wäre unfähig und der nächste Klick würde alle Einfallstore öffnen sondern eines das in nüchterner(!) Sprache den Sachverhalt wahrheitsgetreu(!) erläutert und dem User erlaubt explizit sein Vertrauen auszusprechen und dieses dann auch respektiert.
:
Bearbeitet durch User
FFx schrieb: > Schau halt ob man mit den "certutils" einen Zertifikatsinstaller bauen > oder skripten kann. Ob das dann mit FF57 ff. auch noch funktioniert? Man kann ein Zertifikat gescriptet in ein aktuelles Firefox importieren, auch ein CA-Zertifikat. Ist auch logisch, denn das wird in vollautomatischen PC-Installationen oft benötigt. Gegen das Gemoser bei unverschlüsselten Konfigurations-Webseiten von Devices aller Couleur hilft das aber natürlich nichts.
:
Bearbeitet durch User
Bernd K. schrieb: > Sag mir erst mal wie ich überhaupt ein Cert generiere das für *alle* > 10/8 und 172.16/12 und 192.168/16 und DNS:* gültig wäre. Normalerweise zertifiziert man Namen, nicht IP-Adressen. Wenn der FF das passende CA-Zertifikat an Bord hat, dann wird er damit signierte Site-Zertifikate anstandlos akzeptieren. Dazu reicht es, sich ein hauseigenes CA-Zertifikat zu bauen und in den FF zu importieren. Die Sites bekommen dann beliebig benannte Zertifikate, die von dieser CA signiert werden. Es gibt überdies auch Wildcard-Zertifikate, die beispielsweise auf alle Sites *.trottel.local anwendbar sind. Nur muss man dann auch den vollständigen Namen verwenden, d.h. https://ich.trottel.local wird funktionieren, https://ich oder https://192.168.178.99 hingegen nicht.
:
Bearbeitet durch User
A. K. schrieb: > Die > Sites bekommen dann beliebig benannte Zertifikate, die von dieser CA > signiert werden. Die einzige halbwegs praktikable Möglichkeit für ein Standalone(!)-Gerät die ich momentan sehe ist wenn jedes Device quasi seine eigene CA eingebaut hat und sich je nach IP-Adresse (und evtl. Name) die es dort wo es sich gerade zu befinden beliebt gerade zugewiesen bekommen hat sich jedesmal on the fly selbst sein eigenes zur Umgebung passendes Zertifikat ausstellt. Der Nutzer müsste dann nur noch ein passendes Root-Zertifikat installieren. Das wäre zwar ein hanebüchener Hack und auch bestimmt nicht im Sinne des Erfnders wenn jedes Gerät selbst den Schlüssel für das Root-Zertifikat mit sich herumschleppen muss aber die Browserhersteller zwingen einen ja geradezu zu solchen Würgarounds mangels Alternative.
Bernd K. schrieb: > Es bräuchte wenigestens ein UI mit dem man einem bislang unvertrauten > Zertifikat explizit das Vertrauen aussprechen kann (nicht > Sicherheits-"Ausnahme" mit Warndreieck sondern explizit vertraut(!) und > daher als 100% sicher einstuft) und ein UI welches beim Durchklicken > nicht suggeriert man würde gerade von einer wilden Horde von "Hackern" > angegriffen, der Serverbetreiber wäre unfähig und der nächste Klick > würde alle Einfallstore öffnen sondern eines das in nüchterner(!) > Sprache den Sachverhalt wahrheitsgetreu(!) erläutert und dem User > erlaubt explizit sein Vertrauen auszusprechen und dieses dann auch > respektiert. Das Problem wird sein, dass die meisten Benutzer (also nicht Leute wie du und ich, die verstehen, was tatsächlich dahinter steckt), wenn irgendwas nicht geht, ziemlich bereitwillig die Sicherheit über Bord werfen, um es ans laufen zu kriegen. Oder klicken einfach nur wild rum, bis es irgendwann geht. Und damit wird das ganze Sicherheitskonzept von SSL ausgehebelt. Das ist denke ich der Grund, weshalb Firefox das alles etwas überzogen darstellt. Wenn jemand tatsächlich einer man-in-the-middle-Attacke ausgesetzt ist, soll der Benutzer nicht einfach sagen: "Ja, ok, wird schon passen. Wenn's nur so geht, dann vertrau ich dem eben...", und danach geht's weiter, als wäre nichts gewesen - mit einer dauerhaften Umgehung der Sicherheit, ohne dass das überhaupt irgendwo angezeigt würde.
:
Bearbeitet durch User
A. K. schrieb: > Man kann ein Zertifikat gescriptet in ein aktuelles Firefox importieren, > auch ein CA-Zertifikat. Update: Es läuft darauf hinaus, dem FF per Config-Key zu sagen, dass er die Zertifikate im der Windows-Verwaltung zusätzlich zu denen in seiner eigenen Zertifikats-DB zur Kenntnis nimmt.
:
Bearbeitet durch User
Beitrag #6867103 wurde von einem Moderator gelöscht.
Das es geht, beweist das hier: Mit "rootsupd.exe" hebelt man die Zertifikate aus. Klappt aber nicht immer: Quelle: https://blog.wydler.eu/2017/06/17/vertrauenswuerdige-stammzertifizierungsstellen-manuell-aktualisieren/ ciao gustav
Karl B. schrieb: > Das es geht, beweist das hier: Dieser Post ist der Beweis, dass es vollkommen sinnlos ist, irgendwelche Hinweise einzublenden, sogar diese in roter Fettschrift anzuzeigen ist sinnlos. > Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. wendelsberg
Wendels B. schrieb: > Dieser Post ist der Beweis, dass es vollkommen sinnlos ist, irgendwelche > Hinweise einzublenden, sogar diese in roter Fettschrift anzuzeigen ist > sinnlos. Nö, hab vorige Woche noch den XP-Rechner angeworfen, und bei einer Seite funktionierte tatsächlich die "rootsup.exe". Da Du aber so unverschämt bist, mich hier doof anzumachen, bekommst Du die von mir nicht. ciao gustav
Beitrag #6868686 wurde von einem Moderator gelöscht.
Rolf M. schrieb: > Das Problem wird sein, dass die meisten Benutzer (also nicht Leute wie > du und ich, die verstehen, was tatsächlich dahinter steckt), wenn > irgendwas nicht geht, ziemlich bereitwillig die Sicherheit über Bord > werfen, um es ans laufen zu kriegen. Ja, genau so ist das sicher. Aber: Mozilla sollte irgendeine (meinetwegen auch gut vor DAUs versteckte) Konfigurationsmöglichkeit bieten, um das ganze Generve abzustellen. Mindestens per Ziel-IP und meinetwegen auch beschränkt auf private Netze. Alles andere missachted schlicht die objektive Realität.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.