Możliwości szyfrowania przeglądarki: co potrafią nowoczesne przeglądarki

Nowoczesne przeglądarki mają wbudowaną kryptografię dorównującą dedykowanym bibliotekom bezpieczeństwa. Chrome, Firefox, Safari i Edge udostępniają Web Crypto API (crypto.subtle), implementują TLS 1.3 z mechanizmami zastępującymi HPKP, obsługują WebAuthn/passkeys do uwierzytelniania odpornego na phishing, izolują każde źródło poprzez Site Isolation i zapewniają sprzętowe przechowywanie kluczy przez Trusted Platform Module na Windows oraz Secure Enclave na macOS/iOS. Dla programistów budujących szyfrowane narzędzia do transferu plików oznacza to, że AES-256-GCM, wyprowadzanie kluczy przez PBKDF2 i uwierzytelnianie FIDO2 są dostępne bez żadnej zewnętrznej biblioteki. Oto co każda przeglądarka potrafi w 2026 roku.

Web Crypto API: wspólna podstawa

Wszystkie cztery główne przeglądarki obsługują W3C Web Cryptography API z niemal identycznym zakresem funkcji. Podstawowe algorytmy to:

• Symetryczne: AES-GCM, AES-CBC, AES-CTR, AES-KW (128, 192, 256-bitowe)
• Asymetryczne: RSA-OAEP, RSA-PSS, RSASSA-PKCS1-v1_5 (do 4096-bitowych), ECDSA i ECDH (P-256, P-384, P-521)
• Hashowanie: SHA-1, SHA-256, SHA-384, SHA-512
• Wyprowadzanie kluczy: PBKDF2, HKDF
• MAC: HMAC

Czego brakuje: ChaCha20-Poly1305 (brak wsparcia w przeglądarkach), Argon2 (brak wsparcia), Ed25519/X25519 (Safari 17+ i Firefox 129+ mają, Chrome nadrabia zaległości). Do tych algorytmów nadal potrzebne są biblioteki JavaScript lub WASM, takie jak libsodium.js czy @noble/curves.

Chrome i Edge współdzielą tę samą implementację kryptografii (BoringSSL przez V8). Firefox używa NSS. Safari używa CoreCrypto, biblioteki Apple walidowanej według FIPS. Wydajność różni się: iteracje PBKDF2 w Firefox są o ~20% wolniejsze niż w Chrome na tym samym sprzęcie; AES-GCM Safari z akceleracją sprzętową na Apple Silicon jest ~2x szybszy niż Chrome na tym samym Mac.

TLS 1.3 i przejrzystość certyfikatów

Każda główna przeglądarka domyślnie używa TLS 1.3 dla obsługiwanych źródeł i cofa się do 1.2 wyłącznie dla starszych serwerów. Chrome usunął wsparcie TLS 1.0 i 1.1 w Chrome 84 (lipiec 2020). Firefox usunął je w Firefox 78. Safari zrezygnował w macOS 11 / iOS 14.

Certificate Transparency jest wymuszane: certyfikaty wystawione po kwietniu 2018 muszą pojawić się w co najmniej dwóch logach CT, inaczej Chrome i Safari je odrzucają. To pozwoliło wczesnie wykrywać ataki w stylu DigiNotar, czyniąc błędne wystawianie certyfikatów przez CA publicznie audytowalnym. Mozilla's Firefox zaczął wymuszać CT od Firefox 117 (2023).

Przypinanie kluczy publicznych przez nagłówek HPKP zostało wycofane (Chrome 72 usunął wsparcie), ponieważ umożliwiało ataki blokowania. Nagłówki Expect-CT służyły temu samemu celowi monitorowania i same są wycofywane, gdy CT stało się obowiązkowe. Przedsiębiorstwa potrzebujące przypinania mają je nadal przez zaufane główne certyfikaty w zarządzanych konfiguracjach (MDM na macOS, polityki Chrome Enterprise).

Izolacja źródeł i sandboxing

Site Isolation Chrome umieszcza każde źródło we własnym procesie systemu operacyjnego od 2018 roku (desktop) i 2019 roku (Android). Fission Firefox osiąga to samo od Firefox 94. Safari używa modelu WebKit na proces. Dla szyfrowania oznacza to, że złośliwy skrypt cross-origin nie może odczytać odszyfrowanego pliku z pamięci sąsiedniej karty, ponieważ ta działa w innym procesie z własnym stósem.

Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP) i Cross-Origin-Resource-Policy (CORP) pozwalają stronom zdecydować się na jeszcze ściślejszą izolację. Ustawienie Cross-Origin-Opener-Policy: same-origin i Cross-Origin-Embedder-Policy: require-corp włącza izolację cross-origin, która z kolei odblokowuje SharedArrayBuffer i timery wysokiej rozdzielczości. Istotne dla kryptografii, ponieważ ataki timing w stylu Spectre przeciwko implementacjom AES są łagodzone, gdy atakujący nie może otworzyć SAB w Twoim źródle.

WebAuthn i passkeys do uwierzytelniania

FIDO2 WebAuthn jest obsługiwany w Chrome 67+, Firefox 60+, Safari 14+ i Edge 18+. Pozwala aplikacjom uwierzytelniać użytkowników za pomocą kluczy sprzętowych (YubiKey, Titan), uwierzytelniaczy platformowych (Face ID, Windows Hello, biometria Android) lub passkeys synchronizowanych między urządzeniami użytkownika przez iCloud Keychain, Google Password Manager lub 1Password.

Dla aplikacji transferu pliku WebAuthn zastępuje hasła jako czynnik chroniący dostęp do przechowanego linku. Co istotne, WebAuthn jest odporny na phishing: podpis jest powiązany ze źródłem, więc podobna domena nie może przechwycić danych uwierzytelniających. Chrome i Safari przeszły na domyślne przepływy oparte na passkeys w 2023–2024.

