Нет, вы не можете расшифровать сеансы HTTPS / SSL из захвата сети, даже если у вас есть сертификаты. В этом весь смысл криптографии с открытым ключом , на которой основан SSL.
В вашем хранилище ключей браузера есть сертификаты, которые будут проверять действительность открытых ключей сервера. Указанные открытые ключи доступны, но их нельзя использовать для дешифрования пакетов сеанса, поскольку алгоритм шифрования не является симметричным.
Вам понадобятся частные ключи сервера для того, чтобы расшифровать сеанс SSL, и в нормальных ситуациях его довольно сложно получить.
См. Также статью в Википедии о TLS для получения дополнительной информации.
EDIT:
Я добавлю еще немного информации в терминах непрофессионала, в основном оторванной от двух ссылок выше, чтобы сделать вещи немного яснее.
Криптография с открытым ключом основана на асимметричных алгоритмах шифрования. Они включают в себя два ключа, а не один, открытый ключ и закрытый ключ. Эти два ключа состоят из пары ключей . Предполагая достаточно сильный алгоритм, все, что зашифровано открытым ключом, может быть зашифровано только закрытым и наоборот. Открытый ключ широко доступен для всех, в то время как закрытый ключ надежно хранится и используется только его владельцем. Как это помогает?
На сервере имеется пара ключей, состоящая из общедоступного открытого ключа и защищенного (и недоступного для всех, кроме самого сервера) личного ключа.
Клиент использует открытый ключ сервера для шифрования довольно длинного случайного ключа для симметричного алгоритма в начале каждого зашифрованного сеанса. Этот ключ отправляется на сервер.
Поскольку симметричный ключ шифруется таким образом, его можно расшифровать только с помощью личного ключа сервера. Это означает, что он не может быть извлечен из захваченного сетевого потока, и, поскольку он используется для оставшейся части сеанса, ни одна из данных, передаваемых позднее, не может.
Сервер использует свой закрытый ключ для получения симметричного ключа сеанса, и все в порядке.
Это так? В приведенной выше схеме есть еще одна проблема! Как клиент получит открытый ключ сервера? Более конкретно, как он узнает, что он говорит с самим сервером, а не с каким-то мошенником, которому удалось вставить себя в середину (см. Атака «Человек посредине» )?
Клиент не может знать каждый открытый ключ - их миллионы. Он должен будет извлечь их с серверов и затем каким-то образом убедиться, что они принадлежат интересующему их серверу.
Это - то, где появляется другая функция криптографии с открытым ключом. Ранее мы использовали открытый ключ для шифрования данных, так что только его предполагаемое место назначения могло расшифровать их. Теперь мы
поступите наоборот: мы используем закрытый ключ для шифрования данных, чтобы их можно было расшифровать только с помощью открытого ключа. По сути, мы подписываем данные, чтобы при расшифровке с открытым ключом люди знали, что данные поступили с сервера. Как это помогает?
Когда браузер установлен, в нем предварительно установлено относительно небольшое количество открытых ключей (обычно называемых сертификатами). Они принадлежат сертификационным органам (CA), которые являются организациями (обычно такими компаниями, как Verisign, правительства или даже некоторые учреждения), которые считаются заслуживающими доверия. Центры сертификации используют соответствующие закрытые ключи для подписи других открытых ключей, доступных в Интернете и т. Д.
Поэтому, когда браузер связывается с сервером и получает его открытый ключ, этот ключ должен быть подписан закрытым ключом из пары сертификатов. Эта пара сертификатов также будет подписана другим, и так далее, с до браузер обнаружит открытый ключ, который был подписан с помощью закрытого ключа, который соответствует одному из корневых сертификатов, которые были предварительно установлены с ним. Возможно, вы захотите прочитать мой предыдущий ответ , чтобы узнать больше о корневых сертификатах, или просто прочитайте статьи в Википедии.
Поскольку каждый открытый ключ был подписан последовательно, пока мы не достигли доверенного ключа, клиент теперь может быть уверен, что сервер на другом конце соединения действительно является, например, MyBank.com, а не, скажем, ноутбук какого-то преступника в соседнем кафе, который портит беспроводное соединение.
Хотя были слабые алгоритмы SSL (отсюда и последовательность версий протокола SSL), в наши дни атаки обычно нацелены на реализации:
Используйте специально созданные или неправильно сформированные сертификаты, чтобы обмануть браузер (и его слабую реализацию), думая, что открытый ключ подписан доверенным объектом, когда это действительно не так.
Подрыв целостности клиентского программного обеспечения (например, вируса) для захвата симметричных ключей при их создании. Однако в большинстве этих случаев обычно легче просто захватить интересные данные, когда они вводятся в браузер, например, захватывать нажатия клавиш, когда пользователь вводит номер своей кредитной карты.
Компрометировать сам сервер и украсть закрытый ключ. Хотя это и не так просто, как нацеливание на ничего не подозревающих клиентов, это произошло, и оно может поставить под угрозу значительно большее количество зашифрованных сеансов. Текущая Инфраструктура открытых ключей (PKI) имеет целый механизм для отзыва и отключения скомпрометированных или иным образом недействительных ключей.
Последняя атака может быть побеждена, если клиент отправляет собственный временный открытый ключ вместо симметричного ключа и использует асимметричный алгоритм для всего сеанса. Это сделало бы невозможным для злоумышленника скомпрометировать прошлые сеансы путем кражи закрытого ключа сервера. Этот метод является основой для обеспечения Perfect Forward Secrecy , но, к сожалению, пока не все серверы реализуют его по соображениям совместимости или производительности.