Å pakke en SOCKS-socket inn med TLS i Node.js

Pakk destinasjonsstrømmen socks-pakken returnerer inn med tls.connect, og ta vare på vertsnavnet til nettstedet for SNI og sertifikatvalidering.

SocksClient.createConnection returnerer en strøm som er koblet til destinasjonen du ba om. For HTTPS trenger den strømmen fortsatt et TLS-håndtrykk før den frakter HTTP-forespørselen.

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`
  );
});

Listen over SOCKS5-proxyer gir kandidater for vert og port for proxyen. onTransportError og onResponseBytes hører til den eksisterende applikasjonen; den siste må tolke HTTP-svarstrømmen. TLS-databiter er ikke selvstendig komplette HTTP-meldinger.

servername er DNS-navnet til destinasjonen. Nodes tls.connect på lavt nivå slår ikke på SNI som standard, og vertsnavnet til proxyen er ikke nettstedets sertifikatidentitet.

La sertifikatvalideringen være på. Ved å oppgi den tilkoblede socketen unngår du en egen direkte forbindelse til nettstedet og bevarer TLS-identiteten.

SOCKS-tidsavbruddet begrenser denne forhandlingen. Den senere TLS- og applikasjonsutvekslingen trenger fortsatt det tiltenkte tidsavbruddet, avbruddet og oppryddingspolicyen til den som kaller.

Relaterte artikler