Ang unang paglabas ng implementasyon ng TLS 1.3 protocol sa Java gamit ang mga algorithm ng GOST alinsunod sa RFC 9367

Modyul crypto-gost-tls13 naglalaman ng implementasyon TLS 1.3 (RFC 8446 + RFC 9367) gamit ang GOST cryptography. Ang paglabas na ito ang unang bersyon ng library at handa na para sa panloob na paggamit.

Isang natatanging katangian ng library ay ang purong implementasyon nito ng Java. Ang lahat ng operasyong kriptograpiko ay isinasagawa gamit ang mga built-in na tool ng library, nang walang mga panlabas na dependency.

Ito ang isa sa mga unang open source na implementasyon ng TLS 1.3 na may GOST sa Java, kaya ang interop testing ay isinagawa sa pinakamababang posibleng lawak.

Nasa ibaba ang mga kakayahan ng aklatan.

1. Mga Protokol:

• Pagkamayan: buo (kliyente/server), maikli (PSK), magkapareho (mTLS).
• ALPN (RFC 7301) - Negosasyon ng Protocol ng Layer ng Aplikasyon (HTTP/2, HTTP/1.1).
• SNI (RFC 6066) - Indikasyon ng Pangalan server para sa mga deployment na may maraming nangungupahan.
• KeyUpdate (RFC 8446 §4.6.3) – ina-update ang mga traffic encryption key.
• Mga cipher suite: TLS_KUZNYECHIK_MGM_STREEBOG_256_L/S.
• ECDHE: CryptoPro-A (256-bit), CryptoPro-B (512-bit)
• Muling pag-key ng TLSTREE kada record — pagpapalit ng encryption key para sa bawat TLS record.
• Paghiwa-hiwalay at muling pagsasama-sama ng mga pakikipagkamay at rekord (RFC 8446 §5.1).
• Pagpapatuloy ng sesyon: PSK sa pamamagitan ng NewSessionTicket (PskStore sa memorya, pang-isang gamit lamang).
• Pag-staple ng OCSP: server прикладывает OCSP-ответ к сертификату.
• Mga mensahe pagkatapos ng pakikipagkamay: NewSessionTicket (maliban sa PSK).

2. Kriptograpiya:

• Pangunahing iskedyul: HKDF-Streebog (RFC 5869) sa pamamagitan ng TLS 1.3 (RFC 8446 §7.1).
• Proteksyon ng rekord: MGM-AEAD (Kuznyechik) na may nonce ayon sa RFC 8446 §5.3.
• Ang mga ephemeral key ay binubura pagkatapos gamitin.

3. Mga sertipiko:

• Pag-parse ng X.509v3 (GOST R 34.10-2012) — built-in na DER parser.
• Kadena ng pagpapatunay: mga lagda, DN (tagapag-isyu → paksa), Mga Pangunahing Limitasyon, Paggamit ng Susi, Pinalawak na Paggamit ng Susi * (serverAuth / clientAuth), pathLen.
• Pagsusuri sa Hostname: dNSName + iPAddress (RFC 6125).
• Pag-verify ng mga tugon ng OCSP (RFC 6960).

4.Transportasyon:

• TlsTransport - interface.
• InMemoryTlsTransport - para sa mga pagsubok at mga senaryo ng iisang proseso (in-memory queue).
• SocketTlsTransport — hinaharangan ang I/O sa pamamagitan ng java.net.Socket.
• ChannelTlsTransport - Transportasyong nakabatay sa NIO SocketChannel (mode ng pagharang, maaaring maantala).

5. Hakbang-hakbang na pakikipagkamay:

• Ang TlsHandshakeEngine ay isang state machine para sa handshake (hiniwalay mula sa I/O). Ginagamit nito ang TlsSession bilang isang orchestrator at angkop para sa integrasyon sa JSSE (SSLEngine).

6. API ng ByteBuffer:

• TlsRecord.protect/unprotect — Nag-o-overload ang ByteBuffer para sa zero-copy integration sa NIO. Mga key na nilo-load:
• Pkcs12Loader — pagbabasa ng PFX (PKCS#12) gamit ang PBKDF2-HMAC-SHA256 + AES-256-CBC.

7. Katapusan ng sesyon:

• close_notify - itama ang pagsasara ayon sa protocol.
• Pagpupunas ng mahahalagang materyal kapag nagsasara o nagkakamali.
• Alerto sa paghawak: nakamamatay - agarang pagsasara + pagbura.

8. Seguridad sa pagpapatupad:

• Mga paghahambing na constant-time para sa verify_data at PSK binders (proteksyon laban sa mga pag-atake sa timing)
• Pagbubura ng key material: destroy() sa lahat ng object na may keys (TlsKeySchedule, TlsTrafficKeys, TlsRecord, HandshakeContext), nasa close, fatal alert, exception sa handshake
• Proteksyon ng DoS: mga limitasyon sa haba ng kadena ng sertipiko (10), mga mensahe pagkatapos ng pakikipagkamay, laki ng rekord.
• MGM nonce: Ang MSB ng unang byte ay nililimas para sa ICN (RFC 9058 §3, RFC 9367 §3.3).
• Ang pribadong key ng ECDHE at transcript ng handshake ay sisirain pagkatapos makumpleto ang handshake.
• Ang pangunahing materyal ng HMAC ay binubura pagkatapos gamitin (HkdfStreebog, KdfGostR3411_2012_256).

9. Mga Limitasyon:

• Pagpapatuloy ng PSK lamang (hindi sinusuportahan ang 0-RTT at external PSK).
• Tanging ang psk_dhe_ke (hindi sinusuportahan ang purong PSK na walang ECDHE).
• Hindi sinusuportahan ang HelloRetryRequest (RFC 8446 §4.1.4) - isang pinangalanang grupo lamang ang ginagamit (GC256A bilang default).
• GOST lamang (hindi sinusuportahan ang mga cipher suite na hindi GOST).

10. Pagsubok:

• Ang aklatan ay naglalaman ng Mga Kilalang Pagsusulit sa Sagot mula sa RFC 9367 Appendix A.1 (mga variant na L at S)—ang kumpletong iskedyul ng susi, TLSTREE, AEAD, at ECDHE. Nakapasa rin ito sa buong hanay ng mga pagsusulit na KAT.
• 4 na pagsubok sa integrasyon (self-interop) sa pamamagitan ng mga totoong TCP socket.
• Mga pagsubok sa fuzz para sa mga parser: TlsMessageParser (8 pamamaraan), TlsDerParser (3 pamamaraan), TlsOcspVerifier (1 pamamaraan), upang matiyak ang seguridad at mabawasan ang vector ng pag-atake sa mga parser.

11. Mga solusyon sa arkitektura:

• TlsHandshakeEngine - state machine na hiniwalay mula sa I/O (para sa susunod na JSSE module).
• Overload ng ByteBuffer ng TlsRecord.protect/unprotect para sa NIO/JSSE.
• TLSTREE cache (TlsTreeCache) - muling pagkalkula ng mga binagong antas lamang (RFC 9367).
• Ang InMemoryTlsTransport.Pair ay isang bidirectional pair para sa mga pagsubok at single-process na komunikasyon.

Ang aklatan ay ipinamamahagi sa ilalim ng isang libreng lisensya.

Pinagmulan: linux.org.ru