Я пытаюсь довести старую версию TLS 1.0 (я не писал), чтобы говорить о TLS 1.2.
В качестве первого шага я включил изменение TLS 1.1, введя вектор инициализации открытого текста в запись. Это не проблема. Он, казалось, работал достаточно хорошо, чтобы я мог читать https://example.com в TLS 1.1, а также SSL Labs viewMyClient.html.
Затем я адаптировался к изменению псевдослучайной функции TLS 1.2 (для большинства практических целей) P_SHA256 вместо (более сложной и причудливой) половины и половины MD5/SHA1 rigamarole. Я сделал это неправильно в первый раз и получил недопустимую ошибку MAC, но это была более или менее опечатка с моей стороны, и я ее исправил. Затем ошибка MAC недействительна.
Но, несмотря на это, после отправки сообщений ClientKeyExchange-> ChangeCipherSpec, я получаю сообщение "Decrypt Error" с сервера (ов) (то же Alert независимо, https://google.com или что-нибудь, что я пытаюсь). Я понимаю, что сообщение ChangeCipherSpec шифрует только один байт, помещая его в сообщение с заполнением и MAC и т.д.
Если я настраиваю MAC случайно на один байт, он возвращается к жалобе на недействительный MAC. Меня смущает то, что сам MAC зашифрован как часть GenericBlockCipher:
struct {
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length]; // <-- server reads this fine!
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher;
UPDATE: FWIW, я добавил журнал Wireshark об ошибке 1.2, прочитанный
https://example.com, а также журнал функционирующего сеанса 1.1, который работает с тем же кодом, не считая обновления MAC P_SHA256:http://hostilefork.com/media/shared/stackoverflow/example-com-tls-1.2.pcapng (не удается) http://hostilefork.com/media/shared/stackoverflow/example-com-tls-1.1.pcapng ( успешно)
Итак, что именно это имеет проблемы с расшифровкой? Заполнение кажется правильным, как если бы добавить или вычесть 1 в байт, я получаю недопустимую ошибку MAC. (Спектр говорит: "Приемник ДОЛЖЕН проверять это дополнение и ДОЛЖЕН использовать предупреждение bad_record_mac для указания ошибок заполнения". Это можно ожидать.) Если я испортил клиент-iv в сообщении из того, что я использовал для шифрования (просто поместите плохой байт в переданную версию), делая это также дает мне Bad Record MAC. Я бы ожидал, что и разрушить расшифровку.
Поэтому я озадачен тем, что может быть проблемой:
- Сервер демонстрирует распознавание действительного MAC-адреса вместо него, поэтому он должен быть расшифрован. Как он получает правильный MAC-адрес и имеет дешифрованную ошибку?
- Шифрованный набор является старым (TLS_RSA_WITH_AES_256_CBC_SHA), но я просто решаю одну проблему за раз... и если я не ошибаюсь, это не имеет значения.
Кто-нибудь с соответствующим опытом имеет теорию о том, как TLS 1.2 может выбросить ключ в код, который в противном случае работает в TLS 1.1? (Возможно, кто-то, кто сделал подобное обновление для кодовой базы, и должен был изменить больше, чем две вещи, которые я изменил, чтобы заставить ее работать?) Я пропустил еще одно важное техническое изменение? Каким образом я должен узнать, что делает сервер недовольным?
