LINUX.ORG.RU

Первый выпуск реализации протокола TLS 1.3 на Java с алгоритмами ГОСТ в соответствии с RFC 9367

 ,


0

2

Модуль crypto-gost-tls13 содержит реализацию TLS 1.3 (RFC 8446 + RFC 9367) с ГОСТ-криптографией. Данный релиз является начальной версией библиотеки и готов для внутреннего использования.

Особенностью библиотеки является реализация на чистой Java. Все криптографические операции выполняются встроенными средствами библиотеки — без внешних зависимостей.

Это в своем роде одна из первых открытых реализаций TLS 1.3 с ГОСТ на Java, поэтому interop-тестирование выполнено в минимально доступном объеме.

Ниже приведены возможности библиотеки.

  1. Протоколы:
  • Handshake: полный (client/server), сокращённый (PSK), взаимный (mTLS).
  • ALPN (RFC 7301) — согласование протокола прикладного уровня (HTTP/2, HTTP/1.1).
  • SNI (RFC 6066) — указание имени сервера для multi-tenant развёртываний.
  • KeyUpdate (RFC 8446 §4.6.3) — обновление ключей шифрования трафика.
  • Cipher suites: TLS_KUZNYECHIK_MGM_STREEBOG_256_L/S.
  • ECDHE: CryptoPro-A (256-bit), CryptoPro-B (512-bit)
  • Per-record TLSTREE re-keying — смена ключа шифрования на каждую TLS-запись.
  • Фрагментация и сборка рукопожатий и записей (RFC 8446 §5.1).
  • Session resumption: PSK через NewSessionTicket (PskStore in-memory, single-use).
  • OCSP stapling: сервер прикладывает OCSP-ответ к сертификату.
  • Post-handshake messages: NewSessionTicket (сохранение для PSK).
  1. Криптография:
  • Key schedule: HKDF-Streebog (RFC 5869) по схеме TLS 1.3 (RFC 8446 §7.1).
  • Защита записей: MGM-AEAD (Kuznyechik) с nonce по RFC 8446 §5.3.
  • Эфемерные ключи затираются после использования.
  1. Сертификаты:
  • Парсинг X.509v3 (GOST R 34.10-2012) — встроенный DER-парсер.
  • Валидация цепочки: подписи, DN (issuer → subject), Basic Constraints, Key Usage, Extended Key * Usage (serverAuth / clientAuth), pathLen.
  • Проверка hostname: dNSName + iPAddress (RFC 6125).
  • Верификация OCSP-ответов (RFC 6960).

