Update | Mit der Spiegelreflexkamera in die Cloud: Mein Fotoworkflow mit Eyefi Karte, Smartphone und Photos

Vor fast vier Jahren habe ich in dem Blogpost ‚Mit der Spiegelreflexkamera in die Cloud: Mein Fotoworkflow mit Eye-Fi Karte, Smartphone und Google+‚ meinen damaligen Workflow zum Umgang mit den Fotos beschrieben, die ich mit der Spiegelreflexkamera mache. Der Originaltext ist unten noch einmal angehängt, hier gibt es dazu ein kleines Update, was sich in der Zwischenzeit geändert hat – und was nicht:

Google+ ist heute Google Fotos

Weiterhin landen meine Fotos bei Google, nur das die Fotofunktion schon 2015 aus Google+ ausgegliedert und seit dem im spezialisierten Produkt Google Photos gelandet ist. Google Photos hat den Umgang mit den 100.000+ Fotos, die ich dort abgelegt habe, auf ein Level gehoben, welches noch vor wenigen Jahren kaum vorstellbar war:

Auf jedem Gerät, welches eine halbwegs brauchbare Internetverbindung hat, stehen mir meine Bilder der letzten ca. 20 Jahre in Sekunden zur Verfügung. Und selbst Suchen, die ich nie durch entsprechende Alben oder Fotobeschriftungen antizipiert habe, lassen sich meist schnell über die immer leistungsfähigere Bilderkennung durchführen.

Es ist schon Jahre her, seit ich das letzte Mal Fotos direkt vom Smartphone auf einen PC übertragen haben, heute läuft alles über Google Photos. Tatsächlich habe ich in diesem Moment wohl kein vollständiges Backup meiner Fotos zu Hause.

Weniger Bilder mit der Systemkamera, mehr mit dem Smartphone

Der Umgang mit Fotos, die nicht bereits auf dem Smartphone entstanden sind, ist in den letzten Jahren – zumindest wenn man die Anzahl der gemachten Fotos vergleicht – weniger wichtig geworden: Seit ich mir das Nexus 6P Ende 2015 zugelegt habe waren die Bilder, die vom Smartphone kamen, in vielen Fällen besser bzw. gefälliger als das, was die Systemkamera produzierte:

In diesem Album wird eine Reihe von Dämmerungsbildern des Nexus 6P mit Fotos der Sony Kamera verglichen. Man kann hier über die Farbtreue diskutieren, aber die meisten BetrachterInnen würde vermutlich die Bilder des Smartphones bevorzugen. Seit ich auf das Pixel 2 umgestiegen bin ist die Leistungsfähigkeit der Smartphonekamera noch weiter gestiegen.

 

Eyefi ist heute Keenai

Meine alte Eyefi Karte wird inzwischen nicht mehr richtig auf der Softwareseite unterstützt, und sie war auch nur 4 GB groß. Beim Neukauf einer Karte war ich zunächst verblüfft über die Stolpersteine, die einem bei der Inbetriebnahme dieses über Amazon als neu vertriebenen Produkts begegnen:

Alle – wirklich alle – Links, die man auf der Packung findet, landen auf nicht mehr funktionierenden Seiten. Es scheint, also sei die http://www.eyefi.com/ heute wenig mehr als ein Platzhalter für einige Werbebotschaften, aber ansonsten komplett von jeder Funktion entkleidet.

Sucht man dann im Play Store nach ‚eyefi‘ findet man keine einzige App, die auf den ersten Blick so aussieht, als sei sie eine offizielle App zu der Karte. Allerdings stellt sich dann der erste Treffer – die Keenai App –  tatsächlich als die richtige heraus. Und etwas googlen bringt einen dann zu dieser Meldung, die den Übergang von Eyefi auf Keenai erläutert.

Ist man so weit gekommen geht die Inbetriebnahme der neuen Karte über das Smartphone nichts mehr im Weg, im Gegensatz zum früheren Modell ist kein PC mehr notwendig. Die Registrierung in der Keenai Cloud habe ich dann direkt abgeschaltet, da mir die Funktionen keinen Nutzen bietet. Gefühlt geht die Übertragung der Fotos mit dem neuen Karte schneller, allerdings fällt das bei mir mit dem Wechsel auf das Pixel 2 zusammen.

Der Blogpost von Anfang 2014

Mit dem Start von Google+ und der genialen Möglichkeit quasi unbegrenzt viele Bilder in der Google Cloud abzulegen hat sich mein Umgang mit den selbst geschossenen Bildern komplett umgestellt: Das wichtigste Ziel ist es jetzt alle Bilder möglichst schnell zu Google+ zu schicken, denn das ist der Ort, an dem ich heute nahezu ausschließlich auf meine Bilder zugreife.

Bei den Bildern, die ich mit dem Smartphone mache, ist das geschenkt: Einfach die Option für die Automatische Sicherung aktivieren und der Rest geht – wie versprochen – automatisch. Bei den Bildern von meiner Spiegelreflexkamera bzw. neuerdings meiner Systemkamera geht es aber erst einmal nicht ganz so direkt. Den Workflow, den ich dabei für mich gefunden habe, möchte ich hier einmal beschreiben:

Man wird bequem

Der zunächst naheliegendste Weg wäre es die Bilder von der Kamera – wie früher auch – auf den PC zu kopieren und von dort zu Google+. Aber zum einen gibt es die automatische Google+ Foto Synchronisation für Windows PCs erst seit Mitte Dezember letzten Jahres. Zum anderen ist es erstaunlich, wie lästig einem das Hantieren mit Kabeln werden kann, wenn die ganze andere Kommunikation zwischen den Geräten erst einmal über das Netz bzw. die Cloud funktioniert. Auch ist das keine Lösung für den manchmal dringlichen Wunsch ein irgendwo im Wald gemachtes Foto gleich mit dem Rest der Welt auf Instagram oder Google+ teilen zu wollen.

Die Lösung: Eye-Fi

Meine Lösung für alle diese Bedarfe: Die Eye-Fi WiFi-SD-Karte. Diese Karten bauen ein eigenes WLAN auf, sobald sie mit Strom versorgt sind, und das Smartphone kann über eine vom Hersteller mitgelieferte App eine Verbindung aufbauen. Über diese Verbindung werden die Bilder direkt übertragen und liegen dann auf dem Smartphone, (fast) so wie die direkt mit dem Phone gemachten Bilder.

Als zusätzlichen Bonus kann die Smartphone App die Bilder noch mit GPS Tags versehen, sofern man der App gestattet entsprechende Daten zu sammeln und die Uhren von Phone und Kamera synchron sind. Es reicht also auch eine ganz ‘dumme’ Kamera zu verwenden, ohne eigene WiFi- und GPS-Funktion.

Mein Workflow von A-Z

Und so sieht dann mein Workflow ganz konkret aus:

  1. Mit der Kamera werden viele tolle Bilder geschossen.
  2. Entweder schon während des Shootings oder auch erst später, falls das Smartphone gerade nicht in Reichweite sein sollte, werden die Bilder übertragen und von der App mit GPS Tags versehen.
  3. Die Bilder landen dabei in einem Ordner, der nicht von der automatischen Sicherung der G+ App erfasst wird. Das scheint sich nicht ändern zu lassen, gibt mir aber eine Gelegenheit eine Sichtung durchzuführen und die Bilder gleich zu verwerfen, die unbrauchbar sind. Auch könnte ich nun schon die ersten Bilder bearbeiten und online stellen. Meine Bildbearbeitung hat sich heute fast komplett auf das Smartphone verlagert. [UPDATE: Mit der heutigen Version der Google+ App kann man auch andere Ordner auf dem Smartphone automatisch hochladen lassen. Ich habe aber bisher meinen manuellen Workflow beibehalten.]
  4. Danach verschiebe ich die verbliebenden Bilder in den Ordner, in dem die Smartphone Kamera ihre Bilder speichert. Ich nutze dazu Quickpic, die Foto App, die es bisher immer auf meine Android Smartphones geschafft hat.
  5. Die Bilder werden dann zu Google+ hochgeladen, sobald ich wieder ein WLAN erreicht habe.
    Nach dem Hochladen sortiere ich einige Bilder über die Google+ Fotos App – die sich in den letzten Monaten unglaublich gemacht hat – in bestimmte Ordner, so dass auch die Organisation der Bilder gleich über das Smartphone erfolgt.
  6. Alle paar Monate mache ich schließlich ein komplettes Backup der Bilder von meinem Smartphone. Das ist heute das einzige Mal, dass ich einen normalen PC verwende. Auch dabei habe ich es mir angewöhnt kein Kabel mehr zu verwenden, ich hole mir die Bilder per WLAN mit der AirDroid App.

Für mich ist das im Moment ein nahezu optimaler Ablauf.

Die Nutzung der Eye-Fi Karte war für mich auch beim gerade erfolgten Neukauf einer Kamera ein Argument dafür auf teure Zusatzfunktionen wie integriertes WiFi und GPS zu verzichten.

Die ZKI veröffentlichen ihre Prozesslandkarte für Campusmanagement

Von den ZKI – Zentren für Kommunikation und Informationsverarbeitung e. V. – gibt es schon seit einiger Zeit ein interessantes Dokument, welche den Versuch unternimmt eine geschlossene Landkarte für die Prozesse aufzustellen, die beim Thema Campusmanagement bzw. Campus Management Systeme relevant sind. Jetzt kann man die letzte Version hier herunterladen:

https://www.zki.de/zki-nachrichten/einzelbeitrag/1746/

Das ZKI beschreibt die Ziele und den Anwendungsbereich des Dokuments dabei so:

Ein Hauptziel der ZKI-CM-Prozesslandkarte ist es, die Reflektion, Optimierung und Weiterentwicklung der hochschuleigenen Prozesse im Kontext von Campus-Management zu unterstützen. Sie soll dabei helfen, dass komplexe Zusammenspiel von Haupt-, Teil- und Unterprozessen so weit zu reduzieren, dass das Auffinden und Ausführen von Prozessen möglich wird, ohne den Blick auf die gegenseitigen Abhängigkeiten zu verlieren. Das vorliegende Dokument ist dabei so angelegt, dass es von jeder Hochschule an die eigenen Rahmenbedingungen, Anforderungen und Hochschulabläufe angepasst werden kann.

Insgesamt macht der Text einen sehr guten Eindruck, auch wenn sich im Detail idealisierte Prozessvorstellungen finden lassen, die im realen Betrieb einer Hochschule nur schwer durchzuhalten sein werden.

Steht eine Hochschule vor der Auswahl eines Campus Management Systems kann die Prozesslandkarte mit ihrer weit gefassten Definition des Student Life Cycle ebenfalls eine Hilfe sein, auch wenn es bei der Bewertung eines konkreten Produkts weniger darauf ankommt bei möglichst vielen Stationen des Life Cycles ein Häkchen setzen zu können, als darum Aspekte wie die innere Integration, die Offenheit und die Durchgängigkeit des Datenmodells zu bewerten.

Wie man einen Laptop für die Softwareentwicklung auswählt (oder auch nicht)

Angeregt von Ayo Isaiahs Artikel ‘How to choose the right laptop for programming’ schreibe ich hier einmal auf wie es ausgegangen ist, als ich mir zur Jahreswende die gleiche Frage stellte. Und am Ende bei etwas komplett anderem gelandet bin, als ich mir eigentlich vorgestellt hatte. Die Geschichte dazu findet vielleicht der ein oder andere unterhaltend. Oder sieht sie als warnendes Beispiel 😁

