Gunakan identiti destinasi untuk Java TLS melalui SOCKS

Sambung melalui SOCKS dahulu, kemudian lapis SSLSocket dengan nama hos laman web dan pemeriksaan titik akhir HTTPS yang jelas.

Titik akhir SOCKS membawa anda ke laman web. Rakan TLS di dalam sambungan itu ialah laman web itu sendiri, jadi hantar nama hos destinasi kepada kilang soket berlapis:

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

Coretan ini menganggap import rangkaian Java dan TLS standard, konfigurasi kepercayaan lalai yang sedia ada dan sambungan SOCKS yang tidak memerlukan kelayakan proksi. Ia melakukan jabat tangan; aplikasi masih perlu menghantar permintaan HTTP dalam format yang dijangka pelayan. Untuk sasaran HTTPS awam pada laluan awam yang dibenarkan, senarai proksi SOCKS menawarkan titik akhir calon; padankan versi pelayan dan sokongan nama hos dengan laluan soket Java ini.

Baca dua identiti dalam contoh

127.0.0.1:1080 ialah titik akhir proksi, boleh dicapai daripada proses Java ini. destination dan destinationPort mengenal pasti laman web. createUnresolved mengekalkan nama hos itu untuk laluan SOCKS dan bukannya menyelesaikannya lebih awal pada klien.

createSocket berlapis menerima identiti destinasi. setEndpointIdentificationAlgorithm("HTTPS") meminta pemeriksaan nama hosnya secara jelas. Kepercayaan rantaian sijil SSLSocket mentah tidak dengan sendirinya membuktikan pengesahan nama hos diaktifkan. Menggantikan nama proksi atau loopback untuk menindas ketidakpadanan boleh mengesahkan titik akhir yang salah.

Kekalkan kepercayaan dan pembersihan pada peringkatnya

Kilang lalai menggunakan susunan kepercayaan JVM yang dikonfigurasikan. Aplikasi dengan keperluan peribadi boleh menggunakan kilang SSLContext yang dimulakan dengan betul sebagai gantinya. Pilihan itu terpisah daripada laluan SOCKS; pengurus kepercayaan yang menerima setiap sijil tidak membaiki nama rakan yang salah.

Penolakan SOCKS berlaku sebelum TLS; sijil tidak dipercayai atau nama hos yang salah gagal semasa TLS; ralat HTTP mungkin menyusul selepas itu. Log masuk proksi memberi kuasa kepada permintaan terowong dan bukan mengesahkan laman web di dalamnya.

Menutup soket berlapis dengan tutup automatik diaktifkan menutup pengangkutannya. Skop sumber luar juga menutup pengangkutan itu jika pembalutan atau jabat tangan gagal sebelum penyiapan normal.

Artikel berkaitan