Fragen? Antworten! Siehe auch: Alternativlos
The course will be overseen and shaped by the Homeland Security Advisory Committee, a group consisting of government, academia and private sector employees who provide information and security-related recommendations to the DHS secretary. Of the many requirements, applicants are informed of their duty to meet with the committee on a regular basis."Staatsbürgerkunde" hätte man das in der DDR wohl genannt.
2. Akt: Die Polizei so: Jetzt können die Leute ihre Telefone aus der Ferne löschen, also brauchen wir verdeckten Zugriff auf die Telefone, am besten ohne Richteranordnung. Denn wenn die Leute merken, dass wir ihre Telefone ausspähen, dann löschen sie die ja aus der Ferne!1!!
Founding backers of the Initiative include Amazon Web Services, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Rackspace, VMware and The Linux Foundation.Yeah!
Update: Ich höre gerade aus gewöhnlich gut informierten Quellen, dass sich OpenBSD bei der Linux Foundation um diese Kohle bewirbt :-)
Und beim AKW Brokdorf gab es einen Kurzschluss.
Update: Ich verstehe gerade nicht, wieso ich keine Paywall kriege. Nanu? Wenn ihr eine kriegt, tut mir das leid. :) (Danke, Tilman)
Die Vorratsdatenspeicherung wird zum Streitthema zwischen Bund und Ländern. Während Bundespolitiker immer weiter von dieser Art der Verbrechensbekämpfung abrücken, sprechen Landespolitiker von einem „Verfolgungsvakuum“.
Ich halte bei solchen Regelungen für eines der Hauptprobleme, dass es so schwierig ist, irgendwann wieder damit aufzuhören. Exemplarisch kann man das an der Mädchenförderungen an deutschen Schulen beobachten, wo jetzt Jungen in der Bildung klar benachteiligt werden. Und an Unis kann sowas am Ende auch die Minderheiten benachteiligen, die so reingekommen sind, denn wenn die sich irgendwo bewerben, dann denkt sich die HR-Abteilung, dass der Bewerber der Abschluss gar nicht verdient hat und nimmt lieber jemanden, der nicht aus einer Minderheit kommt. Auch der Geförderte selbst weiß nie, ob er gerade eine gute Zensur kriegt, weil er gut war, oder weil man ihn fördern will. Das muss einen doch total fertig machen!
Die haben schon so viele Undercover-Spitzel, dass sie schon zu solchen Methoden greifen müssen, um noch mehr anzuwerben!
Update: Oh, es gab da noch zwei Updates dazu, inzwischen liegt das Schiff anscheinend in einem Hafen in Korea.
Die Zuger Regierung will die Steuerdaten in Zukunft durch das Tochterunternehmen einer amerikanischen Firma digital verarbeiten lassen.Was kann da schon schiefgehen!1!! (Danke, Alex)
Nun habe ich mir für meine SSL-Library gedacht, dass ich nur auf Systemen laufen werde, bei denen es /dev/urandom oder Äquivalent gibt, und nicht versuchen werde, da selber irgendwelche Entropie-Fummeleien zu machen. Das kann eigentlich nur nach hinten losgehen.
Aaaaaaber. Ein Kumpel von mir macht SSL auf einem Rechner, der nicht am Netz hängt, und eine Smartcard mit Hardware-RNG hat. Es gibt Smartcards mit Hardware-Zufall und einem kleinen ARM drauf. Habt ihr mal darüber nachgedacht, woher der Kernel den Zufall in /dev/urandom nimmt? Dafür nimmt man so Dinge wie das Timing zwischen Netzwerkpaketen und die Rotationslatenz von Festplatten. Timing von Tastatur- und Mauseingaben. Gibt es bei Smartcards alles nicht. Auf Smartphones gibt es Eingabegeräte aber keine Festplatten und bei den Netzwerkpaketen musst du davon ausgehen, dass sie ein Angreifer schickt, um deinen Zufall vorhersagen zu können.
Das ist ein echtes Problem in der Praxis. Gerade wenn ein Gerät frisch gebootet wurde, und die ganzen Krypto-Dienste hochfahren und Zufall für temporäre Schlüssel haben wollen. In solchen Fällen ist es wichtig, dass man den Zufallszahlengenerator irgendwie mit echtem Zufall seeden kann. Auch auf Servern mit SSD ist das ein Problem, wenn da keine Eingaben per Maus und Tastatur kommen.
Unter Linux kann man dafür einfach Daten nach /dev/random schreiben. Unter Windows gibt es zwar auch einen RNG in CryptoAPI, aber es gibt keinen Weg, da Zufall reinzuseeden. Die Sache mit dem Bildschirm-Auslesen ist natürlich echt ein Kracher. Aber da einfach die Möglichkeit wegzunehmen, externen Zufall reinzupipen, das macht LibreSSL für viele Anwendungen kaputt.
Übrigens, sowas wie ~/.rng kommt als Idee daher, dass man beim Runterfahren Entropie aus dem Pool ins Filesystem schreibt, damit man nach dem nächsten Hochfahren gute Entropie hat, wenn man ihn braucht. Das ist nicht per se eine doofe Idee.
Was ich sagen will: LibreSSL schießt sich hier gerade ziemlich massiv in den Fuß. Das sollte man dann auch erst mal ein paar Jahre aufhängen und reifen lassen, bevor man das einsetzen kann. Schade eigentlich.
Update: Mich weist gerade jemand darauf hin, dass das unter Windows doch auch geht.
Damit war nicht OpenSSL gemeint, sondern sowas wie X, perl, gcc. Aber OpenSSL fiel auch darunter, in dem Sinne, dass ich da eh noch andere Vorbehalte für einen Audit hatte. Und diese Policy hat dann dazu geführt, dass ich da auch nicht mal oberflächlich reingucken wollte.
Da ich angesichts aktueller Entwicklungen eh nicht gut schlafen kann mit OpenSSL gerade, habe ich mich entschieden, doch mal kurz einen Blick zu werfen.
Ich bin, gelinde gesagt, entsetzt. Schon die OpenBSD-LibreSSL-CVS-Checkin-Kommentare haben ja tief blicken lassen.
Es gibt so ein paar Kriterien, an denen ich bei C-Code meinen ersten Eindruck festmache. Das erste Kriterium ist, dass Längen und Offsets immer unsigned sein müssen, und vom Typ size_t. Früher hätte ich gesagt: unsigned long ist auch OK. Aber es gibt Plattformen, auf denen long 32-bit aber size_t 64-bit ist. 64-bit Windows z.B. Daher muss es size_t sein, nicht unsigned long. Und schon gar nicht long. Hier ist, was OpenSSL macht:
static int asn1_get_length(const unsigned char **pp, int *inf, long *rl, int max)Hier fallen ja schonmal als erstes die intuitiven Variablennamen auf. Da weiß man doch sofort, was gemeint ist! Ich kläre mal auf: Diese Routine soll einen ASN.1 DER Längenwert parsen. Das Encoding davon ist: Wenn das erste Byte das höchste Bit gesetzt hat, dann sind die unteren 7 Bits die Länge in Bytes für die Länge, die dahinter in big endian folgt. Wenn das erste Byte das höchste Bit nicht gesetzt hat, dann sind die unteren 7 Bits der Wert. Weil X.509 DER benutzt, gibt es zusätzlich noch die Regel, dass alle Längen minimal encoded sein müssen. Beispiele:
05 - Wert 5Meinem aktuellen Verständnis nach kann indefinite length bei X.509 nicht vorkommen, und ich unterstütze den Fall in meinen ASN.1-Routinen im Moment auch nicht sondern liefere einen Fehlerwert zurück. OpenSSL supported das. Möglicherweise übersehe ich da was. Wo ich aber nichts übersehe: OpenSSL prüft an keiner Stelle, dass das Encoding minimal ist. Der Effekt ist, dass man das identische Zertifikat auf mehrere Arten kodieren kann, und damit möglicherweise Angriffsfläche auf Krypto-Verfahren schaffen kann. Überhaupt sind Unterschiede zwischen Parsern immer doof, Differentiale will man an solchen Stellen vermeiden. Das ist jetzt kein "OMG RUN FOR THE HILLS"-Moment, aber wenn man schon eine zentrale Library macht für sowas, dann doch um da penibel solche Sachen abzufangen, damit die Leute das nicht alle von Hand machen und vergessen.
7f - Wert 127
81 01 - Ungültig, da nicht minimal encoded; wäre sonst 1
82 00 23 - Ungültig, da nicht minimal encoded; wäre sonst 35
82 12 34 - Wert 4660 (0x1234)
89 11 11 11 11 11 11 11 11 11 - Ungültig, da der 9-Byte-Wert nicht in einen Integer passt
0x80 - Sonderfall, "indefinite length".
Aber unabhängig davon. pp ist der Quell-Zeiger (das const ist ein gutes Zeichen, das wäre Kriterium 2 für das Erkennen von schlechtem Code gewesen). inf wird auf 1 gesetzt, wenn indefinite length encoding reinkommt. Ich finde, das hätte man direkt zurückweisen sollen. Indefinite length encoding funktioniert so, dass man am Anfang sagt, man weiß nicht, wie groß die Daten werden, die jetzt kommen, und dann schickt man halt so viele Daten wie halt kommen und dann zwei Null-Bytes. Ganz schlechte Idee, und habe ich in der Praxis auch noch nie im Einsatz beobachten können. Das ist ja gerade der Grund, wieso man ASN.1 DER einsetzt, damit man vorher weiß, wieviele Daten jetzt kommen werden. Und im Übrigen siehe oben zu den Parser-Differenzen. Das will man vermeiden.
Aber der eigentliche Punkt, auf den ich die ganze Zeit hinauswill: die Länge ist ein long. Das ist ein ganz schlechtes Zeichen. Die Routine versucht, das Schlimmste zu verhindern, indem sie als unsigned parsed und dann einen Fehler meldet, wenn der Wert größer als LONG_MAX ist. Und in der Tat, wenn sie das nicht gemacht hätte, hätte es im String-Parsing direkt einen schönen Buffer Overflow gegeben.
Ich habe jetzt jedenfalls ein schlechtes Gefühl bei OpenSSL und werde glaube ich erstmal die ASN.1-Routinen von PolarSSL auditieren, damit ich einen Fallback habe, wenn ich die ganzen Atommüllablagerungen in den Fracking-Schächten bei OpenSSL finde.
Update: Oh Graus, ich erfahre gerade, dass ich X.509 die ganze Zeit falsch verstanden hatte. Ich hatte das so verstanden, dass X.509 immer DER Encoding nimmt. Denn, mit Verlaub, alles andere ergibt auch gar keinen Sinn. Man will das ja in digitalen Signaturen verwenden. DER ist eine Teilmenge von BER, die genau den Zweck und die Daseinsberechtigung hat, dass man alles nur auf genau eine wohldefinierte Art kodieren kann. Begründung: Das braucht man so für digitale Signaturen. Und jetzt erfahre ich gerade, dass X.509 gar nicht DER sondern BER benutzt! Man soll das als Implementation anscheinend als BER parsen, dann soll man das als DER neu kodieren und dann die Signaturberechnungen machen!? Das kann ja wohl nicht wahr sein! Dann hätte OpenSSL Recht mit ihrem Code. Heilige Scheiße, wer denkt sich denn solche Standards aus!? In der Praxis habe ich noch nie was anderes als DER-Encoding gesehen. In meiner SSL-Library werde ich jedenfalls gleich beim parsen alles rejecten, das nicht DER ist.
Update: Interessanterweise macht OpenSSL es auch falsch, wenn BER Absicht ist.
173 if (i > sizeof(long))
174 return 0;
Update: Ein paar Hintergründe dazu.
Die EUROMIL (sozusagen die Gewerkschaft der europäischen Soldaten) veröffentlichte am 22.03.2007, dass bis zu diesem Zeitpunkt 109 italienische Soldaten, die 2003 im Irakkrieg (und anderswo z.B. jm Kosovo) eingesetzt waren, an den Folgen des Einsatzes von Uranmunition verstorben sind. Das sind 3,6% der 3000 im Irak eingesetzten italienischen Soldaten.(Danke, Uwe)
Ab Sommer könnten also Fingerabdrücke und DNA-Profile automatisiert abgefragt werden. Dies geschieht im sogenannten im “hit/no-hit-Verfahren”: Zunächst wird angeklopft, ob überhaupt Daten zu einem Profil vorliegen. Falls ja, werden die entsprechenden persönlichen Informationen geliefert. Hierzu gehören nicht nur Meldedaten, sondern unter Umständen auch weitere polizeiliche Erkenntnisse, darunter “politische Anschauungen”, die Mitgliedschaft in einer Gewerkschaft, Angaben zur Gesundheit oder zum Sexualleben. Selbst die Verarbeitung von Informationen zu “Rasse oder ethnische Herkunft” sowie “sonstige Überzeugungen” ist geregelt.Ich muss da irgendwo was missverstanden haben. Ich dachte, unser Staat hat die Aufgabe, unsere Daten vor dem Zugriff anderer zu schützen, nicht diesen Zugriff zu ermöglichen.
Update: Damit ist dann auch klar, wo das FBI die 52 Millionen Fotos für die Gesichererkennungsdatenbank herhaben will. Und in bester Qualität, da wir Deppen uns für unsere Pässe extra biometrische Fotos anfertigen. Damit das FBI weniger Stress hat.
Aber es gab da einen fetten Chemieunfall in West Virginia, wo sie dann aus einem Fluss die Giftbrühe abpumpen mussten. Wohin jetzt mit dem Zeug? Ihr werdet es schon ahnen: Ab in die Fracking-Löcher in Ohio mit der giftigen Brühe von dem Chemieunfall neulich!
Injection wells are considered the safest—or, put another way, the least worst—method of disposing of hazardous waste we don't want to dump in rivers or on land. The toxins aren't supposed to seep through impermeable rock layers. But as a in-depth ProPublica investigation into injection wells has revealed, it happens—even with Class I wells that are the most tightly regulated.Das deute ich mal so, dass die das schon länger machen, ihre Chemieabfälle so zu verklappen. Wer schonmal naturnahen Urlaub in den USA gemacht hat, dem wird bei so einer Meldung das Herz bluten.At two other Class I wells in Ohio, for example, the deadly chemical phenol had risen 1,400 feet through rock, threatening aquifers.
Update: Ich erfahre gerade, dass auch die DDR das so gemacht hat. Siehe auch.
Update: Auch im Westen war das Gang und Gäbe.
Lösung: Kanadische Regierung entfernt Buckelwale von der Liste der gefährdeten Tierarten, baut Pipeline.
The decision removes a major legal hurdle that the environmental group Ecojustice said stood in the way of the $7.9-billion Northern Gateway pipeline project that would bring 550,000 barrels of diluted bitumen crude from Alberta to Kitimat.
Teppich? Welchen Teppich? Na den Teppich mit dem "United Meritocracy of Github"-Bild drauf!
Warum? Na ist doch logisch! Meritocracy ist frauenfeindlich. Das wird ja wohl jeder sofort einsehen. Glaubt ihr nicht?
GitHub's Julie Ann Horvath, a designer who also founded the company's all-female lecture series Passion Projects, said the rug first became a problem when photos of it made their way into feminist discussions online.Checkt mal eure Privilegien, ey!
Update: Oha, die ursprüngliche Story wird mit dieser anonymen "anderen Seite der Geschichte" noch deutlich spannender. John Doe und Jane Doe sind die Namen, die die Polizei in den USA an Leichen ranschreibt, wenn sie noch nicht identifiziert wurden. Oder die Angeklagten bei Klagen gegen Unbekannt. Insofern muss man das als unbelegte Behauptungen sehen, aber das muss man ja auch mit der ursprünglichen Story machen. (Danke, Christian)
Na?
Kommt ihr NIE drauf!
Übrigens kamen noch ein paar spannende Mails zum Thema Medikamentenengpass rein. Einer erzählte, dass die Krankenkassen fette Rahmenverträge mit einem Hersteller machen, in der sie dann praktisch die gesamte Produktion kaufen. Die anderen gehen leer aus und fahren dann halt entsprechend ihre Produktion runter. Wenn dann irgendwo eine Fabrik eine Störung hat, dann gibt es halt keine anderen Marktteilnehmer gerade.
Jemand anderes schrieb mir, dass das nicht nur Impfstoffe betrifft, sondern auch durchaus mal Standard-Medikamente. Es gibt dann eben nur noch ein Werk, in dem das hergestellt wird, und wenn da gestreikt wird o.ä., dann ist halt Ausfall. Da kommt es dann vor, dass es zwar Ersatzmedikamente gibt, aber die haben nur EU-Zulassung, keine deutsche Zulassung. Das kommt sogar bei Antibiotika vor, meint er. Übrigens passiert es wohl auch gelegentlich, dass irgendwelche Zulassungs-Bedingungen verschärft werden, und sich das dann für die Hersteller nicht lohnt, wenn der Patentschutz (die Lizenz zum Gelddrucken) abgelaufen ist. Dann werden die halt aus dem Verkehr gezogen, obwohl sie wirksam und verträglich sind.
Update: Eine EU-Zulassung bedeutet automatisch auch eine Deutschland-Zulassung, schreibt mir gerade jemand anderes. (Danke, Lorenz)
Nach allem, was wir wissen, billigte der serbische Ministerpräsident das Attentat nicht und wusste allenfalls in vagen Umrissen davon. Er musste aber davon ausgehen, dass hohe Beamte und Offiziere seines Landes in die Tat verwickelt waren (was auch stimmte). Wenn er sie verriet, drohte ein Putsch. Entsprechend unkooperativ reagierte die Belgrader Führung auf die Wiener Ermittlungsbemühungen.Aus Angst vor Polizei und Geheimdiensten haben die also lieber einen Weltkrieg ausbrechen lassen. Whoa.
Update: Es hagelt per Mail Protest von Historikern. (Danke, Rico)
Ich persönlich halte DSA in allen Ausprägungen inzwischen für eine NSA-Hintertür und rate von der Verwendung ab. Der Grund ist, dass DSA so ausgelegt ist, dass man einen Zufallswert nimmt pro Operation mit dem geheimen Schlüssel, und wenn man zweimal den gleichen verwendet, dann fällt auf der anderen Seite der geheime Schlüssel aus einer vergleichsweise einfachen arithmetischen Umformung heraus. Das ist offensichtlich völlig unakzeptabel. Wie DSA überhaupt jemals soweit kommen konnte, dass es ein internationaler Standard wurde, erläutert djb in seinem Blog.
Kommen wir zu GCM. GCM ist der Galois Counter Mode. TLS hat einen Geburtsfehler, der seit vielen Jahren bekannt ist, und uns in letzter Zeit vermehrt auf den Fuß fällt. Nehmen wir mal an, Alice schickt Bob eine verschlüsselte Nachricht. Dann will man nicht nur, dass die Nachricht nicht von jemandem auf dem Weg gelesen werden kann, sondern auch, dass sie nicht verändert werden kann. Deshalb machen Protokolle wie TLS immer zwei Schritte: Verschlüsseln und eine Integritätssicherstellung. Dafür verwendet man sogenannte Message Authentication Codes, oder MAC. Dafür verwendet man häufig eine kryptographische Hash-Funktion mit einem beiden Seiten bekannten Geheimnis, aber man kann sowas auch anders konstruieren.
So, wenn man verschlüsseln will, verschlüsselt man dann erst und macht dann den MAC? Oder macht man erst den MAC und dann verschlüsselt man? Das war lange Jahre nicht so klar, ob das eine oder das andere besser ist. TLS macht erst MAC und verschlüsselt dann. Das hat über die Jahre zu einem Haufen an Bugs und Problemen geführt, so dass heute klar ist, dass man das besser anders herum machen sollte. Die IETF-Arbeitsgruppe zu TLS weiß das seit vielen Jahren, aber (u.a. durch Sandsack- und Betoniertätigkeiten der NSA) konnte sie sich noch nicht durchringen, da was zu tun. Das ist eine Schande für alle Beteiligten und sollte zu einem fetten Arschtritt für die NSA-Abgesandten führen — tat es aber bisher nicht.
Warum erzähle ich das alles? Weil jemand auf die Idee kam, "aus Performance-Gründen" Verschlüsselung und Authentication in einem zu machen, und zwar mit einem Verfahren namens Galois Counter Mode. Ein Mode ist eine Art, wie man einen Block Cipher wie AES aufruft. Das heißt Block Cipher, weil es nicht auf einem Bytestrom arbeitet, sondern auf Blöcken von Daten. Wenn die Daten keinen ganzen Block füllen, muss man am Ende mit sogenanntem "Padding" auffüllen. Da gab es schon Stress in TLS. Man kann jeden Block mit dem selben Schlüssel verschlüsseln ("ECB"), aber das ist eine ganz schlechte Idee. Wikipedia hat eine schöne Visualisierung anhand eines Pinguin-Bildes. Welchen Modus man benutzt ist also wichtig. ECB ist offensichtlich doof, daher haben wir halt alle immer CBC genommen. Das flog uns dann mit BEAST um die Ohren.
Übrig blieben Cipher-Suites auf Basis von RC4 (von dem wir inzwischen wissen, dass die NSA es in Echtzeit entschlüsseln kann) und GCM.
Warum ich das jetzt hier alles ausführe: GCM ist auch Scheiße. Das Paper dazu kommt von Niels Ferguson. Es sei noch angemerkt, dass man GCM in Software schon mal gleich so gut wie gar nicht ohne Timing-Probleme implementieren kann. Intel hat in ihren neueren CPUs Hardware-Support für GCM eingebaut, damit geht das dann. Aber fühlt sich damit jemand wohl?
Was können wir denn jetzt überhaupt noch tun? Wir können entweder warten, bis die TLS Working Group mal ihren Arsch hochkriegt und den offensichtlich notwendigen Schritt geht. Es gibt da Bemühungen, aber das kann sich noch um Jahre handeln. Die Situation ist gänzlich unakzeptabel.
Bleibt die Einsicht, dass uns gerade nur djb-Krypto überhaupt noch realistisch retten kann. djb hat als Konkurrenz zu ECDSA ein Verfahren namens ed25519 gemacht, das könnte den public key Teil abdecken. ed25519 wird u.a. in der neuesten Version von openssh unterstützt. Und als Ersatz für AES mit irgendwelchen grottigen Modi könnte man ChaCha20 einbauen. Das ist in Chrome schon eingebaut, aber hat es m.W. in noch keine einzige öffentlich verfügbare TLS-Library geschafft. Es ist alles zum Heulen.
Ich habe ja jahrelang nicht verstanden, wieso djb nie versucht hat, TLS zu fixen. Ich glaube, so langsam kann ich es nachvollziehen.
Update: CBC ist nicht an sich unsicher, sondern wie TLS 1.0 es angewendet hat. Ein Upgrade auf TLS 1.2 galt damals noch als unrealistisch, inzwischen ist es weitgehend vollzogen.
Update: Auch in Jena sucht die selbe Mona mit dem selben Text eine vergleichbare Wohnung.
