Pull to refresh

Comments 20

Очень часто при описании TLS опускается тот факт, что протокол также позволяет проводить аутентификацию клиента. При двусторонней аутентификации сервер посылает сообщение CertificateRequest, чтобы получить сертификат пользователя. Причем, для большей надежности, у пользователя закрытый ключ, который соответствует сертификату, может храниться на аппаратном токене. Такой подход часто применяется на практике в решениях, где особенно строгие требования по безопасности. Сертификаты клиентов и серверов в таких решениях зачастую выпускаются внутренним удостоверяющим центром.
Мы используем подобные решения в нескольких проектах. Очень удобно: у нас всегда есть пользователь, т.е. не надо делать страницу авторизации, пользователю не надо придумывать отдельный пароль, мы знаем имя пользователя, возможность быстрого импорта пользователей (просто файлы с сертификатами).
Но, к сожалению, есть недостатки: клиентские сертификаты более требовательны к качеству криптографии (то Microsoft с апдейтами начудит и всё сломает, то Chrome решит истерить), для FF приходится вручную импортировать сертификат, с мобильными браузерами множество проблем (кто-то не поддерживает, импорт сертификатов приводит к некоторому геморрою).
Ну можно использовать что-то типа sTunnel. При этом вы единообразно работаете со всеми браузерами и на всех платформах.
Подход с клиентскими сертификатами — правильный. Мы расширили этот подход, чтобы одним сертификатом клиент мог логиниться на много сайтов, и сделали децентрализованный механизм генерации и отзыва такого сертификата. Получилось это — habrahabr.ru/post/257605
Хорошая статья, многое собрано в одном месте. Узнал пару новых для себя моментов…

Какая тема курсовой работы? :)
Собственно «анализ протокола TLS». И перевод занимал большую её часть (:
Хотелось бы продолжения.
«Особенности применения российских криптоалгоритмов в протоколе TLS».
С такими же наглядными и красивыми картинками.
Спасибо. Приятно, что статья интересна. От себя продолжения я не планирую (разве что ещё перевод) — чукча скорее читатель, нежели писатель. Но могу порекомендовать вот это и это. Там написано конкретнее и частично про русские системы. Правда, таких красивых картинок там, увы, нет.
Особенности применения российских криптоалгоритмов в TLS определяет Технический Комитет №26 (ТК26). На их сайте можно найти полезные методические материалы.
Если брать протокол TLS, то картинки останутся такими же с российской криптографией. Особенность в том, что популярные реализации не поддерживают ГОСТ и это подводит нас к проблеме встраивания в различные ОС, браузеры и т.п. Пока каждый решает проблему сам в меру своих сил.
Есть относительно универсальное решение. Проксировать.
Собственно, во всех современных браузерах оба решения (OCSP и CRL) дополняют друг друга, более того, как правило имеется возможность настройки предпочитаемой политики проверки статуса сертификата.
При этом в хроме вообще выпилили CRL и OCSP (раньше можно было включить в настройках) в пользу собственного CRLSets (https://dev.chromium.org/Home/chromium-security/crlsets), куда входит только часть CA (плюс требуется чёткое указание причин отзыва, что делают не все и небольшой CRL, чтобы CRLSets не превышал 250kB).

Неплохая статья на тему: www.grc.com/revocation/crlsets.htm
По этому поводу рекомендуется заглянуть на сайт revoked.grc.com. В том же FF tls-соединение не будет установлено, т. к. сертификат отозван. В актуальном хромиуме и бете хрома — это не так.
С одной стороны вроде и костыль, а с другой — сэкономили небольшой лесопарк, наверное уже.
Ага, и выкосили серьезный кусок защитных механизмов PKI. Т. е., если я отзову сертификат в случае компрометации ключа, то люди, пользующиеся хромом это даже не заметят. Особенно хорошо это в свете недавнего heartbleed, когда сертификаты отзывали пачками, а хром считает отозванные сертификаты валидными.

Правильнее, конечно, использовать OCSP-stapling, оно сильно упрощает жизнь. Но непонятно, игнорирует ли его хром или нет. С внедрением DANE ситуация схожая, гугл его, скорее всего, не поддержит, т. к. это увеличение времени ответа на запрос.
Хорошо быть гуглом. Творишь, что считаешь правильным выгодным и никто тебе ничего сделать не может.
касательно OCSP, стоило бы в статье добавить современный подход к решению этой проблемы с постоянным опросом центра сертификации, а именно OCSP stapling
клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера
Наверно, шифрует, а не подписывает.
Sign up to leave a comment.

Articles