Błąd ERR_WRONG_VERSION_ON_EARLY_DATA – przyczyny i naprawa

1. Co to jest błąd ERRWRONGVERSIONONEARLY_DATA?
2. Przyczyny wystąpienia błędu
3. Jak działa mechanizm TLS Early Data (0-RTT)?
4. Rozwiązania dla użytkowników końcowych
5. Rozwiązania dla webmasterów i developerów
6. Testowanie i diagnostyka
7. Najlepsze praktyki bezpieczeństwa
8. FAQ – Najczęściej zadawane pytania

Co to jest błąd ERRWRONGVERSIONONEARLY_DATA?

ERRWRONGVERSIONONEARLY_DATA to błąd połączenia SSL/TLS występujący w przeglądarkach internetowych (głównie Chrome, Edge, Opera i innych opartych na silniku Chromium), który informuje o problemie z funkcją TLS Early Data (znaną również jako 0-RTT Resume).

Charakterystyka błędu

• Komunikat – „To połączenie nie jest prywatne” lub „ERRWRONGVERSIONONEARLY_DATA”
• Kod błędu – net::ERR_WRONG_VERSION_ON_EARLY_DATA
• Dotyczy – Połączeń HTTPS wykorzystujących TLS 1.3
• Wpływ – Uniemożliwia dostęp do strony internetowej

Wizualna identyfikacja

Użytkownik widzi w przeglądarce:

• Ostrzeżenie bezpieczeństwa z czerwonym wykrzyknikiem
• Komunikat sugerujący, że połączenie nie jest bezpieczne
• Opcję „Zaawansowane” z dodatkowymi szczegółami błędu

Przyczyny wystąpienia błędu

1. Niezgodność wersji protokołu TLS

Główna przyczyna: serwer próbuje wznowić sesję TLS z danymi Early Data (0-RTT), ale występuje:

• Niezgodność między wersją protokołu z poprzedniej sesji a aktualną
• Zmiana konfiguracji TLS na serwerze między sesjami
• Problem z cache’owaniem biletów sesji (session tickets)

2. Problemy z konfiguracją serwera

• Nieprawidłowa implementacja 0-RTT – Serwer obsługuje 0-RTT, ale niepoprawnie
• Rotacja kluczy sesji – Zbyt częsta zmiana kluczy używanych do szyfrowania session tickets
• Migracja między serwerami – Load balancer kieruje ruch na różne serwery z różnymi konfiguracjami
• Aktualizacja oprogramowania – Zmiana wersji serwera HTTP/proxy z inną obsługą TLS 1.3

3. Problemy po stronie klienta

• Uszkodzony cache przeglądarki – Przechowywane stare dane sesji TLS
• Przestarzały bilet sesji – Session ticket wygasł lub jest nieważny
• Konflikt rozszerzeń przeglądarki – VPN, proxy lub security extensions modyfikujące połączenia

4. Problemy z infrastrukturą

• CDN/WAF – CloudFlare, Akamai lub inne usługi zmieniły konfigurację
• Reverse proxy – Nginx, Apache, HAProxy z niespójną konfiguracją TLS
• Load balancing – Sticky sessions nie działają poprawnie dla session tickets

5. Zabezpieczenia i blokady

• Firewall/IPS – Systemy bezpieczeństwa blokujące pakiety Early Data
• Antywirus – Oprogramowanie skanujące SSL z problematyczną implementacją
• Corporate proxy – Firmowe proxy z nieprawidłową konfiguracją TLS inspection

Jak działa mechanizm TLS Early Data (0-RTT)?

Podstawy TLS 1.3 Early Data

TLS Early Data (0-RTT) to funkcja wprowadzona w TLS 1.3, która pozwala na:

• Wysyłanie danych aplikacji już w pierwszym pakiecie do serwera
• Eliminację opóźnienia związanego z pełnym handshake’em TLS
• Znaczące przyspieszenie wznowienia połączeń

Normalny przepływ TLS 1.3 (1-RTT):