Was ich (glaubte) zu wollen

Ich suchte einen Laptop als privates Gerät für kleinere Softwareentwicklungsprojekte. Warum einen Laptop? Weil ich schon seit mehr als 15 Jahren auf solchen Geräten entwickle. Bei den ersten Suchen im Netz waren dabei meine Schlagworte meist so etwas wie ‘Dev Laptop’, ‘16GB’, ‘Linux’, ‘SSD’. Und irgendwie landete ich dabei immer wieder bei Dells XPS Reihe und ihren äußerst positiven Rezensionen wie hier von The Verge.

Vielleicht hat mich dann dieses wunderschöne Gerät allmählich auf die ’schiefe Bahn’ gebracht und nach und nach den ästhetischen Aspekt in den Vordergrund treten lassen: Hat man sich erst einmal in ein so flaches Gerät mit nahezu randlosem, sehr hoch auflösendem Display verliebt wirken Produkte, die eigentlich deutlich pragmatischer sind, plötzlich blass und uncool. Und es gibt sogar Versionen mit Linux drauf. Auch das ich in den Jahren zuvor viel Zeit auf einem MacBook verbracht habe hat sicher dazu geführt, dass ich auf keinen Fall irgendeine ‘Klapperkiste’ erwerben wollte.

Was ich dann tatsächlich erwarb

Leider gab es ein Problem mit der XPS Reihe: Schönheit hat ihren Preis und in der Ausstattungslage, die ich mir vorstellte, gab es nichts unterhalb von eineinhalb tausend Euro. Zu viel für ein Gerät, welches im Haushalt neben Smartphone, Pixel C Tablet samt Tastatur, verschiedenen Chromebooks, dem MacBook und einem alten Windows Laptop würde um seinen Platz kämpfen müssen.

Nachdem ich daher lange in Schnäppchen- und Kleinanzeigenseiten vergeblich darauf gewartet hatte ein günstiges (Gebraucht)Gerät zu finden war klar, dass es kein XPS werden würde. Da inzwischen aber schon so viel Zeit vergangen war wurde es Zeit für einen Spontankauf. Von einem Kollegen auf den in Münster beheimateten Gebrauchtgerätehändler Lapstore gebracht ging es dann ganz schnell: Durch die von der XPS Fixierung erzeugt Fokussierung auf gutes Aussehen und eine dünne Bauform schlug ich dann bei einem Lenovo Yoga 600 Ultrabook zu. Natürlich in der goldenen Variante:

Lenovo Yoga Ultrabook

Und wie gut erfüllt nun das Gerät meine ursprünglich formulierten Ansprüche? Hier halte ich mich grob an die Kategorien, die Isaiah gewählt hat:

Mobilität

Das ist einer der wenigen Punkte, bei denen ich mir treu geblieben bin: Ich wollte ein Gerät, welches eher mobil als extrem leistungsfähig ist. Das habe ich mit diesem Ultrabook erreicht: Der Bildschirm ist ausreichend groß, aber nicht zu groß, es ist sehr, sehr flach und man kann in jeder Tasche Platz dafür schaffen, in dem man die c’t herausnimmt. Die dann später – als die ersten Kratzer aufgetreten waren – beschaffte Filzhülle macht das Gerät ca. doppelt so dick, aber es ist immer noch sehr flach.

Display

Das Display ist kraß. Für mich ist es der erste Laptop mit einer Auflösung, die der schon lange von Smartphone und Tablet gewohnten nahekommt (QHD+). Braucht man das? Vielleicht nicht, und die hohe Pixeldichte macht auch manchmal Probleme, z. B. bei einigen Java Anwendungen, die ohne Anpassungen in winzigen Schriftgrößen daher kommen. Aber wenn es klappt, dann sieht es sehr, sehr gut aus.

Es ist auch mein erster Windows Laptop mit Touchscreen. Ich habe mich früher oft verächtlich über den Sinn eines Touchscreens in Geräten mit fest eingebauter Tastatur geäußert und zwar in dem Sinne, warum man ein Bedürfnis haben sollte den Bildschirm unnötigerweise mit seinen Fingerabdrücken zu besudeln?

Tatsächlich bemerkte ich in den letzten Jahren aber immer häufiger, dass ich unbewusst damit begann auf allen möglichen Bildschirmen herum zu wischen, einfach weil inzwischen die Mehrzahl der benutzten Geräte (Smartphone, Tablet, Chromebook) das bot. Ich könnte auch weiterhin ohne die Touchfunktion leben, aber gelegentlich ist sie – z. B. beim Lesen langer Texte bzw. beim Surfen – einfach praktisch.

Bei der Gelegenheit auch ein Wort zur Möglichkeit das Display komplett herum zu klappen und damit das Gerät in ein klobiges Tablet zu verwandeln: Das habe ich ein einziges Mal gemacht, für mich ist es ein wenig nützliches Gimmick. Allerdings nutze ich tatsächlich recht häufig die damit verbundene Möglichkeit das Display extrem flach anzustellen, z. B. wenn ich auf dem Laptop etwas lese.

Was mich tatsächlich an dem Bildschirm insgesamt nervt sind die sehr starken Spiegelungen. Gerade die Chromebooks, die ich meist zum Schreiben langer Texte verwende, sind alle matt, und bei dem MacBook ist es mir nie so störend aufgefallen. Vielleicht liegt es bei Yoga daran, dass nicht nur der Bildschirm spiegel, sondern auch der schwarze Rand drumherum. Das ist wirklich unnötig.

CPU & Lüfter

Erst als der Lüfter des Yoga zum ersten Mal ansprang und sich lange nicht mehr ausschalten wollte fiel mir ein, dass ich jahrelang Geräte genutzt habe, die entweder:

  • keinen Lüfter hatten,
  • so gut belüftet waren, dass er nie anspringen musste oder
  • deren Lüfter unhörbar leise war.

Keiner dieser Punkte trifft auf das Yoga zu und gerade die manchmal stundenlangen Windows 10 Updates verbringt das Gerät gerne mit einem unangenehmen Dauergepuste aus den schicken Luftauslässen:

Lenovo Yoga Ultrabook

Nervig. Bei der für mich normalen Entwicklungsarbeit (Java, Eclipse) hingegen verhält er sich zum Glück meist ruhig.

Die CPU ist eine i5. Reicht für mich und ein i7 hätte die Lüfter- und Batterieprobleme vermutlich noch weiter verschärft.

RAM

Ich bin dann doch bei nur 8 GB gelandet. Für mich reicht es, da ich im Moment doch nicht so viel mit VMs hantiere, wie zunächst gedacht. Die fehlende Erweiterungsoption könnte mich hier aber vielleicht einmal einholen.

Harddisk

Natürlich eine SSD, aber nicht besonders groß. Was OK für mich ist, meine ganzen Fotos lagern sowieso nicht lokal auf den PCs und ich lade mir bei der bescheidenen Internetverbindung hier auch nicht jeden Tag gewaltige Datenmengen herunter.

Das Gerät hat manchmal sekundenlange Aussetzer, in denen ‘nichts’ passiert, und irgendwie bringe ich das mit der SSD in Verbindung. Allerdings ohne es bisher beweisen zu können.

Tastatur & Trackpad

Die Tastatur ist tatsächlich für mich – neben dem nervigen Lüfter – das größte Problem: Lenovo hatte die blöde Idee an den rechten Rand, also neben Return und Backspace, noch eine Tastenspalte zu quetschen und zwar mit so wichtigen Tasten wie Pos1, Ende, Page up/down. Alle, wirklich alle Geräte, die ich sonst nutze, haben keine derartigen, überflüssigen Tasten an dieser Stelle. Wie sehr sich mein Gehirn angewöhnt hat bei der Suche nach Löschen, Zeilenumbruch und Shift einfach den rechten Geräterand mit den Fingern zu suchen und dann auf die ersten dort vorgefundenen Tasten zu klicken ist mir sehr schnell klar geworden.

Lenovo Yoga Ultrabook

Länger hat es gedauert bis klar war, dass sich mein Gehirn nicht so ohne weiteres umprogrammieren lässt, jedenfalls nicht, solange ich die anderen Geräte weiter nutze. Was ich tue. Und so verfluche ich das Yoga und die Designer seiner Tastatur bis heute, wenn ich meine ersten Zeilen eingebe und beim ersten Versuch ein falsches Zeichen zu löschen am Zeilenanfang lande.

Das Trackpad ist hingegen OK, wobei ich inzwischen einfach größere Pads gewohnt bin und die hier gewählte Aufteilung zwischen einer Seite für ‘linken Mausklick’ und einer für ‘rechten Mausklick’ unsinnig und irritierend finde.

Batterie

Laut Prospekt ‘mehr als 8 Stunden’. Aber das ist gelogen. Für mich ist das Yoga kein Gerät, mit dem man einfach morgens ohne Ladegerät aus dem Haus gehen und sicher sein kann nicht irgendwann in Probleme zu geraten. So wie es beim MacBook der Fall ist.

Gerade am Anfang war das Yoga schockierend schnell leer, z. B. wenn man ein Windows Update machte, weitere Software installierte und nebenher normal damit arbeitete. Gleichzeitig ist das Ladegerät ein echter Klotz, den man nicht mitschleppen möchte.

Betriebssystem

Kein Linux, sondern Windows 10. Auch hier haben sich die Folgen der Ästhetik gezeigt: Für die Laptops mit den extrem schlanken Bauformen und aktuellen Bauteilen ist die Treiberlage einfach schlecht und selbst wenn man es schaffen sollte darauf ein Linux zum Laufen zu bringen kann man nicht damit rechnen die gleiche Performance – z. B. bei der Batterielebensdauer – zu erreichen wie unter Windows.

Und im Grunde gefällt mir Windows 10 wirklich gut: Schicke Oberfläche, weit moderner für meinen Geschmack als das, was Apple heute hat, wenn auch natürlich nicht so aufgeräumt wie das Material Design, welches in ChromeOS nach und nach Einzug hält. Und die Sünden und Fehler aus Windows 8 wurden zum größten Teil rausgeworfen oder minimiert.

Und Linux kann man in ganz unterschiedlichem Umfang für Entwicklungszwecke ja trotzdem bekommen, wenigstens wenn einem die Kommandozeile im wesentlichen ausreicht: Abgesehen von der klassischen VM gibt es seit einiger Zeit von Microsoft das sogn. Linux Subsystem, welches einem die Bash bringt. Und für etwas weniger anspruchsvolle Zwecke reicht vielleicht auch schon die Cmder Shell aus.

Aber, aber….

…wieso ich das Gerät behalten habe, trotz der ganzen nervenden Punkte? Vielleicht hätte ich es wirklich zurückgeben sollen, insbesondere wegen der Tastatur. Allerdings dachte ich damals noch, dass ich mich daran bestimmt gewöhnen würde.

Und auf der anderen Seite ist das Gerät für meinen Geschmack wirklich, wirklich schön. Wer hat nicht gern Werkzeug, welches (auch) gut aussieht? Dadurch zieht das Yoga immer mal wieder interessierte KollegInnen an und sorgt für Diskussionen 😆 Das Gehäuse hat eine hohe Steifigkeit, die bei einem so dünnen Gerät verblüfft, und dem Metallgehäuse des MacBooks nicht nachsteht.

