Несоответствие структуры SSLv3 ServerKeyExchange SIgature

Я играю с реализацией SSLv3 в Go в соответствии с rfc6101.

Я могу десериализовать ServerKeyExchange до ServerKeyExchange.signed_params.

Набор шифров TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003).

Алгоритм подписи сертификата: 1.2.840.113549.1.1.5 (sha1 с RSAEncryption).

Согласно RFC, структуры должны выглядеть так:

        структура {
            выберите (KeyExchangeAlgorithm) {
                случай diffie_hellman:
                    параметры ServerDHParams;
                    Подпись signed_params;
                случай рса:
                    параметры ServerRSAParams;
                    Подпись signed_params;
                случай fortezza_kea:
                    параметры ServerFortezzaParams;
            };
        } Обмен Ключами Сервера;

        структура с цифровой подписью {
            выберите (SignatureAlgorithm) {
                case анонимный: struct { };
                случай рса:
                    непрозрачный md5_hash[16];
                    непрозрачный sha_hash[20];
                случай ДСА:
                    непрозрачный sha_hash[20];
            };
        } Подпись;

но я получил другой ответ от сервера:

Что мне не хватает?

Спасибо!

Примерно на 10 строк выше той части, которую вы процитировали, есть

        структура {
            непрозрачный rsa_modulus<1..2^16-1>;
            непрозрачный rsa_exponent<1..2^16-1>;
        } СерверRSAParams;

так дело =рса (что на самом деле только для rsa_export) из Обмен ключами сервера действительно:

        Параметры сервераRSA:
            rsa_modulus -- непрозрачный (действительно бигендерное целое число без знака)
            rsa_exponent -- то же самое
        Подпись -- то же самое 

но это структурирование не влияет на кодирование, которое содержит только три значения «листа», и какое бы декодирование вы ни просматривали (Wireshark?), Здесь не нужно различать два уровня.

Запись структура с цифровой подписью ... Подпись не означает, что в сообщении содержатся два хэша (md5 и sha1); скорее, они являются входными данными для применимого алгоритма генерации подписи, в данном случае «типа блока 1» RSA, определенного в PKCS1v1 (теперь переименованного в RSASSA-PKCS1-v1_5 в PKCS1v2), и вывод алгоритма подписи, для RSA одно целое число, закодированное как bigendian без знака фиксированной длины (см. «I2OSP» в любой версии PKCS1), — это то, что помещается в сообщение с 2-байтовым префиксом длины, как если бы оно было объявлено непрозрачный<?..2^16-1> хотя я не вижу этого в RFC6101; TLS1.0 RFC2246 et succ указывает это в 4.7.

(Возможно, вы захотите просмотреть больше/все RFC2246, за исключением PRF и вывода ключа, некоторых кодов предупреждений и наборов шифров, добавления расширений (из которых RFC5746 Secure Renegotiation стал практически обязательным) и, конечно же, номера версии, чтобы насколько я помню, TLS1.0 технически такой же, как SSL3, но документ более тщательный, вероятно, из-за прохождения через перчатку IETF^Wprocess.)