Nach der Sinnhaftigkeit der Frage hast du sicher auch gesucht, als sich Isaac Newton darüber Gedanken machte, warum der Apfel vom Baum fällt, denn für dich war das ja völlig offensichtlich.
Von Anonymous am Mo, 16. September 2019 um 16:23 #
Keine neuen Qualitäten, aber neue Möglichkeiten.
Auf nem CCC-Congress gab es vor 2 oder 3 Jahren mal einen Vortrag von jemandem, der sich für das Scannen in den unermesslichen Weiten des IPv6-Adressraumes eine Strategie überlegt hatte.
Mit der fand er dann zahlreiche IPv6-Subnetze, von denen die Betreiber (Firmen, Provider, sogar Militär) nur glaubten, das Subnetz sei privat.
Von Verfluchtnochmal_5987108 am Di, 17. September 2019 um 09:32 #
Mimimimi - Dämliches Geschwätz ist es trotzdem zu behaupten 2 Protokollstacks hätten weniger potentielle Probleme als 1 der noch dazu abgehangen und vor allem einer der beiden ist
Viel dämlicher kann man aus technischer Sicht eigentlich kaum argumentieren
Mein Provider für den Heimbereich hat ausschließlich IPv4-Adressen im Angebot. War für mich sogar ein Qualitätskritierium gegenüber Anbietern, die nur Dualstack Lite haben (mit diversen Problemen, wenn man das Heimnetz von außen erreichen will). Gegen echten Dualstack hätte ich nichts.
Habe Kabel bei Vodafone und initial Dual Stack Lite. Habe gemerkt dass selbst hosten damit nicht drin ist, angerufen und 2 Stunden später hatte ich vollen DualStack. Für 0,00€ Aufpreis. Da kann ich nicht meckern.
Mag sein das es bei Dir gut ging, ich habe aber auch schon andere Geschichten gehört. Außerdem verteilen diese Provider ja auch nur solange alternativ echten Dualstack, wenn es nicht zu Viele haben wollen.
Ansonsten könnten sie das ja von Anfang an machen, aber da sie zu wenig IPv4-Adressen haben, machen sie DS Lite.
Von HardwareAmateur am Di, 17. September 2019 um 06:53 #
...machte Torvalds eine Optimierung des ext4- Dateisystems rückgängig. [...]. Manche Systeme konnten beim Booten nicht mehr genug Entropie sammeln und hingen daher, da der sichere Zufallsgenerator nicht initialisiert werden konnte.
Da hat Torwalds der Linux-Welt wohl den Allerwertesten gerettet Ohne ein zuverlässiges /dev/random keine Netzwerkverschlüsselung. Der Entropie-Pool ist scheinbar eine unterschätzte Herausforderung. Auch AMD's neuer Ryzen 3000 hatte ein schwerwiegendes Problem mit dem Zufallszahlengenerator, so dass einige Kernel nicht mehr booten konnten.
Von Verfluchtnochmal_5987108 am Di, 17. September 2019 um 09:38 #
Erstens geht es nicht um /dev/random sondern um syscalls und zweitens darum dass deine Kiste gar nicht erst gebootet hätte wenn irgendein Trottel meint kryptografisch sichere Zufallszahlen für etwas zu verschwenden dass sie nicht braucht und das möglichst früh im Bootvorgang damit ja gute Chancen bestehen endlos zu blocken womit sich der Zustand auch nicht mehr ändert
Von klopskind am Di, 17. September 2019 um 12:06 #
Das darunterliegende Problem ist so vielfältig, dass die beteiligten Entwickler sich bisher uneinig sind, wie damit umzugehen ist. Da es so knapp vor dem Veröffentlichungstermin von Linux 5.3 entdeckt wurde, hat sich Linus dazu entschieden, die Optimierung von ext4, die das Fass in einem ganz anderen Subsystem (crypto) zum Überlaufen brachte, vorerst (d.h. wahrscheinlich für Linux 5.3.y) zurückzunehmen, damit dieser Fehler nicht zum Tragen kommt. Der eigentliche "Bug" besteht weiterhin. Quelle [1]
Dabei geht es um die kritische Phase beim Booten bevor der CRNG des Linux-crypto-Subsystems initialisiert wurde. Dafür muss zunächst eine gewisse Menge Entropie "bemessen" (kann per Definition nur anhand eines Schätzers abgeschätzt werden) und aufbereitet werden (derzeit 512 Byte?). Bis dahin blocken die Zugriffe auf den Pool z.B. via /dev/random (random(4)), welches die Entropie sogar "verbraucht" also den Pool erschöpft (unter Kryptologen übrigens ein äußerst strittiges Konzept), oder getrandom(2). /dev/urandom setzt in diesem lediglich eine Warnung ins Kernel-Log ab.
Das ist besonders kritisch bei Systemen, bei denen das "Sammeln" & "Schätzen" der Entropie schwierig bzw. die Menge der "geschätzten" Entropie begrenzt ist und von denen gleichzeitig erwartet wird, dass sie verlässlich und konsistent zügig booten statt minuten- bis stundenlange Hänger zu haben.
Um einerseits zu wissen, welche Systeme davon nun (am ehesten) betroffen sind, muss man verstehen, welche Entropiequellen dem Kernel zur Verfügung stehen. So "sammelt" Linux Entropie etwa anhand von Hardware Ereignissen wie Interrupts, Benutzereingaben (HID: z.B. Tastatur, Maus), CPU-Zyklenzähler (Unterstützung architekturabhängig) oder eigens dafür entwickelte Komponenten wie Hardware-RNGs in TPM, USB-Sticks, RDSEED/RDRAND (beschränkt auf x86 und Linux nutzt diese Instruktion standardmäßig nicht) etc. Betroffen wären also z.B. Embedded-Geräte, bestimmte Architekturen, Server und virtuelle Maschinen, oder generell Hardware, die tendenziell weniger Interrupts erzeugt (z.B. SSDs im Vergleich zu HDDs). Es gibt aber sicher noch mehr. Quelle [2] via [3], [4], [5]
Andererseits werden auch inzwischen teils viel mehr Zufallszahlen während des Bootens verwendet, insbesondere wegen der Anforderung einiger Geräte, sofort im Netzwerk/Internet hängen zu müssen, um Ihre erdachte Funktion tatsächlich erfüllen zu können. So wäre da bspw. ASLR, systemd-interne Hashtabellen, UUID-Generierung, Generierung temporärer Dateien, Swap-Verschlüsselung mit Zufallsschlüssel je Start, Portrandomisierung, Randomisierung der TCP sequence number, DHCP-Klient, DNS oder SSH-Schlüsselgenerierung, Login-Manager wie GDM, etc. Quellen [1], [6], [7], [8]
Einige Entwickler im "user space" tragen also Ihren Teil zu dem Problem bei. Die Frage ist, ob das tatsächlich immer nötig ist, so früh auf so viel Entropie angewiesen zu sein. Und auch die Hersteller der Geräte müssen diese solide ausstatten, damit die steigenden Anforderungen der Entwickler (und damit der Anwendungen und Nutzer) erfüllt werden.
Tools wie rng-tools oder havaged sind nur Krücken und werden von einigen Sicherheitsforschern sehr kritisch beäugt. Quellen [9], [10]
Jedenfalls ist die Lage ziemlich verzwickt, denn das Anwendungs-/Anforderungs-Spektrum von Linux ist inzwischen so groß, dass keine simple Lösung ausreicht, um das ganze Spektrum abzudecken. Standardmäßig verwendet Linux kein random seed file, wie etwa die BSDs es seit einiger Zeit tun. Hier spielen die BSDs ihren Vorteil aus, das ganze Basissystem zu kontrollieren und nicht nur den Kernel. Immerhin bietet systemd inzwischen einen optionalen Dienst (systemd-random-seed), der das entsprechend umsetzt. Auch systemd-boot bietet hier ein Lösung an, beschränkt sich aber nur auf EFI-Systemen. Quellen [11], [12], [13]
Zudem ist Linux RNG relativ langsam ggü. anderen Betriebssystemen. Es gab da mal einen Vortrag auf einer BSD-Konferenz, der Linux, FreeBSD und Windows (oder macOS?) verglichen hat. Leider finde ich den gerade nicht mehr.
Die Diskussionskultur in [1] finde ich teils sehr verbesserungswürdig. Wie unsachlich und unstrukturiert das Problem teils diskutiert und erörtert wird, ist beschämend - insbesondere in Anbetracht bereits existierender Lösungen. Da werden wild Annahmen aufgestellt, von Ideen um ernste Warnungen und Fehlermeldung vor den Anwendern zu verstecken fantasiert, spezielle Awendungsfälle ersonnen und gleichzeitig andere gänzlich ausgeblendet, allein um das jeweilig subjektive "Problem" zu benennen, natürlich beim Anderen. Linux, die Linux-Distributionen und systemd bzw. die "Distro-Middleware" der Wahl haben hier noch viel zu tun!
Swap-Verschlüsselung mit Zufallsschlüssel je Start
Ob das so eine gute Idee ist da bin ich seit heute auch am zweifeln. Mir ist erst heute mein Rechner nicht hochgefahren, weil Systemd Swap nicht einhängen konnte, welches genau auf diese Weise verschlüsselt wird. Nach 2 Minuten sinnlosem warten während Systemd die Zeit hochzählte, habe ich dann die Reißleine gezogen und nochmal neu gebootet. Ging dann auch wieder. Nein, kein 5er Kernel. Muss das Verhalten mal weiter beobachten.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Sep 2019 um 20:19.
Mit einer IPv6 oder einer (externen) IPv4 Adresse?
Kurz welche Datenpakete versendet euer Router an das Netz außerhalb eures LANs am meisten, IPv4 Pakete oder IPv6 Pakete?
Ich nutze im Moment IPv5, da mir der direkte Umstieg von IPv4 auf IPv6 mental Probleme bereitet.
Du wolltest doch nicht etwa subtile Kritik an der Sinnhaftigkeit der Frage üben?
Nach der Sinnhaftigkeit der Frage hast du sicher auch gesucht, als sich Isaac Newton darüber Gedanken machte, warum der Apfel vom Baum fällt, denn für dich war das ja völlig offensichtlich.
Ist dem nicht ein Apfel auf den Kopf gefallen?
Zumindest war es bei ihm nur ein Apfel.
*YMMD*
ipv4 aus zwei Gründen:
1) die (gefühlte) Mehrheit der Hosts spricht ipv4-only
2) precedence ::ffff:0:0/96 100
IPv6 natürlich. Im Gegensatz zu Whisky gewinnt Technik durch altern keine Qualität.
Keine neuen Qualitäten, aber neue Möglichkeiten.
Auf nem CCC-Congress gab es vor 2 oder 3 Jahren mal einen Vortrag von jemandem, der sich für das Scannen in den unermesslichen Weiten des IPv6-Adressraumes eine Strategie überlegt hatte.
Mit der fand er dann zahlreiche IPv6-Subnetze, von denen die Betreiber (Firmen, Provider, sogar Militär) nur glaubten, das Subnetz sei privat.
Neuland halt.
Wer zu blöde ist eine Firewall aufzusetzen ist das auch mit ipv4
2 stacks, 2 rulesets und normalerweise gilt eingehend deny all mit Ausnahmen
Dämliches Geschwätz! ipv6 only ist auf absehbare Zeit nicht und Dualstack bedeutet zwangsweise mehr Fehler und mehr Komplexität auf allen Ebenen
Und auch Software gewinnt an Qualität wenn man nicht dauernd komplette rewrites macht weil die bugs weniger werden und best practices etabliert sind
"Dämliches Geschwätz" und asoziales Gepöbel ist eher deine Spezialität. Verpiss dich doch einfach, wenn es dir hier nicht passt.
Mimimimi - Dämliches Geschwätz ist es trotzdem zu behaupten 2 Protokollstacks hätten weniger potentielle Probleme als 1 der noch dazu abgehangen und vor allem einer der beiden ist
Viel dämlicher kann man aus technischer Sicht eigentlich kaum argumentieren
IPv4
Mein Provider für den Heimbereich hat ausschließlich IPv4-Adressen im Angebot. War für mich sogar ein Qualitätskritierium gegenüber Anbietern, die nur Dualstack Lite haben (mit diversen Problemen, wenn man das Heimnetz von außen erreichen will). Gegen echten Dualstack hätte ich nichts.
Auch in der Firma IPv4 only
Habe Kabel bei Vodafone und initial Dual Stack Lite. Habe gemerkt dass selbst hosten damit nicht drin ist, angerufen und 2 Stunden später hatte ich vollen DualStack. Für 0,00€ Aufpreis. Da kann ich nicht meckern.
Mag sein das es bei Dir gut ging, ich habe aber auch schon andere Geschichten gehört.
Außerdem verteilen diese Provider ja auch nur solange alternativ echten Dualstack, wenn es nicht zu Viele haben wollen.
Ansonsten könnten sie das ja von Anfang an machen, aber da sie zu wenig IPv4-Adressen haben, machen sie DS Lite.
Die Frage ist bei 40 Prozent ipv6 in Deutschland und 10 Prozent in Österreich dein Ernst?
Ohne ein zuverlässiges /dev/random keine Netzwerkverschlüsselung. Der Entropie-Pool ist scheinbar eine unterschätzte Herausforderung. Auch AMD's neuer Ryzen 3000 hatte ein schwerwiegendes Problem mit dem Zufallszahlengenerator, so dass einige Kernel nicht mehr booten konnten.
Erstens geht es nicht um /dev/random sondern um syscalls und zweitens darum dass deine Kiste gar nicht erst gebootet hätte wenn irgendein Trottel meint kryptografisch sichere Zufallszahlen für etwas zu verschwenden dass sie nicht braucht und das möglichst früh im Bootvorgang damit ja gute Chancen bestehen endlos zu blocken womit sich der Zustand auch nicht mehr ändert
Das darunterliegende Problem ist so vielfältig, dass die beteiligten Entwickler sich bisher uneinig sind, wie damit umzugehen ist. Da es so knapp vor dem Veröffentlichungstermin von Linux 5.3 entdeckt wurde, hat sich Linus dazu entschieden, die Optimierung von ext4, die das Fass in einem ganz anderen Subsystem (crypto) zum Überlaufen brachte, vorerst (d.h. wahrscheinlich für Linux 5.3.y) zurückzunehmen, damit dieser Fehler nicht zum Tragen kommt. Der eigentliche "Bug" besteht weiterhin.
Quelle [1]
Dabei geht es um die kritische Phase beim Booten bevor der CRNG des Linux-crypto-Subsystems initialisiert wurde. Dafür muss zunächst eine gewisse Menge Entropie "bemessen" (kann per Definition nur anhand eines Schätzers abgeschätzt werden) und aufbereitet werden (derzeit 512 Byte?). Bis dahin blocken die Zugriffe auf den Pool z.B. via
/dev/random
(random(4)), welches die Entropie sogar "verbraucht" also den Pool erschöpft (unter Kryptologen übrigens ein äußerst strittiges Konzept), oder getrandom(2)./dev/urandom
setzt in diesem lediglich eine Warnung ins Kernel-Log ab.Das ist besonders kritisch bei Systemen, bei denen das "Sammeln" & "Schätzen" der Entropie schwierig bzw. die Menge der "geschätzten" Entropie begrenzt ist und von denen gleichzeitig erwartet wird, dass sie verlässlich und konsistent zügig booten statt minuten- bis stundenlange Hänger zu haben.
Um einerseits zu wissen, welche Systeme davon nun (am ehesten) betroffen sind, muss man verstehen, welche Entropiequellen dem Kernel zur Verfügung stehen. So "sammelt" Linux Entropie etwa anhand von Hardware Ereignissen wie Interrupts, Benutzereingaben (HID: z.B. Tastatur, Maus), CPU-Zyklenzähler (Unterstützung architekturabhängig) oder eigens dafür entwickelte Komponenten wie Hardware-RNGs in TPM, USB-Sticks, RDSEED/RDRAND (beschränkt auf x86 und Linux nutzt diese Instruktion standardmäßig nicht) etc.
Betroffen wären also z.B. Embedded-Geräte, bestimmte Architekturen, Server und virtuelle Maschinen, oder generell Hardware, die tendenziell weniger Interrupts erzeugt (z.B. SSDs im Vergleich zu HDDs). Es gibt aber sicher noch mehr.
Quelle [2] via [3], [4], [5]
Andererseits werden auch inzwischen teils viel mehr Zufallszahlen während des Bootens verwendet, insbesondere wegen der Anforderung einiger Geräte, sofort im Netzwerk/Internet hängen zu müssen, um Ihre erdachte Funktion tatsächlich erfüllen zu können. So wäre da bspw. ASLR, systemd-interne Hashtabellen, UUID-Generierung, Generierung temporärer Dateien, Swap-Verschlüsselung mit Zufallsschlüssel je Start, Portrandomisierung, Randomisierung der TCP sequence number, DHCP-Klient, DNS oder SSH-Schlüsselgenerierung, Login-Manager wie GDM, etc.
Quellen [1], [6], [7], [8]
Einige Entwickler im "user space" tragen also Ihren Teil zu dem Problem bei. Die Frage ist, ob das tatsächlich immer nötig ist, so früh auf so viel Entropie angewiesen zu sein. Und auch die Hersteller der Geräte müssen diese solide ausstatten, damit die steigenden Anforderungen der Entwickler (und damit der Anwendungen und Nutzer) erfüllt werden.
Tools wie rng-tools oder havaged sind nur Krücken und werden von einigen Sicherheitsforschern sehr kritisch beäugt.
Quellen [9], [10]
Jedenfalls ist die Lage ziemlich verzwickt, denn das Anwendungs-/Anforderungs-Spektrum von Linux ist inzwischen so groß, dass keine simple Lösung ausreicht, um das ganze Spektrum abzudecken. Standardmäßig verwendet Linux kein random seed file, wie etwa die BSDs es seit einiger Zeit tun. Hier spielen die BSDs ihren Vorteil aus, das ganze Basissystem zu kontrollieren und nicht nur den Kernel.
Immerhin bietet systemd inzwischen einen optionalen Dienst (systemd-random-seed), der das entsprechend umsetzt. Auch systemd-boot bietet hier ein Lösung an, beschränkt sich aber nur auf EFI-Systemen.
Quellen [11], [12], [13]
Zudem ist Linux RNG relativ langsam ggü. anderen Betriebssystemen. Es gab da mal einen Vortrag auf einer BSD-Konferenz, der Linux, FreeBSD und Windows (oder macOS?) verglichen hat. Leider finde ich den gerade nicht mehr.
Die Diskussionskultur in [1] finde ich teils sehr verbesserungswürdig. Wie unsachlich und unstrukturiert das Problem teils diskutiert und erörtert wird, ist beschämend - insbesondere in Anbetracht bereits existierender Lösungen. Da werden wild Annahmen aufgestellt, von Ideen um ernste Warnungen und Fehlermeldung vor den Anwendern zu verstecken fantasiert, spezielle Awendungsfälle ersonnen und gleichzeitig andere gänzlich ausgeblendet, allein um das jeweilig subjektive "Problem" zu benennen, natürlich beim Anderen.
Linux, die Linux-Distributionen und systemd bzw. die "Distro-Middleware" der Wahl haben hier noch viel zu tun!
Sehr gute Zusammenfassung. Vielen Dank.
Ob das so eine gute Idee ist da bin ich seit heute auch am zweifeln. Mir ist erst heute mein Rechner nicht hochgefahren, weil Systemd Swap nicht einhängen konnte, welches genau auf diese Weise verschlüsselt wird. Nach 2 Minuten sinnlosem warten während Systemd die Zeit hochzählte, habe ich dann die Reißleine gezogen und nochmal neu gebootet. Ging dann auch wieder. Nein, kein 5er Kernel. Muss das Verhalten mal weiter beobachten.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Sep 2019 um 20:19.