[Discuss] DROWN-Attack ... @ your device? (sorry for crossposting)

[Erich N. Pekarek]

Hallo!

Am 2016-03-02 um 14:37 schrieb Matthias Šubik:
>> On 02.03.2016, at 14:28, L. Aaron Kaplan <(spam-protected)> wrote:
>>> [...]
>> Darf ich auch auf bettercrypto.org verweisen?
Genau den Link habe ich gestern noch gesucht und nicht mehr gefunden! 
Danke, danke, danke!
>> [...]
> [...]
>
>> --> 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.
Ich habe auch nicht vorgeschlagen, neue Anleitungen zu schreiben, 
sondern vielmehr im Wiki eine Seite mit kommentierten Links (sortiert 
nach Themengruppen) anzulegen.

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/80
Zudem 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
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : erich.vcf
Dateityp    : text/x-vcard
Dateigröße  : 4 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.funkfeuer.at/pipermail/discuss/attachments/20160302/7cc458fa/attachment.vcf>