โมดึล คริปโต-โกสต์-ทีแอลเอส13 ประกอบด้วยการใช้งาน TLS 1.3 (RFC 8446 + RFC 9367) พร้อมด้วยการเข้ารหัส GOST เวอร์ชันนี้เป็นเวอร์ชันเริ่มต้นของไลบรารีและพร้อมสำหรับการใช้งานภายใน
จุดเด่นอย่างหนึ่งของไลบรารีนี้คือการใช้งานด้วยภาษา Java อย่างสมบูรณ์ การดำเนินการทางด้านการเข้ารหัสทั้งหมดดำเนินการโดยใช้เครื่องมือในตัวของไลบรารี โดยไม่มีการพึ่งพาไลบรารีภายนอกใดๆ
นี่เป็นหนึ่งในโปรแกรมโอเพนซอร์สแรกๆ ที่ใช้ TLS 1.3 ร่วมกับ GOST ในภาษา Java ดังนั้นการทดสอบการทำงานร่วมกันจึงทำไปในระดับที่น้อยที่สุดเท่าที่จะเป็นไปได้
ด้านล่างนี้คือความสามารถของห้องสมุด
- โปรโตคอล:
- การจับมือ: แบบเต็มรูปแบบ (ไคลเอ็นต์/เซิร์ฟเวอร์), แบบสั้น (PSK), แบบสองทาง (mTLS)
- ALPN (RFC 7301) - การเจรจาโปรโตคอลระดับแอปพลิเคชัน (HTTP/2, HTTP/1.1)
- SNI (RFC 6066) - การระบุชื่อ เซิร์ฟเวอร์ สำหรับการใช้งานแบบหลายผู้เช่า
- KeyUpdate (RFC 8446 §4.6.3) – การอัปเดตคีย์การเข้ารหัสทราฟฟิก
- ชุดการเข้ารหัส: TLS_KUZNYECHIK_MGM_STREEBOG_256_L/S
- ECDHE: CryptoPro-A (256 บิต), CryptoPro-B (512 บิต)
- การเปลี่ยนคีย์การเข้ารหัส TLSTREE ต่อระเบียน — การเปลี่ยนคีย์การเข้ารหัสสำหรับแต่ละระเบียน TLS
- การแยกส่วนและการประกอบใหม่ของข้อมูลการจับมือและบันทึก (RFC 8446 §5.1)
- การกลับมาใช้งานเซสชันต่อ: PSK ผ่าน NewSessionTicket (PskStore ในหน่วยความจำ ใช้ได้ครั้งเดียว)
- การเย็บด้วยลวดเย็บกระดาษ OCSP: เซิร์ฟเวอร์ เพิ่มการตอบสนอง OCSP ต่อท้ายใบรับรอง
- ข้อความหลังการจับมือ: NewSessionTicket (ยกเว้น PSK)
- การเข้ารหัสลับ:
- กำหนดการสำคัญ: HKDF-Streebog (RFC 5869) ผ่าน TLS 1.3 (RFC 8446 §7.1)
- การปกป้องข้อมูล: MGM-AEAD (Kuznyechik) พร้อม nonce ตาม RFC 8446 §5.3
- คีย์ชั่วคราวจะถูกลบหลังจากใช้งานเสร็จ
- ใบรับรอง:
- การแยกวิเคราะห์ X.509v3 (GOST R 34.10-2012) — ตัวแยกวิเคราะห์ DER ในตัว
- ลำดับการตรวจสอบความถูกต้อง: ลายเซ็น, DN (ผู้ออก → ผู้รับ), ข้อจำกัดพื้นฐาน, การใช้งานคีย์, การใช้งานคีย์เพิ่มเติม (serverAuth / clientAuth), pathLen
- การตรวจสอบชื่อโฮสต์: dNSName + ที่อยู่ iPad (RFC 6125)
- การตรวจสอบการตอบสนอง OCSP (RFC 6960)
4.ขนส่ง:
- TlsTransport - อินเทอร์เฟซ
- InMemoryTlsTransport - สำหรับการทดสอบและสถานการณ์การทำงานแบบกระบวนการเดียว (คิวในหน่วยความจำ)
- SocketTlsTransport — การรับส่งข้อมูลแบบบล็อกผ่าน java.net.Socket
- ChannelTlsTransport - การส่งข้อมูลแบบ SocketChannel ของ NIO (โหมดบล็อก สามารถขัดจังหวะได้)
- ขั้นตอนการจับมือทักทาย:
- TlsHandshakeEngine เป็นสเตทแมชชีนสำหรับกระบวนการจับมือ (แยกส่วนจากการรับส่งข้อมูล) โดยใช้ TlsSession เป็นตัวจัดการ และเหมาะสำหรับการบูรณาการกับ JSSE (SSLEngine)
- API ของ ByteBuffer:
- TlsRecord.protect/unprotect — โอเวอร์โหลด ByteBuffer สำหรับการรวมระบบแบบ zero-copy กับ NIO คีย์การโหลด:
- Pkcs12Loader — อ่านไฟล์ PFX (PKCS#12) ด้วย PBKDF2-HMAC-SHA256 + AES-256-CBC
- สิ้นสุดการประชุม:
- close_notify - การปิดที่ถูกต้องตามโปรโตคอล
- การเช็ดวัสดุสำคัญเมื่อปิดหรือเกิดข้อผิดพลาด
- แจ้งเตือนการจัดการ: ร้ายแรง - ปิดและลบข้อมูลทันที
- ความปลอดภัยในการใช้งาน:
- การเปรียบเทียบแบบใช้เวลาคงที่สำหรับ verify_data และ PSK binders (ป้องกันการโจมตีแบบจับเวลา)
- ล้างข้อมูลสำคัญ: ทำลาย (destroy()) วัตถุทั้งหมดที่มีคีย์ (TlsKeySchedule, TlsTrafficKeys, TlsRecord, HandshakeContext) เมื่อปิดโปรแกรม แจ้งเตือนร้ายแรง เกิดข้อผิดพลาดในการเชื่อมต่อ
- การป้องกัน DoS: ข้อจำกัดเกี่ยวกับความยาวของห่วงโซ่ใบรับรอง (10), ข้อความหลังการจับมือ, ขนาดบันทึก
- MGM nonce: บิตที่มีค่าสูงสุด (MSB) ของไบต์แรกจะถูกล้างสำหรับ ICN (RFC 9058 §3, RFC 9367 §3.3)
- กุญแจส่วนตัวของ ECDHE และบันทึกการจับมือจะถูกทำลายหลังจากกระบวนการจับมือเสร็จสมบูรณ์
- ข้อมูลคีย์ HMAC จะถูกลบหลังจากใช้งาน (HkdfStreebog, KdfGostR3411_2012_256)
- ข้อ จำกัด :
- รองรับเฉพาะ PSK สำหรับการกลับมาทำงานต่อเท่านั้น (ไม่รองรับ 0-RTT และ PSK ภายนอก)
- รองรับเฉพาะ psk_dhe_ke เท่านั้น (ไม่รองรับ PSK บริสุทธิ์ที่ไม่มี ECDHE)
- HelloRetryRequest (RFC 8446 §4.1.4) ไม่ได้รับการสนับสนุน - มีการใช้เพียงกลุ่มที่มีชื่อเพียงกลุ่มเดียว (GC256A เป็นค่าเริ่มต้น)
- รองรับเฉพาะ GOST เท่านั้น (ไม่รองรับชุดเข้ารหัสที่ไม่ใช่ GOST)
- การทดสอบ:
- ไลบรารีนี้ประกอบด้วย Known Answer Tests จาก RFC 9367 Appendix A.1 (L และ S variants) ได้แก่ ตารางคีย์แบบเต็มรูปแบบ, TLSTREE, AEAD, ECDHE และยังผ่านการทดสอบ KAT ครบทุกรายการอีกด้วย
- 4 การทดสอบการทำงานร่วมกัน (self-interop) ผ่านซ็อกเก็ต TCP จริง
- การทดสอบแบบ Fuzz สำหรับตัวแยกวิเคราะห์: TlsMessageParser (8 เมธอด), TlsDerParser (3 เมธอด), TlsOcspVerifier (1 เมธอด) เพื่อให้มั่นใจในความปลอดภัยและลดช่องทางการโจมตีตัวแยกวิเคราะห์
- แนวทางการแก้ปัญหาทางสถาปัตยกรรม:
- TlsHandshakeEngine - สเตทแมชชีนที่แยกส่วนจากการรับส่งข้อมูล (สำหรับโมดูล JSSE ในอนาคต)
- ByteBuffer เป็นโอเวอร์โหลดของ TlsRecord.protect/unprotect สำหรับ NIO/JSSE
- แคช TLSTREE (TlsTreeCache) - การคำนวณใหม่เฉพาะระดับที่เปลี่ยนแปลงเท่านั้น (RFC 9367)
- InMemoryTlsTransport.Pair เป็นคู่การสื่อสารแบบสองทิศทางสำหรับการทดสอบและการสื่อสารในกระบวนการเดียว
ชุดข้อมูลนี้เผยแพร่ภายใต้ใบอนุญาตแบบเสรี
ที่มา: linux.org.ru
