SOCKS bağlantısı ile TLS bağlantısı farklı işler yapar. Önce SOCKS üzerinden hedefe bir bayt akışı edinin. Sonra bu akışın üzerinde TLS başlatın ve proxy'yi değil hedef web sitesini tanımlayın.

HTTPS tarzı bir TLS uç noktası için düzen şöyle olabilir:

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

İzin verilen genel proxy rotasındaki genel bir HTTPS hedefi için SOCKS5 proxy listesi ProxyAddr ve ProxyPort için adaylar sunar. Bu parça taşıma katmanlarını kurar; uygulama yine de hedefin beklediği protokolü göndermeli ve bitince soketi kapatmalıdır.

Amaçlanan eş adını koruyun

Proxy uç noktası ilk bağlantıya aittir. TLS SNI ve ana bilgisayar adı doğrulaması example.com ile ilgilidir. O aşamada proxy'nin ana bilgisayar adını kullanmak yanlış kimliği istetebilir veya doğrulayabilir.

Güven deposu yapılandırması bir başka bağımsız gereksinimdir. Bir tanılama örneğinden kopyalanan her şeye güvenen bir geri çağırma yerine uygulamanın amaçladığı CA yapılandırmasını kullanın.

SOCKS adımı başarısız olursa TLS parametrelerini değiştirmek bunu düzeltmez. SOCKS başarılı olup TLS başarısız olursa sertifika ve ana bilgisayar adı hatasını kanıt olarak saklayın, genel bir proxy kesintisi olarak görmeyin.

Modül adları da önemlidir: IO::Socket::Socks ve IO::Socket::SSL farklı kurucular ve yükseltme davranışı sunar. Yalnızca proxy'ye ulaşan ham bir TCP soketi, SOCKS hedef görüşmesini henüz tamamlamamıştır.

İlgili makaleler