TLS and SSL decryption?

Question

[aronsky]

Иногда бывают такие проекты, что невозможно понять, с какой стороны к ним подходить.

Пришло задание:

The scope of the project is to develop a component to decrypt SSL traffic.

Here are the high-level requirements of this project:

1. We develop over Linux (Debian)
   
2. Server certificates will be provided by customers for the extraction of private keys — the required module needs to support multiple certificates simultaneously
   
3. The required decryption module will use the given certificates to extract HTTP traffic from HTTPS
   
4. The clear-text traffic will be replayed through a virtual network interface as normal HTTP
   
5. Justniffer will be the tool that sniffs the clear-text HTTP traffic from the virtual interface, thus the format of the traffic shall be Tcpdump-compatible
   

Насколько реально это сделать? Где взять достаточно литературы по SSL? С чего вообще начать?

Answer 1

[JDima]

Вполне реально. Более того — это уже давно сделано.
wiki.squid-cache.org/Features/SslBump как пример опенсорса на эту тему.
(в общем случае искать по словам «SSL man-in-the-middle»)

Comments

[aronsky]

То-есть человек, который это всё придумал неудосужидлся поискать в интернете готовые решения? Я нашёл сразу SSLBump, но подумал, что я не правильно понял задание…
Может быть в чём-то прикол? На проект отводится 2 месяца, установить это всё можно за один день, как я понял?

[Sergey]

судя по всему они не хотят «просто установить ssldump» в голом виде, они хотят некое интегрированное с Justniffer решение.

[JDima]

То-есть человек, который это всё придумал неудосужидлся поискать в интернете готовые решения?

Почему нет?
Задайте ему наводящие вопросы вида «я правильно понял, что надо сделать так-то?». А далее перечисление функционала того же SSLBump.
Кстати — п.5 меня малость удивил. Написано «слать расшифрованный трафик в виртуальный интерфейс» (в смысле — реальные пакеты со снятым SSL). А как понимать «the format of the traffic shall be Tcpdump-compatible»? Бывают IP пакеты, несовместимые со сниффером? Может, имеется в виду, что надо создать пайпу, в которую кидать HTTP трафик в формате PCAP, а на той стороне строки будет ловить анализатор сниффов (даже сниффером не назовешь)?
Мне кажется, автор ТЗ понимает, что он хочет в итоге получить, но не представляет себе устройство решения задачи. Иными словами, ТЗ должно звучать как «сорвать SSL и скормить дешифрованный трафик такой-то программе».

[aronsky]

Всё, это конец. Написал на пол страницы уточняющих вопросов, перечислил спецификации готовых решений… Получил ответ: надо сделать что-то типа этого. Не знаю, что сказать.

[Ярослав]

Небольшое уточнение — SSLBump в новом Squid'е — не совсем сниффер-декриптор SSL'я, он делает MITM «атаку», устанавливая фактически 2 SSL соединения, одно от клиента к сквиду, второе от сквида к сайту. Он не может никак декриптовать сессию из .pcap файла. А клиенту он отдает самоподписанный и сгенерированный на лету сертификат на имя сервера (но тут возможно, если уже есть есть настоящий сертификат, то можно положить его в пул и его отдавать).

[JDima]

Ага — я сначала малость неправильно понял условие.
(хотя не вполне уверен в этом)

Answer 2

[Maximus43]

Немножко покоробила терминология в ТЗ, а именно:
п.2. — серверный сертификат, как и любой сертификат, не может содержать закрытый ключ, так что извлекать там нечего. Пара ключей может содержаться в файлах p12, pfx или в отдельных файлах в формате PEM или DER. Сертификат — это всего навсего отрытый ключ плюс метадата и все это подписано закрытым ключом центра сертификации. Или может речь идет о брутфорсе закрытого ключа по открытому ключу? :-)
п. 3. — В HTTPS сертификаты используются для создания симметричного сессионного ключа, далее весь трафик шифруется этим ключом. Сессионный ключ может меняться несколько раз за время сессии. Поэтому требование использовать предоставленные сертификаты для вычленения HTTP из HTTPS для меня звучит странно. Тут надо слушать процесс генерации сессионного ключа и уже потом дешифровать трафик этим ключом.

ТЗ писал какой-то дилетант, IMHO

Comments

[Sergey]

первое замечание неверно, PEM и DER — это как раз контейнеры сертификатов, которые могут содержать закрытый ключ одновременно с открытым, более того, так часто и происходит на практике. Не может только P7B. А p12 и pfx — это вообще файлы архивов, а не сертификаты.
второе замечание верно только для Diffie-Hellman, в остальных случаях хватит наличия закрытого ключа сервера. Наверняка, если выдвигается такое требование, то DH будет отключен на веб-серверах. Если нет, то заказчик действительно болван.