Klient Serwer | | |-------- ClientHello ---------------->| | | |<------- ServerHello -----------------| |<------- {Certificate} ---------------| |<------- {CertificateVerify} ---------| |<------- {Finished} -------------------| | | |-------- {Finished} ----------------->| |-------- [Application Data] --------->| |<------- [Application Data] ----------| 

TLS 1.3 z Early Data (0-RTT Resume):

Klient Serwer | | |-------- ClientHello ---------------->| |-------- [Early Data] --------------->| ← Dane wysyłane natychmiast! | | |<------- ServerHello -----------------| |<------- {Finished} -------------------| | | |-------- {Finished} ----------------->| |-------- [Application Data] --------->| |<------- [Application Data] ----------| 

Kiedy występuje błąd?

Błąd ERRWRONGVERSIONONEARLY_DATA pojawia się gdy:

1. Klient wysyła ClientHello z Early Data bazując na poprzedniej sesji
2. Serwer wykrywa niezgodność:

• Wersja TLS się nie zgadza
• Parametry sesji zostały zmienione
• Session ticket jest nieważny

1. Serwer odrzuca połączenie zamiast poprawnie go obsłużyć

Rozwiązania dla użytkowników końcowych

Metoda 1 – Wyczyść cache i pliki cookie przeglądarki

Google Chrome / Microsoft Edge

Krok 1 – Otwórz ustawienia przeglądarki

• Chrome: chrome://settings/privacy
• Edge: edge://settings/privacy

Krok 2 – Wyczyść dane przeglądania

1. Kliknij „Wyczyść dane przeglądania”
2. Wybierz zakres czasu: Cały czas
3. Zaznacz:

• ✅ Pliki cookie i inne dane witryn
• ✅ Obrazy i pliki w pamięci podręcznej
• ✅ Dane witryn i aplikacji w pamięci (opcjonalnie)

1. Kliknij „Wyczyść dane”

Szybka metoda (skrót klawiszowy) –

• Windows/Linux: Ctrl + Shift + Delete
• macOS: Cmd + Shift + Delete

Mozilla Firefox

Krok 1 – Przejdź do ustawień

• Wpisz w pasku adresu: about:preferences#privacy

Krok 2 – Wyczyść dane

1. Przewiń do sekcji „Ciasteczka i dane stron”
2. Kliknij „Wyczyść dane…”
3. Zaznacz oba pola:

• ✅ Ciasteczka i dane stron
• ✅ Treści w pamięci podręcznej

1. Kliknij „Wyczyść”

Szybka metoda –

• Ctrl + Shift + Delete (Windows/Linux)
• Cmd + Shift + Delete (macOS)

Safari (macOS)

Krok 1 – Menu Safari

1. Safari → Preferencje (lub Cmd + ,)
2. Zakładka „Prywatność”

Krok 2 – Zarządzaj danymi witryn

1. Kliknij „Zarządzaj danymi witryn…”
2. Kliknij „Usuń wszystkie”
3. Potwierdź operację

Metoda 2 – Wyłącz rozszerzenia przeglądarki

Google Chrome

Krok po kroku –

1. Przejdź do zarządzania rozszerzeniami –

• Wpisz w pasku adresu: chrome://extensions/
• Lub: Menu (⋮) → Rozszerzenia → Zarządzaj rozszerzeniami

1. Wyłącz wszystkie rozszerzenia –

• Przełącz suwaki przy każdym rozszerzeniu na pozycję „Wyłączone”

1. Sprawdź problematyczną stronę –

• Odśwież stronę, która powodowała błąd

1. Identyfikacja winowajcy –

• Włączaj rozszerzenia pojedynczo
• Po każdym włączeniu sprawdzaj stronę
• Gdy błąd powróci – znalazłeś problematyczne rozszerzenie

Szczególnie podejrzane rozszerzenia –

• VPN (NordVPN, ExpressVPN, Hola VPN)
• Ad blockers (uBlock Origin, AdBlock Plus)
• Security/Privacy tools (HTTPS Everywhere, Privacy Badger)
• Proxy extensions
• SSL/TLS inspection tools

