Model bezpieczeństwa
Routery sprawdzają podpisy wydań przed instalacją aktualizacji. Ogranicza to skutki przejęcia serwera dystrybucji, pod warunkiem ochrony klucza podpisującego i magazynu zaufania routera oraz poprawnej weryfikacji. Podpis potwierdza autentyczność; nie gwarantuje, że podpisane oprogramowanie nie ma błędów.
Skutki przejęcia serwera
- Wstrzymanie aktualizacji. Napastnik może przestać udostępniać aktualizacje. Routery zostają wtedy przy obecnej wersji, a czas ostatniego udanego sprawdzenia przestaje się zmieniać – widać to w panelu administracyjnym.
- Podmiana plików. Napastnik może podawać uszkodzone lub zmienione pliki. Routery odrzucą je przy sprawdzaniu podpisu, zanim cokolwiek zostanie rozpakowane.
- Udostępnianie starych wydań. Poprawny podpis nie potwierdza aktualności pliku. Router odrzuca manifest starszy od wcześniej przyjętego, katalog z niższym numerem wydania oraz manifest przekraczający maksymalny wiek — domyślnie 90 dni. Kontrole ograniczają możliwość cofania wersji i wstrzymywania aktualizacji, ale nie gwarantują natychmiastowego wykrycia każdego nowego wydania.
- Obserwacja ruchu. Napastnik kontrolujący serwer może widzieć adresy IP, certyfikaty urządzeń i żądane pliki. Skracanie adresów w zwykłych dziennikach dostępu ogranicza zapisane dane, ale nie zapobiega tej obserwacji ani nie zapewnia anonimowości.
- Podszywanie się pod serwer. Kradzież klucza tożsamości Ed25519 pozwala podszywać się pod serwer w nowych, opcjonalnych sesjach wymiany kluczy. Sama kradzież tego klucza nie ujawnia wcześniejszych sesji, przy zachowaniu założeń kryptograficznych i pod warunkiem, że ich sekrety nie zostały przejęte. Napastnik kontrolujący działający serwer może odczytać sekrety aktywnych sesji z pamięci.
Napastnik może zmienić tę stronę i opublikować dowolne pliki. Bez prywatnego klucza podpisującego wydania SLH-DSA nie może nadać zmienionemu oprogramowaniu poprawnego podpisu. Router z poprawnie działającą weryfikacją odrzuci je. Prywatny klucz podpisujący ma być przechowywany offline, osobno od tego serwera; publiczny klucz do weryfikacji znajduje się na serwerze i routerach.
Obecne routery GADNET pobierają pliki przez HTTPS z certyfikatem urządzenia i lokalnie sprawdzają podpisy wydań. Nie korzystają z opisanej poniżej opcjonalnej wymiany kluczy na poziomie aplikacji.
Zabezpieczenia
| Ryzyko | Zabezpieczenie |
|---|---|
| Błędy kontroli dostępu | Strony serwisu są publiczne. Pliki wydań – manifesty, pakiety, raporty, wykazy i zestaw kluczy – są udostępniane wyłącznie routerom GADNET, które przedstawią certyfikat urządzenia z ważnym poświadczeniem floty. Wydania publikuje się bezpośrednio w systemie plików serwera, nigdy przez HTTP. |
| Wyjście poza katalog (path traversal) | Żądania plików wydań są sprawdzane w zweryfikowanym katalogu dozwolonych ścieżek, zamiast być bezpośrednio łączone z dowolnymi ścieżkami w systemie plików. Serwis udostępnia też własne pliki statyczne oraz odrębnie podpisane katalogi kluczy i polityk przez przeznaczone do tego adresy. |
| Błędy kryptograficzne | Wyłącznie HTTPS z HSTS. Opcjonalne sesje wymiany kluczy korzystają z hybrydy X25519 + ML-KEM-768, HKDF-SHA-384 i AES-256-GCM, a kody MAC są porównywane w stałym czasie. |
| Wstrzykiwanie poleceń (injection) | Serwer nie używa bazy danych ani powłoki. OpenSSL jest uruchamiany z listą argumentów, a nie przez powłokę. Szablony automatycznie zabezpieczają wyświetlane dane, a jedyne dane od użytkownika, które trafiają na stronę, to sprawdzone fragmenty ścieżki. |
| XSS | Serwis nie zawiera JavaScriptu, a jego polityka Content Security Policy to default-src 'none' – dopuszcza wyłącznie własne style, czcionki i obrazy. Jedynym wyjątkiem jest opcjonalny test w przeglądarce na stronie testu połączenia: jeden plik z tego serwera, uruchamiany dopiero na prośbę odwiedzającego, z osobną polityką, która dodaje script-src 'self' wraz z connect-src 'none' i Trusted Types. Pliki wydań są wysyłane jako załączniki do pobrania (Content-Disposition: attachment) z nagłówkiem nosniff, więc przeglądarka nigdy nie wyświetli ich jako strony. |
| CSRF / narzucenie sesji | Publiczna strona nie udostępnia operacji administracyjnych opartych na ciasteczkach ani sesjach logowania przeglądarki. Strony nie zawierają formularzy. Żądania w ramach opcjonalnych sesji wymiany kluczy mają osobne uwierzytelnienie; nie publikują wydań ani nie zmieniają ustawień routera. |
| Błędna konfiguracja | Bez klucza tożsamości serwer się nie uruchomi; bez klucza publicznego wydań uruchomi się, ale nie opublikuje żadnego wydania. Kanał, który nie przejdzie weryfikacji, jest wycofywany, a wewnętrzny test gotowości (/ready) zgłasza błąd. Interaktywna dokumentacja API jest wyłączona, a nagłówek serwera nie ujawnia wersji oprogramowania. |
| Podmiana nagłówka Host | Żądania z nagłówkiem Host innym niż skonfigurowana domena otrzymują odpowiedź 421. Pełne adresy są budowane na podstawie konfiguracji, nigdy na podstawie żądania. |
| Odmowa usługi (DoS) | Limity liczby żądań z jednego adresu IP są niższe dla wymiany kluczy. Ograniczone są też liczba sesji i klientów, rozmiar żądań oraz liczba równoległych operacji OpenSSL. Pomaga to chronić zasoby serwera, ale nie zapewnia dostępności podczas każdego ataku DoS. |
| Błędy rejestrowania zdarzeń | Dziennik dostępu aplikacji zapisuje jeden ustrukturyzowany wpis na żądanie. Znaki sterujące są zastępowane, a adresy klientów skracane. Inne komponenty mogą zapisywać dodatkowe zdarzenia; nie oznacza to, że każdy dziennik we wdrożeniu zawiera wyłącznie skrócone adresy. |
| Ujawnianie informacji | Serwer nigdy nie zwraca śladów stosu wywołań. Komunikaty o błędach walidacji wskazują nieprawidłowe pole, ale nie powtarzają jego wartości. Brakujący kanał i brakujący plik dają tę samą odpowiedź 404. |
Odporność postkwantowa
Podpisy wydań korzystają z SLH-DSA-SHA2-128s, postkwantowego algorytmu opisanego w FIPS 205. Autentyczność nadal zależy od ochrony kluczy podpisujących i poprawnej weryfikacji.
Opcjonalna wymiana kluczy łączy X25519 i ML-KEM-768 (FIPS 203). Przy spełnieniu założeń bezpieczeństwa ma chronić dane sesji przed przyszłym odszyfrowaniem z użyciem komputerów kwantowych. Podpis Ed25519 pozostaje klasyczny, więc uwierzytelnienie nie jest w pełni postkwantowe. Mechanizm nie ukrywa adresów żądań ani danych identyfikujących plik.
Zgłaszanie podatności
Dane kontaktowe znajdziesz w pliku /.well-known/security.txt (RFC 9116). Prosimy o opis, który pozwoli odtworzyć problem. Potwierdzimy otrzymanie zgłoszenia i poinformujemy, w którym wydaniu i kiedy pojawi się poprawka.