4.Транспорт:

  • TlsTransport — интерфейс.
  • InMemoryTlsTransport — для тестов и однопроцессных сценариев (in-memory очередь).
  • SocketTlsTransport — blocking I/O через java.net.Socket.
  • ChannelTlsTransport — NIO SocketChannel-based transport (blocking mode, interruptible).
  1. Пошаговый handshake:
  • TlsHandshakeEngine — state machine для handshake (отвязан от I/O). Используется TlsSession как оркестратор; пригоден для интеграции с JSSE (SSLEngine).
  1. ByteBuffer API:
  • TlsRecord.protect/unprotect — ByteBuffer-перегрузки для zero-copy интеграции с NIO. Загрузка ключей:
  • Pkcs12Loader — чтение PFX (PKCS#12) с PBKDF2-HMAC-SHA256 + AES-256-CBC.
  1. Завершение сессии:
  • close_notify — корректное закрытие по протоколу.
  • Затирание ключевого материала при закрытии или ошибке.
  • Обработка alert: fatal — немедленное закрытие + затирание.
  1. Безопасность реализации:
  • Constant-time сравнения для verify_data и PSK binders (защита от timing attacks)
  • Затирание ключевого материала: destroy() на всех объектах с ключами (TlsKeySchedule, TlsTrafficKeys, TlsRecord, HandshakeContext), при close, fatal alert, exception в handshake
  • Защита от DoS: лимиты на длину цепочки сертификатов (10), post-handshake messages, размер записей.
  • MGM nonce: MSB первого байта очищается для ICN (RFC 9058 §3, RFC 9367 §3.3).
  • ECDHE-приватный ключ и транскрипт handshake уничтожаются после завершения handshake.
  • HMAC-ключевой материал затирается после использования (HkdfStreebog, KdfGostR3411_2012_256).
  1. Ограничения:
  • Только resumption PSK (0-RTT и external PSK не поддерживаются).
  • Только psk_dhe_ke (pure PSK без ECDHE не поддерживается).
  • HelloRetryRequest (RFC 8446 §4.1.4) не поддерживается — используется только одна named group (GC256A по умолчанию).
  • Только ГОСТ (non-GOST cipher suites не поддерживаются).
  1. Тестирование:
  • Библиотека содержит Known Answer Tests из RFC 9367 Appendix A.1 (L и S варианты) — полный key schedule, TLSTREE, AEAD, ECDHE. И проходит полный спектр KAT тестов.
  • 4 интеграционных теста (self-interop) через реальные TCP-сокеты.
  • Фаззинг-тесты для парсеров: TlsMessageParser (8 методов), TlsDerParser (3 метода), TlsOcspVerifier (1 метод), для обеспечения безопасности и снижения вектора атак на парсеры.
  1. Архитектурные решения:
  • TlsHandshakeEngine — state machine, отвязанная от I/O (для будущего модуля JSSE).
  • ByteBuffer-перегрузки TlsRecord.protect/unprotect для NIO/JSSE.
  • TLSTREE кэш (TlsTreeCache) — пересчёт только изменившихся уровней (RFC 9367).
  • InMemoryTlsTransport.Pair — двунаправленная пара для тестов и однопроцессного взаимодействия.

Библиотека распространяется под свободной лицензией.

>>> Состоялся начальный релиз протокола TLS 1.3 на Java с ГОСТ алгоритмами в соответствии с RFC 9367

anonymous

Проверено: cetjs2 ()
Последнее исправление: hobbit (всего исправлений: 4)

Полезный проект

Но юмор в том, что те, кому нужна реализация гост шифрования, обязаны покупать только одобренные варианты

router ★★★★★
()

Вышел начальный релиз протокола .. и готов для внутреннего использования.

Тогда наверное он не вышел, а зашёл. Кто-то уже пробовал себе установить?

Lucky ★★
()
Ответ на: комментарий от router

Так эта библиотека тоже может стать одобренной. Все одобренные варианты когда-то кто-то написал перед этим.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Это вряд ли. Джаву сертифицировать крайне затруднительно: если вообще возможно. ФСБ крайне не любит управляемые языки. А с криптографией — это к ним.

gns ★★★★★
()

Прикольно, но только я нихрена не понимаю в криптоанализе, все эти алгебраические, алгоритмические методы… Так что оценить не смогу ГОСТ.

seiken ★★★★★
()

А что за red-star-systems - это РедСофт так назвали?

Если они, то иметь дело с этим говном нельзя - они Лукацкого пытались засудить за публикацию общеизвестной информации про дыры в их убожестве. Жидко обосрались в судах всех инстанций потому что ну какая нахрен деловая репутация у этого решета. Однако иметь дело с ними с тех пор откровенно брезгливо.

Ну а если кто-то нормальный, то ждём сертификации.

zabbal ★★★★☆
()
Последнее исправление: zabbal (всего исправлений: 1)
Ответ на: комментарий от zabbal

Не похоже. У проекта один автор и открытая лицензия какая-то.

gns ★★★★★
()
Ответ на: комментарий от seiken

Я почти уверен, что решето. Надо только подождать, пока кто-нибудь дыры найдёт.

Так что не расстраивайся.

Saakx
()
Ответ на: комментарий от router

А кому это надо? Простым юзерам или админам? Так то сайт для всех! И да, помню как-то админил локалку, прогаммер писал на питоне, но без меня не мог зайти в локалку!

piwww ★★★★
()
Ответ на: комментарий от router

ага, выглядит как honeypot.
причём от очень хорошей иишечки, почти без палева.

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 1)
Ответ на: комментарий от router

В браузере ГОСТ нужно. А покупать не обязательно. Вдруг кто-то браузер на Java напишет, вот ему и реализация.

monk ★★★★★
()
Ответ на: комментарий от gns

«Джава» к сертификации имеет мало отношения и полно программных продуктов на java «одобрено». «Одобряют» совсем не язык реализации.

vtVitus ★★★★★
()
Ответ на: комментарий от Saakx

Ну, вообще говоря, в блочных шифрах есть некие общие принципы, ну, типа один бит входа должен менять несколько бит выхода, что нулевые или другие тривиальные значения всё равно дают нетривиальный выход и проч. Так что если они учтены, то вполне может быть не хуже AES.

seiken ★★★★★
()
Ответ на: комментарий от vtVitus

Нет, Java к сертификации СКЗИ имеет самое прямое отношение. Ни о какой другой сертификации в контексте обсуждаемой темы речь идти не может.

Siborgium ★★★★★
()
Ответ на: комментарий от madcore

