TLS a szyfrowanie end-to-end: co warto wiedzieć

TLS (Transport Layer Security) szyfruje dane w trakcie przesyłania między urządzeniem a serwerem, po czym je odszyfrowuje po dotarciu — operator serwera może odczytać pliki w postaci tekstu jawnego. Szyfrowanie end-to-end (E2EE) szyfruje treść na urządzeniu nadawcy kluczem, który posiada wyłącznie odbiorca, więc serwery nigdy nie widzą niezaszyfrowanych danych. W przypadku transferu plików TLS chroni przed podsłuchem w sieci, ale nie przed samym dostawcą. E2EE chroni przed obydwoma. Kłódka w przeglądarce nie mówi, który z tych modeli jest faktycznie stosowany.

Co tak naprawdę chroni TLS

TLS 1.3, ustandaryzowany w RFC 8446, to protokół napędzający każde połączenie HTTPS. Negocjuje klucz sesji przy użyciu ECDHE na krzywych takich jak X25519, uwierzytelnia serwer certyfikatem X.509 i opakowuje ruch HTTP szyfrem AES-128-GCM lub ChaCha20-Poly1305. To doskonała ochrona przed atakującym w kawiarniowym Wi-Fi lub dostawcą internetu próbującym odczytać żądania.

Czego TLS nie robi: kończy działanie na load balancerze. Gdy prześlemy 3 GB wideo do typowej usługi udostępniania plików, TLS odszyfrowuje je na krawędzi sieci, a plik w postaci tekstu jawnego trafia do zasobnika S3, potoku transkodowania, ewentualnie zadania skanowania treści przez model ML, a następnie do strumienia pobierania — zaszyfrowanego nową sesją TLS. Usługa ma pełny dostęp do odczytu na każdym etapie.

Gdzie zaczyna się i kończy szyfrowanie end-to-end

Prawdziwe E2EE przesuwa granicę szyfrowania z serwera na punkty końcowe. W przeglądarce lub kliencie nadawcy generowany jest w pamięci klucz symetryczny (zazwyczaj AES-256-GCM). Plik jest szyfrowany porcja po porcji, zanim choćby jeden bajt opuści urządzenie. Szyfrogram jest przesyłany przez TLS na serwer, który przechowuje nieprzezroczyste bloki. Odbiorca otrzymuje klucz deszyfrowania przez oddzielny kanał — najczęściej jako fragment URL po symbolu #, który przeglądarki nigdy nie wysyłają na serwer.

W tym modelu serwer jest głupią warstwą przechowywania. Nawet pełny nakaz sądowy, nieuczciwy pracownik z dostępem do bazy danych lub dostawca chmury odczytujący migawki dysku uzyska jedynie zaszyfrowane bajty. Taką architekturę stosuje HexaTransfer: AES-256-GCM z kluczem per transfer derywowanym po stronie klienta, który nigdy nie jest wysyłany do serwera.

Porównanie: wyłącznie TLS a szyfrowanie end-to-end

| Właściwość | Transfer wyłącznie TLS | Szyfrowanie end-to-end | |---|---|---| | Szyfr w tranzycie | AES-128/256-GCM | AES-256-GCM (+ TLS) | | Serwer widzi tekst jawny | Tak | Nie | | Lokalizacja klucza | Po stronie serwera | Urządzenie nadawcy | | Ochrona przed nakazem sądowym | Brak | Silna | | Skanowanie treści przez dostawcę | Możliwe | Niemożliwe | | Odtworzenie po utracie klucza | Dostawca może pomóc | Dane są nieodwracalnie utracone | | Typowe usługi | Google Drive, Dropbox | HexaTransfer, SwissTransfer E2EE |

Jak faktycznie działa wymiana kluczy

Trudną częścią E2EE nie jest szyfr — AES jest niezawodny od 25 lat. Trudną częścią jest dostarczenie klucza od nadawcy do odbiorcy bez wiedzy serwera. Usługi transferu plików stosują zazwyczaj jeden z trzech wzorców.

