babayota_kun May 19 2015 at 12:43

Что такое TLS

9 min

487K

Information Security*Cryptography*

From sandbox

+41

Comments 20

jia3ep May 19 2015 at 14:47

Очень часто при описании TLS опускается тот факт, что протокол также позволяет проводить аутентификацию клиента. При двусторонней аутентификации сервер посылает сообщение CertificateRequest, чтобы получить сертификат пользователя. Причем, для большей надежности, у пользователя закрытый ключ, который соответствует сертификату, может храниться на аппаратном токене. Такой подход часто применяется на практике в решениях, где особенно строгие требования по безопасности. Сертификаты клиентов и серверов в таких решениях зачастую выпускаются внутренним удостоверяющим центром.

force May 19 2015 at 18:16

Мы используем подобные решения в нескольких проектах. Очень удобно: у нас всегда есть пользователь, т.е. не надо делать страницу авторизации, пользователю не надо придумывать отдельный пароль, мы знаем имя пользователя, возможность быстрого импорта пользователей (просто файлы с сертификатами).
Но, к сожалению, есть недостатки: клиентские сертификаты более требовательны к качеству криптографии (то Microsoft с апдейтами начудит и всё сломает, то Chrome решит истерить), для FF приходится вручную импортировать сертификат, с мобильными браузерами множество проблем (кто-то не поддерживает, импорт сертификатов приводит к некоторому геморрою).

cryptoman May 19 2015 at 19:42

Ну можно использовать что-то типа sTunnel. При этом вы единообразно работаете со всеми браузерами и на всех платформах.

maxihatop May 27 2015 at 19:45

Подход с клиентскими сертификатами — правильный. Мы расширили этот подход, чтобы одним сертификатом клиент мог логиниться на много сайтов, и сделали децентрализованный механизм генерации и отзыва такого сертификата. Получилось это — habrahabr.ru/post/257605

istui May 19 2015 at 16:41

Хорошая статья, многое собрано в одном месте. Узнал пару новых для себя моментов…

Какая тема курсовой работы? :)

babayota_kun May 19 2015 at 16:44

Собственно «анализ протокола TLS». И перевод занимал большую её часть (:

cryptoman May 19 2015 at 18:34

Хотелось бы продолжения.
«Особенности применения российских криптоалгоритмов в протоколе TLS».
С такими же наглядными и красивыми картинками.

babayota_kun May 19 2015 at 19:03

Спасибо. Приятно, что статья интересна. От себя продолжения я не планирую (разве что ещё перевод) — чукча скорее читатель, нежели писатель. Но могу порекомендовать вот это и это. Там написано конкретнее и частично про русские системы. Правда, таких красивых картинок там, увы, нет.

jia3ep May 19 2015 at 19:28

Особенности применения российских криптоалгоритмов в TLS определяет Технический Комитет №26 (ТК26). На их сайте можно найти полезные методические материалы.

cryptoman May 19 2015 at 19:55

Я спрашивал скорее о «популяризации науки» :)

jia3ep May 19 2015 at 20:12

Если брать протокол TLS, то картинки останутся такими же с российской криптографией. Особенность в том, что популярные реализации не поддерживают ГОСТ и это подводит нас к проблеме встраивания в различные ОС, браузеры и т.п. Пока каждый решает проблему сам в меру своих сил.

cryptoman May 19 2015 at 20:23

Есть относительно универсальное решение. Проксировать.

NeverWalkAloner May 19 2015 at 21:56

Спасибо, кстати вот еще одна интересная статья на тему: Первые несколько миллисекунд HTTPS соединения.

grossws May 20 2015 at 02:05

Собственно, во всех современных браузерах оба решения (OCSP и CRL) дополняют друг друга, более того, как правило имеется возможность настройки предпочитаемой политики проверки статуса сертификата.

При этом в хроме вообще выпилили CRL и OCSP (раньше можно было включить в настройках) в пользу собственного CRLSets (https://dev.chromium.org/Home/chromium-security/crlsets), куда входит только часть CA (плюс требуется чёткое указание причин отзыва, что делают не все и небольшой CRL, чтобы CRLSets не превышал 250kB).

Неплохая статья на тему: www.grc.com/revocation/crlsets.htm

grossws May 20 2015 at 02:12

По этому поводу рекомендуется заглянуть на сайт revoked.grc.com. В том же FF tls-соединение не будет установлено, т. к. сертификат отозван. В актуальном хромиуме и бете хрома — это не так.

WaveCut Jun 1 2015 at 17:37

С одной стороны вроде и костыль, а с другой — сэкономили небольшой лесопарк, наверное уже.

grossws Jun 1 2015 at 17:45

Ага, и выкосили серьезный кусок защитных механизмов PKI. Т. е., если я отзову сертификат в случае компрометации ключа, то люди, пользующиеся хромом это даже не заметят. Особенно хорошо это в свете недавнего heartbleed, когда сертификаты отзывали пачками, а хром считает отозванные сертификаты валидными.

Правильнее, конечно, использовать OCSP-stapling, оно сильно упрощает жизнь. Но непонятно, игнорирует ли его хром или нет. С внедрением DANE ситуация схожая, гугл его, скорее всего, не поддержит, т. к. это увеличение времени ответа на запрос.

WaveCut Jun 1 2015 at 17:47

Хорошо быть гуглом. Творишь, что считаешь ~~правильным~~ выгодным и никто тебе ничего сделать не может.

xeioex May 25 2015 at 14:37

касательно OCSP, стоило бы в статье добавить современный подход к решению этой проблемы с постоянным опросом центра сертификации, а именно OCSP stapling

ol_an May 30 2015 at 01:22

клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера

Наверно, шифрует, а не подписывает.