Notiz Mozilla: Firefox 76 bekommt einen HTTPS-Only-Mode

Waterfox basiert auf Gecko (edit: altem Gecko ohne Quantum/Servo), und damit ist dieser Browser mittelfristig sowieso tot.
 
freshprince2002 schrieb:
Sicherheitstechnisch absolute Grütze, genauso wie auch Palemoon... Die Forks haben nicht mal nen Ansatz einer Sandbox.
 
  • Gefällt mir
Reaktionen: chartmix und P220
Nett wäre doch mal eine Option in der config mit der sich das Geheule unter jeder Firefox-News ausblenden lässt.
 
  • Gefällt mir
Reaktionen: SyntaX, Animal Mother und gaelic
Vorallem über a:c lässt sich doch eh alles unerwünschte aushebeln, sprich alles ist optional, was will man mehr?
 
RalphS schrieb:
Https ungleich sicher. Ob das mal jemals in irgend einen Kopf reingeht?
Das ist purer Aktionismus für Daus und solche die es besser wissen müßten, das aber nicht tun.

Lieber http und wissen daß nicht sicher... als https und falsche Erwartungen. Auch der schlimmste Virus kann über https geliefert werden, und da sslchecks verpönt sind und Av Software Schlangenöl ist, wäre das Ergebnis Pandemie mit Ansage.

Aber es ist ein Schloß in der Adressleiste. Nur darum geht es.
Lesen. Verstehen. Dann wiederkommen:
gaelic schrieb:

Ich persönlich hab keinen Bock, dass die Telekom mir plötzlich ihre Werbung auf einer Seite unterjubelt. Oder irgendein Hacker, der in deren Netz reinkommt, auf einer CB-Seite den Downloadlink auf seinen Virus umbiegen kann. All das ist über HTTP möglich und (siehe den Link) passiert auch täglich.

Natürlich schützt mit HTTPS nicht vor allen Gefahren - wenn der Seitenbetreiber Viren verteilt, hilft es nix. Aber es hilft gegen jeden, der zwischen Seitenbetreiber und mir sitzt und Böses im Sinn hat. Und das ist schonmal eine ganze Menge.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: iWaver, XimeX, P220 und 5 andere
gaelic schrieb:
Ich verstehe die Aufregung nicht. Jeder Popel-Webserver sogar auf schwacher Hardware ala RaspberryPi kann ohne Performance Einbußen oft mit einer Änderung von nur einer Config Zeile auf https umgestellt werden:

https://doesmysiteneedhttps.com/

Ist es wirklich so?

Wenn ich sehe wie die Leistung bei Verschlüsselung zumindest im Kontext von VPN wegbricht fällt es mir schwer zu glauben, dass HTTPS keine Einbußen verursachen soll. Oder verschlüsselte Dateien/Verzeichnis/Laufwerk bei NAS die Probleme haben selbst 1 GBIT/s NIC voll auszulasten.

Nach diesen Erfahrungen scheint mir so eine Aussage erst einmal unseriös.

Da wäre eine Aufschlüsselung x Prozent langsamer aber das sollte jedem Wert sein nachvollziehbarer. So wirkt das nach jemandem mit einer womöglich löblichen Agenda statt einer nüchternen Analyse wonach mal selbst entscheiden kann.
 
  • Gefällt mir
Reaktionen: gaelic
Wobei nen Raspberry leider keine AES implementierung hat und somit... nunja...
 
Das überzeugt mich ehrlich gesagt nicht.

Der genannte Raspberry Pi hat keine AES NI Einheit.

Ebenso dürfte Computerbase CPUs im Einsatz haben das im Verhältnis zur Bandbreite unermesslich überdimensioniert ist.

Normalerweise sieht es ja so aus

Man verbaut CPUs die pro Kern 50 GBIT/s iperf umsetzt. Im CPU sind eine handvoll Kerne. Diese hängen dann an einer 1 GBE Leitung. Dass da bei einer 200 GBIT/s Maschine keinerlei Einbusse spürbar ist wenn obendrein AES NI im Spiel ist und nur 1 GBIT/s abgerufen wird will ich gerne glauben.

Was aber wenn man ein NAS nimmt dessen CPU vielleicht 600 MBIT/s durchschleust und dort von HTTP auf HTTPS schaltet?

Ist die Existenz von AES NI nicht ein Beweis für die benötigte Rechenleistung bei Verschlüsselung? Wenn sie kostenlos wäre, dann würde man doch keine Transistoren dafür verschwenden?

Ich erlebe ja täglich wie die Performance wegbricht bei SFTP oder die schöne Fritzbox VPN Lösung durch eine ausgewachsene VPN Router als VM ersetzen muss weil die Verschlüsselung dermaßen anspruchsvoll ist...

Hat jemand eine Raspi und kann da mal nachmessen?
 
  • Gefällt mir