Pierwszy to sztuczka z fragmentem URL: link wygląda jak https://hexatransfer.com/d/abc123#key=xyz, gdzie wszystko po # pozostaje w przeglądarce. JavaScript odczytuje go lokalnie i dokonuje deszyfrowania. Drugi to szyfrowanie oparte na haśle — nadawca wybiera hasło, przepuszcza je przez PBKDF2 (RFC 8018) lub Argon2id z 600 000+ iteracjami, a hasło udostępnia poza pasmem przez Signal lub telefon. Trzeci to wymiana kluczy publicznych przy użyciu bibliotek takich jak crypto_box z libsodium, gdzie odbiorca publikuje klucz publiczny X25519.

Kiedy sam TLS jest wystarczający

Nie każdy plik wymaga E2EE. Jeśli przesyłany jest komunikat prasowy dziennikarzowi, mem do czatu grupowego lub publiczne PDF z materiałami marketingowymi, usługi oparte wyłącznie na TLS są w pełni odpowiednie. Dane nie były wrażliwe, a fakt odczytania ich przez dostawcę nie stwarza żadnego ryzyka. Priorytetem jest wygoda — podglądy, miniatury, edycja w przeglądarce — a funkcje te wymagają dostępu do tekstu jawnego po stronie serwera.

Kalkulacja zmienia się w przypadku obrazowania medycznego (pliki DICOM objęte HIPAA 45 CFR 164.312(a)(2)(iv)), sprawozdań finansowych pod PCI DSS 4.0 wymóg 3.5.1, materiałów z procesu odkrywania w postępowaniu sądowym, dokumentów fuzji i przejęć lub czegokolwiek zawierającego dane osobowe obywateli UE na podstawie art. 32 RODO. Tutaj „dostawca może technicznie to odczytać" to problem zgodności z regulacjami, a nie jedynie kwestia estetyki prywatności.

Luka metadanych, o której się nie mówi

Nawet przy doskonałym E2EE serwer nadal widzi metadane: znacznik czasu przesłania, rozmiar pliku, adresy IP nadawcy i odbiorcy, ciągi user-agent, czas trwania transferu. Jeśli model zagrożeń obejmuje analizę ruchu — np. dziennikarz komunikujący się ze źródłem — ma to znaczenie. Plik 147 MB przesłany o 3:14 w nocy z biura Reutersa do numeru Signal w Stambule opowiada historię, nawet jeśli treść jest szyfrogramem.

Dobre usługi E2EE minimalizują przechowywanie metadanych. Należy szukać krótkich okien retencji logów (7 dni lub mniej), braku wymogu konta dla podstawowych transferów, braku zewnętrznych analityk na stronach transferu oraz polityki przyjaznej dla sieci Tor i VPN. Zestaw szyfrów ma mniejsze znaczenie niż higiena operacyjna wokół niego.

Weryfikacja deklaracji E2EE

„Szyfrowanie end-to-end" to tekst marketingowy, dopóki nie można go udowodnić. Trzy testy oddzielają prawdziwe E2EE od słownych sztuczek. Po pierwsze: otwórz DevTools i obserwuj zakładkę sieci podczas przesyłania — jeśli treść pliku wychodzi jako tekst jawny multipart/form-data, mamy do czynienia z samym TLS. Po drugie: sprawdź, czy URL deszyfrowania zawiera fragment (#). Brak fragmentu oznacza brak klucza po stronie klienta. Po trzecie: zapoznaj się z polityką odpowiedzi na nakazy sądowe — jeśli usługa może udostępnić treść pliku organom ścigania, pliki nie są E2EE. Usługi publikujące kanary gwarancyjne i udostępniające kod kryptograficzny na zasadach open source (repozytoria GitHub z użyciem WebCrypto API) dają najmocniejsze zapewnienia.

Przy codziennym wysyłaniu dużych plików, gdy poufność ma znaczenie, należy wybrać usługę, która jasno komunikuje swój model bezpieczeństwa. Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.