Dodaj TLS po otwarciu połączenia SOCKS przez Perla

Nałóż IO::Socket::SSL na połączenie IO::Socket::Socks i zweryfikuj nazwę hosta celu.

Połączenie SOCKS i połączenie TLS mają różne zadania. Najpierw uzyskaj strumień bajtów do celu przez SOCKS. Następnie uruchom TLS na tym strumieniu, identyfikując docelową witrynę, a nie proxy.

Dla punktu końcowego TLS w stylu HTTPS układ może wyglądać tak:

use IO::Socket::Socks;
use IO::Socket::SSL;

my $target = 'example.com';
my $socket = IO::Socket::Socks->new(
    SocksVersion => 5,
    ProxyAddr => '127.0.0.1',
    ProxyPort => 1080,
    ConnectAddr => $target,
    ConnectPort => 443,
) or die $!;

IO::Socket::SSL->start_SSL(
    $socket,
    SSL_hostname => $target,
    SSL_verifycn_name => $target,
    SSL_verifycn_scheme => 'http',
    SSL_verify_mode => SSL_VERIFY_PEER,
) or die IO::Socket::SSL::errstr();

Dla publicznego celu HTTPS na dozwolonej trasie publicznego proxy lista proxy SOCKS5 oferuje kandydatów dla ProxyAddr i ProxyPort. Fragment ustawia warstwy transportowe; aplikacja nadal musi wysłać protokół oczekiwany przez cel i zamknąć gniazdo po zakończeniu.

Zachowaj zamierzoną nazwę peera

Punkt końcowy proxy należy do pierwszego połączenia. SNI w TLS i weryfikacja nazwy hosta dotyczą example.com. Użycie nazwy hosta proxy na tym etapie może zażądać lub zweryfikować niewłaściwą tożsamość.

Konfiguracja magazynu zaufania to kolejne niezależne wymaganie. Użyj zamierzonej konfiguracji CA aplikacji zamiast wywołania zwrotnego ufającego wszystkiemu, skopiowanego z przykładu diagnostycznego.

Jeśli krok SOCKS się nie powiedzie, zmiana parametrów TLS tego nie naprawi. Jeśli SOCKS się powiedzie, a TLS nie, zachowaj błąd certyfikatu i nazwy hosta jako dowód, zamiast traktować go jako ogólną awarię proxy.

Nazwy modułów też mają znaczenie: IO::Socket::Socks i IO::Socket::SSL udostępniają różne konstruktory i zachowanie aktualizacji. Surowy socket TCP, który tylko dotarł do proxy, nie zakończył jeszcze negocjacji celu SOCKS.

Powiązane artykuły