CleanPress

Schlagwort: HTTPS

  • HTTPS statt HTTP im Kernel

    HTTPS statt HTTP im Kernel
    Bild: Fabio Lanari | Lizenz: CC BY-SA 4.0

    Vor einer Woche gab Linux Torvalds Kernel 5.8 frei. Jetzt ist die erste Woche des Merge-Windows für Einreichungen zum nächsten Kernel 5.9 vorbei.

    Unter den rund 4.000 bisherigen Einreichungen sind auch Patches, die im Hintergrund Änderungen und Bereinigungen an der Dokumentation und bei den Kommentaren des Kernel-Baums vornehmen. Dieses Mal geht es dabei um den Austausch von internen HTTP-Links gegen solche, die mit HTTPS gesichert sind.

    HTTP mit 320 Patches ersetzen

    Das betrifft sowohl Kommentare zum Code selbst als auch die Dokumentation an vielen Stellen des Kernels. Wer nun aber glaubt, ein einfaches find docs -type f -exec sed {} -i 's/http/https/g' ; würde den Job beispielsweise für die Dokumentation erledigen, der irrt. Kernel-Entwickler Alexander A. Klimov hat in den letzten Wochen über 320 Patches mit einem Algorithmus zum Suchen, Testen und Ersetzen für den Austausch an den betroffenen Stellen in linux-next platziert.

    Suchalgorithmus

    Dabei werden per Script die Vorkommen von HTTP herausgefiltert und festgestellt ob es einen entsprechenden HTTPS-Link gibt. Dann wird getestet, ob beide Varianten den Statuscode 200 OK sowie den gleichen Inhalt ausgeben. Im positiven Fall wird HTTP durch HTTPS ersetzt.

    Gegen Man-in-the-Middle

    Der Kernel folgt damit einem ungebremsten Trend bei Webseiten, die in den letzten Jahren, besonders seit der Verfügbarkeit von kostenlosen Zertifikaten per Let’s Encrypt, Inhalte durch HTTPS geschützt ausliefern. Damit werden unter anderem Man-in-the-Middle-Attacken wesentlich erschwert.

    Merge-Window noch eine Woche

    Der Abschluss der Umstellung wird mit der Veröffentlichung von Kernel 5.9 in rund zwei Monaten erwartet. Das Zeitfenster für Einreichungen wird noch bis zum 16. August geöffnet bleiben. Bereits jetzt sind viele Änderungen unter anderem bei Dateisystemen wie Btrfs eingereicht worden. Zudem soll das Power-Management des Kernels, das bisher auf CPUs beschränkt war, nun auf Peripheriegeräte ausgeweitet werden.

  • Google testet DNS over HTTPS mit Chrome 78

    Quelle: : HTTPS von Sean MacEntee Lizenz: CC BY 2.0

    Kurz nach der Ankündigung von Mozilla, DNS over HTTPS (DoH) noch im September öffentlich testen zu wollen, erklärt Google im Chromium Blog ebenfalls seine Absicht, Tests von DoH mit Chrome 78 beginnen zu wollen. Die Beta zu Chrome 78 erscheint am 19. September. DoH soll die Vorteile von HTTPS auch für DNS-Anfragen aus dem Browser bereitstellen.

    DNS over HTTPS mit Chrome 78

    Der Test umfasst zunächst alle Plattformen außer Linux und iOS. Google will für das Experiment einen anderen Weg einschlagen als Mozilla. Während die Firefox–Macher die DNS-Anfragen der teilnehmenden Anwender automatisch zu Cloudflare umleiten, stellt Google sechs Partner bereit und schaltet DoH nur für solche Anwender frei, die einen dieser Partner in ihrem Betriebssystem als DNS-Dienst eingetragen haben. Hier wird dann nur die Methode auf DoH umgestellt, alle anderen eventuell vorhandenen Einstellungen zu Sicherheit und Kinder- und Jugendschutz bleiben erhalten.

    Sechs Anbieter beim Test

    Google arbeitet anfänglich mit den Anbietern Cleanbrowsing, Cloudflare, DNS.SB, Google, OpenDNS und Quad9 zusammen. Wer einen dieser Anbieter in seinem Betriebssystem als DNS eingetragen hat, nimmt automatisch am Test teil. Wer das nicht möchte, kann den Test unter chrome://flags/#dns-over-https deaktivieren. Ausgenommen vom Test sind vorerst verwaltete Chrome-Bereitstellungen in Unternehmen und Institutionen, diese werden einen gesonderten Test durchlaufen, der demnächst im Chrome Enterprise Blog erläutert werden soll.

    Google beugt Kritik vor

    Google entzieht sich mit seiner Ausgestaltung des Tests zur Einführung von DoH zumindest in der Testphase der Kritik, die Mozilla für eine übermäßige Konzentration auf einen Anbieter entgegenschlägt. Wie die Praxis dann aussieht, wenn DoH zum Standard wird, bleibt abzuwarten.

  • Chrome warnt vor nicht registrierten HTTPS-Seiten

    Chrome warnt
    Photo by Jason Blackeye on Unsplash

    Ab dem 1. Mai gibt Google Chrome eine ganzseitige Warnung aus, wenn eine Webseite besucht wird, deren SSL-Zertifikat nicht in einem öffentlichen Zertifikatsverzeichnis registriert ist. Für Nutzer bedeutet dies einen zusätzlichen Schutz vor Websites, deren SSL-Zertifikate möglicherweise böswillig erworben wurden, um beispielsweise legitime Websites zu fälschen, Man-in-the-Middle-Angriffe zu starten oder Spyware zu verteilen. Die Zertifizierungsstellen wurden im Vorfeld über die jetzt umgesetzte Maßnahme informiert.

    Mittels SSL als kryptografischem Standard werden HTTPS-Verbindungen gesichert, sodass die Daten, die zwischen Webservern und dem Browser übertragen werden, sicher vor dem Zugriff Dritter sind. Beim Besuch einer Webseite stellt ein Authentifizierungsserver sicher, dass das von der Website verwendete SSL-Zertifikat ordnungsgemäß von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde und der Schlüssel nicht widerrufen wurde.

    Neue Richtlinie

    Googles neue Richtlinie für Chrome heißt Certificate Transparency, also in etwa Zertifikatstransparenz. Zertifizierungsstellen  (CAs) sind verpflichtet, ein öffentlich einsehbares Register zu führen, in dem täglich alle ausgestellten Zertifikate dieser Stelle verzeichnet werden. Wenn also eine Website ein von einer CA ausgestelltes Zertifikat besitzt, das nicht in einem dieser öffentlichen Register enthalten ist, erscheint ab sofort eine ganzseitige Warnung. Das bedeutet für den Anwender, dass das Zertifikat dieser Seite nicht Googles Richtlinien der Zertifikatstransparenz entspricht und möglicherweise unsicher ist.

    Andere Browser ziehen nach

    Auch andere Browserhersteller haben angekündigt, Zertifikatsmissbrauch auf ähnliche Weise zu verfolgen. Gerade mit dem Aufkommen von kostenfreien und in Sekunden erstellten Zertifikaten über die CA Let’s Encrypt steigt laut Sicherheitsexperten die Gefahr von Zertifikaten, die für kriminelle Zwecke erstellt werden. Zudem gab es in der Vergangenheit auch des Öfteren Probleme mit den CAs selbst. Fälle wie Trustico und GlobalSign liegen noch nicht weit zurück. Google sorgte wegen Unregelmäßigkeiten auch dafür, dass Symantec aus dem Geschäft mit Zertifikaten ausstieg. Hier kann Google seine Markmacht positiv einbringen, der hauseigene Browser Chrome hat immerhin rund 60 Prozent Marktanteil.

    [Edit 2.5. 08:56]

    Mittlerweile hat Google mitgeteilt, dass die neue Richtlinie zwar ab dem ersten Mai in Kraft ist und alle Zertifikate umfasst, die ab diesem Datum ausgestellt werden, Anwender die Warnungen allerdings erst mit der Veröffentlichung von Chrome 68 im Juli angezeigt bekommen.

     

     

  • Let’s Encrypt bietet Wildcard-Zertifikate

    Wildcard-Zertifikate
    Quelle: : HTTPS von Sean MacEntee Lizenz: CC BY 2.0

     

    Let’s Encrypt, die Certificate Authority (CA) für kostenlose TLS-Zertifikate zur Absicherung von Webseiten per HTTPS, gibt die Freigabe des ACMEv2-Protokolls bekannt. Damit einher geht die Möglichkeit, jetzt mit Let’s Encrypt auch Wildcard-Zertifikate auszustellen. Die Veröffentlichung kommt mit einigen Wochen Verspätung.  Der Grund für die Verschiebung war eine gemeldete Sicherheitslücke in TLS-SNI-01, einer der drei Validierungsmethoden von Let’s Encrypt. Die Nutzung von TLS-SNI zur Validierung von Domains wurde daraufhin gesperrt.

    Erste Clients sprechen ACMEv2

    Wie Josh Aas, Geschäftsführer von Let’s Encrypt in seiner Ankündigung schreibt, ist Acmev2 für Wildcard-Zertifikate zwingend, sodass der benutzte Client dieses neue Protokoll bereits unterstützen muss. Einige Clients unterstützen ACMEv2 bereits, aber bei weitem nicht alle. ACME steht für Automated Certificate Management Environment und dient zur automatischen Prüfung der Inhaberschaft von Internet-Domains bei der Ausstellung von Zertifikaten.

    Nicht immer empfohlen

    Laut Aas können Wildcard-Zertifikate die Zertifikatsverwaltung in einigen Fällen vereinfachen, allerdings empfiehlt er für die meisten Anwendungsfälle nach wie vor Nicht-Wildcard-Zertifikate. RFC 6125 beschäftigt sich mit den Sicherheitsaspekten von Wildcard-Zertifikaten. Über ein Let’s-Encrypt-Konto können über einen Zeitraum von drei Stunden bis zu 300 Wildcard-Zertifikate angefordert werden, sodass auch Hosting-Provider wie WordPress.com und andere, die Let’s Encrypt unterstützen, Anfragen ihrer Kunden zügig bearbeiten können.

    Eine Ebene von Subdomains

    Mit Wildcard-Zertifikaten können alle Subdomains einer Domain mit nur einem Zertifikat abgedeckt werden. Das gilt allerdings nur für eine Ebene von Subdomains. Die technischen Hintergründe zu ACMEv2 vermittelt ein Eintrag im Let’s-Encrypt-Community-Blog. Das Protokoll ist derzeit in der Phase der Standardisierung bei der Internet Engineering Task Force. Es können also noch geringfügige Änderungen am Protokoll einfließen, was die jetzige Nutzung zum Ausstellen von Wildcard-Zertifikaten aber nicht einschränkt.

  • Let’s Encrypt erreicht 50 Millionen aktive Zertifikate

    Let's Encrypt
    Logo: Let’s Encrypt Lizenz: CC BY-NC 4.0

     

    Die Zertifizierungsstelle  (CA) Let’s Encrypt hat die Marke von 50 Millionen aktiver Zertifikate überschritten. Das Ende 2014 gegründete freie Projekt ist mit dem Angebot kostenloser und automatisierter TLS-Zertifikate in drei Jahren zu einer der größten CAs weltweit geworden. Die Zertifikate verschlüsseln die Transportwege zwischen Webseiten und Servern per HTTPS und tragen damit erheblich zur Sicherheit des Internet bei. Hauptsponsoren des Projekts sind unter anderem Akamai, Cisco, die Electronic Frontier Foundation, die Ford-Foundation, Google und Mozilla.

    Bald auch Wildcard-Zertifikate

    Die Zahl der per Zertifikat von Let’s Encrypt geschützten Webseiten beläuft sich derzeit auf rund 66 Millionen. Damit konnte 2017 die Zahl der verschlüsselten Webseiten von 46 auf 67 Prozent angehoben werden. Für das Jahr 2018 hat sich die Internet Security Research Group (ISRG), die hinter Let’s Encrypt steht, viel vorgenommen. Die Zahl der aktiven Zertifikate sowie der eindeutigen Domains soll im kommenden Jahr auf 90, respektive 120 Millionen erhöht werden. Weitere Pläne für 2018 sehen mit dem ACME-Protokoll in Version 2 für Ende Februar die Unterstützung für Wildcard-Zertifikate vor. Später im Jahr will Let’s Encrypt ECDSA-Root-Zertifikate einführen. ECDSA gilt als die Zukunft digitaler Signatur-Algorithmen, die als effizienter als RSA angesehen werden.

    [su_slider source=“media: 4192,4193″ link=“image“ width=“700″ height=“460″ mousewheel=“no“ autoplay=“0″ speed=“0″]

    Einfach und kostenlos

    Der Erfolg von Let’s Encrypt liegt einerseits darin, dass die Zertifikate kostenfrei ausgegeben werden, andererseits aber auch an der Einfachheit mit der sie erstellt und automatisiert erneuert werden können. Mittlerweile gibt es über 60 Clients für unterschiedliche Plattformen, von denen der von der Electronic Fronmtier Foundation (EFF) entwickelte Certbot der bekannteste ist.

    Die Infrastruktur hinter der Certificate Authority (CA) Let’s Encrypt besteht derzeit aus rund 70 Servern, Switches und Firewalls. Der Finanzbedarf des Projekts bleibt dabei weiterhin relativ gering. Das Budget für 2018 beträgt gerade einmal drei Millionen US-Dollar.