הוספת TLS לאחר ש-Perl פתח את חיבור ה-SOCKS

הניחו את IO::Socket::SSL מעל חיבור IO::Socket::Socks ואמתו את שם המארח של היעד.

לחיבור SOCKS ולחיבור TLS יש תפקידים שונים. תחילה השיגו זרם בתים אל היעד דרך SOCKS. לאחר מכן התחילו TLS מעל אותו זרם, וזהו את אתר היעד ולא את ה-proxy.

עבור נקודת קצה של TLS בסגנון HTTPS, הסידור יכול להיות:

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

עבור יעד HTTPS ציבורי בנתיב proxy ציבורי מורשה, רשימת ה-proxy של SOCKS5 מציעה מועמדים עבור ProxyAddr ו-ProxyPort. הקטע מקים את שכבות התעבורה; היישום עדיין חייב לשלוח את הפרוטוקול שהיעד מצפה לו ולסגור את ה-socket כשמסיים.

שמרו על שם העמית המיועד

נקודת הקצה של ה-proxy שייכת לחיבור הראשון. TLS SNI ואימות שם המארח נוגעים ל-example.com. שימוש בשם המארח של ה-proxy בשלב הזה עלול לבקש או לאמת זהות שגויה.

תצורת מאגר האמון היא דרישה עצמאית נוספת. השתמשו בתצורת ה-CA המיועדת של היישום במקום ב-callback שסומך על הכול, שהועתק מדוגמת אבחון.

אם שלב ה-SOCKS נכשל, שינוי פרמטרים של TLS לא יתקן זאת. אם SOCKS מצליח ו-TLS נכשל, שמרו את שגיאת התעודה ושם המארח כראיה במקום להתייחס אליה כאל תקלת proxy כללית.

גם שמות המודולים חשובים: IO::Socket::Socks ו-IO::Socket::SSL חושפים בנאים והתנהגות שדרוג שונים. socket TCP גולמי שהגיע רק אל ה-proxy עדיין לא השלים את משא ומתן היעד של SOCKS.

מאמרים קשורים