ProHoster > Blog > Nachrichten aus dem Internet > Die erste Implementierung des TLS 1.3-Protokolls in Java mit GOST-Algorithmen gemäß RFC 9367

Die erste Implementierung des TLS 1.3-Protokolls in Java mit GOST-Algorithmen gemäß RFC 9367

Modul crypto-gost-tls13 enthält eine Implementierung TLS 1.3 (RFC 8446 + RFC 9367) mit GOST-Kryptografie. Diese Version ist die erste Version der Bibliothek und bereit für den internen Einsatz.

Das Besondere an der Bibliothek ist die Implementierung in reinem Java. Alle kryptografischen Operationen werden mit den integrierten Mitteln der Bibliothek ausgeführt – ohne externe Abhängigkeiten.

Es ist eine der ersten offenen Implementierungen von TLS 1.3 mit GOST in Java, daher wurde die Interoperabilitätstests minimal durchgeführt.

Im Folgenden sind die Möglichkeiten der Bibliothek aufgeführt.

  1. Protokolle:
  • Handshake: vollständig (client/server), verkürzt (PSK), gegenseitig (mTLS).
  • ALPN (RFC 7301) — Aushandlung des Anwendungsschichtprotokolls (HTTP/2, HTTP/1.1).
  • SNI (RFC 6066) — Angabe des Namens Server für Multi-Tenant-Deployments.
  • KeyUpdate (RFC 8446 §4.6.3) — Aktualisierung der Verschlüsselungsschlüssel für den Datenverkehr.
  • Cipher Suites: TLS_KUZNYECHIK_MGM_STREEBOG_256_L/S.
  • ECDHE: CryptoPro-A (256-Bit), CryptoPro-B (512-Bit)
  • Per-Record TLSTREE-Re-Keying — Änderung des Verschlüsselungsschlüssels für jeden TLS-Datensatz.
  • Fragmentierung und Zusammenstellung von Handshakes und Aufzeichnungen (RFC 8446 §5.1).
  • Sitzungswiederaufnahme: PSK über NewSessionTicket (PskStore im Speicher, einmalige Verwendung).
  • OCSP-Stapling: Server fügt die OCSP-Antwort dem Zertifikat bei.
  • Nach-Handshake-Nachrichten: NewSessionTicket (Speicherung für PSK).
  1. Kryptografie:
  • Key Schedule: HKDF-Streebog (RFC 5869) gemäß dem Schema TLS 1.3 (RFC 8446 §7.1).
  • Schutz von Aufzeichnungen: MGM-AEAD (Kuznyechik) mit Nonce gemäß RFC 8446 §5.3.
  • Ephemerale Schlüssel werden nach der Verwendung gelöscht.
  1. Zertifikate:
  • Parsing von X.509v3 (GOST R 34.10-2012) — integrierter DER-Parser.
  • Validierung der Kette: Signaturen, DN (Aussteller → Subjekt), Grundlegende Einschränkungen, Schlüsselverwendung, Erweiterte Schlüsselverwendung (serverAuth / clientAuth), pathLen.
  • Hostname-Prüfung: dNSName + iPAddress (RFC 6125).
  • Verifizierung von OCSP-Antworten (RFC 6960).

4.Transport:

  • TlsTransport — Schnittstelle.
  • InMemoryTlsTransport — für Tests und einprozessuale Szenarien (in-memory Warteschlange).
  • SocketTlsTransport — blockierendes I/O über java.net.Socket.
  • ChannelTlsTransport — NIO SocketChannel-basierter Transport (blockierender Modus, unterbrechbar).
  1. Schrittweiser Handshake:
  • TlsHandshakeEngine — Zustandsautomat für den Handshake (von I/O unabhängig). TlsSession wird als Orchestrator verwendet; geeignet für die Integration mit JSSE (SSLEngine).
  1. ByteBuffer-API:
  • TlsRecord.protect/unprotect — ByteBuffer-Überladungen für die zero-copy-Integration mit NIO. Schlüssel laden:
  • Pkcs12Loader — Lesen von PFX (PKCS#12) mit PBKDF2-HMAC-SHA256 + AES-256-CBC.
  1. Sitzungsabschluss:
  • close_notify — ordnungsgemäße Schließung gemäß Protokoll.
  • Löschen von Schlüsselmaterial bei Schließung oder Fehler.
  • Behandlung von Alerts: fatal — sofortige Schließung + Löschen.
  1. Sicherheit der Implementierung:
  • Vergleich in konstanter Zeit für verify_data und PSK-Binder (Schutz vor Timing-Angriffen)
  • Löschen von Schlüsselmaterial: destroy() für alle Objekte mit Schlüsseln (TlsKeySchedule, TlsTrafficKeys, TlsRecord, HandshakeContext) bei close, fatal alert, Ausnahme im Handshake
  • Schutz vor DoS: Begrenzungen für die Länge der Zertifikatkette (10), Post-Handshake-Nachrichten, Aufzeichnungsgröße.
  • MGM-Nonce: MSB des ersten Bytes wird für ICN gelöscht (RFC 9058 §3, RFC 9367 §3.3).
  • Der ECDHE-Private-Key und der Handshake-Transkript werden nach Abschluss des Handshakes zerstört.
  • HMAC-Schlüsselmaterial wird nach der Verwendung gelöscht (HkdfStreebog, KdfGostR3411_2012_256).
  1. Einschränkungen:
  • Nur Wiederaufnahme-PSK (0-RTT und externe PSK werden nicht unterstützt).
  • Nur psk_dhe_ke (reines PSK ohne ECDHE wird nicht unterstützt).
  • HelloRetryRequest (RFC 8446 §4.1.4) wird nicht unterstützt – es wird nur eine benannte Gruppe verwendet (GC256A standardmäßig).
  • Nur GOST (non-GOST Cipher-Suites werden nicht unterstützt).
  1. Testen:
  • Die Bibliothek enthält bekannte Antworttests aus dem Anhang A.1 von RFC 9367 (L- und S-Varianten) – vollständiger Schlüsselplan, TLSTREE, AEAD, ECDHE. Sie besteht alle KAT-Tests.
  • 4 Integrationstests (self-interop) über echte TCP-Sockets.
  • Fuzzing-Tests für Parser: TlsMessageParser (8 Methoden), TlsDerParser (3 Methoden), TlsOcspVerifier (1 Methode), um Sicherheit zu gewährleisten und die Angriffsvektoren auf Parser zu reduzieren.
  1. Architektonische Entscheidungen:
  • TlsHandshakeEngine – Zustandsmaschine, entkoppelt von I/O (für das zukünftige JSSE-Modul).
  • ByteBuffer-Überladungen TlsRecord.protect/unprotect für NIO/JSSE.
  • TLSTREE-Cache (TlsTreeCache) – Neuberechnung nur der geänderten Ebenen (RFC 9367).
  • InMemoryTlsTransport.Pair – bidirektionales Paar für Tests und die Interaktion in einem Prozess.

Die Bibliothek wird unter einer offenen Lizenz verteilt.

Quelle: linux.org.ru

60GB SSD 8Gb DDR4