Metoda 3 – Tryb incognito / prywatny

Tryb prywatny pomija zapisany cache i session storage.

Jak uruchomić –

• Chrome/Edge – Ctrl + Shift + N (Windows/Linux) lub Cmd + Shift + N (macOS)
• Firefox – Ctrl + Shift + P (Windows/Linux) lub Cmd + Shift + P (macOS)
• Safari – Cmd + Shift + N

Co to sprawdza –

• Czy problem jest związany z lokalnym cache
• Czy rozszerzenia przeglądarki są przyczyną (większość jest wyłączona w trybie incognito)
• Czy dane sesji TLS są skorumpowane

Jeśli strona działa w trybie incognito – → Problem jest lokalny, zastosuj Metodę 1 (czyszczenie cache)

Metoda 4 – Aktualizacja przeglądarki

Google Chrome –

1. Menu (⋮) → Pomoc → O Google Chrome
2. Chrome automatycznie sprawdzi aktualizacje
3. Jeśli dostępna: kliknij „Uruchom ponownie”

Sprawdź wersję: chrome://settings/help

Mozilla Firefox –

1. Menu (☰) → Pomoc → O Firefoksie
2. Firefox sprawdzi i zainstaluje aktualizacje
3. Kliknij „Uruchom ponownie Firefox”

Sprawdź wersję: about:support

Microsoft Edge –

1. Menu (⋯) → Pomoc i opinie → Microsoft Edge — informacje
2. Edge sprawdzi aktualizacje automatycznie
3. Uruchom ponownie jeśli wymagane

Sprawdź wersję: edge://settings/help

Metoda 5 – Zmiana ustawień DNS

Problemy z DNS mogą prowadzić do łączenia z niewłaściwymi serwerami.

Windows 10/11

Krok 1: Otwórz ustawienia sieci

1. Kliknij prawym przyciskiem ikonę sieci w zasobniku systemowym
2. Wybierz „Otwórz ustawienia sieci i Internetu”

Krok 2: Zmień ustawienia adaptera

1. Kliknij „Zmień opcje adaptera”
2. Kliknij prawym na aktywne połączenie
3. Wybierz „Właściwości”

Krok 3: Skonfiguruj DNS

1. Wybierz „Protokół internetowy w wersji 4 (TCP/IPv4)”
2. Kliknij „Właściwości”
3. Zaznacz „Użyj następujących adresów serwerów DNS”
4. Wprowadź:

• Preferowany serwer DNS – 8.8.8.8 (Google)

• Alternatywny serwer DNS – 8.8.4.4

  Lub:

• Cloudflare – 1.1.1.1 i 1.0.0.1

• Quad9 – 9.9.9.9 i 149.112.112.112

1. Kliknij „OK”

Krok 4: Wyczyść cache DNS

1. Otwórz Wiersz polecenia jako Administrator
2. Wpisz:

ipconfig /flushdns 

macOS

Krok 1: Otwórz Preferencje systemowe

1. Menu Apple → Preferencje systemowe
2. Kliknij „Sieć”

Krok 2: Skonfiguruj DNS

1. Wybierz aktywne połączenie (Wi-Fi lub Ethernet)
2. Kliknij „Zaawansowane…”
3. Zakładka „DNS”
4. Kliknij „+” i dodaj:

• 8.8.8.8
• 8.8.4.4

1. Kliknij „OK” i „Zastosuj”

Krok 3: Wyczyść cache DNS Otwórz Terminal i wpisz:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder 

Linux (Ubuntu/Debian)

Metoda 1: NetworkManager

# Edytuj połączenie nmcli connection modify <nazwa-połączenia> ipv4.dns "8.8.8.8 8.8.4.4" nmcli connection up <nazwa-połączenia> # Wyczyść cache sudo systemd-resolve --flush-caches 

Metoda 2: systemd-resolved Edytuj /etc/systemd/resolved.conf:

