עטיפת socket של 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`
  );
});

רשימת ה-proxy של SOCKS5 מספק מועמדים עבור המארח והפורט של ה-proxy. onTransportError ו-onResponseBytes שייכים ליישום הקיים; השני צריך לנתח את זרם תגובת ה-HTTP. מקטעי נתוני TLS אינם הודעות HTTP שלמות באופן עצמאי.

ה-servername הוא שם ה-DNS של היעד. tls.connect ברמה נמוכה של Node אינו מפעיל SNI כברירת מחדל, ושם המארח של ה-proxy אינו זהות התעודה של האתר.

השאירו את אימות התעודה פעיל. מסירת ה-socket המחובר מונעת פתיחת חיבור ישיר נפרד לאתר תוך שמירה על זהות ה-TLS שלו.

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