dxdt.ru: занимательный интернет-журнал

В декабре прошлого года я описывал тонкости реализации прозрачного перехвата TLS. Кроме прочего, в той записке есть и фрагмент про перехват с участием УЦ, но когда УЦ секретные ключи на отдаёт третьей стороне (чтобы меньше нарушать требования). Цитата:

Если договориться с провайдером сервиса не удаётся, то возможен другой вариант: участие хорошо известного удостоверяющего центра (УЦ). “Хорошо известного” – в том смысле, что признаваемого браузерами (в случае с HTTPS). Схема с выпуском перехватывающих промежуточных сертификатов – тоже хорошо известна, некоторые УЦ на этой схеме даже попадались. SSL-прокси может взаимодействовать с УЦ следующим образом. Прокси перехватывает TLS-соединение в момент установления, после чего отправляет на специальный API УЦ запрос с сетевым именем, к которому обращается клиент. УЦ известен секретный ключ, который прокси использует при перехвате. УЦ в режиме онлайн выпускает “короткоживущий” сертификат (например, валидный в течение суток) для ключа прокси и требуемого сетевого имени. Этот сертификат возвращается в качестве ответа API. Далее SSL-прокси использует его для подмены и, таким образом, выдаёт себя за узел, с которым пытался соединиться клиент.

На днях занятную схему “вдруг” обнаружили у УЦ Symantec, об этом пишет The Register. Symantec (ещё в прошлом году) выпустили промежуточный сертификат УЦ для Blue Coat (под этой маркой поставляются SSL-прокси для инспектирования TLS-трафика). При этом Symantec утверждает, что ключи от данного сертификата не покидали пределов систем компании, а практика с выпуском корпоративных промежуточных УЦ является стандартной. С последним, между прочим, не поспоришь: действительно, УЦ вполне могут выпускать подобные партнёрские сертификаты.

()