[Resolve] DNS=8.8.8.8 8.8.4.4 FallbackDNS=1.1.1.1 1.0.0.1 

Następnie:

sudo systemctl restart systemd-resolved 

Metoda 6 – Sprawdzenie oprogramowania zabezpieczającego

Krok 1: Tymczasowe wyłączenie

⚠️ UWAGA – Wykonuj to tylko na krótki czas w celu testowym!

Windows Defender –

1. Ustawienia → Aktualizacja i zabezpieczenia → Zabezpieczenia Windows
2. Ochrona przed wirusami i zagrożeniami
3. Zarządzaj ustawieniami
4. Wyłącz „Ochrona w czasie rzeczywistym”

Inny antywirus –

• Kliknij prawym na ikonę w zasobniku systemowym
• Szukaj opcji „Wyłącz ochronę” lub „Wstrzymaj ochronę”
• Wybierz krótki okres (15 minut)

Krok 2: Testuj stronę

• Jeśli działa → problem jest w antywirusie
• Jeśli nie działa → ponownie włącz antywirusus i szukaj dalej

Krok 3: Konfiguracja wyjątków (jeśli antywirus jest problemem)

Większość antywirusów ma funkcję „SSL Scanning” lub „HTTPS Inspection”:

Norton –

1. Ustawienia → Firewall → Ustawienia zaawansowane
2. Wyłącz „Skanowanie SSL”

Kaspersky –

1. Ustawienia → Dodatkowe → Sieć
2. Wyłącz „Skanuj połączenia szyfrowane”

Avast/AVG –

1. Menu → Ustawienia → Ochrona → Tarcza sieci
2. Wyłącz „Włącz skanowanie HTTPS”

Bitdefender –

1. Ustawienia → Ochrona → Ochrona online
2. Dostosuj ustawienia skanowania SSL

Metoda 7 – Sprawdź datę i czas systemowy

Nieprawidłowy czas może powodować problemy z walidacją certyfikatów TLS.

Windows

Automatyczna synchronizacja –

1. Ustawienia → Czas i język → Data i godzina
2. Włącz „Ustaw czas automatycznie”
3. Włącz „Ustaw strefę czasową automatycznie”

Ręczna synchronizacja –

1. Kliknij prawym na zegar w zasobniku
2. „Dostosuj datę/godzinę”
3. Kliknij „Synchronizuj teraz”

Wiersz polecenia (jako Administrator) –

w32tm /resync 

macOS

1. Preferencje systemowe → Data i godzina
2. Zaznacz „Ustaw datę i godzinę automatycznie”
3. Wybierz serwer czasu (domyślnie: time.apple.com)

Linux

# Sprawdź aktualny czas timedatectl # Włącz NTP sudo timedatectl set-ntp true # Ręczna synchronizacja sudo ntpdate pool.ntp.org 

Metoda 8 – Alternatywna przeglądarka (test diagnostyczny)

Celem tej metody jest sprawdzenie, czy problem dotyczy:

• Konkretnej przeglądarki → problem lokalny
• Wszystkich przeglądarek → problem serwera

Przeglądarki do przetestowania –

1. Firefox (jeśli używasz Chrome/Edge) – inna implementacja TLS
2. Chrome (jeśli używasz Firefox/Safari)
3. Brave – prywatność-focused, oparta na Chromium
4. Opera – również Chromium, ale inna konfiguracja

Procedura testowa –

1. Zainstaluj alternatywną przeglądarkę
2. NIE importuj danych z poprzedniej przeglądarki
3. Spróbuj wejść na problematyczną stronę
4. Wyciągnij wnioski:

• Działa – Problem z konfiguracją Twojej głównej przeglądarki
• Nie działa – Problem prawdopodobnie po stronie serwera

Metoda 9 – Sprawdzenie połączenia przez VPN/Proxy

Cel – Wykluczenie problemów z ISP lub lokalną siecią.

Bezpłatne opcje VPN do testów –

• ProtonVPN (darmowy tier)
• Windscribe (10GB/miesiąc za darmo)
• TunnelBear (500MB/miesiąc)

