GitHub-Sicherheit: Unverschlüsselte Git-Protokolle demnächst Geschichte

Inhaltsverzeichnis

Zurzeit führt GitHub Maßnahmen zur Erhöhung der Sicherheit der bei ihm gehosteten Code-Repositorys durch. Wie das Git-System-Team per Blogeintrag mitteilt, ist ab sofort beim Pushen und Pullen von Git-Daten ein verschlüsseltes Git-Protokoll Pflicht. Die Änderungen betreffen einige in SSH unterstützte Keys, und unverschlüsselte Git-Protokolle sind dem System-Team zufolge nun Geschichte.

Konkret unterstützt GitHub keine DSA-Keys mehr (Digital Signature Algorithm) und einige Legacy-SSH-Algorithmen wie HMAC-SHA-1 und CBC Ciphers enfallen. Besonders Letztere sollen für Angreifer ein leichtes Ziel geworden sein. Für SSH sind zwei neue Host-Keys hinzugekommen (ECDSA und Ed25519), die auf einer elliptischen Kurven-Kryptografie beruhen. Neu ergänzte RSA-Keys (Rivest-Shamir-Adleman) sollen künftig zusätzlichen Sicherheitsauflagen durch eine SHA-2-Signatur unterliegen.

Änderungen betreffen nicht alle GitHub-Nutzer

Laut System-Team sollten die meisten Nutzerinnen und Nutzer ihre Arbeit allerdings uneingeschränkt fortsetzen können: Nur, wer sich über SSH oder git:// mit Repositorys verbindet, ist laut Ankündigung betroffen. Beginnt das eigene Git hingegen mit https://, steht keine Disruption ins Haus. GitHub hatte vor Kurzem die Passwort-Authentifizierung für Git Actions verworfen: Während die Verschlüsselungspflicht für Git-Protokolle in keinem technischen Zusammenhang damit steht, sind beide Neuerungen dem Blogeintrag zufolge Teil einer GitHub-Kampagne zur Absicherung der Nutzerdaten.

Dass GitHub ältere Key-Typen und einige Algorithmen beispielsweise für das Signieren aufgibt, ist laut System-Team Sicherheitsbedenken wegen zunehmender Angriffe und neuer Angriffsmethoden geschuldet. Was vor Jahrzehnten als sicher galt, ist es heute nicht mehr unbedingt, lautet das Motto. So haben DSA-Keys lediglich ein Sicherheitsniveau von 80 Bit, der heutige Standard liegt bei 128 Bit. Den meisten GitHub-Nutzern dürfte das bewusst sein, denn gemäß einer internen Statistik des Code-Hosters verwenden deutlich unter einem Prozent der GitHub-Anfragen DSA (0,3 Prozent). Den DSA-Host-Key will GitHub künftig auch entfernen.

GitHub zieht veraltete Signatur-Algorithmen aus dem Verkehr

Als sicherer gelten RSA-Keys (ssh-rsa), allerdings kommen sie bei älteren Git-Clients oft in Kombination mit veralteten Signatur-Algorithmen zum Einsatz (SHA-1-basiert). Als sicher gelten hier Kombinationen aus RSA und SHA-2-Signatur, auch OpenSSH ab Version 7.2 (rsa-sha2-256 und rsa-sha2-512). Das als zu schwach geltende SHA-1 ist der Grund dafür, dass GitHub neue RSA-Klienten dazu zwingt, SHA-2-Signaturen zu verwenden. Dennoch steht es den Nutzerinnen und Nutzern vorerst frei, SHA-1-Signaturen weiter zu verwenden, sofern ihre Keys ein valid_after-Datum vor dem Stichtag aufweisen. Für alle ab dem 2. November 2021 angelegten Keys soll eine SHA-2-Signatur erforderlich sein.

Das Git-Team hat einen Zeitplan für die bevorstehenden Änderungen geteilt, so sollen die neuen Host-Keys bereits ab dem 14. September 2021 verfügbar sein, und zwar durch die UpdateHostKeys-Extension. Den weiteren Vorgang bezeichnet das Team als "Brownout", gemeint ist wohl ein schrittweises Runterfahren: Ab dem 2. November entfällt die Option, RSA-Keys mit dem SHA-1-Algorithmus einzurichten und SHA-2 wird verbindlich. Die beiden Host-Keys ECDSA und Ed25519 sollen ab dem 16. November vollständig in Betrieb gehen, zeitgleich fällt der bisherige DSA-Host-Key aus dem Support.

Fahrplan: Brownout bis Januar, Blackout im März 2022

Der sogenannte Brownout soll am 11. Januar 2022 abgeschlossen sein: Ab diesem Stichtag akzeptiert GitHub als veraltet gekennzeichnete Key- und Signatur-Typen nicht mehr neu, und auch Ciphers, MACs und unverschlüsselte Git-Protokolle sollen sich dann nicht mehr neu anlegen lassen. In Stein gemeißelt ist das Ende der DSA-Keys laut Team ab dem 15. März 2022, die angepeilten Änderungen gelten ab diesem Datum dauerhaft.

Wer bei GitHub Repositorys betreibt, sollte in diesem Zeitfenster seine Schlüssel prüfen und gegebenenfalls ein SSH- oder Git-Protokoll-Troubleshooting vornehmen. Weitere Informationen hierzu finden sich im Blogeintrag des Git-System-Teams.

(sih)