Aber würde ich es noch einmal kaufen? Vermutlich nicht. Denn beim nächsten Kauf hätte ich diese Prioritäten:

  1. Das Gerät sollte weiterhin eine gewisse Eleganz und Schlankheit haben (ja, ich kann da nicht aus meiner Haut)
  2. Die Tastatur muss zu mir passen bzw. meinen Gewohnheiten entsprechen, das Trackpad sollte möglichst groß sein
  3. Der Bildschirm muss nicht matt sein, aber er sollte auch nicht so extrem stark spiegeln. Touch ist OK, aber kein MUSS
  4. Wenn schon Lüfter, dann bitte leise oder selten genutzt
  5. Der Akku sollte einen durch den Tag bringen

Ansonsten natürlich eine gewisse Grundleistungsfähigkeit (SSD, RAM, etc.). Diese Liste führt eigentlich automatisch dazu, dass man das Gerät ein paar Tage nutzen muss, da sich gerade die Frage ob man in der Lage ist sich auf bestimmte Eigenarten einzustellen, oder ob sie ein dauerhafter Stein des Anstoßes sein werden, sonst kaum beurteilen lässt.

BoringSSL und die FIPS 140-2 Zertifizierung

Vor inzwischen mehr als 3 Jahren verkündete Adam Langley in seinem Blog den Beginn der Arbeiten an BoringSSL, einem Fork von OpenSSL, der speziell auf die Anforderungen von Google zugeschnitten ist. Anlass waren die verschiedenen Probleme in SSL/TLS Implementierungen, insbesondere der Heartbleed Bug in OpenSSL, der damals für viel Aufsehen sorgte. Mit BoringSSL schuf Google sich eine bereinigte SSL/TLS Implementierung, die schon knapp ein Jahr später in die großen Google Produkte Chrome & Android einging und zum Betrieb der Google Services im Netz verwendet wurde. Für Google ist das Projekt offenbar ein Erfolg, da sie damit endlich eine einheitliche Basis für diesen sicherheitsrelevanten Code schaffen konnten, die sie nach eigenem Gutdünken weiterentwickeln können.

Ist BoringSSL eine Alternative?

Wer OpenSSL einsetzt, oder LibreSSL, den anderen damals entstandenen Fork, kann sich die Frage stellen ob ein Library, welches von Google entwickelt wird, vielleicht die bessere Alternative ist? ‘Besser‘ ist dabei ein Adjektiv mit mehreren Aspekten, darunter Rückwärtskompatibilität (mit OpenSSL), Stabilität, Sicherheit, Codereife, Funktionsumfang und Lizenzierung. Google stellt auf der BoringSSL Seite dazu diese Hinweise direkt an den Anfang:

“BoringSSL is a fork of OpenSSL that is designed to meet Google’s needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don’t recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.”

Das kann man nicht gerade als aktives Werben um neue NutzerInnen verstehen. In jedem Fall muss man damit rechnen einen gewissen ’Preis’ für die Nutzung eines leistungsfähigen, von einem hochkompetenten Entwicklerteam weiterentwickelten Pakets zu bezahlen, und zwar in Form vorzuhaltender eigener Entwicklerkapazitäten, damit man im Fall von Änderungen an BoringSSL in den eigenen Produkten entsprechend nachsteuern kann. Auf der anderen Seite ist heute das Risiko eines kompletten Refactorings von BoringSSL wohl eher gering, dazu ist selbst Google nicht mehr so ohne weiteres in der Lage angesichts von Millionen – oder gar Milliarden – von Android Geräten, die sich nur schwer aktualisieren lassen.

Seit ein paar Tagen gibt es eine neue Seite im BoringSSL Repository, die das Thema der FIPS Validierung behandelt. Dabei geht es nicht um das komplette Projekt, sondern um einen Teilbereich, genannt BoringCrypto. Dies könnte für Unternehmen, die nur entsprechend zertifizierte Produkte einsetzen dürfen (Finanzbereich, etc.), noch einmal einen Stolperstein bei der Nutzung beseitigen. Aber was ist FIPS 140-2 eigentlich und verbessert es wirklich die Sicherheit von BoringSSL?

Was ist FIPS 140-2 und was macht es ‘sicher’

Der ‘Federal Information Processing Standard (FIPS) Publication 140-2’ ist ein Standard der US Regierung, der – ausgeführt vom NIST – Anforderungen an kryptographische Module sowohl in Hardware wie auch Software definiert. Er legt damit verbindlich fest welche Anforderungen an entsprechende Module gestellt werden (z. B. in Form einer Liste der notwendigen/zulässigen kryptographischen Algorithmen) und auch das Verfahren, über das Anbieter entsprechender Produkte diese Zertifizierung erhalten können. Dabei wird in 4 Level unterschieden, die jeweils immer höhere Anforderungen stellen, z. B. in Bezug auf die Verhinderung bzw. Feststellung von Manipulationsversuchen.

Dieser Standard ist neben den Common Criteria wohl der wichtigste IT Sicherheitsstand weltweit. Eine FIPS Zertifizierung erhöht damit die Sicherheit eines Produkts in jedem Fall. Oder?

Die Snowden Enthüllungen

Eine Anforderung im FIPS Zertifizierungsprozess ist die Garantie, dass eine zertifizierte Software sich selbst auf Konsistenz prüfen kann. Siehe dazu im letzten Abschnitt mehr. Dies kann nur auf eine Weise erreicht werden, die man aus heutiger Sicht nicht mehr unbedingt als letzten Stand der sicherheitsbewussten Programmierung sehen muss. In der BoringSSL Seite zu FIPS findet sich daher an einer Stelle der Satz

‘This might make building ROP chains easier for an attacker, but so it goes.’

Ein weiterer Kritikpunkt – der z. B. in der entsprechenden OpenSSL Seite vorgebracht wird – ist die Langsamkeit des Zertifizierungsprozesses. Nun braucht eine sorgfältige Zertifizierung ihre Zeit, aber auf der anderen Seite ist es heute wichtiger denn je bei gefundenen Fehlern schnell Bugfixes verbreiten zu können. Denn selbst nach einer Zertifizierung ist es unwahrscheinlich, dass jeder einzelne Fehler gefunden wurde. Wenn aber eine Fehlerkorrektur dann eine erneute Zertifizierung erforderlich macht vergehen schnell mal einige Monate. In dieser Zeit haben Angreifer dann ausgerechnet in den Industrien mit besonderen Sicherheitsanforderungen, die zur Nutzung FIPS-zertifizierter Lösungen gezwungen sind, ggf. leichtes Spiel.

Ein letzter, massiver Kritikpunkt entsteht allerdings aus dem mit den Snowden Enthüllungen massiv gewachsenen Misstrauen gegen die US-Geheimdienste und ihre Verquickungen mit den Standardisierungsbehörden. Insbesondere betraf dieses Misstrauen damals einen in den Standard gebrachten Algorithmus zur Generierung von Zufallszahlen, der immer schon von Kryptographen misstrauisch beäugt worden war, sich nun aber als sehr wahrscheinlich mit einer bewusst konstruierten Hintertür versehen erwies. Durch die langsamen Standardisierungsprozesse war es dann ein sehr zeitaufwändiger Prozess diesen Algorithmus aus Produkten zu entfernen, bis dahin schlummerte er als potentielles Einfallstor in den als ‘sicher’ zertifizierten Produkten.

Insgesamt ist die Sache also ein zweischneidiges Schwert, und für EntwicklerInnen eines Libraries wie BoringSSL immer mit der Frage verbunden was ihnen wichtiger ist: Ein Produkt zu entwickeln, welches nach den bekannten Maßstäben der IT Sicherheit ganz vorne ist, oder zusätzlichen, teilweise bürokratischen Aufwand auf sich nehmen um am Ende bei einem möglicherweise in Teilaspekten weniger sicheren Produkt zu landen, welches dafür dann aber in besonders sicherheitsbedürftigen Bereichen eingesetzt werden – und dort vielleicht andere, weniger gut gepflegte Lösungen verdrängen – kann. Oder den Aufwand noch weiter zu erhöhen und parallele Stränge des eigenen Produkts zu pflegen, die beiden Anforderungen gerecht werden.

Wie macht man Software FIPS kompatibel

Aber nun wieder zurück zu der Frage welche Anforderungen eigentlich entstehen, wenn man eine C/C++ Programmierung mit den FIPS Vorgaben in Einklang bringen will?

‘FIPS-140 mandates that a module calculate an HMAC of its own code in a constructor function and compare the result to a known-good value. Typical code produced by a C compiler includes large numbers of relocations’

Wie man diesen Spagat löst, darüber geht der größere Teil der BoringSSL Seite und er erklärt auch recht gut wie ein C/C++ Compiler im Detail vorgeht und welche Dinge man ihm abgewöhnen muss, damit dieses Ziel erreichbar wird. Möglicherweise haben die Google Leute hier nur damit begonnen die Erfahrungen nachzuhalten, die sie entweder selbst gemacht haben oder große Android Nutzer wie Samsung (PDF), die auf BoringSSL basierende Komponenten bereits in den FIPS Prozess eingebracht haben.

Zwei Jahre Android Security Rewards – Was hat sich verändert?

Vor nun zwei Jahren hat Google mit den Android Security Rewards sein spezielles Bug-Bounty-Programm für Android gestartet. Kurz bevor mit den ersten Stagefright Sicherheitslücken die Kritik an der damaligen, desolaten Sicherheitslage Androids ein Allzeithoch erreichte. Im Android Entwicklerblog hat Google nun ein Fazit dazu gezogen, wie sich die Situation seit damals entwickelt hat. Der Post ist recht kurz, aber trotzdem in seinen Details interessant:

Android Update - Rot

Ein steter Strom von Bugreports

Man kann wohl sagen, dass dieses Bug-Bounty-Programm heute funktioniert: Im letzten Jahr sind mehr als 450 Reports eingegangen. Es vergeht damit wohl kaum ein Tag bei Google, an dem nicht eine Fehlermeldung eintrifft. Das ist zunächst einmal ein echter Erfolg, auch wenn daraus natürlich Schlagzeilen entstehen wie z. B. diese hier: „Android Was 2016’s Most Vulnerable Product.

Da Google den Android Quellcode im Android Open Source Project (AOSP) veröffentlicht kann sich hier faktisch jedeR an der Fehlersuche beteiligen und damit Geld und Anerkennung verdienen. Und tatsächlich tut dies eine große Zahl von Leuten.

In gewisser Weise bestätigt Android damit das von Open Source Verfechtern gern ins Feld geführte Argument, wonach die Offenheit auch gleichzeitig für eine bessere Sicherheit sorge, weil eben viele Menschen ohne große Hürden nach Fehlern suchen können. Auf der anderen Seite zeigt aber der Erfolg des Bug-Bounty-Programms auch was für ein wichtiger Faktor der finanzielle Anreiz sein kann. Dieser Anreiz fehlt bei vielen Open Source Projekten.

Mehr Geld, mehr Bugreports?

1,1 Millionen Dollar hat Google laut dem Bericht in den letzten 12 Monaten ausgeschüttet, was einer durchschnittlichen Summe von mehr als 10.000$ pro Sicherheitsforscher entspräche. Natürlich gibt es Personen / Gruppen, die durch besonders viele Meldungen herausstechen, Google selbst hebt hier das C0RE Team hervor, welches allein 118 Reports eingereicht und dafür 300.000$ erhalten hat.