[Maximus43]

Мне кажется, вы немного невнимательно прочитали мой комментарий. Речь шла о том, что сертификат мне содержит и не может содержать закрытого ключа. Про возможности форматов PEM и DER речи не шло.
Насчет HTTPS только на ассиметричных ключах, то такого в природе я не встречал никогда. И SSL, и TLS работают с сеансовыми симметричными ключами.

[Sergey]

Не надо вводить неопытного читателя в заблуждение, всё он может содержать. А PEM и DER — как раз два самых распространенных формата сертификатов.

PEM Format
The PEM format is the most common format that Certificate Authorities issue certificates in. PEM certificates usually have extentions such as .pem, .crt, .cer, and .key. They are Base64 encoded ASCII files and contain "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" statements. Server certificates, intermediate certificates, and private keys can all be put into the PEM format.

Apache and other similar servers use PEM format certificates. Several PEM certificates, and even the private key, can be included in one file, one below the other.

DER Format
The DER format is simply a binary form of a certificate instead of the ASCII PEM format. It sometimes has a file extension of .der but it often has a file extension of .cer so the only way to tell the difference between a DER .cer file and a PEM .cer file is to open it in a text editor and look for the BEGIN/END statements. All types of certificates and private keys can be encoded in DER format. DER is typically used with Java platforms.

Насчет

HTTPS только на ассиметричных ключах

речи никакой не было, надо таки внимательнее читать. Речь шла ровно про то, что если вместо DH использовать, например RSA для key exchange, то для расшифровки будет достаточно обладать закрытым ключом.

[Maximus43]

Я вам про Фому, вы мне про Ерему. :-(
Что вы привязались к этим форматам? С вами никто по этому поводу и не спорит. Разговор о том, что сертификат не может содержать закрытого ключа. Точка. Если вы не знаете определение цифрового сертификата, то я очень советую это определение узнать.
RSA применяется для обмена сессионным ключом, остальной трафик шифруется именно сессионным ключом. Я про это и писал в первом сообщении, что закрытого ключа для расшифровки трафика недостаточно, надо знать сессионный ключ, а для этого надо мониторить процесс обмена сессионными ключами.
Все у меня верно написано, перестаньте ко мне придираться без причины.

[Sergey]

Сертификат может содержать любое количество ключей, как закрытых, так и открытых. Точка.
Почитай про обмен ключами в RSA, немного подумай, осознай, что «придирки без причины» не являются таковыми.

[Maximus43]

Во-первых, не надо мне «тыкать».
Во-вторых, надо бы мне, конечно, плюнуть и не связываться, но важно исправить заблуждение. Читайте свои же цитаты из мануалов:
Server certificates, intermediate certificates, and private keys can all be put into the PEM format. Далее. Several PEM certificates, and even the private key, can be included in one file, one below the other. И далее по тексту везде. Нигде нет смешивания сертификата и закрытого ключа. Это две совершенно разные вещи. Сертификат — это подписанный публичный ключ с метадатой. Ничего другого сертификатом называться не может.
Не надо спорить в области, которая вам знакома по статьям из Википедии. Я работаю с PKI каждый день в течение последних трех лет и прекрасно знаю, что такое обмен ключами RSA, сертификаты и многое другое.
Советую остыть и все-таки попытаться понять, о чем я тут пишу уже несколько сообщений подряд.

[Sergey]

Вот наконец ты дошел до этого. «Я автор статей, текстов и постов» ©.
Произнося «сертификат» ты ограничиваешься PKC и X.509. Это нормальный процесс, часть профессиональной деформации, мне это знакомо. Но я стараюсь этого избегать.
Ну и изучи таки вопрос про RSA, не позорь честь мундира, а то обидно становится за коллегу.

Answer 3

[Sergey]

Все правильно написал JDima, все уже написано. Под линукс есть еще ssldump, она вообще под BSD-лицензией, значит можно юзать в коммерческих проектах ее исходники.

Answer 4

[rapidsslonline]

TLS and SSL both are the similar products and they work on the same algorithm, so there is no doubt that if you learn SSL certificate security then you will understand about TLS automatically. If you want in-depth view on SSL certificate and knowledge about SSL certificate, then would advise you go through below enlisted platforms which offers good knowledge about SSL certificate security!

SSL certificate information center - www.symantec.com/page.jsp?id=ssl-information-center
SSL knowledge article, www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x64.html
SSL products detail research and blogs - https://www.rapidsslonline.com/blog/