... da kann man wirklich keine Rücksicht auf Marketing nehmen.
Willkommen im wirklichen Leben
Warum sollte YT Mitarbeiter und Geld in etwas investieren, wovon es keinen wirklichen Vorteil hat? SSL/TLS ist bei fast allen großen Websites (in den öffentlichen Bereich) nur Marketinggewäsch, weil die Informationen eh öffentlich zugänglich sind und die gewöhnlichen Nutzer nicht in den Sicherheitskonzepten der Betreiber als Assets auftauchen. Dein Idealbild eines sicheren Internets ist ja lobenswert, aber in der Realität musst du Sicherheit immer gegenüber anderen Faktoren (v.a. Wirtschaftlichkeit und Business Nutzen) abwiegen.
Ja ich meine "secure by default", das könnte man aber auch als Voraussetzung für "secure by design" sehen.
"Security by Design" hat nichts mit "Security by Default" zu tun. In ersterem baust du auf einem Design auf, das per se nicht unsicher - bitte beachte, dass Sicherheit immer relativ gesehen werden muss! - sein kann, letzteres beschreibt lediglich eine sichere Default-Konfiguration.
Trotzdem sollte man daran arbeiten, auch wenn man mal legacy support aufgeben muss.
Damit schliesst du einen Großteil der Benutzer aus und das nur, weil sich *wenige* Leute nach Snowden darüber echauffieren, dass ihre Youtube-Videos bei einem gezielten Angriff abgehört werden könnten. Sicherheit ist nicht alles und muss immer gegenüber dem Business Nutzen abgewogen werden. Oder umgekehrt gesagt: Wenn niemanden mehr Youtube nutzen kann, was bringt dir dann AES-256-GCM und Benutzeridentifikation via IPv6?
Haben die CAs keine CRLs weil es die Browser eh nicht interessiert oder andersrum, ist die Frage ...
Eine CA hat schlichtweg keinen Nutzen durch das Publizieren einer CRL, sondern nur anfallende Kosten, die gedeckt werden wollen, da es sich bei allen großen CAs um Unternehmen handelt. Daher fehlen für eine CA die Anreize, wenn sie eh nur drauf zahlen müssen, z.B. für die Generierung der CRLs und den anfallenden Traffic beim Ausliefern.
Einige CAs gegen daher den Weg und berechnen für eine Revokation eine geringe Gebühr, die der Nutzer zu tragen hat. Der hat allerdings auch kein Interesse daran, diese Gebühr zu bezahlen - sie bringt ihm ja auch keinen wirklichen Vorteil und er muss ja meistens schon für das neue Zertifikat an nicht ganz so geringen Betrag hinlegen (und ja, ich halte das SSL Business für pervers!).
Defacto bieten CRLs, unabhängig ihrer Implementierung in Browsern, keine geeignete Informationsbasis an, auf deren Basis man auf die Gültigkeit eines Zertifikats schliessen kann. Browserhersteller haben mit dem Problem im Grunde nichts zu tun. Das Problem bei Browsern besteht vielmehr in der Auswahl geeigneter Root CAs, weswegen sie in gängigen Sicherheitsmodellen auch nur als "Root Store Provider" bezeichnet werden.
Aber nur, wenn man es als nicht gesicherte Verbindung betrachtet
Du bist derzeit der einzige, der das tut
Niemand hier zweifelt an deiner Aussage, dass RC4 unsicher ist und aus Umgebungen, in denen ein bestimmtes Sicherheitniveau erreicht werden muss, abgeschafft gehört. Aber derzeit ist eine Abschaffung aus meiner Sicht nicht sinnvoll, da es keine Alternativen gibt, die ein ähnliches Sicherheitsniveau in bestimmten Angreifermodellen bei äquivalenter Geschwindigkeit und Ressourcennutzung erreichen. Oder kannst du mir eine Alternative zu RC4 nennen?
Aus diesem Grunde ist es meiner Meinung nach besser, die öffentlichen Inhalte (wenn man es streng nimmt, eigentlich alle Inhalte) unverschlüsselt zu übertragen, als sie mit einem als gebrochen und ohne Aufwand zu entschlüsselnden Verfahren zu verschlüsseln.
(Funktionierende) Verschlüsselung bedeutet Aufwand, Aufwand bedeutet Kosten und Kosten wollen bezahlt werden. Ein Angriff ist damit nicht weltweit auf alle Nutzer möglich, sondern nur noch auf eine wenige, bei denen diese Kosten rechtfertigt werden können. Das ist z.B. auch die Logik hinter "opportunistic encryption", das im neuen HTTP-Standard Einsatz finden soll (die Verschlüsselung bringt an sich keinen Nutzen gegen MitM, sie soll nur den Aufwand auf ein Kostenlevel steigern, dass eine Überwachung uninteressant macht).
Natürlich macht es keinen Sinn, eine Caesar-Chiffre mit statischem Key zu implementieren. Davon sprechen wir aber hier auch nicht, oder?
Der Sicherheitsgewinn durch eine so verschlüsselte Verbindung ist nur ein scheinbarer Gewinn, in der Realität geht die Vertraulichkeit verloren und das Wissen, ob die Daten jetzt sicher oder unsicher übertragen werden.
Sicherheit ist imemr relativ. Wenn es nur um YT geht, dann ist RC4 aktuell völlig ausreichend, da eine flächendeckende Überwachung damit erschwert wird und die Infos derart unwichtig sind, das die Implementierung "sicherer" Algorithmen keinen weiteren Nutzen bringt, sondern nur Kosten verursacht. Dass wir das in Zukunft ändern müssen, bestreitet in der Informatik, in der das Gesagte morgen eh schon wieder hinfällig ist, niemand. Daher hast du zwar einen geringen Gewinn, aber gegenüber der unverschlüsselten Übertragung ist es denoch ein zu nennender Gewinn.
![[HaBo]](/styles/default/logoklein.png){kind=small}