Sprzętowe przechowywanie kluczy

Na Windows układ TPM 2.0 (obowiązkowy w Windows 11) może przechowywać klucze Web Crypto wygenerowane jako nieekstrahowalne przez most Windows CNG. Na macOS i iOS Secure Enclave przechowuje klucze używane do Face ID, Touch ID i passkeys. Na Android, Keystore zabezpieczony przez StrongBox (sprzętowy) lub TEE (Trusted Execution Environment) zapewnia podobną ochronę.

W praktyce: klucz wygenerowany jako extractable: false przez Web Crypto na nowoczesnym laptopie może żyć w TPM lub Secure Enclave, a nie w głównej pamięci. Nawet pełny exploit przeglądarki, który zrzuca pamięć JavaScript, nie uzyska surowych bajtów klucza. Dla narzędzi transferu pliku jest to najbardziej przydatne dla długoterminowych kluczy odbiorców; efemeryczne klucze AES per plik nie potrzebują tej ochrony.

Content Security Policy jako mnożnik bezpieczeństwa kryptograficznego

Szyfrowanie jest bezużyteczne, jeśli złośliwy skrypt może odczytać jawny tekst przed zaszyfrowaniem. Nagłówki Content Security Policy pozwalają stronie deklarować, które skrypty mogą być uruchamiane. Rygorystyczna polityka jak:

Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-abc123';

blokuje skrypty inline i kod zewnętrznych dostawców, nie pozostawiając powierzchni ataku dla wstrzykniętych ładunków kradnących klucze kryptograficzne. Wszystkie główne przeglądarki obsługują CSP Level 3. Dla aplikacji transferu pliku połącz CSP ze Subresource Integrity (SRI) dla wszelkich zewnętrznych skryptów, aby upewnić się, że nawet dozwolony zewnętrzny JS nie został zmodyfikowany.

File System Access API i OPFS

File System Access API (Chrome 86+, Edge 86+, częściowo Safari 15.2+ przez Origin Private File System) pozwala aplikacjom webowym czytać i zapisywać lokalne pliki za zgodą użytkownika. Origin Private File System jest szczególnie istotny dla szyfrowania: to prywatny system plików per źródło, zarządzany przez przeglądarkę, używany do buforowania dużych zaszyfrowanych ładunków przed wysłaniem bez ładowania całości do pamięci.

Firefox był wolniejszy we wdrożeniu FSA, ale obsługuje OPFS od Firefox 111. Safari obsługuje OPFS wszechstronnie, ale ma bardziej restrykcyjne zachowanie dla szerszego File System Access API.

Czego przeglądarki nadal nie robią dobrze

Kilka luk pozostaje:

• Argon2 do wyprowadzania kluczy jest nieobecny w Web Crypto. Używaj bibliotek WASM do hashowania haseł powyżej PBKDF2.
• ChaCha20-Poly1305 nie jest dostępny. AES-GCM pokrywa większość potrzeb, ale ChaCha pomogłby na urządzeniach bez AES-NI (starszy ARM).
• Atestacja kluczy dla kluczy zabezpieczonych sprzętowo jest ograniczona. WebAuthn zapewnia atestację; szersze Web Crypto API nie.
• Strumieniowe AEAD nie jest jeszcze częścią specyfikacji. Szyfrowanie dużych plików wymaga logiki fragmentowania lub WASM.
• Algorytmy post-kwantowe (Kyber, Dilithium) nie są jeszcze w przeglądarce. Google wdrożył Kyber w uzgodnieniach TLS (Chrome 116+), ale kryptografia post-kwantowa dostępna z JavaScript to nadal domena bibliotek.

Co stosować do transferu pliku

Wiarygodny stos transferu pliku oparty na przeglądarce w 2026 roku:

• AES-256-GCM przez crypto.subtle.encrypt do zawartości pliku
• PBKDF2-SHA-256 przy 600 000 iteracjach dla kluczy wyprowadzanych z hasła
• crypto.getRandomValues() dla soli i nonce (nigdy Math.random)
• Fragmenty URL (#key=...) do przekazywania kluczy po stronie klienta bez ekspozycji serwera
• HTTPS z minimum TLS 1.3, HSTS włączone, COOP/COEP dla izolacji
• CSP strict-dynamic, bez skryptów inline
• Passkeys WebAuthn dla wszelkich funkcji przechowywanych kont
• OPFS do buforowania dużych plików na Chrome/Edge/Safari 16+

HexaTransfer korzysta z tego stosu. Podobnie SwissTransfer, Tresorit Send, Cryptpad i Proton Drive Share. Prymitywy są dojrzałe i spójne między przeglądarkami.

Testowanie w różnych przeglądarkach

Zawsze testuj we wszystkich czterech. Rzeczywiste błędy: Firefox zgłasza OperationError dla danych wejściowych PBKDF2, które Chrome akceptuje cicho. FileReader Safari jest wolniejszy dla plików powyżej 2 GB. Zapisy OPFS Chrome są fragmentowane dla plików powyżej 4 GB w niektórych wersjach. Monity weryfikacji użytkownika WebAuthn różnią się znacznie (Face ID vs Touch ID vs Windows Hello vs biometria Android). Użyj BrowserStack, Sauce Labs lub lokalnej matrycy fizycznych urządzeń do testów przed wydaniem.

Przeglądarki po cichu stały się jedną z najbardziej kompletnych platform kryptograficznych. Te same standaryzowane prymitywy, które zasilają aplikacje bankowe, menedżery haseł i klientów wiadomości, są dostępne za jednym wywołaniem JavaScript dla każdego budującego szyfrowane narzędzia do transferu pliku.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.