Update zur Beschwerde beim Presserat – Welt Online

Von Mainboarder am 20.04.2014 veröffentlicht
Tags: , , ,

Ende Februar reichte ich eine Beschwerde beim Deutschen Presserat ein. Darin beschwere ich mich über einen Beitrag von Welt Online. Dieser hat für mich einen werbenden Charakter für die Website auf welcher Edathy die fragwürdigen Abbildungen von Kindern kaufte. Ebenfalls werden weitere Details zu dem Geschäft genannt.

Mich erreichte danach eine Eingangsbestätigung. Darin wurde auch erklärt, dass zunächst mit dem Vorsitzenden des Beschwerdeausschusses geprüft wird, ob diese Beschwerde offensichtlich unbegründet ist. Nun erhielt ich Nachricht, dass meine Beschwerde einem Beschwerdeausschuss zugeleitet wird.

Die Redaktion wird um eine Stellungnahme gebeten, auch wird empfohlen in Kontakt mit mir zu treten.
Bei der nächsten Sitzung wird dann Beraten ob der Beitrag in seiner jetzigen Form gegen den Pressekodex verstößt und wenn ja, wie dies sanktioniert wird.

Da ich Unterlagen als vertraulich zu behandeln habe, und es auch nicht öffentliche Sanktionsmittel gibt, kann ich zukünftig eventuell nicht alle Details veröffentlichen. Bislang habe ich nur auf die Details aus dem Beitrag verzichtet, die ich selbst kritisiere.


Frohe Ostern! :)

Der Hoster Netcup (da steht auch der Server von diesem Blog) bietet auch dieses Jahr wieder eine Osteraktion an. Mit dabei sind kräftig reduzierte Angebote:

Wem das noch nicht genug ist, kann einen der folgenden Gutscheine verwenden (5€ Rabatt als Neukunde):

36nc13979461190
36nc13979461191
36nc13979461192
36nc13979461193
36nc13979461194
36nc13979461195
36nc13979461196
36nc13979461197
36nc13979461198
36nc13979461199

Sagt bescheid, wenn ihr einen Code verwendet, dann kann ich den löschen und ggf. neue erstellen.

Ich mache das, da ich mit den Leistungen zufrieden bin und deswegen diesen Hoster empfehlen kann. Zusätzlich erhalte ich bei Werben von Neukunden Provision.


Wie ich eine hohe SWAP-Latenz beseitigte

Von Mainboarder am 11.04.2014 veröffentlicht
Tags: , ,

Letztens, und damit meine ich, dass das schon eine Weile her ist, klingelte mein Handy immer wieder in der Nacht. Grund war eine zu hohe SWAP-Latenz. Das passiert, wenn der RAM voll ist und auf die wesentlich langsamere Festplatte Teile des RAMs ausgelagert werden.
Je mehr die Festplatte zu schreiben hat, desto länger dauert das und damit steigt auch die Latenz.

Ich machte mich also daran den Fehler zu suchen.

Obwohl der RAM nicht vollständig ausgeschöpft war, swappte der Server. Mittels iotop stellte ich im Grunde nichts wirklich außergewöhnliches fest. Gut, MySQL swappte ein bisschen. Aber das hat mich nicht sonderlich beunruhigt.

Doch nach einigen Minuten stellte ich fest, dass auf einmal viel RAM frei wurde. Damit musste natürlich auch nicht mehr im hohen Maße geswappt werden.
Das lag an einem Cronjob der die Last auf dem System steigerte.

Da ich BOINC mit der niedrigst möglichen nice laufen lasse, war mir klar, damit hat es zu tun. Allerdings hatte ich vorher keine Probleme damit. Die Last ging hoch und der Prozessor beschäftigte sich mit höher priorisierten Prozessen, wie zum Beispiel dem Cronjob.

Ich stellte fest, dass nach dem Durchlauf des Cronjobs tatsächlich der RAM wieder voll wurde. Um zu überprüfen, ob es wirklich an BOINC liegt, beendete ich den Manager. Mein Verdacht bestätigte sich.

Da ich immer nur an einem Projekt gleichzeitig mitrechne, war klar, dass das Problem Rosetta@home auslöste. Ich beendete die aktuelle Workunit, verwarf die anderen und wechselte das Projekt.
Der RAM ist nun weit weniger stark belastet und alles läuft flüssig. Man kann Fehler offenbar auch relativ schnell durch Zufall finden.


