A conexión SOCKS e a conexión TLS teñen traballos distintos. Primeiro obtén un fluxo de bytes cara ao destino mediante SOCKS. Despois inicia TLS sobre ese fluxo, identificando o sitio web de destino e non o proxy.

Para un extremo TLS de estilo HTTPS, a disposición pode ser:

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();

Para un destino HTTPS público nunha ruta de proxy público permitida, a lista de proxies SOCKS5 ofrece candidatos para ProxyAddr e ProxyPort. O fragmento establece as capas de transporte; a aplicación aínda debe enviar o protocolo que espera o destino e pechar o socket ao rematar.

Conserva o nome de par previsto

O extremo do proxy pertence á primeira conexión. O SNI de TLS e a verificación do nome de host refírense a example.com. Usar o nome de host do proxy nesa etapa pode solicitar ou verificar unha identidade incorrecta.

A configuración do almacén de confianza é outro requisito independente. Usa a configuración de CA prevista pola aplicación en lugar dunha función de retorno que confía en todo, copiada dun exemplo de diagnóstico.

Se o paso SOCKS falla, cambiar parámetros de TLS non o arranxará. Se SOCKS ten éxito e TLS falla, conserva o erro de certificado e de nome de host como evidencia en lugar de tratalo como unha caída xenérica do proxy.

Os nomes dos módulos tamén importan: IO::Socket::Socks e IO::Socket::SSL expoñen construtores e comportamento de actualización distintos. Un socket TCP en bruto que só chegou ao proxy aínda non completou a negociación de destino SOCKS.

Artigos relacionados