Alternatywnie – Hotspot mobilny –

1. Włącz hotspot na telefonie
2. Połącz komputer z siecią telefonu
3. Testuj stronę

Co to weryfikuje –

• Czy ISP blokuje/modyfikuje połączenia TLS
• Czy problem jest z routingiem
• Czy lokalny firewall sieci korporacyjnej interferuje

Metoda 10 – Kontakt z administratorem strony

Jeśli wszystkie powyższe metody zawiodły, problem jest po stronie serwera.

Informacje do przekazania administratorowi –

Temat: Błąd ERR_WRONG_VERSION_ON_EARLY_DATA przy próbie dostępu Opis: Nie mogę uzyskać dostępu do [URL strony] z powodu błędu: ERR_WRONG_VERSION_ON_EARLY_DATA Szczegóły: - Przeglądarka: [Chrome 120.0.6099.109 / Firefox 121.0 / itp.] - System operacyjny: [Windows 11 / macOS 14.2 / Ubuntu 22.04] - Data i godzina wystąpienia: [dokładny czas] - Czy problem jest stały czy sporadyczny: [opis] Wykonane kroki diagnostyczne: - Wyczyszczenie cache przeglądarki: TAK - Test w trybie incognito: [wynik] - Test na innej przeglądarce: [wynik] - Test z innej sieci: [wynik] Dodatkowe informacje: - Czy inni użytkownicy mają ten sam problem? - Czy była ostatnio zmiana konfiguracji serwera/CDN? 

Gdzie zgłosić –

• Formularz kontaktowy na stronie
• Email techniczny support/webmaster
• Social media / kanały wsparcia
• Ticketing system jeśli dostępny

Rozwiązania dla webmasterów i developerów

Szybka diagnoza – Checklist

Zanim przejdziesz do szczegółowych kroków, zweryfikuj:

• [ ] Czy problem występuje sporadycznie czy stale?
• [ ] Czy dotyczy wszystkich użytkowników czy wybranych?
• [ ] Czy była niedawna zmiana konfiguracji serwera?
• [ ] Czy używasz CDN/WAF (CloudFlare, Cloudfront, itp.)?
• [ ] Jaka wersja TLS jest używana? (sprawdź: openssl s_client -connect domain.com:443 -tls1_3)
• [ ] Czy 0-RTT jest włączone?

Rozwiązanie 1 – Wyłączenie TLS Early Data (0-RTT)

To najszybsze i najskuteczniejsze rozwiązanie. 0-RTT ma problemy bezpieczeństwa (replay attacks) i nie jest krytyczne dla działania.

Nginx

Lokalizacja konfiguracji – /etc/nginx/nginx.conf lub /etc/nginx/sites-available/default

Krok 1 – Zlokalizuj blok server z konfiguracją SSL

Krok 2 – Dodaj lub zmień dyrektywę:

