Gunakan identitas tujuan untuk Java TLS melalui SOCKS

Hubungkan dulu melalui SOCKS, lalu lapisi SSLSocket dengan nama host situs dan pemeriksaan eksplisit endpoint HTTPS.

Endpoint SOCKS membawa Anda ke situs. Rekan TLS di dalam koneksi itu adalah situs itu sendiri, jadi teruskan nama host tujuan ke pabrik 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.
    }
}

Fragmen ini mengasumsikan impor Java networking dan TLS standar, konfigurasi kepercayaan bawaan yang sudah ada, dan koneksi SOCKS yang tidak memerlukan kredensial proxy. Fragmen menjalankan jabat tangan; aplikasi masih perlu mengirim permintaan HTTP dalam format yang diharapkan server. Untuk target HTTPS publik pada rute publik yang diizinkan, daftar proxy SOCKS menawarkan endpoint kandidat; cocokkan versi server dan dukungan nama host dengan jalur soket Java ini.

Baca dua identitas dalam contoh

127.0.0.1:1080 adalah endpoint proxy, dapat dijangkau dari proses Java ini. destination dan destinationPort mengidentifikasi situs. createUnresolved mempertahankan nama host itu untuk jalur SOCKS alih-alih menyelesaikannya lebih awal di klien.

createSocket berlapis menerima identitas tujuan. setEndpointIdentificationAlgorithm("HTTPS") secara eksplisit meminta pemeriksaan nama hostnya. Kepercayaan rantai sertifikat SSLSocket mentah tidak dengan sendirinya membuktikan bahwa verifikasi nama host diaktifkan. Mengganti nama proxy atau loopback untuk menekan ketidakcocokan dapat mengautentikasi endpoint yang salah.

Jaga kepercayaan dan pembersihan pada tahapannya

Pabrik bawaan menggunakan pengaturan kepercayaan JVM yang dikonfigurasi. Aplikasi dengan kebutuhan privat dapat menggunakan pabrik SSLContext yang diinisialisasi dengan benar sebagai gantinya. Pilihan itu terpisah dari rute SOCKS; manajer kepercayaan yang menerima setiap sertifikat tidak memperbaiki nama rekan yang salah.

Penolakan SOCKS terjadi sebelum TLS; sertifikat yang tidak tepercaya atau nama host yang salah gagal selama TLS; kesalahan HTTP dapat menyusul setelahnya. Login proxy mengotorisasi permintaan terowongan, bukan mengautentikasi situs di dalamnya.

Menutup soket berlapis dengan tutup otomatis aktif akan menutup transportnya. Cakupan sumber daya luar juga menutup transport itu jika pembungkusan atau jabat tangan gagal sebelum penyelesaian normal.

Artikel terkait