Pakka ein SOCKS-socket inn med TLS i Node.js
Pakka målstraumen som socks-pakken returnerer inn med tls.connect, og hald på vertsnamnet til nettstaden for SNI og sertifikatvalidering.
SocksClient.createConnection returnerer ein straum som er kopla til målet du bad om. For HTTPS treng den straumen framleis eit TLS-handtrykk før han ber HTTP-førespurnaden.
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-proxylista gjev kandidatar for vert og port til proxyen. onTransportError og onResponseBytes høyrer til den eksisterande applikasjonen; den siste må parse HTTP-svarstraumen. TLS-databitar er ikkje sjølvstendig komplette HTTP-meldingar.
servername er DNS-namnet til målet. Nodes tls.connect på lågt nivå slår ikkje på SNI som standard, og vertsnamnet til proxyen er ikkje sertifikatidentiteten til nettstaden.
Lat sertifikatvalideringa stå på. Å gje den tilkopla socketen unngår ei eiga direkte tilkopling til nettstaden og bevarer TLS-identiteten.
SOCKS-tidsavbrotet avgrensar den forhandlinga. Den seinare TLS- og applikasjonsutvekslinga treng framleis det tiltenkte tidsavbrotet, avbrytinga og oppryddingspolicyen til den som kallar.