server { listen 443 ssl http2; server_name example.com; # Certyfikaty SSL ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; # Wyłącz Early Data (0-RTT) ssl_early_data off; # Alternatywnie, jeśli linia powyżej nie działa: # ssl_protocols TLSv1.2 TLSv1.3; # (bez dodatkowych flag dla early data) # Pozostała konfiguracja... } 

Krok 3 – Testuj konfigurację

sudo nginx -t 

Krok 4 – Przeładuj Nginx

sudo systemctl reload nginx # lub sudo service nginx reload 

Weryfikacja –

openssl s_client -connect example.com:443 -tls1_3 -early_data 

Sprawdź output – nie powinno być wzmianki o „Early data was accepted/rejected”.

Apache (2.4.39+)

Lokalizacja – /etc/apache2/sites-available/default-ssl.conf lub /etc/httpd/conf.d/ssl.conf

Krok 1 – Upewnij się, że mod_ssl jest włączony:

# Debian/Ubuntu sudo a2enmod ssl sudo systemctl restart apache2 # RHEL/CentOS # mod_ssl powinien być zainstalowany domyślnie 

Krok 2 – Edytuj VirtualHost:

<VirtualHost *:443> ServerName example.com SSLEngine on SSLCertificateFile /path/to/cert.pem SSLCertificateKeyFile /path/to/key.pem # Wyłącz Early Data # Apache domyślnie nie włącza 0-RTT, ale dla pewności: SSLProtocol -all +TLSv1.2 +TLSv1.3 # Jeśli masz explicit włączone 0-RTT, usuń: # SSLOptions +ExportCertData +StdEnvVars +StrictRequire # Pozostała konfiguracja... </VirtualHost> 

Krok 3 – Testuj i restartuj

sudo apachectl configtest sudo systemctl restart apache2 

Caddy

Lokalizacja – Caddyfile

Konfiguracja –

example.com { # Caddy domyślnie nie włącza 0-RTT # Jeśli chcesz się upewnić, użyj explicit: tls { protocols tls1.2 tls1.3 # Nie ma dedykowanej dyrektywy dla 0-RTT w Caddy # Jest wyłączone domyślnie } reverse_proxy localhost:8080 } 

Reload –

sudo systemctl reload caddy 

HAProxy

Lokalizacja – /etc/haproxy/haproxy.cfg

Konfiguracja –

frontend https-in bind *:443 ssl crt /path/to/cert.pem # Wyłącz 0-RTT przez nie włączanie go # HAProxy nie włącza 0-RTT domyślnie # Jeśli było włączone, usuń flagę 'allow-0rtt': # bind *:443 ssl crt /path/to/cert.pem allow-0rtt # <- USUŃ to default_backend web-backend backend web-backend server web1 127.0.0.1:8080 check 

Reload –

sudo systemctl reload haproxy 

Cloudflare

Jeśli używasz Cloudflare jako CDN/WAF:

Metoda 1: Dashboard

1. Zaloguj się do dashboard Cloudflare
2. Wybierz swoją domenę
3. Przejdź do SSL/TLS → Edge Certificates
4. Przewiń do TLS 1.3
5. Wyłącz opcję 0-RTT Connection Resumption
6. Zapisz zmiany

Metoda 2: API

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/settings/0rtt" \ -H "Authorization: Bearer {api_token}" \ -H "Content-Type: application/json" \ --data '{"value":"off"}' 

Weryfikacja –

curl -I https://example.com # Sprawdź nagłówki odpowiedzi 

Rozwiązanie 2 – Poprawna implementacja obsługi 0-RTT

Jeśli chcesz zachować 0-RTT dla wydajności, musisz poprawnie obsłużyć replay protection.

Nginx z Anti-Replay Protection

server { listen 443 ssl http2; server_name example.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; # Włącz Early Data ssl_early_data on; # Dodaj nagłówek informujący backend o Early Data proxy_set_header Early-Data $ssl_early_data; location / { # Ogranicz Early Data tylko do bezpiecznych metod if ($ssl_early_data != "") { # Sprawdź czy metoda jest idempotentna set $block_early_data 0; if ($request_method !~ ^(GET|HEAD|OPTIONS)$) { set $block_early_data 1; } # Odrzuć niebezpieczne metody w Early Data if ($block_early_data = 1) { return 425; # Too Early (RFC 8470) } } proxy_pass http://backend; } } 

Apache z obsługą Early-Data

„`apache ServerName example.com

SSLEngine on SSLCertificateFile /path/to/cert.pem SSLCertificateKeyFile /path/to/key.pem # Włącz TLS 1.3 z Early Data SSLProtocol -all +TLSv1.2 +TLSv1.3 # Przekaż informację o Early Data do aplikacji <If "%{SSL:SSL_EARLY_DATA} == '1'"> RequestHeader set Early-Data "1" </If> # Ogranicz Early Data do GET/HEAD <If "%{SSL:SSL_EARLY_DATA} == '1' && %{REQUEST_METHOD} !~ /^(GET|HEAD|OPTIONS)$/"> Require all denied ErrorDocument 403 "Early Data not allowed for this method"