Die höchsten Belohungsstufen wurden dabei aber bisher nicht erreicht, Google hebt diese Belohnungen nun auf das 4- bzw. 5-fache der bisherigen Werte. Damit könnte man nun 6-stellige Summen allein für einen einzigen Bugreport erhalten.

Google steht hier – wie heute alle großen IT Unternehmen – in starker Konkurrenz zu staatlichen Stellen aus aller Welt, die für ihre Geheimdienste nach ‚Cyberwaffen‘ Ausschau halten und sich dazu privater Dienstleister bedienen, für die die Suche nach Einbruchsmöglichkeiten in populäre Software zu einem profitablem Geschäft geworden ist. Hier kann man mit einem funktionierenden Exploit in das weltweit meistgenutzte Betriebssystem vermutlich noch weitaus höhere Gewinne erzielen.

Das ein hoher Belohnungspreis ein Bug-Bounty-Programm nicht automatisch erfolgreich machen muss hat der gescheiterte Versuch von Googles Project Zero gezeigt: Dieses wollte mit dem Project Zero Price ein eigenes Programm auf die Beine zu stellen, welches ebenfalls 6-stellige Summen für hochwertige Angriffe auf Android in Aussicht stellte. Es erhielt aber keine einzige relevante Einreichung und wurde wieder eingestellt.

Ein breiter aufgestelltes Programm wie die Android Security Rewards kann da durchaus erfolgreicher sein, auch wenn bzw. gerade weil seine Belohnungsstaffelung bei deutlich kleineren Summen beginnt: Dadurch erhöht sich die Zahl der beitragenden ForscherInnen und der Versuch einzelne Fehler zu horten, bis sie sich zu einem leistungsfähigeren Exploit kombinieren lassen, ist dann mit dem großen Risiko verbunden, dass jemand anderes einen der Fehler findet, die Belohnung erhält und Google die Lücke schließt.

Welche Geräte sind für sicherheitsbewusste Android NutzerInnen kaufbar?

Im Oktober 2015 – gezwungen durch das Stagefright Debakel – entschied sich Google einen lange überfälligen Schritt zu machen: Damals begann das Programm der monatlichen Android Sicherheitsupdates. Bis dahin gab es den absurden Zustand, in dem Google Meldungen über Sicherheitslücken zwar einsammelte, aber faktisch niemand zeitnah davon profitieren konnte. Durch die neuen Updates waren zuerst nur die direkt von Google kontrollierten Android Geräte wieder auf einem akzeptablen Sicherheitslevel, aber allmählich auch die Produkte einiger anderer Hersteller.

Android Upate

Und auch darüber gibt der aktuelle Blogpost Auskunft: Bei welchen Herstellern von Android Geräten ist meine Chance groß, dass diese zeitnah Sicherheitsupdates bekommen? Google sagt dabei zum einen dies:

Over 100 device models have a majority of their deployed devices running a security update from the last 90 days

Die dann gezeigte Tabelle mit konkreten Geräten lässt trotz ihrer etwas anderen Semantik (‚This table shows the models with a majority of deployed devices running a security update from the last two months‘) eigentlich nur einen Schluss zu: Wer keines der wenigen direkt von Google kommenden Gerät kaufen kann oder will, der sollte zu einem Samsung Gerät greifen. Samsung hat mit Abstand die größte Zahl von Geräten in dieser Liste und kann damit wohl als Vorbild bei der Updatepolitik gelten (wobei es hier wohlgemerkt nicht um Updates der Android Version geht, dass ist noch mal ein ganz anderes Thema).

Fazit: Auf dem richtigen Weg (aber der Weg ist noch weit)

Google ist es augenscheinlich gelungen ein lebendiges Umfeld von Sicherheitsforschern zu schaffen, die zur Android Sicherheit beitragen. Die ausgeschütteten Summen – auch wenn es sich dabei inzwischen um einen Millionenbetrag handelt – sind dabei vermutlich immer noch ‚günstig‘. Muss man das Fazit ziehen, dass Android angesichts der weiterhin hohen Zahl von monatlichen Fehlerkorrekturen besonders unsicher ist?

Das finde ich schwer zu beurteilen, auch andere (Betriebs-)Systeme haben durchaus ansehnliche Zahlen an korrigierten Fehlern vorzuweisen und faktisch ist jeder korrigierte Fehler einer weniger, den jemand anderes schon im Geheimen gefunden und ausgenutzt haben könnte. Nur falls auch in den kommenden Jahren die Zahl der in Android gefundenen Fehler so hoch bleibt wäre das ein sicheres Zeichen, dass mit der Codebasis bzw. der Weiterentwicklung etwas grundsätzlich nicht in Ordnung ist.

Weiterhin das größte Problem des Android Ökosystems ist aber das Fehlen von Updates für die Masse der inzwischen mehr als 2 Milliarden Geräte. Auch wenn Google die ‚mehr als 100 Modelle‘ nicht genau benennt, bei denen die Mehrheit der NutzerInnen wenigstens ein maximal 3 Monate altes Sicherheitslevel erreicht hat, kann man auf Grund der Vielzahl von Android Geräten – siehe die immer wieder gern zitierte Auswertung von OpenSignal aus dem Jahr 2015 – davon ausgehen, das dies nur ein Bruchteil der in aktiver Nutzung befindlichen Geräte ist.

Auch hier muss es die Zeit erst zeigen, ob die Seamless Updates, die mit Android N eingeführt wurden, und die in Android O mit dem Project Treble geplante stärkere Separierung von Betriebssystemteilen in der Lage sein werden eine signifikante Verbesserung zu bringen. Angesichts der gewohnt langsamen Ausbreitung neuer Android Versionen kann man von diesen Verbesserungen aber bestenfalls in einigen Jahren einen sichtbaren Effekt erwarten.

Bis dahin wird es wohl insbesondere den im Hintergrund von Google durchgeführten Prüfungen im Play Store und auf den Endgeräten überlassen bleiben Angriffe zu verhindert.

restart.sh – Ein Bash Script für zuverlässige Server Restarts

Auf Github ist jetzt ein kleines Bash Script zu finden, welches einen einfachen Zweck verfolgt: Als Teil eines Cronjobs soll es einen Serverprozess zuverlässig neu starten können. Anlass war ein Server, der alle paar Tage eine Instabilität entwickelte, die sich nicht ohne weiteres beheben lies. Der regelmäßige Neustart ‚behebt‘ das Problem, auch wenn er natürlich nur eine Krücke ist. Aber manchmal geht es eben nicht besser…

Ziel des Scripts

Der Script solle in der Lage sein diese Funktion auszuüben:

  1. Den relevanten Prozess finden
  2. Wenn der Prozess läuft das reguläre Stopkommando ausführen
  3. Abwarten, bis sich der Prozess normal beendet. Im konkreten Anwendungsfall brauchte der entsprechende Server für einen regulären Shutdown an die 30 Sekunden
  4. Es darf nicht unendlich lange gewartet werden, um auch bei einem dysfunktional gewordenen Prozess einen Neustart ausführen zu können. Auf der anderen Seite soll der Neustart möglichst rasch erfolgen, sobald sich der Prozess normal beendet hat
  5. Neustart des Prozesses

Implementierung

Das Script restart.sh setzt die Anforderungen mehr oder weniger 1-zu-1 um:

  1. Suchen der PID des Prozesses über ein eindeutiges Muster in der Prozessliste
  2. Wenn die PID gefunden wurde ‚freundliche‘ Beendigung durch das normale Stopkommando (welches vielleicht nur ein „kill $PID“ ist)
  3. Beginn eines Countdowns, bei dem regelmäßig – z. B. jede Sekunde – geprüft wird ob der Prozess noch aktiv ist
  4. Wenn der Countdown eine maximale Laufzeit erreicht wird ein „kill -9 $PID“ abgesetzt und der Prozess damit gewaltsam beendet
  5. Absetzen des Startkommandos und Beendigung des Scripts

Eigentlich eine sehr einfache Funktion, aber ich hatte im Netz nichts gefunden, was mir genau diese Funktion bot.

Inbetriebnahme

Die Implementierung ist unter MacOS erfolgt, auf anderen unixartigen Plattformen sind vielleicht kleine Anpassungen notwendig, insbesondere in Hinblick auf die Verarbeitung der Ausgabe des ps Kommandos. Zusätzlich muss der Prozessname angepasst werden und die Wartezeit, die maximal zulässig sein soll. Siehe dazu die Kommentare in restart.sh.

Um erste Tests ohne Aufwand durchführen zu können wird dummy.sh verwendet. Das ist ein lange laufendes Script, welches sich nicht durch ein einfaches kill beenden lässt. Dazu dummy.sh in einem Terminal starten, restart.sh in einem zweiten und sehen wie sich beide Scripts verhalten.

https://github.com/ihbrune/Restart.sh

Remember my name: Werner Heisenberg

Einer der Podcasts, auf die ich erst kürzlich gestoßen bin, ist Forschergeist. Und über die Folge 34, in der Tim Pritlove mit Ernst Peter Fischer spricht, bin ich wieder an den großen Physiker Werner Heisenberg erinnert worden, dessen Todestag sich in 2016 zum vierzigsten Mal gejährt hat. Was mich nach dem Hören dieser Sendung besonders interessiert hat ist die Frage warum Heisenberg im Vergleich zu anderen Physikern dieser Zeit – insbesondere Einstein, aber auch Schrödinger  – heute einen eher geringen Bekanntheitsgrad hat. Selbst nach dem kurzen Popularitätsschub, der vor einigen Jahren aus einer überraschenden Ecke kam.

Der (etwas) anstrengende, aber inspirierende Podcast

Der Podcast ist hörenswert, er skizziert das Leben und die wesentlichen Stationen von Heisenbergs Wirken in der Zeitspanne zwischen dem Ende des ersten Weltkriegs und dem Ende der Nazizeit. Naturgemäß wird stark auf die entscheidenden Entdeckungen eingegangen (Weiterentwicklung des Atommodells, Unschärferelation), die das Fundament der heutigen Quantenmechanik legten, und die anderen berühmten Personen, mit denen Heisenberg in dieser Zeit in Kontakt steht (Bohr, Pauli, Born, Einstein und viele andere). Tim Pritlove hat mit Ernst Peter Fischer einen Gesprächspartner, der ungeheuer enthusiastisch ans Thema herangeht: Wäre Heisenberg ein heutiger Popstar und Fischer ein 16-jähriger Teenager würde man ihn vermutlich als Groupie oder Fanboy bezeichnen.

Werner_Heisenberg

Fischer – der zahlreiche Bücher zur Wissenschaftsgeschichte geschrieben hat – bemüht sich sehr Heisenberg mit seinen persönlichen Eigenschaften wie der Liebe zur Natur und zur Musik zu zeichnen und ihn so zu ‘vermenschlichen’, also den genialen Physiker, der eine mit anschaulichen Begriffen kaum beschreibbare Theorie entwickelt hat, auf eine Ebene zu holen, auf der man ihn und seine Motivation verstehen kann auch ohne Leistungskurse in Mathematik und Physik besucht zu haben. Dabei zeigt er eine außerordentliche Detailkenntnis.