Reaktionen: DaBzzz
Wattwanderer schrieb:
Oder verschlüsselte Dateien/Verzeichnis/Laufwerk bei NAS die Probleme haben selbst 1 GBIT/s NIC voll auszulasten.
Weils räudige Consumer-NAS sind mit schwächlichen ARM/Atom-CPUs ohne AES in Hardware? Jeder Server der den Namen verdient (und auch jede aktuelle Desktop- und Mobile-CPU) hat AES-NI, damit bewältigt man mehrere GB/s, die Verschlüsselung fällt nicht ins Gewicht. Der initiale Schlüsseltausch erfordert einen zusätzlichen Round-Trip, lässt sich aber über mehrere Request hinweg wiederverwenden durch server-seitigem Session Cache oder Resumption Tickets.

PIs und ähnliche sind natürlich erst recht ungeeignet für alles was irgendwie nennenswert Durchsatz bringen soll.
 
  • Gefällt mir
Reaktionen: gaelic
Schau doch mal an wie weit die Billighoster die CPUs aufteilen. Da ist ein eigenes Einsteiger NAS eine Rakete.

Und nein, für die drei Seitenaufrufe will ich keinen eigenen Server mieten. Aber man bekommt eine Ahnung davon, dass Rechenleistung nicht endlos ist.

Egal. Das driftet in die Richtung ab, dass jemand sich einen Highend Rechner hinstellt und meint 8 K Videostreams bekäme man kostenlos während andere versuchen bei 4 K das Ruckeln abzugewöhnen.
 
Nun ja, bei meinem 3700X @Stock (65 Watt @3200er RAM, nur XMP) ist der Fakter mit/ohne AES-NI ~6. Selbst wenn damit der "Preis" für TLS mit AES statt ~1% auf ~7% mehr Last ansteigt ist das immer noch zu vernachlässigen...

1585163245674.png1585163255182.png

Klar ist ein Raspy eher langsam, aber selbst 10% wären kein Beinbruch.
 
Es gibt ja nicht nur AES. es gibt zB auch ChaCha20-Poly1305 das auch schnell für CPUs ohne AES in Hardware läuft
 
Zuletzt bearbeitet:
RalphS schrieb:
[...]
Irgendein Netzwerkmonitor, den man vielleicht hat, würde vielleicht anschlagen, wenn er denn HTTPS grundsätzlich überwachen könnte; tut er aber nicht, da dekonfiguriert weil SSL Scan blöd. [...]

Weshalb? Keine Lust auf Ausnahmenbildung?
 
ChaCha20-Poly1305 ist state of the art. das kann man nicht mit RC4 etc vergleichen die schon seit Jahren als geknackt gelten. MD5 ist hier was ganz anderes. (Stream/Block Cipher vs Hashing Algorithm)
Gut konfiguerierte Server verwenden AES als default und ChaCha20-Poly1305 als fallback für clients die keine AES Hardware Unterstützung haben
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: I'm unknown
Wattwanderer schrieb:
Ist es wirklich so?
Ja.
https://istlsfastyet.com/

Davon ab kannst du mit HTTP2.0/SPDY glatt noch Ressourcen sparen, wenn du den Webserver gut aufsetzt.

Was die totalen Billigmöhren ohne AES-NI angeht: Die benutzt man normalerweise ja auch nicht für High-Traffic Seiten. Bei ein paar Seitenaufrufen pro Minute bekommen auch die TLS hin. Wenn es nicht mehr klappt, sollte man insgesamt eine halbwegs brauchbare Lösung anvisieren. Beim Raspberry wird ja nicht nur die CPU schnell zum Flaschenhals, sondern auch der Durchsatz, geteiltes USB Interface für LAN und die USB Ports und alles möglich andere.

Mein Raspberry hat keinerlei Probleme, den PiHole mit TLS zu betreiben, und auch die DNS Requests per DoH aufzulösen geht wunderbar. CPU kommt da nie ins Schwitzen.
 
  • Gefällt mir
Reaktionen: gaelic und I'm unknown
camlo schrieb:
HTTP rauswerfen, FTP auch und das Ding ist nur noch für Facebook zu gebrauchen
Bin ich absolut dagegen! Ihr vergeßt alle, daß man für interne Systeme noch viel HTTP benötigt, wenn ich da an Karaf Webkonsolen denke, Apps die interne Tomcat-Server verwenden, ebenso zig Apps wie Gitlab und Co mit httpd und nginx. Und nein, ich werde jetzt nicht für jedes Test- und interne System immer ein Zertifikat generieren, was eh nach ein paar Wochen obsolete ist!
 
Autokiller677 schrieb:
Mein Raspberry hat keinerlei Probleme, den PiHole mit TLS zu betreiben, und auch die DNS Requests per DoH aufzulösen geht wunderbar. CPU kommt da nie ins Schwitzen.

Hast du schon mal sagen wir mal eine 10 GB Datei mit und ohne Verschlüsselung von deiner Raspi heruntergeladen?

Falls das ohne Einfluss auf den Durchsatz bleiben soll, würde ich sogar mein Workflow mit VPN überdenken und versuchen die Traffic über HTTPS zu tunneln.
 
Wattwanderer schrieb:
Hast du schon mal sagen wir mal eine 10 GB Datei mit und ohne Verschlüsselung von deiner Raspi heruntergeladen?

Warum benutzt man überhaupt http(s) für die Übertragung einer Datei vom eigenen Server?
 
Zurück
Oben