GitHub wyłącza SHA-1 w HTTPS: czego nauczył brownout z 14 lipca

14 lipca GitHub na 18 godzin wyłączył obsługę SHA-1 w HTTPS. Brownout trwał od 00:00 do 18:00 UTC i miał ujawnić stare przeglądarki, biblioteki, klienty Git oraz integracje przed trwałą zmianą. Ostateczne wyłączenie SHA-1 w HTTPS/TLS dla GitHub i partnerskich CDN zaplanowano na 15 września 2026 r.

To nie jest temat wyłącznie dla administratorów GitHuba. Jeśli pipeline pobiera zależności, automaty wysyłają release’y, narzędzie skanujące odpytuje API albo starszy system wykonuje git pull po HTTPS, problem może zatrzymać proces biznesowy dopiero w dniu trwałego wyłączenia.

Najpierw ważne rozróżnienie

Zmiana dotyczy SHA-1 używanego w połączeniu HTTPS/TLS, czyli algorytmów potrzebnych podczas ustanawiania zaufanego kanału do GitHub. Nie oznacza automatycznej zmiany identyfikatorów obiektów Git ani polityki podpisów commitów.

To rozróżnienie ma znaczenie w komunikacji. Polecenie „znajdź SHA-1 w repozytoriach” może wygenerować tysiące normalnych 40-znakowych identyfikatorów commitów, a jednocześnie nie wykryć ani jednego starego klienta TLS, który faktycznie przestanie działać.

Co obejmuje harmonogram GitHub

brownout 14 lipca: SHA-1 wyłączony na github.com przez 18 godzin; CDN nie były objęte tym testem;
15 września: pełne wyłączenie SHA-1 w HTTPS/TLS dla GitHub i partnerskich CDN;
zakres: przeglądarki, GitHub API oraz Git przez HTTPS;
GitHub Enterprise Server: według komunikatu nie jest objęty tą zmianą.

GitHub udostępnia prosty test: wejście na https://github.dev, gdzie SHA-1 jest już wyłączony. Udane połączenie potwierdza zgodność konkretnej przeglądarki, ale nie testuje automatycznie Javy w Jenkinsie, klienta Git w obrazie kontenera ani biblioteki HTTP zaszytej w produkcyjnym skanerze.

Gdzie szukać starych klientów

Najbardziej oczywisty laptop dewelopera zwykle jest najmniejszym problemem, bo nowoczesne systemy i przeglądarki obsługują nowsze algorytmy. Ryzyko kryje się w elementach rzadko aktualizowanych:

self-hosted runners i stare obrazy CI/CD;
urządzenia sieciowe pobierające konfiguracje z repozytorium;
serwery z niewspieranym systemem lub środowiskiem Java;
wtyczki IDE, narzędzia release management i skanery;
wewnętrzne proxy TLS oraz urządzenia wykonujące inspekcję HTTPS;
skrypty wykorzystujące stary curl, OpenSSL albo bibliotekę HTTP;
integracje dostawców łączące się z GitHub API.

Brownout jest cennym źródłem danych. Sprawdź błędy pipeline’ów, alerty syntetyczne, zgłoszenia użytkowników i logi proxy z 14 lipca w godzinach 00:00–18:00 UTC. Błąd negocjacji TLS w tym oknie jest znacznie silniejszą wskazówką niż ogólna lista starych pakietów.

Test przed 15 września

Krok 1: spisz krytyczne przepływy

Nie inwentaryzuj jedynie kont użytkowników. Wypisz procesy: checkout kodu, pobieranie release’ów, wywołanie API, publikację artefaktu, webhook, skanowanie repozytorium i odtwarzanie środowiska po awarii.

Krok 2: uruchom je w reprezentatywnym środowisku

Test na laptopie nie potwierdza zgodności produkcyjnego runnera. Wykonaj próbę z tego samego obrazu, systemu, proxy i biblioteki, których używa proces docelowy.

Krok 3: obserwuj cały łańcuch

Jeśli połączenie przechodzi przez proxy lub inspekcję TLS, sprawdź obie negocjacje: klient–proxy i proxy–GitHub. Nowoczesny serwer pośredni nie naprawi starego klienta po swojej wewnętrznej stronie.

Krok 4: zaktualizuj i powtórz

Aktualizacja może obejmować system operacyjny, OpenSSL, środowisko Java, klienta Git albo samo urządzenie proxy. Zachowaj wynik testu po zmianie.

Nie czekaj na dzień migracji

15 września problem stanie się incydentem dostępności: build nie pobierze kodu, automatyczna publikacja stanie, a procedura disaster recovery może odkryć niezgodność w najgorszym momencie. Najbardziej kosztowny przypadek to integracja uruchamiana raz na miesiąc — nie wykonała się podczas brownoutu, więc pozostała niewidoczna.

Właściciel procesu powinien zaakceptować dowód, że reprezentatywny klient połączył się bez SHA-1. Sam wpis „biblioteka wygląda na nową” jest zbyt słaby.

Szersza lekcja dla kryptografii

Migracje algorytmów nie kończą się na ustawieniu serwera. Zależności, urządzenia pośredniczące i dawno zbudowane obrazy tworzą kryptograficzny dług techniczny. W ramach audytu bezpieczeństwa IT warto utrzymywać inwentaryzację wersji TLS, certyfikatów i bibliotek dla krytycznych integracji, zanim zewnętrzny dostawca wymusi termin.

Źródło pierwotne: GitHub Changelog — Sunsetting SHA-1 in HTTPS on GitHub.