ใช้ตัวตนของปลายทางสำหรับ Java TLS ผ่าน SOCKS

ปลายทาง SOCKS พาคุณไปยังเว็บไซต์ คู่ TLS ภายในการเชื่อมต่อนั้นคือเว็บไซต์เอง ดังนั้นส่งชื่อโฮสต์ของปลายทางไปยังโรงงานซ็อกเก็ตแบบซ้อนชั้น:

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

ส่วนย่อยนี้ถือว่ามีการนำเข้า Java networking และ TLS มาตรฐาน มีการกำหนดค่าความเชื่อถือเริ่มต้นอยู่แล้ว และการเชื่อมต่อ SOCKS ที่ไม่ต้องใช้ข้อมูลรับรองพร็อกซี มันทำแฮนด์เชก แอปพลิเคชันยังต้องส่งคำขอ HTTP ในรูปแบบที่เซิร์ฟเวอร์คาดหวัง สำหรับเป้าหมาย HTTPS สาธารณะบนเส้นทางสาธารณะที่ได้รับอนุญาต รายการพร็อกซี SOCKS เสนอปลายทางที่เป็นตัวเลือก จับคู่เวอร์ชันของเซิร์ฟเวอร์และการรองรับชื่อโฮสต์กับเส้นทางซ็อกเก็ต Java นี้

อ่านตัวตนสองอย่างในตัวอย่าง

127.0.0.1:1080 คือปลายทางของพร็อกซี เข้าถึงได้จากกระบวนการ Java นี้ destination และ destinationPort ระบุเว็บไซต์ createUnresolved เก็บชื่อโฮสต์นั้นไว้สำหรับเส้นทาง SOCKS แทนที่จะแก้ไขล่วงหน้าที่ไคลเอนต์

createSocket แบบซ้อนชั้นได้รับตัวตนของปลายทาง setEndpointIdentificationAlgorithm("HTTPS") ขอการตรวจสอบชื่อโฮสต์อย่างชัดเจน ความเชื่อถือในห่วงโซ่ใบรับรองของ SSLSocket ดิบไม่ได้พิสูจน์โดยตัวมันเองว่าการตรวจสอบชื่อโฮสต์เปิดใช้งานอยู่ การแทนที่ชื่อพร็อกซีหรือ loopback เพื่อระงับความไม่ตรงกันอาจยืนยันปลายทางผิด

เก็บความเชื่อถือและการทำความสะอาดไว้กับระยะของมัน

โรงงานเริ่มต้นใช้การจัดความเชื่อถือที่กำหนดค่าไว้ของ JVM แอปพลิเคชันที่มีข้อกำหนดเฉพาะสามารถใช้โรงงาน SSLContext ที่เริ่มต้นอย่างเหมาะสมแทนได้ ตัวเลือกนั้นแยกจากเส้นทาง SOCKS ผู้จัดการความเชื่อถือที่ยอมรับทุกใบรับรองไม่ได้แก้ไขชื่อคู่ที่ผิด

การปฏิเสธ SOCKS เกิดขึ้นก่อน TLS ใบรับรองที่ไม่น่าเชื่อถือหรือชื่อโฮสต์ที่ผิดจะล้มเหลวระหว่าง TLS หลังจากนั้นข้อผิดพลาด HTTP อาจตามมา การเข้าสู่ระบบพร็อกซีอนุญาตคำขออุโมงค์ ไม่ใช่ยืนยันเว็บไซต์ภายใน

การปิดซ็อกเก็ตแบบซ้อนชั้นเมื่อเปิดการปิดอัตโนมัติจะปิดการรับส่งของมัน ขอบเขตทรัพยากรภายนอกก็ปิดการรับส่งนั้นด้วยหากการห่อหรือแฮนด์เชก ล้มเหลวก่อนการเสร็จสิ้นปกติ