А мы вот запустили тихой сапой один из самых необычных для нас курсов — «Цифровая подпись в информационной безопасности». Несмотря на всё мы вроде справились и людей привлекли, посмотрим, что получится. А сегодня мы разберём оставшийся интересный материал и посмотрим вкратце, как работает TLS, а также в чем разница между недоверенным и доверенным веб-сертификатами.
Перевод — dzone.com/articles/a-look-at-tls-transport-layer-security
Автор — Arun Pandey
TLS — сокращение от Transport Layer Security (протокол защиты транспортного уровня), основан на SSL. Как следует из названия, это протокол, работающий на транспортном уровне.
Как известно, безопасность связи — очень распространенная головная боль, но корректная реализация TLS может перенести веб-безопасность на новый уровень. В среде с внедренным TLS злоумышленник может получить информацию о хосте, к которому вы пытаетесь подключиться, узнать какое шифрование используется, прервать соединение, но сделать что-то кроме этого — не получится.
Почти во всех протоколах связи есть три основных части: шифрование данных, аутентификация и целостность данных.
В этом протоколе шифровать данные можно двумя способами: используя Криптосистему с Открытым Ключом или Симметричные Криптосистемы. Криптосистема с открытым ключом, как реализация, совершенней симметричных криптосистем.
Краткий обзор Криптосистемы с Открытым Ключом и Симметричных Криптосистем
Криптосистема с открытым ключом, являющаяся разновидностью Асимметричного Шифрования, использует открытый-закрытый ключ. Так открытый ключ B используется для шифрования данных A (B поделился открытым ключом с A), а после получения зашифрованных данных B расшифровывает их, используя собственный закрытый ключ.
В Симметричных Криптосистемах используется один и тот же ключ и для расшифровки, и для шифрования, поэтому секретный ключ у A и B будет один и тот же. И это является большим недостатком.
А теперь посмотрим, как работает аутентификация в TLS. Чтобы убедиться в подлинности отправителя сообщения и обеспечить получателя средствами для шифрования ответа, аутентификация может быть достигнута с помощью цифровых сертификатов. Операционные системы и браузеры хранят списки доверенных сертификатов, которые они могут подтвердить.
Доверенные vs. Недоверенные Сертификаты
Цифровые сертификаты бывают двух категорий. Доверенные сертификаты подписываются Центром Сертификации (Certificate Authority, кратко — CA), в то время как недоверенные сертификаты — самоподписанные.
Доверенные Сертификаты
Доверенные сертификаты находятся в веб-браузере и подписываются CA. Это необходимо для обеспечения наивысшего уровня надежности. Предположим, сайт “xyz.com” хочет получить доверенный цифровой сертификат от известного сертификационного центра “Comodo”.
Шаги будут следующими:
- Создать веб-сервер для приложения: xyz.com;
- Создать пару секретных ключей (открытый-закрытый ключ), используя шифрование с открытым ключом (в силу его надежности);
- Сгенерировать Запрос на Получение Сертификата (Certificate Signing Request, кратко — CSR) для сертификационного центра, в моем случае — Comodo. На диске файл может называться “certreq.txt”;
- Подать заявку в сертификационный центр, включить в нее CSR;
- Сертификационный центр (Comodo в моем случае) проверит ваш запрос, в том числе и открытый-закрытый ключ;
- Если все в порядке, сертификационный центр подпишет запрос, используя свой собственный закрытый ключ;
- Центр отправит сертификат, который нужно установить на веб-сервер;
- Все готово!
Недоверенные Сертификаты
Недоверенный сертификат подписывается самим владельцем сайта. Такой метод подходит, если проблемы надежности не актуальны.
Заметим, что в реализации TLS не принято использовать недоверенный сертификат.
Как работает замена сертификата TLS
- Открыть адрес “xyz.com” в браузере;
- Веб-сервер получает запрос;
- Веб-сервер в ответ на запрос отправляет сертификат;
- Веб-браузер оценивает ответ и проверяет сертификат;
- В процессе валидации веб-браузер узнает, что сертификат подписан центром Comodo;
- Веб-браузер проверяет базу данных сертификатов (например, IE -> Internet Options -> content -> certificate) на наличие сертификата Comodo;
- Как только он находится, веб-браузер использует открытый ключ Comodo для проверки сертификата, отправленного веб-сервером;
- Если валидация проходит успешно, браузер считает эту связь безопасной.
THE END
Как обычно ждём вопросы и комментарии.
Комментарии (38)
rzerda
27.11.2018 18:12+1… и не выиграл, а проиграл.
Автор умолчал, что в процессе установления соединения посредством ассиметричной криптографии получается ключевой материал для симметричного шифрования, которое потом и используется для шифрования данных. Дело в том, что симметричное шифрование значительно быстрее асимметричного, хотя, по мнению автора, и значительно несовершеннее (а на самом деле просто другое, со своими преимуществами и недостатками).
Если остальной курс такой же, надо с этим что-то срочно делать.irbis_al
27.11.2018 20:33Автор умолчал, что в процессе установления соединения посредством ассиметричной криптографии получается ключевой материал для симметричного шифрования, которое потом и используется для шифрования данных.
А я вот правильно располагаю информацией, что ассиметричным шифрованием можно зашифровать только блок не более или равный длине байт закрытого ключа.(в отличие от симметричного, которым можно шифровать терабайты).
Т.е если ключ 2048, то я и зашифровать могу блок не более 2048?rzerda
27.11.2018 21:27В RSA и Elgamal да. DH тот же вообще для шифрования не предназначен.
Да и симметричные блочные алгоритмы шифруют только блоки длиной ровно с ключ, а всё остальное делается режимами, которые от самих алгоритмов зависят слабо.
HenadziMatuts
27.11.2018 19:44+1Статья очень вредна для начинающих, поверхностна и с неточностями. То что в симметричных системах у сторон одинаковый ключ само по себе недостатком не является. Про схему Диффи-Хеллмана ни слова. По части сертификатов всё очень плохо с терминологией. Как-то так.
Nokta_strigo
27.11.2018 19:44Статья вроде для тех, кто вообще не в теме, при этом по тексту откуда-то появляются термины, скорее всего не знакомые читателям, без какого-либо объяснения.
TLS… основан на SSL
А что такое SSL? Это основа TLS? Ну и слово «основан» тут ИМХО не подходит.
Вы используете слово «сертификат» никак не объясняя что это такое и как это вообще связано с ассиметричной криптографией.
В этом протоколе [TLS?] шифровать данные можно двумя способами: используя Криптосистему с Открытым Ключом или Симметричные Криптосистемы.
чего-то я не помню, что бы TLS предоставлял такой выбор. Там всегда используется и то, и то.
Цифровые сертификаты бывают двух категорий. Доверенные сертификаты подписываются Центром Сертификации (Certificate Authority, кратко — CA), в то время как недоверенные сертификаты — самоподписанные.
Самоподписанные могут быть доверенными (например сами CA сертификаты), а подписанные CA — недоверенными (подписать можно недоверенным CA сертификатом).
И много других неточностей/недосказанностей и вообще перлов типа «Криптосистема с открытым ключом, как реализация, совершенней симметричных криптосистем.»
maslyaev
27.11.2018 20:50Ради прикола поинтересовался, кто в моём компе фигурирует в списке доверенных корневых центров сертификации. 274 фигрунта, из которых лично знаком с издателями только 4-х сертификатов. Кого там только нет… И какой-то китайский телеком, и какие-то парни из солнечной Басконии, и даже такие названия контор, которые я затрудняюсь прочитать. В связи с этим несколько вопросов:
1. На основании чего я этим товарищам доверяю? Я с ними на брудершафт не пил. Об их репутации мне неизвестно ровным счётом ничего.
2. Как так получилось, что я принужден им доверять?
3. Кто гарантирует, что это моё безоговорочное доверие не станет для меня источником серьёзных проблем? И, главное, чем это гарантировано?rzerda
27.11.2018 21:32+1Вы доверились авторам браузера или ОС, которые используете. И никто ничего не гарантирует, и у PKI есть куча проблем типа доверия «этот ЦС может удостоверять всё, что захочет». Но вот беда — сильно лучших решений нет и пока не предвидится, а безопасно смотреть котиков в интернете надо вчера.
maslyaev
27.11.2018 22:40лучших решений нет и пока не предвидится
Публика обожглась на сети доверия, и теперь пребывает в состоянии выученной беспомощности.
Лучшие решения совершенно точно возможны, но приступить к их поиску невозможно, не избавившись от выученной беспомощности. И не осознав, что PKI, основанный на авторитете удостоверяющих центров — редкостная дрянь.HenadziMatuts
27.11.2018 23:56Кто обжёгся? Какая публика?
Не нужно строить теорию заговора, кто-то где-то собрался, что-то за кого-то порешал, о чём ты вообще? Очень часто УЦ представляют собой нормальные такие государственные структуры. С работниками, кабинетами и бюрократией.
И вот я например выпустил приложение. И моё приложение должно аутентифицироваться перед твоим браузером с помощью SSL сертификата. И я такой прихожу в УЦ в своём городе, то есть прям физически прихожу, ногами. Пишу заявление, мне выпускают сертификат. Я, как разработчик, доверяю этому УЦ, просто потому что я там был, всё там видел. И я говорю своим пользователям, что если вы хотите пользоваться моим приложением, то подгрузите себе сертификат этого УЦ, потому что Я, РАЗРАБОТЧИК, ЕМУ ДОВЕРЯЮ. А ТЫ, ПОЛЬЗОВАТЕЛЬ, доверяй мне, или не пользуйся моим приложением. Так в чём твоя проблема?
1. На основании чего я этим товарищам доверяю? Я с ними на брудершафт не пил. Об их репутации мне неизвестно ровным счётом ничего.
Ты доверяешь не им, ты доверяешь мне/разработчику. У меня это прописано в лицензионном соглашении.
2. Как так получилось, что я принужден им доверять?
Не принуждён — не доверяешь, не пользуйся приложением.
3. Кто гарантирует, что это моё безоговорочное доверие не станет для меня источником серьёзных проблем? И, главное, чем это гарантировано?
Я/разработчик тебе это гарантирую. Опять же, лицензионное соглашение. Если я его нарушу — можешь меня засудить.R-Driver
28.11.2018 09:04В этой схеме изъян. Если я начну доверять издателю вашего сертификата, то я автоматически буду доверять всем сертификатам, которые удостоверены (подписаны) этим издателем. Как Ваше лицензионное соглашение будет гарантировать, что приложение другого разработчика подписанное этим же УЦ не нанесет мне вреда?
HenadziMatuts
28.11.2018 11:15Вы говорите немного о другом. То что другое приложение может нанести вам вред либо никак, либо очень косвенно связано с доверием центру сертификации. Мы здесь говорим о «доверии» не в том смысле, что программы не сделают вам ничего плохого, а в том, что эта программа именно та за кого себя выдаёт, и если по задумке автора она должна вам навредить, то, безусловно, так и будет.
И опять же, не путайтесь в терминологии, в контексте PKI вы автоматически доверяете только корневому сертификату, доверие к дочерним сертификатам всякий раз проверяется когда вы устанавливаете соединение.R-Driver
28.11.2018 11:21Для этого используется электронная подпись, а не TLS.
HenadziMatuts
28.11.2018 11:36Электронная подпись это криптографический примитив, как и симметричное шифрование. А TLS это криптографический протокол который, в том числе, применяет ЭЦП, аутентифицируя стороны.
R-Driver
28.11.2018 11:38Определитесь что вы имеете ввиду под фразами:
И вот я например выпустил приложение. И моё приложение должно аутентифицироваться перед твоим браузером с помощью SSL сертификата
что эта программа именно та за кого себя выдаёт
HenadziMatuts
28.11.2018 12:01Эти фразы идентичны. Для построения безопасного канала связи между клиентом (браузером) и приложением используем TLS. Перед установкой шифрованного канала приложение должно аутентифицироваться перед браузером, таким образом клиент может удостоверится в том, что приложение именно то за кого себя выдаёт. Аутентификацию мы проводим с помощью сертификатов открытого ключа. Приложение отправляет браузеру свой сертификат, подписанный неким доверенным сертификатом УЦ, клиент принимает сертификат, и проверяет подпись при помощи открытого ключа доверенного УЦ (я опускаю цепочки сертификатов). Успешная проверка подписи означает, что владелец присланного сертификата и есть приложение. Приложение подтвердило свою подлинность, после этого стороны могу переходить к установке шифрованного канала.
Замени TLS на IPsec, и принципиально ничего не изменится.R-Driver
28.11.2018 12:09+1В случае TLS и доверенных издателей сертификата сервера (считаем, что все валидно) мы можем удостовериться только в том, что обратились к тому серверу, на который указывает адрес (доменное имя), а какое там приложение — на усмотрение владельца хоста (доменного имени). Сертификат сервера в валидации этого приложения никак не поможет.
Требование разработчика сервиса (приложения), который опубликовал его на некотором ресурсе с сертификатом, подписанным некоторым УЦ невольно и неуправляемо подразумевает, что все другие ресурсы, сертификаты которых подписаны этим УЦ автоматически становятся доверенными. Разработчик сервиса (приложения), который пользуется услугами стороннего УЦ, не может повлиять на это и управлять этим.
Поэтому:
Я/разработчик тебе это гарантирую. Опять же, лицензионное соглашение. Если я его нарушу — можешь меня засудить
Это просто фраза. Разработчик (да и владелец хоста, на котором опубликовано его приложение) не в состоянии этого контролировать и гарантировать.HenadziMatuts
28.11.2018 12:32Внедрение вредоносного приложения на доверенный сервер — это совсем другая угроза, не связанная с PKI в принципе. Но тут признаю свою ошибку, действительно аутентификация приложения на сервере это о другом.
Про «автоматически» мы по-моему уже решили, доверие любым клиентским сертификатам, кем бы они не были подписаны, ДОЛЖНО проверятся, если это не так, то проблема не в PKI как таковой, а в её некорректной реализации.
Разработчик в состоянии гарантировать возмещение ущерба, если таковой был. Это вполне себе организационная мера защищающая клиента.R-Driver
28.11.2018 12:44Я не говорю про «хороший» сервер. я говорю про другой сервер, который мы вынуждены считать доверенным, так как ваше приложение на вашем сервере — хорошее, а сертификаты вашего и другого сервера удостоверены одним УЦ.
R-Driver
28.11.2018 11:24+1К сожалению в современном мире доверие каждый раз не очень то и проверяется. Браузеры по умолчанию не выполняют проверку отзыва сертификата. Совсем. А если такую проверку включить, то выясняется, что та же Windows не очень для этого приспособлена (имеются проблемы с доступом к ресурсам, если способ подключения отличается от «прямое подключение без прокси»).
HenadziMatuts
28.11.2018 11:45+1Другой разговор. Тут на товарищ доказывает что PKI на X.509 сломано в принципе. X.509 вполне себе позволяет сделать всё достаточно безопасно, но так как X.509 это, строго говоря, не стандарт, то реализации плавают. И это, увы, проблемы реализации.
maslyaev
28.11.2018 09:53Кто обжёгся? Какая публика?
Печальная история про PGPшную сеть доверия, которая выглядела достойной альтернативой, но оказалась не жилец. Люди обычно мыслят прямолинейно и бинарно: если альтернативное решение облажалось, то основному решение победило во веки веков аминь. Применение не к месту закона исключённого среднего. Всё как всегда, ничего экстраординарного.
Вот скажите, можно ли сделать так, чтобы элемент списка корневых сертификатов применялся только к одной конкретной программе? А то ведь, знаете ли, если секретным ключом корневого сертификата завладеют жулики, то они смогут провернуть MITM моему общению с https sberbank ru. И потырить все мои деньги. Браузер будет показывать зелёный замочек, а общаться на тему финансов я буду не со сбербанком, а с жуликами. Ваша программа действительно настолько прекрасна, что ради неё можно принять риск лишиться сбережений?HenadziMatuts
28.11.2018 11:34+1Вот скажите, можно ли сделать так, чтобы элемент списка корневых сертификатов применялся только к одной конкретной программе?
Можно. Вариант первый — я сам владелец УЦ обслуживающего только одно моё приложение. Вариант второй, для сертификатов УЦ разрешено специальное расширение Name Constrains, которое ограничивает пространство имён дочерних сертификатов.
А про «завладевание» секретным ключом УЦ, так это совсем другая угроза, и для её устранения применяются совсем другие, комплексные методы, в том числе и упомянутое лицензионное соглашение. Программа может и не идеальна, но все риски я беру на себя.maslyaev
28.11.2018 13:05Намного честнее (прямее, правильнее) по-простому реализовать в приложухе какое-нибудь ECDH+AES, встроить в дистриб открытый ключ сервера, и горя не знать.
Хотя я могу сразу сказать, что этому помешает. Такое решение — реализация криптографических функций, а у нас это очень строго лицензируемый вид деятельности. Чтобы получить на такое лицензию, нужно взять в штат, если мне память не изменяет, троих отставных КГБшников. Можно не отставных, а действующих.Nokta_strigo
28.11.2018 13:37Лучше делать по-другому: в своём приложении используем стандартную реализацию TLS, но проверяем сертификат по встроенному в приложение CA (своему собственному. Речь ведь идёт только о случае, когда сервер и ПО контролируются одним субъектом?) Все API к TLS, которые я знаю, это прекрасно поддерживают.
Реализовывать самому не стоит по двум причинам:
— шансы накосячить в реализации довольно большие (или очень большие)
— трудоёмкость самостоятельной реализации намного выше.maslyaev
28.11.2018 15:17Можно и так. При этом, заметьте, ничего в системное хранилище корневых сертификатов ничего дополнительного не вписывается.
Кстати, реализация криптоалгоритмов — не бог весть какая сложная штука. В сущности, там всё весьма примитивно. И есть в открытых исходниках под нормальными человеческими лицензиями. Основная сложность с криптографией в том, что при всей простоте реализации есть много нюансов грамотного использования. Замок может быть супернадёжным и ключ суперхитрым, но если ключ храним под ковриком, то всё псу под хвост.
HenadziMatuts
27.11.2018 21:49Это основы. Смотри стандарт X.509, раздел про верификацию маршрута сертификации. Прикол в том что доверенный корневой сертификат, он же trusted anchor выбирается произвольно. Это просто исходные данные.
maslyaev
27.11.2018 22:51-1Про произвольность не очень понял. Включение сертификата в веточку «доверенные корневые» — результат договорённости многих сторон и достижения множества компромиссов. Насколько мне известно.
То есть где-то какие-то люди между собой перетёрли, попили напитки, договорились и пожали руки. А доверять должен я, не знакомый ни с ними самими, ни с их мотивами, ни с тем, каким образом договорённость была достигнута.HenadziMatuts
27.11.2018 23:29Я спецом для тебя частично процитирую RFC 5280 п.6.1 который определяет всю процедуру:
6.1. Basic Path Validation
6.1.1. Inputs
…
(d) trust anchor information, describing a CA that serves as a trust anchor for the certification path…
В данном случае trust anchor-ами являются все твои 274 корневых сертификата. Это просто Inputs, то бишь входные данные. Ты просто берёшь чей-то самоподписанный корневик и называешь его доверенным.
Да ты даже сам можешь выпустить себе самоподписанный сертификат и подгрузить его в браузер, и всё, для тебя он станет доверенным. Можешь раздать его своим друзьям, и для них он тоже станет доверенным. Вот и вся история.maslyaev
28.11.2018 01:27Ну, в моём случае из 274 один мой, а ещё 3 — самоподписки друзей. А остальные 270? Почему я им доверяю?
HenadziMatuts
27.11.2018 21:57И никто никого не заставляет, не доверяешь — сноси корневые, в этом случае ты, конечно, сломаешь себе интернет, но зато не будет проблем с доверием.
maslyaev
27.11.2018 22:54Ещё и программы перестанут работать. Может быть, даже ОС перестанет грузиться. Вот она, сила т.н. мягкого принуждения.
Бегство от благ цивилизации в леса, я считаю, не лучшая стратегия.
amatoro
27.11.2018 21:57+1Вы доверяете этим товарищам потому, что доверяете производителю ОС или браузера, которые посчитали нужным доверять этим CA по умолчанию.
Вы не принуждены им доверять. Вы можете всех их удалить из спаска доверенных CA.
А статья ужасная.
Про мное уже сказали. Вот добавлю: «Доверенные сертификаты находятся в веб-браузере и подписываются CA» — Как бы нет.
Те сертификаты которым браузеру стоило бы доверять не находятся в браузе, а получаются им в момент подключения к серверам в 99% случаев.
Если имелись ввиду корневые сертификаты сами CA, которым доверят ваш браузер, то как минимум в 2 из топ 3 браузеров эти сертификаты не хранятся.maslyaev
27.11.2018 22:57-1Я не доверяю производителю ОС. У меня на то, извините, нет никаких оснований. Я пользуюсь ОС — это да, но доверие производителю ОС для этого не является ни необходимым, ни достаточным условием.
pansa
28.11.2018 11:57+1Но если вы не доверяете ОС, то и нет смысла заморачиваться с доверенным набором root ca. Ведь даже если по волшебству у вас останутся только са, которым вы — как на духу, ОС способна перехватить любые передаваемые данные. А следовательно — по принципу самого слабого звена — ваша система не защищена.
maslyaev
28.11.2018 13:21Говорят, вся тема информационной безопасности основывается на понятии модели угроз. Совсем глобально полностью обезопасить всё своё информационное хозяйство — без шансов. В реальном мире, кстати, та же фигня. Но недостижимость идеала вовсе не означает, что следует вообще на всё забить и держать ключ от двери под ковриком.
Архитектура PKI с удостоверяющими центрами — откровенный ляп. Делегирование заботы об обеспечении безопасности неустановленному кругу третьих лиц. Когда (я уверен, что не «если», а именно «когда») от этого архитектурного бага удастся избавиться, мир станет только лучше. Минус одна неприятная дырка — это всегда полезно, вне зависимости от того, сколько других осталось.
bambucho
27.11.2018 21:57А если сертификата Comodo на компьютере нет? Он устанавливается с браузером? У него есть срок действия? Если сертификат на компьютере просрочен?
Sly_tom_cat
28.11.2018 11:10+1Сертификационный центр (Comodo в моем случае) проверит ваш запрос, в том числе и открытый-закрытый ключ;
В CSR нет закрытого ключа сайта. Он на то и закрытый что бы его НИКОМУ не показывать и не передавать.
Проверка осуществляется не ключей, а домена + вы забыли сказать что за сертификат Comodo надо еще денег заплатить, но можно получить и бесплатные сертификаты (Let's Encrypt, например).
cooladmin
А если сертификат выпущен Центром Сертификации, которому я не доверяю, какой он? А если самоподписан, но я доверяю подписавшему хосту (автору выпуска)? Вы уверены в правильности ваших формулировок?
Одно лишь условие — сертификат выпущен CA — не является достаточным для «наивысшей» надёжности. Пожалуйста, не будьте так категоричны в суждениях, это может запутать тех кто только начинает изучать TLS (потенциальная ЦА вашей статьи).