Wireshark не расшифровывает пакет TLS

Я не могу понять, почему здесь не работает расшифровка.

Рассмотрим сценарий в этом файле pcap - https://drive.google.com/open?id=0Bz5corUPBatBWWpXTFYwWjdfS0k

У меня такая сетевая настройка, что

Internet Server (104.31.17.3)<---------> (eth1) Gateway (192.168.151.19) (eth0) <----------> Client (192.168.151.15)

Для контекста этого захвата я использую фильтры tcp и! Ssh, и меня интересуют только кадры от кадра № 22 до кадра № 98.

Объяснение того, что происходит между этими кадрами -

1. Кадр 22-30 - это рукопожатие TLS.
2. Кадр 31 - это запрос GET. Это сбрасывается правилом брандмауэра.
3. Кадры 32-35 - это некоторые повторные передачи для одного и того же запроса GET (см. Длину пакета и т. Д.)
4. Фреймы 38-86 - это клиентский компьютер (тот, который сделал запрос GET) и компьютер-шлюз взаимодействуют. (связь rsync + ssh - см. номер порта 22 в кадрах) Кадр 61 - это просто еще одна повторная передача для запроса GET.
5. Кадр 87 - еще одна повторная передача для запроса GET от клиента.
6. Разница во времени между кадрами 86 и 87 составляет 0,9 секунды (в течение которых были обновлены некоторые правила межсетевого экрана).
7. Кадр 88 - это когда сервер отвечает и содержит данные приложения TLS. Wireshark не может расшифровать фрейм 88, который меня интересует.

Файл отладки нелегко прочитать, поскольку код диссектора изменен. (Использование оператора ssl_debug_printf в цикле необходимо для других целей). Используйте следующую команду, чтобы прочитать файл отладки. Параметр -C печатает следующие # строки после строки grep.

cat debug.txt | grep -C 10 "frame #88"

Я не понимаю, почему Wireshark не может расшифровать пакет данных приложения TLS. Пакет принадлежит одному и тому же потоку TCP, номеру порта TCP и разговору SSL. Состояние SSL такое же, как и для начального запроса GET (которое было отброшено из-за правила брандмауэра - кадр 31).