Was den Podcast dann insgesamt etwas anstrengend macht sind zwei Dinge: Zum einen ist da Peters Fähigkeit ohne Punkt und Komma reden zu können. Selbst Pritlove als im Umgang mit Nerds und Geeks erfahrener Podcaster braucht da etwas bis er wieder in der Lage ist das Thema wo nötig voranzutreiben und die manchmal zu romantisierende Darstellung Heisenbergs zu hinterfragen. Und das ist der zweite Punkt, der zumindest mich beim Hören zunehmend gestört hat:

Peters scheint dem Objekt seiner Bewunderung im Laufe der Zeit so nahe gekommen zu sein, dass es ihm schwer fällt eine kritische Distanz an den Stellen einzunehmen, wo sie vielleicht angesagt wäre. Besonders fällt dies im Teil zu Heisenbergs Verhalten in der Nazizeit auf, bei dem Peters ohne direkten Anlass eine Art ‘Verteidigung’ von Heisenberg vom Stapel lässt, die in der absurden Aussage gipfelt, dass Heisenberg diese Zeit im wesentlichen am schönen Walchensee verbracht habe und dass jeder, der diesen See schon mal gesehen habe, einsehen müsse, dass man da garnicht mehr an Politik (und Krieg und Atombomben und massenhaften Mord) habe denken können.

Das macht den Podcast am Ende etwas unrund, da es den Verdacht weckt hier würde etwas unterschlagen und im Nachhinein hätte man an dieser Stelle sicher einiges mehr unterbringen können, z. B. den ‘Uranverein’, der in der Kriegszeit versuchte die Kernspaltung im Nazideutschland voranzubringen, die Anfeindungen, die Heisenberg von der sogn. ‘Deutschen Physik’ ertragen musste und die gescheiterte Reise zu Bohr nach Kopenhagen, mit der Heisenberg offenbar versuchte die Physiker der Welt zu einem gemeinsamen Verzicht auf eine Forschung an Atomwaffen zu bewegen, und die in einem gründlichen Missverständnis endete.

Aber letztlich haben mich diese Unstimmigkeiten dann dazu gebracht das Thema weiter zu verfolgen:

‘Der Teil und das Ganze’: Heisenbergs Erinnerungen

Der naheliegende Ansatzpunkt um mehr über Heisenberg zu erfahren ist sein Buch ‘Der Teil und das Ganze – Gespräche im Umkreis der Atomphyik’, welches im Jahr 1969 erschien. Dieses Buch ist keine (Auto)Biographie im eigentlichen Sinne, man erfährt daraus z. B. nicht, dass Heisenberg im Jahr 1932 der Nobelpreis verliehen wurde. Auch ist es kein Buch voller Formeln, tatsächlich kommen faktisch keine Formeln vor. Und trotz des Titels, der ja schon von Gesprächen spricht, war die Form dann eine Überraschung für mich: Zumindest anfänglich besteht der Text meist aus fiktiven Dialogen mit verschiedenen Weggefährten, die Heisenberg bis zu vier Jahrzehnte später rekonstruiert um die ihm wichtigen Punkte zu verdeutlichen. Dabei kann ich für mich zwei Schwerpunkte ausmachen:

Über Begriffsbildung in Physik und Philosophie…

Der größte Teil des Buches ist – natürlich – Themen aus der Atomphysik gewidmet. Heisenberg befand sich in jungen Jahren mitten einer Phase der Physik, in der die klassischen Beschreibungsmodelle nicht mehr so recht ausreichten um neu entdeckte Vorgänge in der Nähe des Atomkerns zu erklären. Nicht einmal warum Atome nicht direkt wieder zerfallen und wieso sie sich in den von den Chemikern schon lange beschriebenen Weisen miteinander zu Molekülen verbinden.

Heisenberg gelingt es hier – während eines durch einen Allergieschub erzwungenen Aufenthalts auf Helgoland im Jahr 1925 – die bisherigen Denkmuster abzuschütteln und ein allein an den vorhandenen Versuchsergebnissen orientiertes neues Modell zu entwickeln, welches zu einer der Grundlagen der Quantenmechanik wird. Zwei Jahre später ergänzt er die nach ihm benannte Unschärferelation, die der Genauigkeit von Messungen unterschiedlicher Eigenschaften eines Teilchens eine prinzipielle Grenze setzt, die sich auch nicht durch verbesserte Apparaturen oder Versuchsaufbauten unterschreiten lässt.

Das Jahrzehnt von 1920 bis 1930 nimmt dementsprechend einen großen Raum ein in ‘Der Teil und das Ganze’, wird aber nicht so behandelt, wie man es von einem Physiker vielleicht erwarten würde (wie zumindest ich es erwartet habe): Statt aus Zahlenreihen und Formeln und Verweisen auf wissenschaftliche Arbeiten zu bestehen ist dieser Teil des Buchs eigentlich ein durchgehender philosophischer und erkenntnistheoretischer Diskurs, aufgelockert durch einige persönliche Anekdoten zu den Orten und Umständen, an denen Heisenberg für ihn wichtige Erkenntnisse gewann.

Heisenberg – und seine Dialogpartner, denen er die Worte in den Mund legt, die diese nach seiner Erinnerung vielleicht gewählt hätten – sprechen immer wieder über die Frage inwieweit sich Begriffe aus der anschaulichen Welt, die wir mit unseren Sinnen erfassen können, eigentlich noch tauglich sind um sich über die merkwürdigen Aussagen der Quantenmechanik zu verständigen. Und wenn sie nicht tauglich sind, wie sollen sich dann Physiker untereinander eigentlich darüber verständigen?

Dieser Teil macht auch die intensiven Diskussionen zwischen den Physikern sichtbar, die oft zunächst nur Theorien diskutieren oder Konstrukte, mit denen sich zwar immer besser rechnen und immer mehr Dinge erklären (oder nur errechnen?) lassen, für die aber die menschliche Anschauung keine rechten Bilder liefern will.

…zur Frage der persönlichen Rechtschaffenheit in schwierigen Zeiten

In anderer Hinsicht interessant ist dann der Teil, der sich mit der Nazizeit beschäftigt: Heisenberg bleibt in Deutschland und stellt dies als bewusste Entscheidung dar, die er u. a. durch Gespräche mit Planck gefunden habe. Abgesehen von der politischen Lage sehen sich die Physiker durch Otto Hahn’s Entdeckung der Kernspaltung im Jahr 1938 sehr schnell vor diese Fragen gestellt:

  1. Wie kann damit einen ‘Supersprengstoff’ bauen?
  2. Ist es moralisch vertretbar beim Bau einer Atombombe mitzuwirken?

Beim ersten Punkt unterläuft den in Deutschland verbliebenen Physikern ein merkwürdiger Fehler, der die entsprechenden Forschungen in eine Sackgasse treibt. Beim zweiten Punkt können die Beteiligten vor sich selbst und der Nachwelt zu der Ausrede greifen, dass Nazideutschland im Krieg gar nicht die industriellen Ressourcen gehabt habe, die für den Bau einer solchen Waffe notwendig sind.

Man muss dabei den Punkten, die Heisenberg für sich und andere vorbringt, nicht folgen. Aber man erhält im Buch einen Einblick in diese Zeit, die es einem erlaubt vor einer Verurteilung Heisenbergs und der anderen darüber nachzudenken, wie man sich wohl selbst verhalten hätte.

Auch der letzte Teil des Buches – der die Nachkriegszeit in der noch jungen Bundesrepublik behandelt – widmet sich sehr stark dem Verhältnis von Atomphysik und Politik, dieses Mal zunächst in der Frage der zivilen Nutzung der Kernspaltung, dann aber auch der heute fern wirkenden Diskussion über eine nukleare Aufrüstung der Bundeswehr, in welcher der ‘Atomminister’ eine wichtige Rolle spielt.

Warum ist Einstein so viel berühmter?

Im Podcast beklagt Fischer die – aus seiner Sicht ungerechtfertigte – geringe Präsenz Heisenbergs im öffentlichen Bewusstsein, insbesondere im Vergleich zu Einstein. Diesen Eindruck kann man sich im Netz leicht bestätigen lassen, z. B. über die Google Trends:

Google_Suchetrends_seit_2004_Heisenberg_Einstein_DE

 

Hier zeigt die rote Linie die aus Deutschland kommenden Suchen nach ‘Einstein’ und die blaue nach ‘Heisenberg’. Der Abstand ist immer enorm. Ein ähnliches Bild zeigt sich im Ngram Viewer von Google Books:

Google_Ngram_Heisenberg_Einstein

Diese Anzeige ist auf deutschsprachige Publikationen beschränkt, aber selbst hier kommen die beiden Linien sich nur ein einziges Mal nahe und zwar mitten im 2. Weltkrieg, als Einstein in Nazideutschland zum Feindbild aufgebaut wurde. Als letzter Test mag die Google Bildersuche dienen: Während man beim Suchbegriff ‘Albert Einstein’ etliche Bilder findet, die wohl fast jedem auf Anhieb bekannt sind…

Google_Suche_Albert_Einstein

..ist das bei der Suche nach ‘Werner Heisenberg’ nicht der Fall:

Google_Suche_Werner_Heisenberg

Aber warum ist das so? Sind die Entdeckungen Einsteins wichtiger als die von Heisenberg? Wenn man die Wichtigkeit als Einfluss auf unser heutiges Leben definiert, dann ist die Quantenmechanik – für die Heisenberg entscheidende Grundlagen geschaffen hat – als Basis für die heutige Elektronik möglicherweise wichtiger als die Entdeckungen Einsteins, denn bald wird jeder Mensch über sein Smartphone und das Internet mit den Resultaten in Verbindung stehen.

Allerdings sind die Effekte der Quantenmechanik so kompliziert zu erklären, siehe die langen Diskussionen, die selbst die besten Physiker ihrer Zeit in ‘Der Teil und das Ganze’ darüber führen, dass Normalsterbliche kaum eine Chance haben zu verstehen worum es dabei geht. Am bekanntesten ist da vermutlich noch das Gedankenexperiment von Schrödinger, welches als ‘Schrödingers Katze’ bekannt geworden ist, und das eigentlich ein Lächerlichmachen der Aussagen der Quantenmechanik darstellt, in dem es ihre Ausssagen in die makroskopische Welt überträgt, wo sie nichts verloren haben.

Hingegen haben Aspekte von Einsteins Relativitätstheorie wie die Zeitdilatation vielfältigen Eingang in die Popkultur wie die Science Fiction gefunden: Ganze Romane wie ‘Der ewige Krieg’ bilden ihre Handlung um diesen Effekt ab und machen ihn damit vermutlich für viele Menschen ‘erlebbarer’ als die merkwürdige Welt der Elementarteilchen.

Bei Einstein kommt aber vermutlich noch viel stärker zum tragen, dass er zu einer Art prototypischem Genie stilisiert wurde und das bis heute: Will man jemanden als hochintelligent bezeichnen, so nennt man sie/ihn einen Einstein. Vergleichbares ist mit Heisenberg nie passiert.

Heisenberg und ‘Breaking Bad’

Der Bekanntheitsgrad des Namens ‘Heisenberg’ hat allerdings seit 2009 eine interessante Steigerung erfahren: In diesem Jahr startete in den USA die zweite Staffel der Serie Breaking Bad. Dort legt sich der Protagonist Walter White für seinen Einstieg in den Drogenhandel das Alias ‘Heisenberg’ zu und verbreitet fortan Angst und Schrecken (und erfährt selbst ein gerüttelt Maß davon). Die Serie hat auch in Deutschland großen Erfolg und für einige Zeit einen wesentlichen kulturellen Einfluss, was sich zum Beispiel daran ablesen ließ, dass Breaking Bad Themen damals den regelmäßigen Posterverkauf in der Uni Bielefeld dominierten:

BreakBadPosterverkauf

Es bleibt abzuwarten, ob dadurch der Name ‘Heisenberg’ einen dauerhaft gesteigerten Bekanntheitsgrad erreichen und wenn ja welche Assoziationen er dabei auslösen wird: Drogen oder Quantenmechanik? Das Ergebnis der Google Bildersuche zum Wort ‘Heisenberg’ hat die Serie jedenfalls schon nachhaltig beeinflusst:

Google_Suche_Heisenberg

Sinn und Unsinn von Stagingkonzepten

Der CommitStrip bringt es auf den Punkt:

I’m not sure wether I should feel proud, or worried..
CommitStrip vom 10.02.2017: ‚Proud or worried?‘

Bis zu welchem Grad ist der Aufbau von Staging Umgebungen nützlich, und ab wann ist die Stelle erreicht, ab der der Betrieb und die Komplexität zu viel kosten? Oder umgekehrt: Wann lohnt es sich eigentlich ein Staging einzuführen, wenn man – wie wir – bisher keines hat?

Warum wir (bisher) kein Staging haben

Tatsächlich haben wir in dem umfangreichen Softwareprojekt, welches ich leite, bisher gar kein echtes Staging, faktisch gibt es nur das produktive System und die jeweiligen Entwicklungssysteme. Warum das bei uns so funktioniert würde ich mit diesen Punkten erklären:

Softwarequalität

Das beste Argument gegen ein Staging ist sicher eine hohe Softwarequalität: Wenn (fast) nie Fehler passieren (oder sie niemand bemerkt, weil sie so schnell behoben werden), dann wird auch niemand nach zusätzlicher Qualitätssicherung rufen. Die Softwareentwicklung wird bei uns von einem kleinem Team geleistet, welches teilweise schon sehr lange im Thema ist und dementsprechend erfahren ist. Häufige Releases mit entsprechend kleinen Entwicklungsschritten vereinfachen die Qualitätssicherung, da sie die Komplexität der einzelnen Schritte deutlich reduzieren. Die häufigen Releasezyklen werden durch eine Aufteilung des Produkts (hier ein Campusmanagementsystem) in viele Teilmodule erreicht, die weitgehend unabhängig voneinander sind (trotz einer in weiten Teilen gemeinsamen Codebasis).

Agilität

Bei uns fallen Softwareentwicklung und Serverbetrieb zusammen. Wenn es tatsächlich Fehler in die Produktion schaffen sind wir handlungsfähig und machen meist gar kein Rollback, sondern erstellen direkt eine neue Version mit entsprechender Fehlerkorrektur. Möglich ist dies durch eine Serverstruktur, die es erlaubt zu jeder Zeit für die Benutzer unmerkliche Updates durchzuführen, die nicht lange geplant oder angekündigt werden müssen.

Freigabeprozesse

Die Zuständigkeiten für das Produkt und die inhaltlichen wie technischen Kompetenzen für die Weiterentwicklung sind bisher nahezu komplett im Team gebündelt. Bei neuen Releases müssen daher nur selten Freigaben durch Key User eingeholt werden. Und falls doch, so wird dies auf den Entwicklungssystemen in direktem Kontakt gemacht. Da wir ein hausinterner Dienstleister sind und sich unsere Ansprechpartner in räumlicher Nähe befinden können wir so vorgehen.

Java

Das ‚Java Versprechen‘, wonach eine auf einer Plattform entwickelte Software auch problemlos auf einer anderen laufen wird, hat sich für uns weitgehend erfüllt: Heute findet die Entwicklung unter Windows statt und verwendet eine PostgreSQL Datenbank, während das produktive System unter Solaris und einer anderen relationalen Datenbank betrieben wird. Insgesamt gab es in der langen bisherigen Projektlaufzeit nur extrem selten Probleme, die sich auf den Entwicklungssystemen nicht nachstellen ließen. Diese wenigen Probleme waren so komplex, dass eine Nachstellung in einer Staging Umgebung mit einem enormen Aufwand verbunden gewesen wäre.

Backup

Um das Risiko von fatalen Fehlern, die es in die Produktion schaffen sollten, zu minimieren, ist ein leistungsfähiges und zugreifbares (!) Datenbankbackup essentiell. Mit fatalen Fehlern meine ich dabei solche, die Datenbankinhalte vernichten oder unmerklich korrumpieren. Ein solches Backup muss bei einer komplexen Anwendung in der Lage sein ohne großen Aufwand jederzeit Teildaten in verschiedenen Versionsständen zu liefern.

Unittests

Man kann nie genug automatisierte Tests haben, aber an bestimmten entscheidenden Stellen haben wir sie und können damit auch nach Systemänderungen sicher sein, dass diese Programmierungen noch korrekt funktionieren. 

Was einem das Staging verleiden kann

Es gibt viele Gründe Staging Konzepte einzusetzen, einen guten Teil nennt der Comic Strip bereits: Entwicklungssysteme, Testsysteme mit verschiedenen Zielsetzungen, Demosysteme, Freigabesysteme, etc. Und in den meisten Konstellationen wird man auch nicht ohne Staging auskommen. Was einem an der ganzen Sache den Spaß verderben (oder die Aufwandskalkulation für die entsprechenden IT Abteilungen nach oben treiben) kann, sind dann u. a. diese Punkte:

Wer kümmert sich um die Server?

Auch wenn es ‘nur’ ein interner Testserver ist: Irgendjemand muss ihn warten. Wird er nicht gewartet, so ist er ein zukünftiges Einfallstor für Angreifer, selbst wenn er sich tief in internen Netzen befindet. Mit jeder Stage wächst die Zahl der Server, um die sich irgendjemand kümmern muss. Falls man den Versuch unternimmt Stages aufzubauen, die der produktiven Umgebung sehr nahe sind, kann die Zahl der zusätzlichen Server enorm werden, vor allem wenn für verbundene Systeme wie Datenbanken, Identity Provider etc. ebenfalls entsprechende Staging Umgebung aufzubauen sind. Gut, wenn man hier schon eine Automatisierungslösung im Einsatz hat, die dies vereinfacht.

Echtdaten für Stages

Schnell wird man bei dem Wunsch landen in nicht-produktiven Stages die Daten des Produktivsystems zur Verfügung zu haben. Solche Daten(und ggf. Konfigurations-)kopien anzulegen erzeugt mindestens initial Aufwände für die Inbetriebnahme.

Wenn es sich um personenbezogene Daten handelt wird man sich zusätzlich den Fragen der Datenschutzbeauftragten stellen müssen. Und landet schnell bei einem Schutzbedarf der nicht-produktiven Stages, der dem Schutzbedarf der produktiven Stages in nichts nachsteht, denn auch von solchen Stages können sensible Unternehmensdaten abhanden können. Alternativ müssen Pseudonymisierungsverfahren entwickelt werden, damit die Echtdaten so unkritisch werden, dass sie auch in weniger geschützten Umgebungen genutzt werden können.

Wenn man es irgendwie vermeiden kann (Unittests, Generierung realistischer Testdaten) sollte man die Echtdatenübernahme in andere Stages vermeiden.

Enttäuschte Erwartungen I: Key User

Bei einer starken Aufgabenteilung zwischen IT Betrieb und Key Usern entsteht gelegentlich die Erwartung der IT, dass die Key User neue Versionen einer Software über eine für sie bereitgestellte Stage ausgiebig testen und damit in gewisser Weise die ‘Verantwortung’ übernehmen, dass die Software korrekt funktioniert. Die Frage ist allerdings inwieweit diese Erwartung realistisch sein kann? Key User, die per Definition ExpertInnen in dem fraglichen Themenfeld sein müssen, sind erfahrungsgemäß sowieso in ihren Abteilungen stark belastet und werden Besseres zu tun haben als neue Releases systematisch zu testen. Funktionieren kann so ein Konzept höchstens wenn es darum geht Weiterentwicklungen im Einzelfall abzunehmen. 

Enttäuschte Erwartungen II: Lasttests

Ein weitere Enttäuschung droht im Bereich von Lasttests. Gerade bei neuen, unbekannten Systemen kann der Wunsch entstehen die notwendige Dimensionierung der Infrastruktur vorher durch synthetische Belastungstests ermitteln zu wollen. Hier gibt es zwei grundlegende Schwierigkeiten:

  1. Wie erzeuge ich realistische Lasten? Bei einem schon laufenden System kann ich versuchen in den vorhandenen Protokollierungen Nutzungsmuster zu finden, die mir ein Testdesign ermöglichen. Bei Systemen mit vielen Nutzern kann es trotzdem schwierig sein die gefundenen Nutzungsmuster in realistischer Weise in einem Test auszuführen (wie simuliere ich Zugriffe von tausenden von Clients aus unterschiedlichen Netzen?).
  2. Wie erzeuge ich eine realistische Staging Umgebung? Bei einem System, welches sich im Aufbau befindet, kann ich vor der Inbetriebnahme die produktive Stage für entsprechende Tests verwenden. Nach der Inbetriebnahme ist das natürlich kaum noch möglich. Eine Stage für realistische Lasttests aufzubauen kann eine Duplizierung weiter Teile der unterstützenden IT Infrastruktur erfordern und lässt einen schnell bei der Forderung nach Echtdaten landen.

Im Endeffekt hat man ein hohes Risiko kein angemessenes Ergebnis für den erbrachten, erheblichen Aufwand zu erhalten. In vielen Fällen wird man vermutlich besser fahren, wenn man seine Systemarchitektur so aufstellt, dass auf unerwartete Lasten rasch reagiert werden kann. Dies ist mit heutigen Virtualisierungskonzepten auch normalerweise problemlos möglich.

Warum wir vermutlich doch (irgendwann) ein Staging haben werden

Aber auch für uns wird sich das Thema ‘Staging’ in Zukunft neu stellen. Ein wichtiger Treiber ist dabei die Idee Deployments unseres Produktes in Zukunft automatisieren zu können (CI/CD).

Everyone has a test environment. some are lucky enough to have a production environment too
@stahnma auf Twitter am 22.08.2015

Ein erster Schritt in diese Richtung wäre daher eine ‘Demo- oder Reviewstage’, die automatisiert die jeweils aktuell in der Versionskontrolle befindlichen Versionen unserer Anwendungsmodule verwendet, so dass sie sich schnell vorführen und prüfen lassen. Ggf. könnte man hier auch gleich weiter denken und diese Stage für verschiedene Branches verfügbar machen.

Ein anderer Treiber ist die durch Organisationsveränderungen fortschreitende funktionale Differenzierung im IT Betrieb, die die Serveradministration in andere Hände legen wird. Auch hier ist möglicherweise ein Staging ein Mittel um sowohl die Produktqualität, die Handlungsfähigkeit und die Releasegeschwindigkeit hoch halten zu können.

Google baut eine eigene Root-CA auf

Vor ein paar Tagen hat Google in seinem Security Blog bekannt gegeben selbst zu einer Zertifizierungsstelle (Certificate Authority / CA) zu werden. Diese kann man unter der Adresse https://pki.goog/ erreichen. CAs sind heute entscheidende Stellen in der Public Key Infrastructure (PKI) des Webs, die erst die sichere Kommunikation z. B. zwischen Webbrowser und Webserver ermöglichen.

