Përdorni identitetin e destinacionit për Java TLS përmes SOCKS

Lidhuni fillimisht përmes SOCKS, më pas shtresoni një SSLSocket me emrin e hostit të faqes dhe kontrolle të qarta të pikës fundore HTTPS.

Pika fundore SOCKS ju çon te faqja. Partneri TLS brenda asaj lidhjeje është vetë faqja, prandaj kaloni emrin e hostit të destinacionit te fabrika e shtresuar e soketëve:

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.
    }
}

Fragmenti supozon importe standarde të Java networking dhe TLS, një konfigurim ekzistues parazgjedhës besimi dhe një lidhje SOCKS që nuk kërkon kredenciale proxy. Ai kryen shtrëngimin e duarve; aplikacioni ende duhet të dërgojë një kërkesë HTTP në formatin që pret serveri. Për objektiva publike HTTPS në rrugë publike të lejuara, lista e proxy-ve SOCKS ofron pika fundore kandidate; përputhni versionin e serverit dhe mbështetjen e emrave të hosteve me këtë rrugë soketi Java.

Lexoni dy identitetet në shembull

127.0.0.1:1080 është pika fundore e proxy-t, e arritshme nga ky proces Java. destination dhe destinationPort identifikojnë faqen. createUnresolved ruan atë emër hosti për rrugën SOCKS në vend që ta zgjidhë menjëherë në klient.

createSocket i shtresuar merr identitetin e destinacionit. setEndpointIdentificationAlgorithm("HTTPS") kërkon në mënyrë të qartë kontrollet e emrit të hostit. Besimi në zinxhirin e certifikatave të një SSLSocket të papërpunuar nuk vërteton më vete se verifikimi i emrit të hostit është aktivizuar. Zëvendësimi i emrit të proxy-t ose i loopback-ut për të shtypur një mospërputhje mund të vërtetojë pikën fundore të gabuar.

Mbani besimin dhe pastrimin me fazat e tyre

Fabrika parazgjedhëse përdor renditjen e konfiguruar të besimit të JVM. Një aplikacion me kërkesa private mund të përdorë në vend të kësaj fabrikën e tij SSLContext të inicializuar siç duhet. Kjo zgjedhje është e ndarë nga rruga SOCKS; një menaxher besimi që pranon çdo certifikatë nuk rregullon një emër të gabuar partneri.

Një refuzim SOCKS ndodh para TLS; një certifikatë e pabesuar ose emër hosti i gabuar dështon gjatë TLS; më pas mund të pasojë një gabim HTTP. Hyrja në proxy autorizon kërkesën e tunelit, jo vërtetimin e faqes brenda tij.

Mbyllja e soketit të shtresuar me mbylljen automatike të aktivizuar mbyll transportin e tij. Fusha e jashtme e burimeve mbyll gjithashtu atë transport nëse mbështjellja ose shtrëngimi i duarve dështon para përfundimit normal.

Artikuj të ngjashëm