en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Sicherheitsübersicht Dezember 2020

SSL.com wünscht allen Kunden und Besuchern eine glückliche, sichere und gesunde Weihnachtszeit und ein erfolgreiches Jahr 2021! Wir hoffen, dass das neue Jahr etwas kürzer wird, ähm ... interessant als 2020 war in gewisser Hinsicht, aber wir sind sicher, dass kein Monat ohne wichtige Neuigkeiten aus der Welt der Netzwerksicherheit, der digitalen Zertifikate und vergehen wird PKI.

OpenSSL DoS-Sicherheitsanfälligkeit

Wir haben dieses Problem in einem behandelt Blog-Post Anfang dieses Monats, aber es lohnt sich zu wiederholen. Eine hochschwere Sicherheitslücke in OpenSSL Es wurde festgestellt, dass alle Versionen von OpenSSL 1.0.2 und 1.1.1 vor 1.1.1i betroffen sind. Diese Sicherheitsanfälligkeit kann ausgenutzt werden, um einen Denial-of-Service-Angriff (DoS) durchzuführen. OpenSSL 1.1.1i, veröffentlicht am 8. Dezember 2020, enthält einen Fix.

OpenSSL-Benutzer sollten ihre Installationen so schnell wie möglich aktualisieren. Es gibt zwei Wege, um das Update anzuwenden:

  • Benutzer von OpenSSL 1.1.1 und nicht unterstützten 1.0.2-Benutzern sollten ein Upgrade auf 1.1.1i durchführen.
  • Premium-Support-Kunden von OpenSSL 1.0.2 sollten auf 1.0.2x aktualisieren.

OpenSSL ist derzeit auf den meisten HTTPS-Webservern installiert. Weitere Informationen zur Sicherheitsanfälligkeit finden Sie in SSL.com Blogund in den OpenSSL-Projekten Sicherheitshinweis.

Das Mitnehmen von SSL.com: Wenn Sie ein OpenSSL-Benutzer sind und dies noch nicht getan haben, lesen Sie bitte OpenSSLs beratend über die Sicherheitsanfälligkeit und aktualisieren Sie Ihre Installation so schnell wie möglich.

Cloudflare befürwortet neue Datenschutzprotokolle

Tim Anderson berichtet in dem Register, dass Cloudflare "auf die Einführung neuer Internetprotokolle drängt, die ein" datenschutzrechtliches Internet "ermöglichen sollen." Diese Protokolle enthalten eine Verbesserung der Privatsphäre DNS über HTTPS (DoH), zusätzliche Verschlüsselung für die TLS Handschlagund Sicherheitsverbesserungen für den Umgang mit Benutzerkennwörtern.

Vergessliches DoH

DNS über HTTPS (DoH) Behebt ein schwaches Glied im Datenschutz im Internet, indem DNS-Abfragen und -Antworten verschlüsselt werden, die in der Vergangenheit als Klartext gesendet wurden. Oblivious DoH (ODoH)  Der Schutz der DNS-Privatsphäre geht noch einen Schritt weiter, indem verhindert wird, dass DoH-Server die IP-Adresse des Clients kennen:

Das Wesentliche von ODoH ist, dass es einen Netzwerk-Proxy zwischen dem Client und dem DoH-Server einführt. Der Proxy hat keinen Einblick in die DNS-Abfrage, die nur vom DoH-Server gelesen werden kann. Der Server kennt die IP-Adresse des Clients nicht. Die Abfrage ist privat, sofern der Proxy und der Server nicht zusammenarbeiten.

Cloudflare hat bereits die Unterstützung für ODoH erklärt, das von Ingenieuren bei Cloudflare, Apple und Fastly entwickelt wurde. Sie können mehr erfahren, indem Sie auschecken ihr Papier bei arxiv.org.

Verschlüsselter Client Hallo (ECH)

Verschlüsselter Client Hallo (ECH) bietet erweiterte Handshake-Verschlüsselung in TLS, darüber hinausgehen Verschlüsseltes SNI (ESNI), die nur die Server Name Indication (SNI) in der TLS Handschlag. Christopher Patton, Forschungsingenieur für Cloudflare schreibt,

Obwohl ESNI einen bedeutenden Schritt nach vorne gemacht hat, bleibt es hinter unserem Ziel zurück, eine vollständige Handshake-Verschlüsselung zu erreichen. Abgesehen davon, dass es unvollständig ist - es schützt nur SNI -, ist es anfällig für eine Handvoll raffinierter Angriffe, die zwar schwer zu lösen sind, aber auf theoretische Schwächen im Protokolldesign hinweisen, die behoben werden müssen.
...
Letztendlich ist es das Ziel von ECH, dies sicherzustellen TLS Verbindungen zu verschiedenen Ursprungsservern hinter demselben ECH-Dienstanbieter sind nicht voneinander zu unterscheiden.

