Mozilla will HTTP ausrangieren

Zitat von Smut

bin dagegen, da dadurch nur noch viel mehr insecure CAs aus dem boden gestampft werden ohne einen mehrwert an sicherheit zu bieten.

Es gibt zwar noch immer zu viele Zertifizierungsstellen und sie gehören strenger reguliert, aber ich glaube, es war noch nie so schwierig eine Zertifizierungsstelle "aus dem Boden zu stampfen" wie heute.

Zitat

es wird sogar noch unsicherer weil diese insecure CAs, dann aufgrund schlechter prüfungen ein zertifikat für von mir aus google.com ausstellen können. diese probleme muss man zuerst adressieren. hier wird durch die finanzierung von CAs blödsinnig geld verbraten.

Es wurden bereits Gegenmaßnahmen ergriffen: z.B. Public Key Pinning Extension for HTTP und Certificate Transparency

Zitat

bist du dir sicher dass crl abgelöst ist?
ich habe eher die befürchtung dass certificate revoking nicht ordentlich funktioniert, da es viele clients aus performance gründen nicht überprüfen, als dass OCSP CRLs tatsächlich ablösen wird.

Die Mängel von CRL sind schon lange bekannt, deshalb hat man OCSP Stapling entworfen. Es wird bereits von den großen Browsern unterstützt, leider sind die meisten Serverbetreiber nicht so schnell.

Der Webserver von oc.at unterstützt übrigens OCSP stapling

Zitat von Smut

das henne ei problem ist ja künstlich geschaffen, da man eine public information, die auch aus privacy sicht nicht abstreitbar ist, plötzlich ausschließlich über SSL verschicken will.

HTTPS ist auch für öffentliche Information sinnvoll. Mit HTTPS wird sichergestellt, dass auch wirklich das ankommt, was der Server dir schicken wollte. Sonst könnte ein Angreifer im Netzwerk den Datenverkehr manipulieren. HTTPS ist speziell in offenen WLANs wichtig und schützt auch vor ISPs, die dir Werbung unterschieben wollen usw.

Der öffentliche Schlüssel mit dem die Signatur des Pakets überprüft wird, war im ISO-Image von Debian enthalten. Das ISO-Image kann man meistens nur über HTTP herunterladen, aber immerhin ist es ebenfalls signiert. Nur wie überprüft man die Signatur? Wie geht man sicher, dass man den richtigen öffentlichen Schlüssel von Debian heruntergeladen hat?

Wenn man den Schlüssel über HTTPS herunterlädt, hängt die Sicherheit von GPG erst recht vom kaputten Zertifikatsystem ab.

Ich denke auch, die wiederholten Sicherheitslücken in APT zeigen, dass HTTPS trotz Signatur sinnvoll wäre.

Zitat von luka

Der öffentliche Schlüssel mit dem die Signatur des Pakets überprüft wird, war im ISO-Image von Debian enthalten. Das ISO-Image kann man meistens nur über HTTP herunterladen, aber immerhin ist es ebenfalls signiert. Nur wie überprüft man die Signatur? Wie geht man sicher, dass man den richtigen öffentlichen Schlüssel von Debian heruntergeladen hat?

Wenn man den Schlüssel über HTTPS herunterlädt, hängt die Sicherheit von GPG erst recht vom kaputten Zertifikatsystem ab.

Ich denke auch, die wiederholten Sicherheitslücken in APT zeigen, dass HTTPS trotz Signatur sinnvoll wäre.

Das fuehrt doch aber so zu nichts. Wie sind die als "vertrauenswuerdig" eingestuften CA-Zertifikate in den Trust Store deines TLS-Stacks gekommen? Woher kommt der ueberhaupt?

Irgendwo, irgendwann, hast du immer einen finalen Trust Anchor, den du nicht ueber ein rein technisches, interaktionsloses Verfahren wirst pruefen koennen.

Und die TLS-Implementierung, die bislang fehlerfrei war, werfe den ersten Stein...

Ich habe ja nichts dagegen, https _optional_ anzubieten. (Es gibt im Falle von apt ja auch apt-transport-https zu diesem Zweck.) Aber mandatorisch; fuer _ALLES_? Bloede Idee, Punkt.

Firefox Developer Edition 46 warnt, wenn Zugangsdaten unverschlüsselt verschickt werden:


Ich denke, es ist richtig, zuerst die Entwickler über das Problem zu informieren. Aber ich befürchte, viele Webentwickler reagieren erst, wenn die Browser sie dazu zwingen.

ich hätte gern dass alles router hersteller ihr web-admin-interface auf https-only umstellen, ist leider aucht nicht standard. ansich ja kein problem afaik.