วันพฤหัสบดีที่ 1 ธันวาคม พ.ศ. 2554

Why not Client Auth? on TLS/SSL

- สร้าง TLS/SSL โดยใช้ JSSE ซึ่งใช้ public/private (keystore/truststore) ในการเข้ารหัส โดยกำหนดค่าผ่าน SSLContext

- Server อ่านค่า private key ของตนเอง แล้ว เปิด port รอไว้ เมื่อ client จะติดต่อ ก็ไป load public key ของ server มา แล้วก็ connect server โดยใช้ TLS/SSL ไร้ปัญหา สำหรับ server เพราะเป็นตัวจริงแน่ ๆ ถ้า public key ของ server เป็นของจริง

- ปัญหาคือ หาก server ต้องการ Authen Client ด้วย ถ้ามีแค่ 2 เครื่องแบบ client-server ก็ง่ายนิดเดียว ซึ่งเราสามารถสั่ง Client Auth ได้ผ่านคำสั่ง sslserversocket.setNeedClientAuth(true); โดยการกำหนด public key ของ client และ private key ของ server ที่ server ก่อนที่จะเปิด port รอ และ client ก็ set ในแบบเดียวกัน

- แต่ถ้าในระบบ P2P/DHT/Chord Server ไม่สามารถทราบได้ว่า client มีใครจะมาติดต่อบ้าง และ server ต้องเปิด port รอ โดยที่ยังไม่ทราบ public key ของ client และ ปัญหาใหญ่คือ ทุก ๆ เครื่องเป็น ทั้ง client/server ในตัว

- วิธีแก้ปัญหาในตอนนี้คือ ให้ verify เฉพาะ server อย่างเดียว เพราะ server เปิด port รอไว้ โดยใช้ private key ของตัวเอง client ก็ verify server โดยใช้ public key ของ server (อาจจะไป download จาก CA ที่ไหนสักแห่งที่ไว้ใจได้) ส่วนการ verify client ให้ใช้วิธีการ verify แบบอื่นที่ง่ายกว่า เช่น HTTP Digest เนื่องจาก วิธีนี้ มี overhead น้อย และ ปลอดภัย เนื่องจากมันถูกห่อหุ้มด้วย TLS/SSL อยู่ด้วย

- แต่การใช้ HTTP Digest มันก็ต้องมี pre-shared key ซึ่งส่งกันลำบาก ถ้ามองในแง่การส่งข้อมูล ที่ได้ทำการ implement แบบ stateless เวลา P1 -> P2, P2 ถูก verify แต่ P1 ไม่ถูก verify แต่เมื่อ P2 ตอบกลับ P1 ถูก verify แต่ P2 ไม่ถูก verify สุดท้ายแล้วก็ได้ verify ทั้ง 2 ฝ่ายอยู่ดี (เหลือปัญหาอยู่อย่างเดียวคือ คนที่เริ่ม connection อาจจะไม่ใช่คนนั้นจริง ๆ แต่ก็ตรวจสอบได้ภายหลัง)

ไม่มีความคิดเห็น: