SOCKS სოკეტის TLS-ით გახვევა Node.js-ში

SocksClient.createConnection აბრუნებს ნაკადს, რომელიც დაკავშირებულია მოთხოვნილ დანიშნულებასთან. HTTPS-ისთვის ამ ნაკადს ჯერ კიდევ სჭირდება TLS ხელის ჩამორთმევა, სანამ HTTP მოთხოვნას გადაიტანს.

import { SocksClient } from 'socks';
import tls from 'node:tls';

const targetHost = 'service.example';
const info = await SocksClient.createConnection({
  proxy: { host: 'proxy.example', port: 1080, type: 5 },
  command: 'connect',
  destination: { host: targetHost, port: 443 },
  timeout: 10000,
});
const secure = tls.connect({
  socket: info.socket,
  servername: targetHost,
});
secure.on('error', onTransportError);
secure.on('data', onResponseBytes);
secure.once('secureConnect', () => {
  secure.write(
    `GET /data HTTP/1.1\r\nHost: ${targetHost}\r\nConnection: close\r\n\r\n`
  );
});

SOCKS5 პროქსების სია გვაძლევს კანდიდატებს პროქსის ჰოსტისა და პორტისთვის. onTransportError და onResponseBytes არსებულ აპლიკაციას ეკუთვნის; მეორემ უნდა გაანალიზოს HTTP პასუხის ნაკადი. TLS მონაცემთა ნაწილები დამოუკიდებლად სრული HTTP შეტყობინებები არ არის.

servername დანიშნულების DNS სახელია. Node-ის დაბალი დონის tls.connect ნაგულისხმევად არ რთავს SNI-ს, და პროქსის ჰოსტის სახელი ვებსაიტის სერტიფიკატის იდენტობა არ არის.

დატოვეთ სერტიფიკატის შემოწმება ჩართული. დაკავშირებული სოკეტის მიწოდება თავიდან გვაცილებს ვებსაიტთან ცალკე პირდაპირი კავშირის გახსნას და ინარჩუნებს მის TLS იდენტობას.

SOCKS-ის დროის ლიმიტი ზღუდავს ამ მოლაპარაკებას. შემდგომი TLS და აპლიკაციის გაცვლას მაინც სჭირდება გამომძახებლის მიერ განზრახული დროის ლიმიტი, გაუქმება და გასუფთავების პოლიტიკა.