A cél identitásának használata Java TLS-hez SOCKS-on át

Először SOCKS-on keresztül csatlakozzon, majd rétegezzen egy SSLSocketet a webhely hosztnevével és explicit HTTPS végpont-ellenőrzésekkel.

A SOCKS végpont eljuttat a webhelyre. A kapcsolaton belüli TLS partner maga a webhely, ezért adja át a cél hosztnevét a rétegzett socket-gyárnak:

String destination = "example.com";
int destinationPort = 443;
Proxy proxy = new Proxy(
    Proxy.Type.SOCKS,
    new InetSocketAddress("127.0.0.1", 1080)
);

try (Socket transport = new Socket(proxy)) {
    transport.connect(
        InetSocketAddress.createUnresolved(destination, destinationPort),
        5000
    );
    SSLSocketFactory factory =
        (SSLSocketFactory) SSLSocketFactory.getDefault();
    try (SSLSocket tls = (SSLSocket) factory.createSocket(
            transport, destination, destinationPort, true)) {
        SSLParameters parameters = tls.getSSLParameters();
        parameters.setEndpointIdentificationAlgorithm("HTTPS");
        tls.setSSLParameters(parameters);
        tls.setSoTimeout(15000);
        tls.startHandshake();
        // Send the application's HTTPS request through tls.
    }
}

A részlet szabványos Java hálózati és TLS importokat, meglévő alapértelmezett bizalmi konfigurációt és proxy-hitelesítő adatokat nem igénylő SOCKS-kapcsolatot feltételez. Elvégzi a kézfogást; az alkalmazásnak továbbra is el kell küldenie egy HTTP-kérést a szerver által elvárt formátumban. Nyilvános HTTPS-célokhoz engedélyezett nyilvános útvonalakon a SOCKS proxy lista jelölt végpontokat kínál; igazítsa a szerver verzióját és hosztnév-támogatását ehhez a Java socket-útvonalhoz.

Olvassa el a két identitást a példában

127.0.0.1:1080 a proxy végpontja, amely ebből a Java-folyamatból elérhető. destination és destinationPort azonosítja a webhelyet. createUnresolved megtartja ezt a hosztnevet a SOCKS-útvonalhoz ahelyett, hogy a kliensen előre feloldaná.

A rétegzett createSocket megkapja a cél identitását. setEndpointIdentificationAlgorithm("HTTPS") kifejezetten kéri a hosztnév-ellenőrzéseit. Egy nyers SSLSocket tanúsítványlánc-bizalma önmagában nem bizonyítja, hogy a hosztnév-ellenőrzés engedélyezve van. A proxy nevének vagy a loopbacknek a helyettesítése az eltérés elfojtására a rossz végpontot hitelesítheti.

Tartsa a bizalmat és a tisztítást a saját szakaszaiknál

Az alapértelmezett gyár a JVM beállított bizalmi rendszerét használja. A privát követelményekkel rendelkező alkalmazás helyette a megfelelően inicializált SSLContext gyárát használhatja. Ez a választás elkülönül a SOCKS-útvonaltól; a minden tanúsítványt elfogadó bizalmi kezelő nem javítja a hibás partnernevet.

A SOCKS elutasítása a TLS előtt történik; a nem megbízható tanúsítvány vagy a hibás hosztnév a TLS során meghiúsul; utána HTTP-hiba következhet. A proxyba való bejelentkezés az alagútkérelmet engedélyezi, nem a benne lévő webhelyet hitelesíti.

A rétegzett socket bezárása engedélyezett automatikus bezárás mellett bezárja a szállítását. A külső erőforrás-hatókör is bezárja azt a szállítást, ha a becsomagolás vagy a kézfogás a normál befejezés előtt meghiúsul.

Kapcsolódó cikkek