потому что это жуткий NIH, реализация TLS 1.3 с нуля. Да еще и с собственными криптоалгоритмами. Подобный софт просто невозможно написать, не наплодив миллион багов. А у них еще и юнит-тестов раз-два и обчелся.

Я вообще не понимаю, зачем надо было делать это с нуля при наличии готовых проверенных библиотек вроде BouncyCastle, которые можно просто пропатчить.

Lrrr ★★★★★
()
Ответ на: комментарий от Saakx

ага, а потом вопросы - «почему не работает?», «первый отдел подарил бутылку шампаского. к чему бы это?»🤡

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 1)
Ответ на: комментарий от Lrrr

потому что это жуткий NIH,

а вот те же азиаты тоже почему-то так не считают, пилят свои сид, см4 и прочие камелии
сноуден тоже так не считает, закладки от анб никто не отменял
ну и всякие такие неактуальные мелочи, как юридическая и санкционная независимость

madcore ★★★★★
()
Ответ на: комментарий от madcore

чудик, хотя бы пост для начала прочитай, на который отвечаешь. Не говоря уже про то чтобы разбираться в теме.

Lrrr ★★★★★
()

Данный проект распространяется под Открытой лицензией на программное обеспечение “Рэд старс системс”, версия 1.0.

Вот это сильно смущает. Нужно бы изучить что там (обычно Java проекты под Apache License 2.0/CDDL/EPL)...

X-Pilot ★★★★★
()
Ответ на: комментарий от Lrrr

Ох уж эти любители «готовых библиотек».

У автора есть и какая-то обёртка над «bouncycastle с gost» (которую автор депрекейтнул неделю назад со ссылкой на вот эту новую библиотеку), и пояснения почему bouncycastle плохое (в readme к этому проекту). В детали я не вдавался, да и джава-криптографию всё равно использовать не собираюсь (только на Си), но ты бы, раз тебя эта тема задела, мог бы хотя бы прочитать описание и критиковать с его учётом.

firkax ★★★★★
()
Ответ на: комментарий от Lrrr

готовых проверенных библиотек вроде BouncyCastle

Это один из худших проектов на Java, не понимаю почему с ним носятся: криво работает, плохая совместимость по версиям и прочее. Я редко это говорю, но это тот самый случай, когда «лучше написать с нуля»

X-Pilot ★★★★★
()
Ответ на: комментарий от X-Pilot

Смущать должны дыры в коде (я не проверял есть ли они там) а не побочные тексты.

Что касается лицензии, то она там на русском языке, а конкретно на канцелярите, видимо с учётом целевой аудитории библиотеки. На иностранном не подойдут. Суть лицензии копилефтная.

firkax ★★★★★
()
Ответ на: комментарий от Lrrr

Всё очень просто. С разраба, который рядом, можно спросить и востребовать. А с разраба за океаном ты хрен спросишь. Странно, что надо такие вещи объяснять. А юнит-тесты это для Корп с бездельниками, которым время некуда девать. Нормальные пацаны тестируют для конкретной железки и версии всего софта системы. Просто смотрят на покрытие кода, и тестируют все юз-кейсы end-to-end. Потом берут эту версию исходников, копируют на флешку, оформляют сопроводительную документацию и в сейф шефа.

seiken ★★★★★
()
Ответ на: комментарий от Lrrr

И потом, какие там юнит-тесты могут быть? Самые главные юнит-тесты - это фиксированные вектора вход-выход для блочных шифров. А схемы обмена и согласования ключами просто на бумаге с ручкой и экспертом оцениваются.

seiken ★★★★★
()
Ответ на: комментарий от firkax