Es überrascht nicht, dass sich Cloudflare als wahrscheinlicher ECH-Anbieter versteht, da ECH „nur neben DoH und im Kontext eines CDN (Content Distribution Network) Sinn macht“. Sie können mehr über ECH in den IETFs lesen Entwurfsvorschlag.

OPAQUE Passwörter

OPAQUE-Passwörter - eine Art Wortspiel für Oblivious Pseudo-Random Function (OPRF) in Kombination mit PAKE (Password Authenticated Key Exchange) - sind ein Mechanismus, mit dem die Übertragung des Passworts eines Benutzers auf einen Server vollständig vermieden werden kann. OPAQUE erreicht dies, indem „Server und Client gemeinsam einen gesalzenen Hash berechnen, um ihn mit einem zwischengeschalteten zweiten Salt zu vergleichen. Dies stellt sicher, dass der Server das Kennwort des Benutzers während der Authentifizierung nicht lernen kann und der Benutzer das geheime Salz des Servers nicht lernt. “

Weitere Informationen zu OPAQUE-Passwörtern finden Sie unter Dieses Papier [PDF-Link] von Forschern der University of California, Irvine und IBM sowie von Tatiana Bradley, Cloudflare-Ingenieurin Blog-Post.

Das Mitnehmen von SSL.com: Wir sind immer gespannt auf neue Netzwerksicherheitsprotokolle, insbesondere in Bezug auf diese PKI und digitale Zertifikate. Wir werden Ihnen weitere Informationen zu diesen und anderen Sicherheits- und Datenschutzverbesserungen zur Verfügung stellen, sobald diese angezeigt und implementiert werden.

Durchgesickerte FTP-Anmeldeinformationen sind möglicherweise mit SolarWinds Attack verbunden

Sofern Sie die letzten Wochen nicht in einer abgelegenen, netzunabhängigen Kabine verbracht haben (keine schlechte Idee, jetzt wo wir darüber nachdenken), haben Sie wahrscheinlich schon eine ganze Menge über das gehört Supply-Chain-Angriff Dies beeinträchtigte die Orion-IT-Überwachungssoftware von SolarWinds und viele seiner Benutzer in Regierung und Industrie. Ravie Lakshmanans 16. Dezember Story In den Hacker News wird erläutert, wie es den Angreifern wahrscheinlich bereits im Oktober 2019 gelungen ist, die Software-Build- und Codesignatur-Infrastruktur der SolarWinds Orion-Plattform zu gefährden, um die böswillige Hintertür durch den Software-Release-Prozess bereitzustellen.

Die Idee… war, das Build-System zu kompromittieren, leise ihren eigenen Code in den Quellcode der Software einzufügen, auf die Kompilierung des Unternehmens zu warten, Pakete zu signieren und schließlich zu überprüfen, ob ihre Änderungen in den neu veröffentlichten Updates wie erwartet angezeigt werden.

Die Zeitleiste vom Oktober 2019 stimmt mit der des Sicherheitsforschers Vinoth Kumer überein Entdeckungim November 2019 eines öffentlichen GitHub-Repos, bei dem Klartext-FTP-Anmeldeinformationen für den Update-Server von Solarwinds verloren gingen - und dass auf diesen Server mit dem Kennwort „solarwinds123“ zugegriffen werden konnte. Das fragliche Repo war „seit dem 17. Juni 2018“ für die Öffentlichkeit zugänglich, sodass potenzielle Angreifer genügend Zeit hatten, die durchgesickerten Anmeldeinformationen zu entdecken und auszunutzen.

Natürlich hat es nicht geholfen, dass SolarWinds den Benutzern auch geraten hat, Sicherheitsmaßnahmen zu deaktivieren:

Erschwerend kommt hinzu, dass bösartiger Code, der einem Orion-Softwareupdate hinzugefügt wurde, aufgrund von SolarWinds möglicherweise von Antivirensoftware und anderen Sicherheitstools auf Zielsystemen nicht bemerkt wurde Support-BeratungDies besagt, dass seine Produkte möglicherweise nicht ordnungsgemäß funktionieren, es sei denn, ihre Dateiverzeichnisse sind von Antivirenscans und Gruppenrichtlinienobjektbeschränkungen (Group Policy Object, GPO) ausgenommen.

Das Mitnehmen von SSL.com: Codesignatur Dies ist ein wichtiger, sogar obligatorischer Schritt zur Aufrechterhaltung des Vertrauens bei der Verteilung von Software an Kunden. Für den Erfolg ist jedoch eine sichere Umgebung erforderlich. Durch den Schutz wichtiger Server mit schwachen, leicht zu erratenden Kennwörtern und / oder die versehentliche Offenlegung von Klartext-Anmeldeinformationen für die Öffentlichkeit bleibt eine Tür offen für Angriffe, die Ihr Build-System ausnutzen, um signierte, jedoch trojanische Software freizugeben.

Abonnieren Sie den Newsletter von SSL.com

Verpassen Sie keine neuen Artikel und Updates von SSL.com