Каков правильный способ разобрать расширенные приветственные сообщения в протоколе TLS?

Question

В соответствии с RFC 5246 (который определяет TLS протокол версии 1.2)

Page 18:

Запись слой фрагментов информационных блоков в TLSPlaintext записи, несущие данные в куски 2^14 байт или меньше. Клиентские границы не сохраняются на уровне записи (то есть несколько клиентских сообщений одного и того же ContentType МОГУТ быть объединены в одну запись TLSPlaintext или одно сообщение МОЖЕТ быть , фрагментированное на нескольких записях).

На странице 40 написано:

TLS позволяет расширениям следовать за полем compression_methods В одном из расширений блока. Наличие расширений может быть обнаружено , определяющим, есть ли байты после методов сжатия_в конце ClientHello. Обратите внимание, что этот способ определения необязательных данных отличается от обычного TLS-метода наличием поля переменной длины , но он используется для совместимости с TLS до того, как были определены расширения.

То, что я понял из этого отрывка, когда я сделал разбор ClientHello сообщения, я должен сравнить его размер в TlsPlaintext.length поле сообщения инкапсулирующей записи слоя, чтобы увидеть, если есть какие-либо дополнительные байты в конце записывать слой messsage, а если есть, интерпретировать их как структуры Extension.

Это действительно корректно работает для некоторых проб трафика TLS, с которыми я тестирую свое приложение, но не работает для некоторых других (то есть он не может обнаружить сообщения, которые могут использовать проводники). Когда я смотрю на проблемный пакет с помощью wirehark, он выглядит как несколько сообщений для рукопожатия, объединенных в одно сообщение подтверждения. Это ServerHello (который выглядит точно так же, как ClientHello) с расширениями, Certificate и ServerHelloDone.

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

Любая помощь или предложение о том, как разбирать эти пакеты, будут оценены.

Answer 1

Каждое сообщение TLS, принадлежащее протоколу hanshake, протоколу изменения шифрования, протоколу оповещений, другому протоколу, отправляется в (или выше) протоколе уровня записи.Посмотрите на это: https://technet.microsoft.com/en-us/library/cc767139.aspx

протокола Record Layer обеспечит:

• Тип содержимого (1 октет)
• Version (2 октета)
• Длина (2 октета)

Каждое сообщение TLS начнется с этих полей, даже если вы увидите много сообщений SSL в полезной нагрузке одного и того же сегмента TCP. Вы можете анализировать эти сообщения как отдельные сообщения TLS.

Длина протокола протокола SSL даст вам общую длину сообщения протокола верхнего уровня. Если это сообщение Hello как часть протокола Handshake, оно будет включать расширения. Это поле также позволит вам определить границы или множество сообщений TLS, которые собираются вместе.

В случае сообщения Hello после поля методов сжатия у вас есть 2 октета с указанием длины расширений. Расширения включены в поле Длина протокола протокола SSL, содержащего сообщение Hello. Они также включены в длину того же сообщения Hello.

После SSL Record Layer, каждое сообщение из другого протокола разбирается в своем роде:

• Change Cipher Spec протокола: всегда 1 октет
• протокол квитирования: TLV (тип, длина, Value)
• оповещение Протокол: 2 Octets (уровень, оповещение)
• HTTP или другие ...

Так что, когда у вас есть много TL S сообщения, приходящие вместе в одном сегменте TCP, вы всегда:

Offset = 0 
While more data (based on TCP payload length): 
    Read first 5 octets at Offset 
     Obtain Length field (Assign to MessageLength, Offset += 5) 
      Process first TLS message from Offset, with length MessageLength 
      Offset += MessageLength 

Я надеюсь, что я обращаюсь ваш вопрос правильно ...