Welches Problem will Google damit für sich lösen?

Google ist zum einen ein Unternehmen, welches einen enormen Bedarf an Zertifikaten hat, der durch zwei Faktoren bedingt wird:

  1. Die schiere Anzahl der zu sichernden Onlinedienste
  2. Googles schnelle Zertifikatsrotation, die Zertifikate heute nach 3 Monaten auslaufen lässt

Dann hat Google das Thema der IT Sicherheit wie kaum ein zweites Unternehmen im Blick und treibt es an allen Ecken voran, auch im Bereich der Zertifizierungsstellen. Gleichzeitig sind Google Zertifikate oft das Ziel bei Kompromittierungen von Zertifizierungsstellen, da Googles Dienste nun mal von vielen Nutzern besucht und damit für Angreifer besonders wichtig sind.

Google hat hier  in den letzten Jahren über seine Marktmacht mit Chrome als dominierendem Webbrowser und Android als dominierendem Mobilbetriebssystem immer mal wieder kräftig an den Zügeln gezogen, wenn eine CA Mist gebaut hat.

Was stimmt nicht mit mit dem heutigen System der Zertifizierungsstellen?

Das heute existierende System der Zertifizierungsstellen ist in der Lage unsere Webbrowser-Webserver-Kommunikation gegen massenhaftes Abhören zu sichern, wenigstens seit es Initiativen wie Let’s encrypt gibt, die Serverbetreibern die dazu notwendigen Zertifikate kostenfrei und mit geringem Aufwand automatisiert zur Verfügung stellen können. Die Verschlüsselung ist aber nur der eine Aspekt bei einer PKI: Der andere ist die Sicherstellung der Authentizität meines Kommunikationspartners. Damit ist gemeint, dass ich – wenn ich z. B. auf ‘https://www.google.com’ gehe – auch tatsächlich direkt auf einer zu Google gehörenden Webseite lande, und nicht auf einer gefälschten Seite bzw. über einen mithörenden Mittelsmann kommuniziere.

Hier kommen die CAs ins Spiel, die mir garantieren sollen, dass das Zertifikat, welches mir beim Besuch von google.com präsentiert wird, auch tatsächlich Google gehört. Eine CA kann dabei ihre Aufgabe nur erfüllen, wenn sie es schafft mit ihren Wurzelzertifikaten in die gängigen Webbrowser und Betriebssysteme aufgenommen zu werden. Damit ihr das gelingt muss sie ihre Sorgfalt bei der Vergabe von Zertifikaten beweisen.

So weit, so gut. Ein grundlegendes Problem ist dabei allerdings, dass mein Webbrowser danach zunächst jeder der mitgelieferten CAs uneingeschränkt vertraut. Dies sind im Firefox heute mehr als 150 Zertifikate von mehr als 50 Herausgebern und jedes Zertifikat – und sogar davon abgeleitete Unterzertifizierungsstellen – ist in der Lage ein ‘gültiges’ Zertifikat für google.com zu unterzeichnen. Natürlich muss so etwas immer mal wieder schief gehen, Beispiele siehe oben.

Google hat hier in den letzten Jahren in mehreren Schritten versucht diese Probleme zumindest teilweise in den Griff zu bekommen:

  • Certificate Pinning in Chrome: In Chrome ist ein kleines Set von CAs fest einkodiert, die prinzipiell für Google Zertifikate ausstellen könn(t)en. Dadurch hat sich Chrome in den vergangenen Jahren immer wieder als Melder von Verstößen gegen die Sicherheit oder die Regelungen von CAs erwiesen.
  • Dieser Ansatz ließ sich natürlich nicht auf das komplette Web skalieren, von Google kommt daher das inzwischen in einem RFC definierte HPKP, welcher aber noch nicht alle Browser unterstützen. Auch schützt es Benutzer nicht beim ersten Besuch einer Webseite.
  • Abkehr von SHA-1: Die Ablösung von SHA-1 als Signaturalgorithmus für Zertifikate wurde von Google besonders aggressiv vorangetrieben.
  • Certificate Transparency (CT): Dieses Projekt beschreibt wie ein endloses Logbuch aller jemals von CAs ausgegebenen Zertifikate effizient geführt und online zugreifbar gemacht werden kann. Es gibt eine Implementierung von Google, aber inzwischen auch von CAs. Certificate Transparency ermöglicht es Webseitenbetreibern gezielt zu prüfen ob für ihre Webseiten illegitime Zertifikate ausgestellt wurden.
  • Chrome und CT: Google hat für den Herbst 2017 angekündigt, dass Chrome beginnen wird bestimmte Zertifikate nur noch dann zu honorieren, wenn die Certificate Transparency verfügbar ist.

Google hat die CAs hier in den letzten Jahren teilweise vor sich hergetrieben und sich damit durchaus einiges an Kritik eingefangen. Für Google selbst ist der Aufbau einer eigenen CA vermutlich nur ein letzter Baustein in einem System, dass sie bereits mit einem Browser (Chrome), Betriebssystemen (Android, ChromeOS), Protokollen (SPDY und QUIC) und einigen der wichtigsten Internetdienste der Welt nahezu vollständig im Griff haben und weiterentwickeln möchten. Google schafft sich damit nun auch an dieser Stelle ein eigenes Experimentierfeld, in dem sie beweisen können, dass sich ihre Ideen für die Zukunft des Netzes in großem Maßstab umsetzen lassen.

Wird Google Zertifikate frei anbieten bzw. verkaufen?

Abgesehen vom Vorantreiben der Internetsicherheit wird Google seine PKI sicher in Zukunft mit anderen Diensten wie der Domänenregistrierung verknüpfen. Unklar ist allerdings ob sie tatsächlich zu einer CA werden wollen, die jedem Zertifikate anbietet.

Aus dem Policy Dokument der Google PKI kann man nach meinem Verständnis entnehmen, dass Google zumindest zur Zeit nicht mit kostenfreien Angeboten wie Let’s encrypt konkurrieren will. Ich lese das aus der Beschreibung des Verfahrens zur Überprüfung der Identität von Antragsstellern bei der Zertifikatsbeantragung. Hier gibt es u. a. einen Aspekt, der eine Überprüfung der postalischen Adresse fordert. Das ist ein über die Domänenvalidierung der Gratisdienste hinausgehender Schritt, der sich nicht voll automatisieren lässt.

Meine Vermutung ist daher, dass Google zumindest mittelfristig nicht mit den existierenden CAs in direkte Konkurrenz treten, sondern seine CA nur für die eigenen Dienste nutzen wird. Auch damit wird diese CA allerdings schnell zu einer der CAs werden, deren Zertifikate den größten Teil des Internetverkehrs sichern.

Wann werden die Google Root Zertifikate in Webbrowsern auftauchen?

Google selbst weist in seinem Blogpost darauf hin, dass es einige Zeit dauert die Wurzelzertifikate für eine neue CA zu verbreiten. Hier müssen zunächst die großen Browseranbieter überzeugt werden die Zertifikate aufzunehmen. Gleiches gilt für die Betriebssystemhersteller (praktischerweise in einigen Fällen die gleichen Unternehmen). Und es müssen noch viele andere Dinge wie die Updategeschwindigkeiten der jeweiligen Produkte bedacht werden. Vermutlich wird man die Zertifikate zuerst in den Google-eigenen Produkten wie Chrome, ChromeOS und Android finden können, auch wenn Google bei Mozilla den entsprechenden Prozess schon im letzten Dezember angestoßen hat.

Google ist allerdings nicht dafür bekannt Dinge, die sie unbedingt wollen, von den Zeitplänen anderer abhängig zu machen. Daher hat man zwei bereits in Browsern und Betriebssystemen vorhandene Wurzelzertifikate gekauft und kann mit diesen schon jetzt nach eigenem Gutdünken verfahren. Faktisch ist damit Google bereits zur Root CA geworden. Der vorherige Screenshot zeigt eines dieser Zertifikate in Chrome.

Was soll man von der ganzen Sache halten?

“You can now have a website secured by a certificate issued by a Google CA, hosted on Google web infrastructure, with a domain registered using Google Domains, resolved using Google Public DNS, going over Google Fiber, in Google Chrome on a Google Chromebook. Google has officially vertically integrated the Internet.” – aduffy, 27.01.2017 auf ycombinator

Auf ycombinator findet man eine sehr ausführliche und meist gute Diskussion zu der Frage welche Auswirkungen dieser Schritt hat. Natürlich gibt es viele, die das zitierte Szenario eines über alle Ebenen des Internets integrierten Konzerns für bedrohlich / monopolistisch halten. Andere stellen die Frage warum man Google eigentlich so viel Vertrauen entgegen bringen sollte um nun auch noch ihrer CA zu trauen?

Die zweite Frage ist dabei für mich die einfachere: Wenn ich von meinem Android Smartphone über eine Google Suche eine Seite im Chrome Browser öffne vertraue ich Google sowieso schon sehr, sehr weitgehend. Wenn Google dann auch noch die Zertifikate verantwortet, die wenigstens die Google Dienste schützen, fällt für mich eine Stelle weg, der ich bisher auch noch vertrauen musste (die zuvor verwendete CA). Das ist eine Verbesserung.

Die Frage der Machtkonzentration bzw. des Monopols ist da wohl eher eine Gefühlsfrage: Aus meiner Sicht hat Google das Thema der Internetsicherheit in den letzten Jahren sehr vorangebracht und ist dabei in schwierigen Fragen wie z. B. der Bestrafung von versagenden CAs mehr oder weniger auf der richtigen Seite geblieben. Mit einer eigenen CA kann Google im besten Fall demonstrieren wie eine leistungsfähige und sichere PKI aussehen kann. Ich sehe das Ganze also positiv.

Eine andere Frage ist vielleicht die, ob dadurch CAs verschwinden werden? Heute sehen sich die existierenden Zertifizierungsstellen am unteren Ende durch Let’s encrypt bedrängt, welches für viele Webdienste Zertifikate in vollkommen ausreichender Qualität bereitstellt. Am oberen Ende mag es in Zukunft eine Konkurrenz durch die Google CA geben, aber nicht ohne Grund haben viele Länder eigene CAs gegründet und werden die ganz unabhängig von einem Google Angebot betreiben. Wenn dafür einige der kleineren CAs, die möglicherweise Probleme damit haben einen seriösen Betrieb zu leisten, am Ende verschwinden, so ist das für die Sicherheit des Internets dann eher gut.

Anti-DoS Tomcat Valve auf Github veröffentlicht

Auf Github findet sich jetzt unter dem Namen Anti-DoS Valve ein Werkzeug, welches beim Betrieb von Tomcat Servern nützlich sein kann um diese vor Überlastungen durch böswillige Akteure im Netz zu schützen. Dazu implementiert das Valve eine dynamische Zugriffsratenlimitierung, die sich umfangreich konfigurieren lässt. Zur Simulation der Auswirkungen unterschiedlicher Konfigurationen habe ich ein Google Drive Sheet veröffentlicht. Der Code steht unter der Apache Lizenz, kann also frei verwendet werden.

Woher kommt die Idee

Das Valve ist eine verallgemeinerte Version einer kleinen Programmierung, die ich im vergangenen Jahr kurzfristig erstellen musste, nachdem unsere Server immer mal wieder unter Überlastungen litten, die offenbar durch auf gekaperten Rechnern laufende Webcrawler verursacht wurden. Diese Zugriffe waren teilweise so aggressiv, dass sie Auswirkungen auf unsere regulären Nutzer hatten.

