Embolcallar un sòcol SOCKS amb TLS a Node.js

SocksClient.createConnection retorna un flux connectat a la destinació sol·licitada. Per a HTTPS, aquest flux encara necessita un handshake TLS abans de transportar la petició 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`
  );
});

La llista de proxys SOCKS5 proporciona candidats per a l'amfitrió i el port del proxy. onTransportError i onResponseBytes pertanyen a l'aplicació existent; el segon ha d'analitzar el flux de resposta HTTP. Els fragments de dades TLS no són missatges HTTP complets de manera independent.

El servername és el nom DNS de la destinació. El tls.connect de baix nivell de Node no activa SNI per defecte, i el nom d'amfitrió del proxy no és la identitat del certificat del lloc.

Mantén activada la verificació del certificat. Subministrar el sòcol connectat evita obrir una connexió directa separada al lloc mentre es conserva la seva identitat TLS.

El temps d'espera de SOCKS limita aquesta negociació. L'intercanvi posterior de TLS i d'aplicació encara necessita el temps d'espera, la cancel·lació i la política de neteja previstos pel sol·licitant.