Pakk en SOCKS-socket inn med TLS i Node.js
Pakk destinasjonsstrømmen som socks-pakken returnerer inn med tls.connect, og behold 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 bærer 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`
);
});
SOCKS5-proxylisten gir kandidater for vert og port til proxyen. onTransportError og onResponseBytes tilhører den eksisterende applikasjonen; sistnevnte må parse HTTP-svarstrømmen. TLS-databiter er ikke selvstendig komplette HTTP-meldinger.
servername er destinasjonens DNS-navn. Nodes lavnivå-tls.connect aktiverer ikke SNI som standard, og proxyens vertsnavn er ikke nettstedets sertifikatidentitet.
La sertifikatvalideringen stå på. Å oppgi den tilkoblede socketen unngår en egen direkte forbindelse til nettstedet og bevarer TLS-identiteten.
SOCKS-tidsavbruddet begrenser den forhandlingen. Den senere TLS- og applikasjonsutvekslingen trenger fortsatt det tiltenkte tidsavbruddet, avbrytelsen og oppryddingspolicyen til den som kaller.