В настоящее время я внедряю симулятор сервера TLSv1.2, используя SunJSSE из JDK10 для тестирования клиента с ограниченными ресурсами.Клиент отправляет клиенту Hello с расширением согласования максимальной длины фрагмента, чтобы запросить 512 байтов TLSPlaintext.fragment в соответствии с определением в RFC 6066 .
См. Этот CR в OpenJDK пункт 11, я вызываю setMaximumPacketSize(517)
для максимальной длины фрагмента 512 байтов, которые требуются клиенту + 5 байтов заголовка записи TLS в симуляторе сервера, но результат фрагментации кажетсябыло сделано на сообщениях Рукопожатия вместо записи TLS.
Вот журнал перехваченной Wireshark первой записи TLS, отправленной моим имитатором сервера:
TLS фрагментированная запись путем установки jsse.enableMFLNExtension = true и максимальный размер пакета = 517
Я вижу, что Server Hello использовал 74 байта, а Server Server - 512 байтов, поэтому длина 586. Тестируемый клиент прервал квитированиес предупреждением (record_overflow), поскольку он нашел length
> согласованную длину, т.е. 512 байт.
Мои вопросы are:
Правильна ли моя конфигурация для MFLN?Мой код, как показано ниже:
// enable Maximum Fragment Length Negotiation
System.setProperty("jsse.enableMFLNExtension", "true");
Socket serverSocket = srvSock.accept();
SSLParameters sslParams = ((SSLSocket) serverSocket).getSSLParameters();
int maxPacketSize = (int) 517;
sslParams.setMaximumPacketSize(maxPacketSize);
((SSLSocket) serverSocket).setSSLParameters(sslParams);
Расширение согласования максимальной длины фрагмента не включено в Hello сервера (пожалуйста, проверьте изображение выше), но запись TLS фрагментирована, это поведениепринято?
Является ли текущая реализация (JDK v10.0.1) SunJSSE для фрагментации неправильной?Я проверил исходный код OpenJDK , он имеет системное свойство jsse.enableMFLExtension вместо jsse.enableMFL N расширение , определенное в Документация JSSE .
Заранее благодарим за любые рекомендации и мнения.