Heartbleed und was viele vergessen

Von Mainboarder am 9.04.2014 veröffentlicht
Tags: , , ,

Ein Bug, von dem man noch lange Zeit wissen wird. Das ist Heartbleed. Am späten Montagabend wurde er veröffentlicht. Manche, wie Cloudflare, waren informiert, andere, wie Linuxdistributionen, nicht. Ein Vorgehen das an sich hätte besser laufen sollen, bei solch einer schwerwiegenden Lücke. Aber von vorn.

Diese Einstellung sollte in Chrome unbedingt gesetzt werden.

Diese Einstellung sollte in Chrome unbedingt gesetzt werden.

OpenSSL wird sehr oft genutzt um verschlüsselte Verbindungen zwischen Client und Server herzustellen (Onlinebanking, E-Mail made in Germany, vermutlich De-Mail, Onlineshops). Dafür gibt es einen Algorithmus, welcher nicht das gleiche Passwort zum Ver- und Entschlüsseln benötigt. Ähnlich wie bei PGP (was nach Snowden mehr Leute kennen dürften).

Es gibt einen öffentlichen Schlüssel, mit dem Nachrichten des Clients verschlüsselt werden und einen privaten Schlüssel, um die Nachrichten zu entschlüsseln.
Der Bug lässt es zu bis zu 64 kByte aus dem Hauptspeicher eines Rechners ohne größere Mühen auszulesen. 64 kByte ist für Text verhältnismäßig viel und so kann man darin auch viel finden: wie zum Beispiel Passwörter oder auch Teile des privaten Schlüssels. Ließt man die richtigen Speicherbereiche aus, so erhält man den vollständigen Schlüssel.

Diese Möglichkeit führt dazu, dass wenn man streng nach Vorschrift geht, nun alle Zertifikate und Passwörter schnellstmöglich geändert werden müssen. Erst dann kann ein System als nicht mehr kompromittiert angesehen werden. Schließlich bestand die Lücke seit über zwei Jahren.

Aber auch hier gibt es wieder ein Problem. Die SSL-Zertifikate (also die zur Verschlüsselung verwendeten Passwörter), werden durch Firmen vergeben, meist gegen Geld. Ein Rückruf kostet nun oftmals Geld. Man hat die Wahl: entweder Bares in die Hand nehmen und alles ordentlich machen, oder darauf vertrauen, dass man selbst ein zu uninteressantes Ziel war und der Aufwand für den Angriff bei einem sich nicht lohnte.

Ein weiteres, aber viel schwerwiegenderes Problem sehe ich noch. Nutzt ein Besucher Chrome, so prüft dieser gar nicht, ob ein Zertifikat als ungültig erklärt wurde. Er akzeptiert es, solange es plausibel scheint. Erst durch Änderung der Standardeinstellungen: Einstellungen, Erweiterte Einstellungen anzeigen, HTTPS/SSL -> Serverzertifikate auf Sperrung prüfen, prüft Chrome dies.

Da es sich um eine unsichere Standardeinstellung handelt, werden die wenigsten Nutzer jemals eine vernünftige Einstellung erhalten. Dadurch kann sich ein Angreifer zwischen Client und Server positionieren und die Kommunikation ändern, da er im Besitz des Zertifikates eigene Nachrichten erstellen und als der Server signieren kann.

[Update 20.04.14 16:00 Uhr]

Fefe berichtet von einem Google-Entwickler der sich mit SSL befasst. Dieser rät davon ab, Zertifikate auf Widerruf zu prüfen. Es ist angeblich nicht sicherer. Ich sehe das anders. Wenn ich keine Warnung bekommte, ist das keine Entwarnung. Wenn ich aber eine Warnung aufgrund eines zurückgerufenen Zertifikates erhalte, dann weiß ich, dass ich diese Seite nicht besuchen sollte. Das ist gerade eine ähnlich unsichere Lage wie bei dem BSI-Emailsicherheitstest. Wenn ich keine Mail bekomme, heißt es nicht, dass meine Daten nicht betroffen sind. Nur wenn ich eine E-Mail erhalte ist sicher, dass meine Daten betroffen sind. Ein Zertifikat macht einen Server nicht automatisch sicher, wenn man damit falsch umgeht. Und dass nicht standardmäßig auf Widerruf geprüft wird, halte ich für fahrlässig.