Дыры можно поправить. В крайнем случае, можно форкнуть проект, но это должна позволять лицензия. А вот если лицензия кривая, то с этим практически ничего не сделать: вон, Крокфорд (автор JSON) распространял свою библиотеку org.json под кривой лицензией (с «Don't use for evil») и эта хрень расплодилась по куче проектов. И если быть честным и буквоедствовать, то юристы могли зарубить все эти проекты (пока они бы не перенесли на другие JSON библиотеки получше, типа GSON или Jackson). Пару лет назад он наконец-то отдал ее в Public Domain, без этой идиотской приписки, но осадок остался.

X-Pilot ★★★★★
()
Ответ на: комментарий от X-Pilot

кривой лицензией (с «Don't use for evil») и эта хрень расплодилась по куче проектов

Это - не кривая лицензия, это - общественная позиция автора, и шаг этот определённо похвальный.

firkax ★★★★★
()
Ответ на: комментарий от X-Pilot

Сам ты кривой, сторонник канцеляритских пустых текстов. Я не «оправдываю», я категорически одобряю действие автора json. А придирщиков, которые вздумали осуждать чужой труд, которым бесплатно делятся, осуждаю.

И если быть честным и буквоедствовать, то юристы могли зарубить все эти проекты

Для этого им надо было бы доказать что проекты используют её во зло.

А ещё точно так же они могли зарубить юзеров библиотеки и проектов на ней, если докажут что юзеры используют софт во зло. По-моему, прекрасная идея, хотя скорее всего юристы ничего такого делать не будут - слишком сложно.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от X-Pilot

Не вижу проблемы в конкретной формулировке «do not use for evil». Понятие зла - философское, для юридической практики (судебных разбирательств) бесполезное.

seiken ★★★★★
()
Ответ на: комментарий от router

те, кому нужна реализация гост шифрования, обязаны покупать только одобренные варианты

С чего бы это вдруг? Для подачи, например, уведомлений в налоговую, никаких одобренных вариантов никто покупать не обязан, а шифрование там по ГОСТ.

Aceler ★★★★★
()
Ответ на: комментарий от X-Pilot

Во-первых,

Первая и единственная

уже намекает на то, что все не так просто.

А еще можно вдуматься в прочитанное

Axiom JDK Certified. Сертифицировано ФСТЭК

Тогда как речь про сертификацию в ФСБ.

Siborgium ★★★★★
()
Последнее исправление: Siborgium (всего исправлений: 1)
Ответ на: комментарий от firkax

У автора есть и какая-то обёртка над «bouncycastle с gost»

У автора есть созданные 2 года назад репы «учебное приложение hypermedia» и «рецепты git». Еще он называет секретный ключ закрытым, то есть по определению не имеет отношения ни к криптографии ни к информационной безопасности.

(которую автор депрекейтнул неделю назад со ссылкой на вот эту новую библиотеку), и пояснения почему bouncycastle плохое (в readme к этому проекту). В детали я не вдавался

ну если бы вдавался, то понял бы что это не пояснения, а высер нейронки. Естественно не имеющий отношения к объективной реальности.

Отсутствие современной реализации TLS для ГОСТ.

Вот это (github.com) типа не современная, или что он там имеет ввиду? Если он не знает, как скомпилировать это под ведроид и прикрутить к жабе по JNI (хотя в жабе сейчас отказываются от JNI), то пусть обратится ко мне, я поясню. Может быть.

Lrrr ★★★★★
()
Ответ на: комментарий от Lrrr

Вот тут 4 года назад https://github.com/redstarssystems/gost/

Еще он называет секретный ключ закрытым, то есть по определению не имеет отношения ни к криптографии ни к информационной безопасности.

С чего бы это? Это обычное название.

Вот это (github.com) типа не современная, или что он там имеет ввиду?

Поскольку то был пункт спика недостатков bouncycastle, вероятно речь про bouncycastle+tls1.3+gost. Поддерживается ли там такое или нет на самом деле я разумеется не знаю, изучать джава-библиотеки не собираюсь.

ну если бы вдавался, то понял бы что это не пояснения, а высер нейронки

Может быть. Ну если это действительно так, то остальное незачем было упоминать.

firkax ★★★★★
()
Ответ на: комментарий от seiken

С разраба, который рядом, можно спросить и востребовать.

Так он помрёт завтра. Сам или помогут. Что с него стребовать? Да даже с живого. Упрется рогом и чего?

cobold ★★★★★
()
Ответ на: комментарий от firkax

Очень кривая лицензия. Потому что термин evil, он отосительный

cobold ★★★★★
()
Ответ на: комментарий от zabbal

и это ещё не всё!

коспелят венду во всём, например, заходишь такой по ссшу, а там:

Last login: Wed Apr 29 15:27:53 2026 from 192.168.X.Y
Операционная система не активирована. Для получения подробной информации выполните «man astra-subscription»

mumpster ★★★★★
()
Ответ на: комментарий от router

Если пакет аттестуют ФСТЭК, то не обязаны

MEZON ★★★★★
()
Ответ на: комментарий от X-Pilot

Ну Вы ФСТЭК-то с ФСБ не путайте. А так же СЗИ и СКЗИ

gns ★★★★★
()

Если криптография будет сертифицирована ФСБ, значит в ней гарантированно будут бэкдоры, которые тщ майор одобряэ. Имею Мнение Хрен Оспоришь.

dimgel ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.