Zur Begrenzung dieser unwillkommenen Zugriffe standen zunächst unterschiedliche Optionen im Raum, aber die Option ein Tomcat Valve zu implementieren setzte sich am Ende aus diesen Gründen durch:

  • Ein Valve ist durch seine Verortung im Tomcat Server nahe an der Geschäftslogik bzw. an den Leuten, die wissen was auf dem Applikationsserver läuft. Eine Verortung etwa auf Netzwerkebene hätte einen nicht unerheblichen Wissenstransfer zwischen unterschiedlichen IT Bereichen erfordert
  • Da es sich bei den Angriffen – auch böswillige Webcrawler kann man dabei als Angreifer sehen – nicht um umfangreiche (D)DoS Angriffe handelte war eine Gegenmaßnahme auf Ebene der Applikationsserver ausreichend
  • Der Aufwand für die Programmierung des Valves war auf Grund der vorhandenen Erfahrungen vergleichsweise gering
  • Der Einsatz eines Filters mit identischer Funktion, der innerhalb der Webapplikationen eingesetzt würde, erzeugt im Vergleich zu einem Valve einen höheren Aufwand in der Konfiguration

Was macht das Valve

Ziel ist es unwillkommene Belastungen der eigenen Server so weit begrenzen zu können, dass sie nicht mehr in der Lage sind negative Auswirkungen auf die regulären Nutzer zu entfalten. Dabei soll die Schutzfunktion dynamisch sein, sich also selbstständig auf neue Angreifer einstellen und diese blockieren können. Und schließlich soll der Overhead dieser zusätzlichen Filterung, die zunächst für alle im Tomcat Server eingetreffenden Requests anspringt, möglichst klein sein. In der aktuellen Version arbeitet das Valve dabei auf der Ebene einzelner IP Adressen, für die Limitierungen durchgesetzt werden können.

Für die konkrete Implementierung wurden dann Erfahrungen genutzt, die ich früher bei anderen Programmierungen zu Ratenlimitierungen gemacht hatte, insbesondere beim Aufbau unserer Identity Provider Infrastruktur und der dort durchgesetzten Begrenzung der Anzahl von möglichen Versuchen zum Erraten eines Passworts.

Um die Implementierung ressourcenschonend zu gestalten – insbesondere in einer DoS Situation, wo schnell abertausende von Requests in kurzer Zeit eintreffen können – wird für die Ermittlung der aktuellen Zugriffsrate einer IP Adresse keine gleitende Auswertung gemacht, sondern es wird nur über die Anzahl der Zugriffe innerhalb eines bestimmten Zeitintervalls (in der Programmierung Slot genannt) Buch geführt. Wird innerhalb eines solchen Slots die Anzahl der erlaubten Zugriffe überschritten, so werden alle weiteren Zugriffe bis zum Ende des Slots abgelehnt. Damit nicht mit jedem neuen Slot das Spiel von vorn beginnt kann ein Anteil der in früheren Slots gezählten Zugriffe übernommen werden. Auf diese Weise sind sowohl die Datenhaltung im Valve wie auch Rechenaufwand gering und nehmen auch in einer Hochlastphase nicht wesentlich zu.

Über die Konfigurationsoptionen können dabei nahezu alle Eigenschaften gesteuert werden, neben dem Grenzwert der Zugriffe pro Slot auch die Slotlänge und der Umfang der aus früheren Slots übernommenen Requestanzahlen. Mit diesem einfachen Mittel lassen sich durchaus komplexe Filterungen realisieren.

Es gibt im Valve noch weitere Optionen, über die sich steuern lässt auf welchen Adressen die Ratenlimitierung überhaupt wirksam werden soll (hier kann man z. B. Requests auf statische Inhalte wie JS oder CSS Dateien ausschließen um schärfere Einstellungen zu realisieren) und ob bestimmte IP Adressen oder Adressbereiche generell von einer Filterung ausgenommen werden sollen (z. B. Adressen aus dem Intranet, um interne Nutzer nie zu beeinträchtigen).

Wie legt man los

Während die grundsätzliche Inbetriebnahme des Valves sehr einfach ist (Clone von Github, Ausführen von Maven Install, JAR in Tomcat/lib Verzeichnis kopieren, Valve Konfiguration in server.xml ergänzen), liegt die eigentliche Herausforderung darin die für den eigenen Anwendungsfall passenden Konfigurationsparameter zu finden. Hier gilt es die richtige Balance zu finden zwischen zu engen Einstellungen, die auch die regulären Benutzer beeinträchtigen können, und zu offenen Parametern, die die Angreifer nicht richtig im Zaum halten können und damit auch wieder die regulären Benutzer beeinträchtigen.

In der README findet sich ein eigener Abschnitt dazu, wie man bei der Inbetriebnahme vorgehen kann. Der Kernpunkt ist es hier ein ausreichendes Wissen über die reguläre Nutzung der eigenen Dienste zu haben, also welche Zugriffszahlen OK sind und welche ein böswilliges bzw. störendes Level erreichen. Die Auswertung der Tomcat Access Logfiles ist dabei der Schlüssel. Hat man diese Werte kann man in dem Simulator Sheet vergleichen welche Auswirkungen eine bestimmte Konfiguration hat und damit prüfen, ob sie in der Lage ist die Spreu vom Weizen zu trennen. Diese Knackpunkte gibt es dabei der Erfahrung nach:

  • Wie häufig greifen Suchmaschinen zu? Gutartige Suchmaschinen zeichnen sich meist durch gleichmäßige Zugriffe aus und haben keine Zugriffsspitzen. Je nach Valve Konfiguration kann es aber vorkommen, dass auch solche Zugriffsformen gesperrt werden, die dauerhaft unter den pro Slot erlaubten Zugriffsraten bleiben.
  • Dienen die eigenen Webapplikationen als Service Endpunkt, der von anderen Applikationsservern in großem Umfang genutzt wird? Wenn es sich dabei um gewollte Fälle handelt, so sollte man die entsprechenden Adressen bzw. Adressbereiche grundsätzlich freischalten, damit die Valve Konfiguration nicht auf Grund solcher Einzelfälle zu offen gestaltet sein muss.
  • Wie viele Request löst ein Benutzer beim ersten Besuch (also mit leerem Cache) der eigenen Seiten aus? Hier erreichen moderne Webseiten auf Grund der vielen Komponenten häufig erstaunliche Zahlen, wobei die Masse der Zugriffe auf statische Inhalte entfällt. Um auch hier die Valve Konfiguration nicht zu offen gestalten zu müssen ist es meist sehr sinnvoll die Zugriffe auf statische Inhalte nicht mit in die Zugriffszählungen eingehen zu lassen. Diese Zugriffe sollten sowieso nicht die Hauptlastverursacher in einer dynamischen Webapplikation sein und die böswillige Akteure werden sie sowieso nicht abrufen.
  • Kommen reguläre Benutzer in großer Zahl über Proxies auf den eigenen Server, so dass sich hinter einzelnen IP Adressen faktisch viele Benutzer verbergen?

Auch bei sehr sorgfältiger Vorbereitung ist es aber notwendig zumindest in der ersten Zeit nach der Aktivierung des Valves die Logging Informationen im Auge zu behalten und zu beobachten ob Adressen gesperrt werden, die man eigentlich zulassen möchte.

Ist das Valve richtig konfiguriert kann man es in gewisser Weise ‚vergessen‘, da es danach Angriffe automatisch im Zaum halten kann. Änderungsbedarfe ergeben sich dann nur noch bei Modifikationen an den im Server installierten Anwendungen, die das Lastverhalten beeinflussen. Trotzdem sollte ein Monitoring fortgesetzt werden, schon allein um zu sehen ob Angriffe erfolgen und in welchem Umfang.

Was sind die Grenzen

Das Anti-DoS Valve kann seinem Namen nur in einem Teilaspekt des weiteren Themas (D)DoS gerecht werden. Es wird z. B. nicht bei riesigen Überflutungen helfen, die schon die Netzwerkebene überlasten. Es hat aber seine Daseinsberechtigung in dem Bereich, der unterhalb des Angriffslevels liegt, der sich auf Netzwerkebene einfach erkennen lässt:

Im Fall unserer Server werden heute pro Tag normalerweise mehr als eine Million Requests verarbeitet. Starke Belastungen können aber schon entstehen, ohne das sich diese Zahl insgesamt vervielfacht, sofern die Zugriffe auf die entsprechenden Adressen gebündelt werden. An genau dieser Stelle kann das Valve eingesetzt werden, in dem es insbesondere die Zugriffe auf die Adressen reguliert, die geeignet sind hohe Belastungen zu erzeugen. Dafür ist eine Kenntnis der entsprechenden Applikationen und ihrer sensiblen Punkte notwendig.

Die ursprüngliche Version des Valves hat dabei den angestrebten Zweck bisher erfüllt und sich als sehr stabil erwiesen.

Monitoring per JMX

Das Valve kann sehr weitgehend per JMX administriert und beobachtet werden. In der JConsole präsentiert es sich dabei so:

Auf diese Weise können Konfigurationsänderungen auch am laufenden Server durchgeführt werden und gleichzeitig der aktuelle Status z. B. von blockierten IP Adressen beobachtet werden.

Ideen für die Weiterentwicklung

Die bisherige Implementierung hatte das Ziel möglicht einfach gehalten zu sein und ist auf den bisherigen Einsatzzweck zugeschnitten. Für eine Verallgemeinerung der Funktion bieten sich aber eine Reihe von Erweiterungen an:

  • Testmodus: Ein Option das Valve im Server so zu betreiben, dass nur Loggings über Blockaden erfolgen, aber keine echten Blockaden. Auf diese Weise könnten Konfigurationen zunächst risikofrei getestet werden.
  • Zähler auf Ebene von Subnetzen: Nicht nur echte DDoS Attacken verteilen ihre Zugriffe auf viele Ausgangsrechner, auch bei Webscrapern / böswilligen Crawlern kann dies beobachtet werden. Hier wäre eine Verallgemeinerung der Programmierung interessant, die in der Lage ist Zähler nicht nur auf Ebene von einzelnen IP Adressen zu führen. Die Implementierung des Monitors, der die Zugriffszählung durchführt, ist bereits entsprechend verallgemeinert worden.
  • Möglichkeit mehrere Instanzen des Valves im Server nutzen zu können: Zwar kann man heute das Valve mehrfach in einem Tomcat konfigurieren, aber die Monitor Instanz ist nicht getrennt und per JMX wird nur eine Instanz des Valves gezeigt. Die Nutzung unterschiedlicher Valve-Instanzen in einem Server kann nützlich sei falls unterschiedliche Konfigurationen für verschiedene Webapplikationen gefahren werden sollen.
  • Verbesserungen für den Einsatz in Serverfarmen: Heute müssen Konfigurationsänderungen an allen Servern separat erfolgen, auch gibt es keine Möglichkeit wie sich Instanzen des Anti-DoS Valves auf unterschiedlichen Servern verständigen können. In unserer Serverfarm beeinträchtigt uns das heute nicht, aber bei großen Farmen könnte so etwas nützlich sein.

Falls jemand Lust hat an dem Projekt mitzumachen: Einfach melden 🙂