Nach dem Auftauchen von Zertifikatsfälschungen des indischen National Informatics Centre (NIC) liefert Microsoft ein Windows-Update, welches die Zertifikate sperrt. Ursprünglich war nur von vier gefälschten Zertifikaten die Rede, inzwischen sind 45 bekannt.
Mitarbeiter von Google haben mehrere gefälschte Zertifikate für Domains des Konzerns gefunden. Ausgestellt wurden sie von einer Zertifizierungsstelle der indischen Regierung. Diese Zertifizierungsstelle wird nur von Windows akzeptiert.
Im Code des POP3-Kioslaves in KDEs E-Mail-Anwendung Kmail beziehungsweise in Kdelibs ist ein Fehler, durch den ungültige Zertifikate ohne Abfrage akzeptiert werden. Angreifer könnten sich so in den verschlüsselten E-Mail-Verkehr einklinken.
Fast unbemerkt haben Entwickler eine weitere Sicherheitslücke in der Kryptobibliothek GnuTLS geschlossen. Anwendungen, die die Bibliothek nutzen, müssen jedoch ebenfalls angepasst werden.
DANE könnte die Echtheitsprüfung von Zertifikaten bei TLS-Verbindungen verbessern. Allerdings benötigt das System DNSSEC - und das ist bislang kaum verbreitet. Der Mailanbieter Posteo prescht jetzt voran und will das System etablieren.
Nach dem Heartbleed-Bug haben viele Administratoren Zertifikate für TLS-Verbindungen ausgetauscht. Viele haben dabei jedoch einen fatalen Fehler begangen: Sie erstellten zwar ein neues Zertifikat, aber keinen neuen Schlüssel.
Im Zuge von Heartbleed sollen Serverbetreiber ihre Zertifikate erneuern und die alten zurückziehen. Das Problem dabei: Das bringt fast nichts, denn kein einziger Browser prüft die Gültigkeit der Zertifikate auf sichere Weise.
Zwei Personen ist es gelungen, private Schlüssel mit Hilfe des Heartbleed-Bugs aus einem Nginx-Testserver auszulesen. Der Server gehört der Firma Cloudflare, die mit einem Wettbewerb sicherstellen wollte, dass das Auslesen privater Schlüssel unmöglich ist.
Cisco und Juniper Networks haben in offiziellen Warnungen vor dem Heartbleed-Bug in ihren Produkten gewarnt. Nicht nur Server, sondern auch zahlreiche Netzwerkprodukte und Software seien betroffen.
Weder Mac OS X, iOS noch Apples Dienste wie iCloud sind von der Heartbleed-Schwachstelle betroffen. Denn Apple verzichtet auf OpenSSL. Einige Apps verwenden die Kryptobibliothek jedoch.
Update Der Heartbleed-Bug in OpenSSL dürfte wohl als eine der gravierendsten Sicherheitslücken aller Zeiten in die Geschichte eingehen. Wir haben die wichtigsten Infos zusammengefasst.
Update Ein Fehler in OpenSSL lässt das Auslesen von Arbeitsspeicher zu. Damit können Angreifer private Keys von Servern erhalten. Eine sichere Verschlüsselung ist nicht mehr gewährleistet. Der Bug betrifft sehr viele Web- und Mailserver im Internet.
Mit Hilfe von fehlerhaften X.509-Zertifikaten haben Forscher zahlreiche zum Teil sicherheitskritische Bugs in TLS-Bibliotheken gefunden. Erneut wurde dabei eine gravierende Sicherheitslücke in GnuTLS entdeckt.
Die Zertifikate von Cacert werden aus verschiedenen Linux-Distributionen entfernt. Manche sehen darin das Ende des Projekts, das der kommerziellen Konkurrenz eine Community-basierte Zertifizierungsstelle entgegensetzen wollte.
Entwickler verlassen sich zu sehr auf HTTPS und verzichten auf grundlegende Sicherheitsmaßnahmen. Über eine Man-in-the-Middle-Attacke konnten Security-Forscher in den Datenverkehr zwischen App-Server und Apps hineinsehen - und entdeckten Sonderbares.
In der Verschlüsselungsbibliothek GnuTLS ist ein Fehler gefunden worden, der dazu führen kann, dass bösartige, gefälschte Zertifikate akzeptiert werden. Ähnlich wie bei der kürzlich bei Apple entdeckten Lücke spielt ein "goto fail" eine Rolle.
Erneut gibt es Probleme mit dem TLS-Protokoll. Mit der Triple-Handshake-Attacke kann ein bösartiger HTTPS-Server einem weiteren Server vorgaukeln, er hätte das Zertifikat eines Nutzers. Die meisten Anwender sind von dem Angriff vermutlich nicht betroffen.
Nach Empfehlungen der US-Behörde Nist darf der Hash-Algorithmus SHA-1 für digitale Signaturen 2014 nicht mehr genutzt werden, das Nist hielt sich aber selbst nicht daran. Auch das BSI kennt offenbar seine eigenen Empfehlungen in Sachen Hash-Funktionen nicht.
Ein von Huawei hergestellter Router, den T-Mobile Austria vertreibt, hat eine schwere Sicherheitslücke, die sich auch über das Internet ausnutzen lässt. Abhilfe schafft eine neue Firmware, welche der Provider bereits vertreibt.
Eine neue Firmware von Siemens stopft eine Sicherheitslücke in Industriesteuerungen der Sinamics-Familie. Die Steuerungsanlagen mit integriertem Webserver hatten bisher offene FTP- und Telnet-Ports.
Falsche digitale Zertifikate sind gegenwärtig im Umlauf. Sie wurden irrtümlicherweise von der französischen Zertifizierungsstelle IGC/A signiert. Dort wurden die Zertifikate bereits widerrufen.
Googles Browser wird künftig Nutzer bei Zertifikaten mit kurzen Schlüsseln und anderen Problemen warnen. Auch eine neue Technologie namens Certificate Transparency, die betrügerische Zertifizierungsstellen identifiziert, soll bald genutzt werden.
Beim Aufbau von TLS-Verbindungen kann Firefox künftig Informationen über die Gültigkeit eines Zertifikats mitliefern. Das sogenannte OCSP Stapling wird damit von allen großen Browsern unterstützt, aber bei den Servern gibt es noch Probleme.
Die TLS-Schnittstelle von Windows lädt automatisch fehlende Zertifizierungsstellen nach. Das sowieso schon kritisierte System der TLS-Zertifizierung wird dadurch noch unsicherer.
Hacker haben erfolgreich die Server von Opera Software attackiert. Sie haben ein Sicherheitszertifikat gestohlen und so Schadsoftware von Operas Servern verteilt. Mehrere tausend Windows-Nutzer könnten betroffen sein.
Eigentlich soll die neue Standard-Sicherheitseinstellung von Java für mehr Sicherheit sorgen, da nur noch signierte Java-Programme im Browser ohne Sicherheitswarnung ausgeführt werden. Doch nun ist ein erster signierter Java-Exploit aufgetaucht.
Bislang seien UEFI und Secure Boot als Herausforderung aufgenommen worden, sie könnten aber auch für Linux nützlich sein, sagte Shim-Entwickler Matthew Garrett.
Unter Fedora 18 lassen sich die Sicherheitsprüfungen von Secure Boot gänzlich deaktivieren. Damit können auch unsignierte Treiber genutzt werden, etwa die proprietären der Grafikkartenhersteller Nvidia oder AMD.
Update Die Deutsche Telekom und AVM melden sich beide zu der UPnP-Sicherheitslücke, die zahlreiche Router betrifft. Sie versichern beide, dass ihre eigenen Router nicht von außen per UPnP angreifbar sind.
Update Das US-Cert warnt vor einer Lücke in den UPnP-Funktionen, welche vermutlich nahezu alle privat genutzten Router betrifft. Zwar gibt es eine einfache Abhilfe, aber das Stopfen der Lücke dürfte einige Zeit in Anspruch nehmen.
Ubuntu macht einige UEFI-Rechner unbrauchbar, berichten Nutzer. Lenovos UEFI-Implementierung untersucht vermeintlich Booteinträge, was den Start fast aller Linux-Systeme verhindert.
Warum Opensuse nicht versucht, Secure Boot möglichst schnell umzusetzen, verrät Frederic Crozat im Gespräch mit Golem.de. Er bedauert zudem den Alleingang der Linux-Foundation.
Über den Bootloader Shim sollen sich eigene Secure-Boot-Schlüssel für Linux in einer Datenbank hinterlegen lassen. Andere Linux-Distributionen benötigen dann nur noch den signierten Shim-Loader von Fedora.
Angreifern ist es offenbar gelungen, Malware mit einem Zertifikat von Adobe zu signieren, so dass bei deren Installation unter Windows keine Warnungen auftreten. Adobe hat angekündigt, das entsprechende Zertifikat zurückzuziehen.
In Ubuntu 12.10 wird Grub 2 wieder der Standard-Bootloader. Bedenken wegen der möglichen Offenlegung der Signaturschlüssel haben Canonical und die FSF ausgeräumt.
In der Virtualisierungsumgebung Qemu und KVM lässt sich UEFIs Secure Boot nutzen. Der noch experimentelle Code stammt von Linux-Entwickler James Bottomley.
Statt wie Fedora auf eine Microsoft-Signatur für Secure-Boot zu setzen, definiert Canonical eigene Zertifizierungsrichtlinien. Das ähnelt dem Vorgehen von Microsoft, bis auf eine entscheidende Ausnahme.
Linux-Erfinder Linus Torvalds zeigt wenig Verständnis für die Kritik am Umgang von Fedora und Red Hat mit Secure Boot. Er könne sich sogar vorstellen, Secure Boot selbst zu nutzen.
Nachdem Red Hat und Fedora eine mögliche Lösung für die Verwendung von Linux mit UEFIs Secure Boot präsentiert haben, wächst die Kritik. Denn unabhängige Distributionen müssten den Bootloader ebenfalls von Microsoft signieren lassen.
Die in der vergangenen Woche bekanntgewordene Malware Flame wurde zum Teil mit gefälschten Microsoft-Zertifikaten signiert, so dass die Software wirkte, als käme sie von Microsoft.
Ein kleines Stück Software, das noch vor Grub geladen wird, soll von Microsoft signiert werden. Alles andere möchte das Fedora-Team selbst signieren und so Secure-Boot in Fedora 18 für alle nutzbar machen.
Adam Langley aus Googles Sicherheitsteam kündigt in seinem privaten Blog an, dass Googles Browser Chrome bei SSL künftig nicht bei der CA anfragen wird, ob ein Zertifikat zurückgezogen wurde. Das erhöhe die Sicherheit nicht und dauere dadurch unnötig lang.
Die technischen Hürden einer Linux-Installation auf UEFI-Geräten werden sich überwinden lassen. Nutzerfreundlich wird das wohl aber nicht, befürchtet Entwickler Matthew Garrett.
Auf ARM-basierten Geräten mit Windows 8 soll es nach den Vorgaben von Microsoft nicht möglich sein, Secure Boot auszuschalten. Damit ließe sich ein alternatives Betriebssystem nur dann installieren, wenn der Hersteller einen Schlüssel mitliefert.
Der zu KPN gehörende Anbieter von Sicherheitszertifikaten Gemnet hat seine Website abgeschaltet, da offenbar über phpMyAdmin ein Zugriff auf die dahinterliegende Datenbank ohne Eingabe eines Passworts möglich war.
Entwickler von Google schlagen einen einfachen Mechanismus vor, um Browserzertifikate vor Diebstahl zu schützen: Der Browser soll bei jeder SSL-Verbindung nachsehen, ob das Zertifikat noch gilt.
Die Linux Foundation und Canonical haben jeweils Vorschläge veröffentlicht, die das UEFI Secure Boot auch für offene Plattformen zugänglich machen soll. Mit Secure Boot soll die Startumgebung von Systemen mit Schlüsseln abgesichert werden.
