Прошлое и настоящее SSL-сертификатов
Появление SSL
SSL (Secure Sockets Layer), семейство транспортных криптографических протоколов, известно примерно с 1994 года (первые работы по использованию средств криптографии в качестве транспорта для уже известных протоколов проводились и раньше).
Последний протокол семейства, SSL v3, в июне 2015 года в RFC7568 объявлен устаревшим. Взамен него надлежит использовать новые версии семейства SSL, протоколы TLS (Transport Layer Security) версии 1.2 или старше (на момент написания этого текста).
Оба протокола используют так называемый сертификат открытого ключа стандарта X.509, который не вполне корректно принято называть сейчас SSL-сертификатом. Стандарт известен с 1988 года. Сертификат открытого ключа, успешно использовавшийся на протяжении всего прошедшего времени, успел продемонстрировать свои сильные и слабые стороны (о них сказано ниже).
X.509 используется в так называемой инфраструктуре открытых ключей (PKI) — сюда входит не только программное обеспечение для использования сертификатов и других компонентов стандарта для передачи данных по защищённым от перехвата каналам, но также и оборудование, организации, собственно люди, соблюдающие упомянутые стандарты и обеспечивающие функционирование всей инфраструктуры в самых разных масштабах. Одного системного администратора может быть достаточно для успешного поддержания PKI в рамках достаточно крупной локальной сети не очень большой организации.
Важно понимать, что SSL-сертификат — всего лишь формат документа. Он не является «магическим» инструментом для формирования доверия к тому или иному ресурсу. Сертификат позволяет, при соблюдении ряда условий, проверить аутентичность передаваемых данных, указать на степень доверия к источнику зашифрованных данных. Как любой инструмент, сертификат может быть использован как для формирования определённой степени доверия к источнику данных, так и для дискредитации его.
Криптография с открытым ключом
До 1970 года использовалась практически только криптография с симметричным ключом. Очевидное слабое звено таких криптографических схем — необходимость передачи ключа всем участвующим в защищённом обмене сторонам.
Изобретателем методики шифрования с открытым ключом считается Роберт Меркл. Если в случае симметричного шифрования один и тот же ключ (фиксированный набор данных произвольной длины) используется как для зашифровки, так и для расшифровки, то в подходе с открытым ключом есть два ключа: секретный, который надлежит знать только владельцу, и открытый — доступный всем желающим. Только владелец секретного ключа может дешифровать предназначенный для него шифротекст или подписать своим ключом любой набор данных (файл). В то же время любой владелец открытого ключа может отправить (зашифровать) текст владельцу секретного ключа, или проверить подпись того или иного файла.
Теоретически система шифрования с открытым ключом опирается на то, что разложение на простые множители достаточно больших чисел потребует много времени и/или значительных вычислительных мощностей. Это лежит в основе подбора секретного ключа по известному открытому. Всё упирается в вычислительные ресурсы и время. Сегодня принято считать, что использование ключей длиной 2048 бит не позволяет в общем случае подобрать секретный ключ за разумный срок в пределах вычислительной мощности, доступной в настоящее время. Рекомендуем ознакомиться с подробностями того, как длина ключа влияет на вероятность вскрытия шифра в случае симметричного шифрования и шифрования с открытым ключом. Упрощая: открытый ключ длиной 1024 бит по уровню требуемой вычислительной мощности примерно так же стоек, как и 80-битный симметричный ключ.
В случае использования RSA (сокращение по фамилиям изобретателей этой криптосистемы, Rivest-Shamir-Adleman) скорость шифрования примерно пропорциональна квадрату длины ключа, а расшифровки — кубу. Современные программы криптографии оперируют в общем случае с ключами вплоть до 4096 бит. Даже 2048 бит во многих случаях достаточно, чтобы исключить возможность взлома за разумное время. Использование более длинных ключей может серьёзно повысить затраты времени и вычислительной мощности, а также размер полученного шифротекста, при этом не добавляя существенных различий во времени, необходимом для дешифровки. Что сто лет, что миллион — на практике в большинстве случаев разницы нет.
Важный момент: если удалось сохранить и шифротекст, и актуальный для того момента открытый ключ, то рано или поздно (теоретически) текст удастся прочесть. Это следует иметь в виду, если информация предназначена для длительного хранения без доступа к ней третьих лиц. Шифрование в таком виде не предполагает наличия т. н. Perfect forward secrecy, когда получение ключа для шифрования в будущем не повлияло бы на возможность расшифровки прошлых сообщений.
Сертификаты и PKI в целом
Не очень сложно сформулировать основные принципы PKI. Поскольку всё вращается вокруг пар ключей и цифровых подписей, основные положения легко вывести, опираясь на эти термины.
Сертификат позволяет определить степень доверия — поскольку создать сертификат может кто угодно, вопрос именно в доверии. Цифровая подпись открытого ключа (одна из частей сертификата) и является способом обозначить доверие.
Наличие цифровой подписи означает, что где-то в этой цепочке имеется начало. Так называемые корневые сертификаты, принадлежащие обычно центрам сертификации (Certificate Authority, CA), должны приниматься на веру. На практике ряд корневых сертификатов уже вносится или в соответствующие хранилища конкретной операционной системы, или в хранилище программы, использующей SSL/TLS (такие как браузеры, почтовые клиенты и т. д.).
Помимо наличия цифровой подписи от достойного доверия CA, требуется ассоциировать сертификат с конкретным ресурсом (например, Web-сайтом, доступ к которому осуществляется по HTTPS или иному аналогичному защищённому протоколу). В сертификате указывается доменное имя и/или IP-адрес ресурса, чтобы клиент мог определить, насколько достоверным является сертификат. По той же причине в сертификате указывается, кому он выдан (лицу или организации), срок его действия. Всё это, взятое вместе, позволяет удостовериться, что сертификат используется именно тем, кому выдан.
CA, выдающие (подписывающие) сертификаты, по сути ручаются за добропорядочность владельцев ресурсов, которым их выдают. Это приводит к ложному выводу, что сертификат, полученный у надёжного CA, особенно платный (а тем более — очень дорогой), гарантирует добропорядочность.
На практике, разумеется, это не так. Хотя широко используются иконки и значки, демонстрирующие степень доверия к сайту (например, зелёный замок в адресной строке), само по себе существование дорогого сертификата не может быть гарантией того, что посетителям сайта действительно гарантируется безопасность, высокое качество обслуживания и отсутствие последующих неприятностей.
Необходимо помнить, что взаимодействие ведётся с людьми. Надёжность, безопасность и прочие достоинства использования сертификатов X.509 определяются самым слабым звеном во всех системах безопасности: конкретными людьми.
Суммируя: SSL-сертификаты используются для реализации следующих основных возможностей:
конфиденциальности общения;
подтверждения целостности сообщения (что оно не было изменено в процессе доставки);
подтверждения аутентичности источника сообщения.
Отзыв ключей и сертификатов
Тем, кто пользуется криптографией, например, программой вида GnuPG (или её «предком» — OpenPGP), известно понятие сертификата отзыва (revocation certiificate). Поскольку для распространения GnuPG-ключей используются публичные серверы ключей, для аннулирования последующих операций с конкретным ключом обычно достаточно отправить на сервер ключей специальный сертификат, объявляющий конкретный ключ отозванным. После этого любой, кто берёт ваши ключи с серверов ключей, не сможет воспользоваться уже отозванным ключом, тем самым подвергая риску общением с вами по защищённому каналу.
В случае SSL-сертификатов есть несколько протоколов (CMP, OCSP и т. д.), позволяющих определить статус сертификата и, соответственно, возможность или невозможность его использования. На практике, поскольку в реальности связность в пределах Интернета и быстрый ответ тех или иных ресурсов не гарантирован, нет возможности достоверно объявить об отзыве сертификата. Типичная установка «доверять сертификату, если нет возможности проверить его статус» может использоваться злоумышленниками в ситуации, когда удаётся блокировать доступ к службам, проверяющим достоверность.
Различные модели доверия
CA может проводить как упрощённую верификацию, только по домену (DV — когда проверяется, что заказывающий сертификат управляет настройками домена), так и расширенную (OV — верификация организации; EV — расширенная верификация организации). В зависимости от ситуации и типа запрошенного сертификата, верификация может включать проверку существования организации-заказчика, наличие действующих контактных данных и т. д.
Вследствие всего этого цены на сертификаты OV/EV-типа, для которых требуется проверка, а главное — гарантия (например, в виде страхования), могут оказаться весьма высокими. В этой связи стоит упомянуть модель «сеть доверия» (Web of trust), когда доверие распространяется не только от корневого сертификата, надёжность которого не подлежит сомнению, а от человека или организации, за которых поручились другие участники сети доверия.
Проще говоря, если подтверждено доверие к одному из участников сети, то оно применяется и ко всем остальным участникам той же сети. Сама процедура верификации обычно требует физического присутствия человека, поэтому распространение таких сетей может оказаться не слишком простым процессом.
В число недостатков подхода «сеть доверия» можно включить не очень понятную процедуру отзыва доверия (как усилиями самого участника сети, так и усилиями других лиц или организаций).
Примером CA, работающего по схеме сети доверия, является OpenCA. При минимальном уровне доверия их сертификаты по сути подтверждают только факт управления доменным именем. Кроме того, корневой сертификат OpenCA не входит по умолчанию в хранилища доверенных сертификатов ОС и отдельных программных продуктов — так что ещё предстоит убедить пользователя внести его вручную. Использование сертификатов для ресурсов коммерческой направленности, для ресурсов, обрабатывающих или хранящих частные данные, и т. п. становится проблематичным.
Организация EFF (Electronic Frontier Foundation) объявила о запуска в сентябре 2015 года сервиса Lets Encrypt, где бесплатный сертификат сможет получить каждый ресурс.
Злоупотребление доверием
Главное слабое звено любых схем безопасности — люди. PKI не исключение. В случае, если интересы государства или иных силовых структур превозмогают ожидания пользователя, становится возможным использование т. н. SSL-прокси (вариант атаки man-in-the-middle), тем самым исчезает уверенность в том, что обмен данными остаётся конфиденциальным.
Два известных примера, иллюстрирующих возможные опасности использования схем доверия, фундаментальных для этой инфраструктуры. Голландский CA DigiNotar был закрыт после ряда инцидентов, начавшихся 10 июля 2011 года, когда злоумышленниками были получены подложные мультидоменные сертификаты (вначале использовавшиеся для маскировки под сервисы Google, несколькими днями позже к списку добавились домены других популярных интернет-сервисов).
Другой пример — инцидент с CA TrustWave, который выпустил в 2011 году подчинённый (дочерний) CA-сертификат, пригодный для фальсификации любого сертификата в ситуации, когда установлен корневой сертификат TrustWave. Хотя компания и признала сам факт такой выдачи, а также отметила, что были приняты все меры, чтобы подобной фальсификации не могло произойти, их корневой сертификат был отозван большинством ОС и программных продуктов.
В случае подобных инцидентов главное — оперативность отзыва корневых сертификатов. В этом заключается один из недостатков SSL-сертификатов: нет механизма, гарантирующего быстрый отзыв того или иного сертификата. По ряду причин далеко не все ОС и программные продукты всегда используют последние, наиболее актуальные списки доверенных корневых сертификатов. Даже разница в считанные дни может привести к нежелательным последствиям (масштабы последствий определяются тем, для чего именно был выдан фальсифицированный или более не доверенный сертификат).
Также следует отметить, что производители некоторых ОС и программных продуктов (пример: Microsoft в случае с Windows) могут дополнять список доверенных сертификатов в хранилище ОС без явного уведомления о том пользователя.
Программные ошибки при использовании сертификатов
Одной из наиболее неприятных проблем является полное игнорирование ошибок сертификатов при использовании защищённого соединения. В статье «The Most Dangerous Code in the World» рассматриваются типичные приёмы, непригодные с точки зрения практической информационной безопасности, когда ошибки сертификатов просто игнорируются.
Другим инцидентом была ситуация, когда продукты Mozilla стали считать недействительными все самоподписанные сертификаты, для которых не было возможности проверить достоверность на внешних службах (таких как OCSP-серверы). Следствием стала практическая невозможность использования таких продуктов для локальных сетей компаний, где обычно использовался их собственный CA и его корневой сертификат.
Перспективы использования SSL-сертификатов
В ближайшее время вряд ли появится альтернатива PKI на базе стандарта X.509: размах необходимых действий по глобальному переходу на новые стандарты был бы весьма велик. По той же причине не следует ожидать существенного преодоления уже известных проблем стандарта, таких как невозможность оперативного исключения корневого сертификата, или трудоёмкая процедура получения сертификата в целом.
Практически все протоколы и сети Интернета переходят на защищённый канал передачи данных. Как следствие, спрос на SSL-сертификаты будет только возрастать. Насколько жизнеспособными окажутся модели OpenCA и Lets Encrypt, можно только гадать.
А пока тщательная проверка репутации CA перед приобретением у него сертификата является самым надёжным средством убедиться, что вас не ждут неприятности в этой области, как минимум до появления ближайшего обновления любого из установленных у вас на компьютере продуктов, использующих SSL/TSL. И, разумеется, имеет смысл следить за всеми обновлениям ОС и компонентов, не забывать интересоваться их состоянием с точки зрения безопасности.
Материалы и ссылки по теме
tools.ietf.org/html/rfc7568
en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
en.wikipedia.org/wiki/X.509
en.wikipedia.org/wiki/Web_of_trust
en.wikipedia.org/wiki/Public_key_infrastructure
https://en.wikipedia.org/wiki/RSA_(cryptosystem)
www.pgpru.com/glavnaja
en.wikipedia.org/wiki/Key_size
www.zytrax.com/tech/survival/ssl.html
en.wikipedia.org/wiki/DigiNotar
www.trustwave.com/Resources/SpiderLabs-Blog/Clarifying-The-Trustwave-CA-Policy-Update
files.cloudprivacy.net/ssl-mitm.pdf
news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html
pki.openca.org/projects/openca
letsencrypt.org
www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
bugzilla.mozilla.org/show_bug.cgi? id=1042889
