на хабре была статейка.

( Наличие дампа + приватный ключ ) & RSA = декодирование

( Наличие дампа + приватный ключ ) & RSA = декодирование

у меня есть все три. просто не могу найти правильный инструмент или не могу правильно пользоваться ими.

https://habrahabr.ru/post/253521/

Или у меня руки кривые или глаза не там где надо, но эта вкладка «Decrypted SSL Data» не появляется.

нет, не получается. Пробовал и на windows и на linux.

Не всё так просто. Какой согласовался Cipher Suite? В Server Hello пакете его видно. Если не видно, скиньте дамп без RSA ключа, я подскажу. Некоторые современные Cipher Suite нельзя открыть даже с RSA ключом, я попался на этом год назад.

Выход есть - на клиенте ограничить список Cipher Suites до тех, которые точно можно открыть RSA ключом.

( Наличие дампа + приватный ключ ) & RSA = декодирование

Не всегда.

если используется DHE/ECDHE, то его точно не расшифровать без сессионных ключей которых у ТС нет.

Выход есть - на клиенте ограничить список Cipher Suites до тех, которые точно можно открыть RSA ключом.

не, так не получится. у меня все по pcidss.

как нет ?
я и клиент, я и сервер.
я так понимаю ты про ключ, который после handshake передается.
проблема в том, что я не знаю как их скормить акуле.

Что вообще эта фраза означает? Сделай, значит, чтобы не было по PCI DSS, пока диагностируешь.

Как тут уже написали, есть Forward secrecy. Суть в том, что ключ шифрования согласуется сторонами для каждой сессии и его нельзя узнать только прослушивая трафик (нужно в него вклиниваться по типу MiTM). Более того, насколько я понимаю, все не Forward secrecy протоколы из последнего стандарта TLS убрали. Так что не факт, что у тебя получится расшифровать дамп.

Что я делаю не так?

Как уже верно отметили, в случае Perfect Forward Secrecy одного приватного ключа недостаточно. Для декодирования TLS потребуются сессионные ключи. Есть несколько путей:

- При наличии доступа к отладке приложения на устройстве, возможно, есть способы логировать сессионные ключи (по аналогии с переменной окружений SSLKEYLOGFILE для Firefox и Chrome) в формате Wireshark.

- Изучить экзотические способы извлечения/логирования сессионных ключей на стороне веб-сервера (например, с помощью gdb или LD_PRELOAD). Штатного механизма в NGINX нет.

- На время отладки включить non-DH и дешифровать трафик приватным ключом.

С одного из них наблюдается проблема.

Всё же какую проблему вы пытаетесь решить? Для диагностики проблем на уровне SSL/TLS достаточно «сырого» дампа. Если проблема проявляется уже после согласования TLS на уровне HTTP, то NGINX покрывается логированием. Поведение NGINX удобно изучать со включенным режимом отладки (--with-debug).

- При наличии доступа к отладке приложения на устройстве, возможно, есть способы логировать сессионные ключи (по аналогии с переменной окружений SSLKEYLOGFILE для Firefox и Chrome) в формате Wireshark.

У меня есть сессионые ключи, они записываются в файл(как на хабре).
Есть и ключ сертификата, установленного на сервере.
Вопрос в том как отдать wireshark и sesionkeys и key от сертификата.

Оффтоп

Добрый день. Пардон за оффтоп. Хотел с Вами связаться и ничего лучше в голову не пришло. Можете, пожалуйста, написать мне на почту rfhusv@gmail.com? Буду очень признателен. Спасибо.