Тестирую свою реализацию TLS с Вашим демо-стендом. После Client Key Exchange/Change Cipher Spec/Encrypted Handshake получаю RST со стороны стенда (tlsgost-256).
В логах со стороны сервера:


Правильно ли я понимаю, что где-то не сошелся MAC? Есть ли возможность выяснить, какой именно?
TLS со старыми cipher suite проходит без проблем. CMS-сообщения (signed, key transport) из ТК26CMS тоже
обрабатываются правильно.

И уточняющий вопрос: Если в сертификате в параметрах указан OID 1.2.643.2.2.31.1, на каком наборе параметров
должны происходить шифрование и вычисление имитовставки при шифровании ключа? При вычислении MAC пакета?

Спасибо.

Параметры алгоритма имитозащиты пакета определяются, как и параметры шифрования пакета, выбором сюиты (для 2001 - id-Gost28147-89-CryptoPro A ParamSet, для 2012 - id-tc26-gost-28147-param-Z) (см. [ТК26TLS, 4.4]).

Параметры алгоритма шифрования и имитозащиты при передаче premaster_secret определяются, в соответствии с [ТК26TLS, 5.6.1] и [ТК26CMS, 6.2.1], параметрами ключа получателя, т.е. параметрами из сертификата сервера.

В Вашем случае (при работе на TLS_GOSTR341112_256_WITH_28147_CNT_IMIT при сертификате сервера с 1.2.643.2.2.31.1 = id-Gost28147-89-CryptoPro-A-ParamSet) шифрование и имитозащита пакета должна происходить на id-tc26-gost-28147-param-Z, а защита premaster_secret (шифрование и имита) на id-Gost28147-89-CryptoPro-A-ParamSet.

Отредактировано пользователем 20 августа 2014 г. 10:18:41(UTC)  | Причина: Не указана

Станислав, большое спасибо. Все заработало, как с аутентификацией, так и без нее.

Отлаживаю свою реализацию TLS с новыми циферсьютами, есть проблема.
До client key exchange включительно все проходит успешно, с серт-верифай проблема.

Для начала, не сходится у меня с примером (для начала, сервер 512бит и клиент 256бит) ТК26TLS вычисление хеша от сообщений.
Из примера (а там, похоже, ошибки - местами нулевых байт в длинах не хватает) уже руками склеил все хендшейк-сообщения, считаю от них хеш - не совпадает.
Проверяю утилитой из CSP:
cpverify.exe -mk-alg GR3411_2012_256 handshakeforhash.bin
хеш совпадает с моим, с тем, что в примере не совпадает

вторая проблема, в примере верифай выглядит так

message type
0F
length
000040
certificate verify
F17A142A 4D306C61 1C5FE211 055A40A1 18A3080F 2A82771F 9447E4C9 A5AEC9C6
4411AC5A BDBDBA1F 6FBD23CD 3AC0873C ED7B0C90 8CAFDB07 60E8B20E DEA72A9F

когда в старых реализациях еще была длина перед ЭЦП, т.е. должно быть так
message type
0F
length
000042
certificate verify
0040
F17A142A 4D306C61 1C5FE211 055A40A1 18A3080F 2A82771F 9447E4C9 A5AEC9C6
4411AC5A BDBDBA1F 6FBD23CD 3AC0873C ED7B0C90 8CAFDB07 60E8B20E DEA72A9F

Не первый посыл тестовый сервер мне сообщает
Dec 21 15:13:11 tlsgost cprdr[8946]: libssp: ssl3_verify_records_new not a tls record - http may be

на второй в лог не попадает вообще ничего, меня молча отключает.

Какой вариант правильный ?

Добрый день!

Действительно, в примерах в утвержденной версии документа от 2013 года указаны некорректные сообщения после обработки мастер-ключа (ошибка в лишнем хэшировании), корректные примеры всем партнерам мы всегда предоставляем от себя (от лица ТК 26 формального права не имеем), обращайтесь.

Скорректированная версия подготовлена, надеемся ее утвердить весной на очередном заседании ТК 26.