das dürfte interessant für jeden sein, der Server betreibt:
In erster Linie betroffen sind jetzt alle Betreiber von Servern, die SSL zur Verschlüsselung einsetzen. Das sind nicht nur Web-Server, sondern häufig auch solche für E-Mail, VPN und andere Dienste. Es ist äußerst wichtig, diese Systeme jetzt schnellstmöglichst zu sichern. Die Version OpenSSL 1.0.1g enthält den Fehler nicht mehr. Debian stellt bereits ein Update bereit; andere Distributionen werden bald folgen. Wer OpenSSL selbst mit der Option -DOPENSSL_NO_HEARTBEATS übersetzt, kann eine nicht anfällige Bibliothek erzeugen. [Update: Versionen vor der aktuellen 1.0.1 wie das auf älteren Systemen noch verbreitete OpenSSL 0.9.8 sind offenbar nicht betroffen.]
Im nächsten Zug müssen natürlich auch Endanwender, die Produkte auf OpenSSL-Basis einsetzen, aktualisierte Versionen installieren. Und das dürften nahezu alle sein. Denn das Problem betrifft nicht nur PCs, sondern insbesondere auch Smartphones, SmartTVs, Router und viele andere Geräte – im wesentlich alles, was irgendwie mit dem Internet spricht und keine proprietären SSL-Bibliotheken beziehungsweise den Exoten GnuTLS einsetzt.
Ich habe sofort geupdatet. Die Dienste auf meinem Server habe ich trotzdem erst einmal abgeschaltet, da Server und Client auf dem neuesten Stand sein müssen.
Ich halte meine Kiste eigentlich immer aktuell und hatte tatsächlich auch die betroffene auf dem Server. Aber das Update ist heute Nacht schon in die Debian Repos geschoben worden, da waren sie schnell.
Naja, die CVEs betreffend aber meist nicht nur die 0.9.8er Versionen, sondern auch höhere. Das mit der Versionsgeilheit nehmen ich zurück, da OpenSSL 1.0.1 es in Debian Wheezy geschafft hat und die sind ja eher konservativ
Btw. Abschalten müsstest deine Dienste nicht, aber neue Private Keys/Zertifikate wären angesagt.
Doch, ich sitze auf der Arbeit und habe nicht groß Zeit an meinem Server zu schrauben. Da hab ich betroffene Dienste erst mal abgeschaltet, weiter geht es dann mit dem Spaß erst heute abend nach Feierabend
Als StartSSL User scheint man Pech zu haben. Für das Wiederrufen eines Zertifikats muss man draufzahlen. Ich benutze daher für meine Dienste CaCert Zertifikate.
Der eigentliche WTF bei diesem Bug ist meiner Meinung nach, dass OpenSSL in C (nicht einmal in C++) geschrieben ist. Ja ich weiß, systemnah, Performance, Übersetzungsaufwand, bla… Und ich weiß auch, dass definitiv Java die falsche Sprache für eine Implementierung wäre. Aber es gibt inzwischen so viele gute Alternativen (mein Favorit für den Job wäre D 2.0), wo solche “einfachen” Fehler gar nicht erst möglich wären. Bei C und (schlecht geschriebenen) C++ zu bleiben heißt, ganz bewußt in die nächste Runde des Hase-und-Igel-Spiels zu gehen. Sollte man nicht langsam anfangen, ernsthafte Konsequenzen zu ziehen statt an den Symptomen herumzudoktern?
Dir ist bewusst das dann einige Mannjahre in das neue Projekt geschoben wird. Das nur eine “paar” Programmierer die Sprache können. Das dadurch die Qualität des Codes leidet (weil wenige Ahnung von der Spache haben). Das dies zu neuen Fehlern führen wird, die ebenfalls so kritisch sein können.
Es ist egal welche Sprache es ist. Das Hase-und-Igel-Spiel geht mit jeder Sprache.
Jede Software hat ein EOL (auch wenn das nicht immer eingesehen wird). Ja, ich weiß, bei Banken und Versicherungen läuft noch COBOL, aber ist das auch wirklich sinnvoll?
Das nur eine „paar“ Programmierer die Sprache können.
Ein typisches Henne-Ei-Problem.
Das dadurch die Qualität des Codes leidet (weil wenige Ahnung von der Spache haben). Das dies zu neuen Fehlern führen wird, die ebenfalls so kritisch sein können.
Soooo unterschiedlich sind die alternativen Sprachen nicht, die meisten sehen recht ähnlich aus, nur das halt der gefährlichste Nonsense einfach verboten ist, und das Verhalten der Sprache insgesamt konsistenter ist.
C ist eigentlich eine Unsprache, voller unnötiger Fallstricke und WTFs, dazu inkonsistent und schlecht definiert. Wenn man die Energie, die man aufwenden muss, um diesen Schwachsinn zu beherrschen, in eine vernünftige Sprache investiert, kommt man meiner Meinung nach schneller ans Ziel.
Es ist egal welche Sprache es ist. Das Hase-und-Igel-Spiel geht mit jeder Sprache.
Ja, aber auf einer neuen Ebene - ohne Pufferüberläufe und ähnliche Anachronismen.
Man könnte auch einfach Sprachen nehmen die für „High Integrity“-Systeme schon seit längerem etabliert sind und sich mit relativ wenig Aufwand auf die Geschwindigkeit von den C-Programmen bringen lassen, dazu gehört z.B. SPARK (Teilmenge von ADA)
