Hallo! Am 2016-03-02 um 14:37 schrieb Matthias Šubik:
Genau den Link habe ich gestern noch gesucht und nicht mehr gefunden! Danke, danke, danke!On 02.03.2016, at 14:28, L. Aaron Kaplan <[email protected]> wrote:[...]Darf ich auch auf bettercrypto.org verweisen?
Ich habe auch nicht vorgeschlagen, neue Anleitungen zu schreiben, sondern vielmehr im Wiki eine Seite mit kommentierten Links (sortiert nach Themengruppen) anzulegen.[...][...]--> bitte schaut mal in bettercrypto.org rein. Da haben sich ein paar Leute schon wirklich viel Arbeit angetan und mit vielen Experten quergecheckt (unter anderem hat Dan Bernstein bettercrypto ziemlich gelobt). Macht vielleicht Sinn, bestehende guides anzusehen (und zu verbessern, wenn was auffällt), als wieder komplett einen neuen zu schreiben - weil das ist echt viel Aufwand.Unbedingt. Wir sollten aber sammeln, was halt im Funkfeuer-Umfeld *speziell* ist, z.B. openwrt-Änderungen, und wie die auf die Sicherheit wirken.
Die am häufigsten genutzten OpenSSL-Befehle, etwaige alternative ACME-Clients, die wichtigsten (SSL/TLS-bezogenen) Konfigurationseinträge für die gängisten Serverdienste aus diesen verlinkten Dokumentationen könnte man bei Bedarf dennoch übersichtlich dort zusammenfassen.
Bezogen auf OpenWRT: Adi hat Recht; man kann da nicht viel tun.Sslwrap, das auf einigen der Firmwares zum Einsatz kommt, scheint in den alten Versionen angreifbar zu sein:
https://github.com/nodejs/LTS/issues/80Zudem haben wir bei OpenWRT die Wahl zwischen polarssl, openssl und cyassl, wobei es die Abhängigkeiten dazu führen, dass meist zwei davon in die Firmwareimages integriert werden und ein ACME-Client fehlt bislang gänzlich.
Ich denke, dass das Thema Secure-OpenWRT ein ganz eigenes Kapitel ist... auf das wir hier nur bedingt Rücksicht nehmen können. Dafür bräuchte es eine Task-Force und einen Fork, der auch von Routerherstellern Support erhält - auch in Hinblick auf das kommende Bootloader-Locking.
Eine Art paket-lastigeres WRT, ähnlich debWRT, wäre da vermutlich der richtigere, weil vielseitigere Ansatz. Leider steht diese Vorgehensweise aber auch heute noch mit den Flash-Kapazitäten auf den im Handel befindlichen Geräten meist im Widerspruch.
Offengestanden sehe ich für die bisherigen Konzepte im Funknetz aufgrund dieser Entwicklungen das Ende der Fahnenstange erreicht. Wir werden wohl in Hinblick auf neue Funkstandards, neue Regulatorien, neue Routingprotokolle, die IT-Sicherheit und die auch Hinsichtlich der Usability wie auch der Dezentralität mittel- und langfristig von Grund auf neu planen müssen.
Kurzfristig sehe ich keine großartigen Verbesserungsmöglichkeiten: Die dhparams auf den Routern sind bescheiden, die Zertifikate sind mit z.T. veralteten Libraries erstellt und selbstsigniert. Das Problem der schlechten Pseudozufallszahlen hat Matthias erst kürzlich thematisiert. Für die kritischen Protokolle wird ohnedies keine Verschlüsselung benützt (olsr), zudem funken wir ja nach wie vor über offene Netzwerke und tunneln auch unverschlüsselt. Ich wüsste nicht, wo man in Anbetracht so vieler Unsicherheitsfaktoren kurzfristig anfangen sollte...
bG Matthias
Begründete Gegenmeinungen und konkrete Vorschläge sind willkommen! LG Erich
<<attachment: erich.vcf>>
-- Discuss mailing list [email protected] https://lists.funkfeuer.at/mailman/listinfo/discuss
