Меня зовут Ян Жу, я инженер по безопасности компании Yahoo, это Питер Эккерсли, ведущий компьютерный специалист компании Electronic Frontier Foundation, лидер команды разработчиков технологий, и Джеймс Кастен, специалист по технологиям и аспирант компьютерных наук и инженерии Мичиганского университета. Итак, кого из Вас потрясла возможность зашифровать весь Интернет? Я в восторге от вашего энтуазиазма!
Так вот, какие проблемы волнуют мир, кроме глобального потепления, детского голода и всего подобного? Проблема того, что протоколы защиты транспортного уровня TLS до сих пор не распространены повсеместно, даже в 2015 году. Прошлым летом, когда я захотела воспользоваться сайтом Quora, я зашла на страничку авторизации и увидела, что она реализована на основе простого http, что уже плохо. Кроме того, http открыт для воздействия инструментов злоумышленников и передаёт Ваши пароли в виде открытого текста. Это действительно плохо, если Вы ежедневно видите миллионы активных пользователей, которые входят на сайт подобным образом. Целью Quora является распространение социальных знаний, а может, и дезинформация пользователей, это сайт вопросов-ответов на различные темы.
Есть ещё такой небольшой сайт под названием Google, пусть поднимут руки те, кто о нём слышал, так вот они всегда были достаточно хороши в смысле использования SSL. Однако некоторые странички, как вот этот лендинг приложений Google Ads, до сих пор по умолчанию использует обычный протокол HTTP. Вы можете сказать, что в этом нет ничего страшного, это статичная публичная страница, не требующая ввода пользовательских данных. Но человек вроде меня, который разбирается в этих вопросах, проверит, куда ведёт кнопка Log In. Обычный пользователь, ничего не подозревая, после нажатия на эту кнопку может быть перенаправлен на фишинговый сайт, где и введёт свои регистрационные данные.
И поскольку здесь используется HTTP, это до сих пор является проблемой.
Вторая проблема заключается в том, что получение протоколов защиты транспортного уровня TLS до сих пор является весьма утомительной, даже в 2015 году. Кто слышал об этом, пусть поднимет руку. Вижу, таких много. Если Вы хотите проделать это, то можете зайти на сайт wiki.cremehost.com и ознакомиться с 12 шагами, которые нужно предпринять, чтобы приобрести сертификат электронной подписи, удостоверенный центром сертификации CA. И хотя Вы пока ещё не Анонимные Алкоголики, даже для Вас эта процедура является достаточно утомительной.
Рассмотрим, сколько времени занимает настройка TLS. У меня здесь есть видео по этому поводу. Я говорила со многими своими коллегами из EFF, умеют ли они настраивать TLS, и никто из них не делал этого прежде. Надеюсь, моё видео работает.
Часть 1 – Паркер Хиггинс, активист EFF.
— Привет, Паркер, чем ты занимаешься сегодня?
— Я пытаюсь установить HTTPS на свой тестовый сайт.
— Ну как, это весело?
— Может быть, пока не знаю.
— Я могу снять видео про то, как ты это делаешь?
— Да, можешь!
— Отлично!
А дальше Вы видите, что у него это получается с трудом. Он щелкает по кнопке Помощника, страница грузится снова и снова, но у него ничего не получается. Я говорю ему, что наверное, сегодня у него это не получится, и ухожу.
Часть 2 – Ноа.
Здесь продолжается аналогичный процесс, который в общей сложности занял у Ноа почти 9 часов. Он не может понять, что происходит с его почтой и как настроить сертификат, поэтому отправляется пить кофе. Через три часа я возвращаюсь к нему.
— Вот этот сайт, который мы пытаемся защитить. И эта кнопка снова в неактивном состоянии. Я не могу прикрутить сюда сертификат. Приходит сообщение: «Заполнены не все поля». Попробую заполнить их заново. Так, выскочила надпись «Поздравляем»! Это то, ради чего я потратил столько времени?
Хорошо, продолжим, попробуем запустить наш сайт. Находим его в выпадающем меню формы, кликаем по нему, ждём…
На экране высвечивается информация, и Ноа с удивлением произносит: «А это что значит? По-моему, это письмо моей сестры, какой-то счёт, оплата. Это вообще мой браузер»?
Проходит ещё час. Я возвращаюсь к Ноа, который до сих пор ждёт своё письмо с подтверждением успешности получения сертификата ключа безопасности шифрования его сайта. Он говорит, что получил письмо с благодарностью за использование услуги сертификации, но когда пытается пройти по указанной в письме ссылке, у него ничего не выходит, возможно, это связано с проблемами proxy-сервера на его стороне.
Ноа говорит, что прошёл целый час, в течении которого он предпринял ещё несколько безуспешных попыток получить сертификат, но у него ничего не вышло. Прошу извинить меня за это грустное видео.
Итак, мы убедились, что процесс сертификации занимает несколько часов, связан со многими ошибками и часто бывает неуспешным.
Проблема три заключается в том, что TLS обладает запутанной конфигурацией.
Предположим, что у нас всё прошло идеально, мы получили свой сертификат и хотим установить его на сервер. Но все его настройки действительно очень запутаны. Несколько лет назад люди говорили: «у нас есть потоковый шифр RC4, отлично, он очень эффективен»! Но сейчас, в 2015 году такие эксперты, как Ник из сети доставки контента CloudFlare, заявляют, что мы должны уничтожить RС4.
Другой пример – алгоритм криптографического хеширования Secure Hash Algorithm SHA-1, который тоже признан небезопасным, потому что рано или поздно Ваш сайт, который использует это хеширование и цепочки сертификатов будет признан браузерами Chrome и Firefox небезопасным.
Поэтому я предлагаю Вашему вниманию фильм под названием «SHA-256: Избавление». Это кино про человека, которого по ошибке обвинили в использовании SHA-1 на своём сайте и выгнали с работы. Он встречает Моргана Фримена и тратит всё время, чтобы убедить людей в том, в действительности он использовал SHA-256. Смотрите во всех кинотеатрах страны! Это была шутка!
А сейчас перейдём к следующей проблеме под названием «Как защитить сервер от уязвимости POODLE SSlv3». Люди говорят, что они отказались от криптографического протокола SSL v.3, потому что он был подвержен атакам Logjam, которые способны расшифровать или взломать любое TLS-соединение, установленное с неправильно сконфигурированными веб-сервисами или почтовыми серверами.
Хочу показать Вам результаты аудита сайтов, который выполнила независимая лаборатория ssllabs.com. Как видите, наш сайт letsencrypt.org имеет наивысшую оценку А+ и является одним из лучших сайтов в смысле безопасности, потому что ssllabs серьёзная организация и им можно доверять. Мы используем последние шифры из списка рекомендованных. Вы видите другие сайты, которые получили минимальную оценку F. Проблема состоит в том, что многим так и не удаётся правильно настроить SSL и они пользуются сломанным шифрованием.
Проблема №4 заключается в блокировке смешанного контента. Ваш сайт может быть заблокирован, когда Вы пользуетесь SSL, но загружаете все ресурсы через HTTP. Браузер считает, что должен переместить этого пользователя на уровень безопасности HTTPS и поэтому блокирует его контент HTTP. В результате сайт перестаёт функционировать, если Вы загружаете скрипты через HTTP. В случае с Lenovo, которых я проверяла несколько ночей назад, они могли использовать HTTPS, но не могли загрузить даже свои шрифты через него, потому что по умолчанию должны были использовать HTTP. Я покажу Вам на слайде, какие сайты используют только HTTPS.
Питер и я работаем над поддержкой расширения браузера. Поэтому если Вы пользуетесь браузером Chrome, Вы можете увидеть, что все его ресурсы могут быть прочитаны как HTTPS. То есть у нас имеется полезный инструмент для того, чтобы Вы могли превратить свой сайт из незащищённого в безопасный. Если Вы используете сторонний контент и не знаете, поддерживает ли он SSL, то можно воспользоваться инструментом разработчика в виде таблицы и «поиграть» с ней. Это поможет переписать ресурсы, что может очень Вам помочь.
Имеется новый заголовок страницы под названием «upgrade insecure request», «обновление небезопасных запросов», и когда браузер его видит, то понимает, что все субресурсы сайта и ссылки нужно преобразовать в HTTPS, даже если они написаны на HTTP. Так что Вы можете воспользоваться этим заголовком для своих сайтов.
Проблема №5 заключается в том, что существует слишком много доверенных организаций, выдающих сертификаты безопасности. Год назад Питер даже нарисовал очень сложную таблицу, которую Вы видите на экране. Питер, объясни, что она означает!
Питер Эккерсли говорит, что это далеко не полная карта, а всего лишь часть. Она была представлена на DEFCON в 2010 году проектом SSL Odservatory. Мы выяснили, что на то время было 66 центров авторизации в Firefox и почти 150 в IE. Когда мы просканировали Интернет, то убедились, что они все были авторизированны и сертифицированы другими центрами сертификации, и им доверяют браузеры. Существовали тысячи CAS, Центров сервиса аутентификации, которые могли скомпрометировать сотни организаций и доменов в сети, и это выглядело ужасающе. В прошлом году Google обнаружил ошибочные сертификаты, выданные Китайским центром сертификации, так что это не просто теоретическая атака на безопасность сайтов.
А сейчас я передаю слово Питеру, который расскажет, как мы видим мир в будущем.
Я расскажу Вам о том, как мы видим решение перечисленных проблем. Во-первых, можно создать свой собственный Центр Авторизации Сертификатов LetsEncrypt, бесплатный, автоматизированный и открытый. Я вижу, Вам понравилась эта шутка!
В действительности мы нуждаемся в детальном рассмотрении, как безопасности, так и всех сайтов, которые в ней нуждаются. Нам нужно решение, которое одновременно обеспечивало бы и безопасность, и удобство использования.
Люди, которые называют себя веб-разработчиками, не хотят углубляться во все тонкости использования уязвимости SSL и не нуждаются в этом. Поэтому самый важный вопрос, на который мы должны ответить, это то, как мы собираемся выдавать сертификаты. Потому что существующее положение напоминает сцены из Святого Грааля, когда Вам приказывают пойти туда — не знаю куда и принести то — не знаю что. И когда Вы это приносите, выясняется, что это совсем не то, что от Вас требовалось.
Вопрос, который я обозначу цифрой «ноль», называется «Самозагрузка». Здесь имеется в виду использование существующего варианта для создания нового. Какое решение мы должны использовать на основе прежнего шифрования? Обычный ответ на этот вопрос — Domain Validation DV, или легализацию доменного имени. Это не требует тысячедолларовой оплаты, достаточно отослать письмо адрес или разместить запрос на сайте, чтобы сделать апгрейд протокола безопасности.
Какие типы DV использует Let's Encrypt? Для загрузки это протокол DVSNI через порт 443 или простой HTTP через порт 88 для тех, кто использует прокси-сервер. В данном случае CAS проверяет Ваши административные права на управление сайтом, чтобы Вы могли его настроить. По ссылке на ресурс, указанной в письме, мы заходим к Вам и проверяем ответное «рукопожатие» TLS, и проводим несколько тестовых атак на Ваш ресурс, чтобы убедиться в его защищенности.
Многие спрашивают меня о возможности легализации DNS имён, возможно, позже мы реализуем такую функцию для клиентов вместе с возможность апгрейда протокола для доменов DVSNI 2 для портов 443 и 100. Если на Вашем виртуальном хостинге имеются тысячи доменов, Вы сможете внести всего одно изменение в протокол вместо тысячи изменений. Это можно проделать на различных портах, в том числе на особенных, как порт 443, на котором обычно размещают файервол. У нас имеется возможность аудита портов, которые хотят использовать пользователи, путём широкого сканирования Интернета.
Многих пугает всё, что связано с валидацией доменов. Интернет в этом случае представляется тёмной дырой, путём, по которому Вы отправляете пакеты информации, они исчезают на середине пути, а некоторые возвращаются к Вам обратно и говорят: «да, я действительно этот домен»! Будут ли Ваши пакеты съедены злобными монстрами или модифицированы на этом пути, Вы не знаете. Вы можете быть атакованы, если Ваш роутер или DNS сервер не защищён должным образом. Описанные выше методы не слишком совершенны, поэтому мы можем использовать более «продвинутую» методику проверки. Мы можем использовать многовариантный путь проверки, в котором задействуем серверы дата-центров и другие ресурсы мировой «паутины», и создать несколько версий запросов валидации или нескольких версий запросов DNS. Этот способ не защищает Вас от атаки более мощного противника, потому что он может воспользоваться уязвимостью роутера своей жертвы и через него добраться до Вас. Так что DV не является оптимальным способом защиты при создании инфраструктуры безопасности для всего Интернета.
Однако у нас есть лучший вариант защиты. К счастью, описанное выше «путешествие по неосвещённому шоссе Интернета» необходимо совершить только один раз. Мы обсуждали проект изучения всех SSL на конференции DEFCON ещё 5 лет назад, и с тех пор провели серию исследований благодаря поддержке пользователей Firefox и Google, которые выслали нам миллионы сертификатов и благодаря проекту ZMap, которым Джеймс занимается вместе с командой Мичиганского университета. Теперь, когда у нас есть огромная база данных по сертификатам и целый силлабус (список заблуждений), мы можем помочь человеку, даже когда он обращается к нам с просьбой проверить доменное имя Новозеландского банка. Мы никогда не слышали о корпоративной сетевой почте этого банка, но можем посоветовать нашему клиенту посмотреть базу сертификатов и увидеть, что это доменное имя имеет сертификат валидации.
Доступ к базе данных обеспечивается сканированием портов 443, просмотром логов стандарта CT (Certificate Transparency) или по запросу клиента. Мы не собираемся проверять Ваш незашифрованный домен, а просим Вас доказать, что Вы владеете частным ключом существующего легализированного сертификата. Таким образом Вы всегда можете получить наш сертификат или сертификат другого CAS, если уже владеете отпечатком ключа какого-либо авторизованного сертификата безопасности.
Это бывает не слишком удобно, потому что вынуждает Вас искать этот самый ключ. В случае, если Вы его потеряли, Вам придётся проходить всю процедуру сертификации заново и платить за весь пакет настроек.
Если Вы что-либо слышали об аутентификации TOFU, Trust on first use, то знаете, что этот механизм полагается на то, что первая передача ключа не была скомпрометирована, запоминает этот ключ и отвергает подтверждение безопасности при его внезапной смене. Скорее всего, Вы знакомы с ним по модели безопасной оболочки SSH. Это бывает хорошим решением в некоторых случаях.
Следующим важным вопросом являются проблемы TLS и HTTPS. Мы сталкиваемся с этой проблемой при неграмотном конфигурировании TLS, о чём уже говорила Ян. В этом случае Вы уязвимы для poodles, logjam и hotblades атак. Всё, что нужно для решения этой проблемы – это клиент, который запускается на Вашем сервере и волшебным образом конфигурирует его так, как надо. Потому что существует огромное количество сайтов, серверов и огромный массив информации, и нужны серьёзные знания, чтобы соответствовать всем требованиям. Мы же представляем собой маленькую команду людей, которые стараются внести свой вклад в решение проблемы. Мы хотим правильно настроить TLS и поделиться своими инструментами со всеми, кто в этом нуждается.
В чём же заключается цель клиента, который мы собираемся поддерживать? Она состоит в том, что пользователь получает этот клиент на полгода или год и с его помощью поддерживает настройки существующего сервера на движке Apache/Nginx или другом в актуальном состоянии, проводя необходимые изменения и затем устанавливая результирующий сертификат. При этом клиент настраивает функции безопасности оптимальным образом для получения наилучшего результата для конкретной конфигурации Вашего сервера и автоматически обновляет систему безопасности в соответствии с текущими требованиями. То есть он автоматически противодействует случаям нарушения безопасности, которые создают массовые проблемы при использовании HTTP.
Что имеется в виду под автоматизацией безопасности? Это целый спектр задач различной сложности, которые решаются в автоматическом режиме. К легким задачам относятся настройка наборов шифрования Cipher, OCSP stapling и апгрейд CSP. Более сложным является трансляция HTTP 302 (код перенаправления) в HTTPS для современных клиентов, потому что при этом может быть заблокирован смешанный контент даже в случае обновления параметров безопасности, и здесь нужно использовать смешанные сертификаты: новый для нового контента и старый для старого HTTP-контента. Задачей средней сложности также является автообновление и переназначение ключей в случае изменения доменных имён, потому что нужно опять-таки иметь набор для старого имени и набор для нового.
Сложной задачей является полное переписывание сертификатов и HSTS. HSTS это механизм, активирующий форсированное защищённое соединение через протокол HTTPS вместо использования HTTP-протокола, что позволяет сразу же устанавливать безопасное соединение. Если Вы не используете HSTS, Ваш сайт совершенно не защищён, однако этом механизм обладает некоторыми секретными свойствами, которые способны «положить» Ваш сайт при некорректной работе настроек безопасности.
Самой сложной задачей является аудит и исправление смешанного контента. Её решение возможно, однако является серьёзной инженерной задачей.
Третьим важным вопросом является то, что центры авторизации CA сами по себе являются ужасающими вещами, потому что контролируют безопасность всего Интернета, и мы пытаем создать автоматический гигантский центр сертификации, такую безумную машину, которой сами побаиваемся. Какой дизайн безопасности мы выбираем для этого гиганта?
Запуск вашего собственного СА является не менее ужасающей вещью, однако мы не только проводим исследования существующих угроз, но и планируем заранее обнаруживать и отражать угрожающие безопасности события, чтобы нацелить на них нашего автоматического гиганта.
Далее рассмотрим вопрос защиты от самих себя, то есть защиты своей репутации как СА. Она подразумевает полную прозрачность процессов сертификации:
Для защиты от других CA мы предоставляем поддержку HPKP, или HTTP Public Key Pinning, если Вы достаточно смелый или сумасшедший человек. Key Pinning – это привязывание публичного ключа к сетевому ресурсу (по имени или по адресу) на стороне клиента. При такой технологии изменение отпечатка ключа позволяет обнаружить подмену ключей при атаке по схеме «человек посередине».
Кроме этого, мы предоставляем услуги ресертификации, если Ваш ресурс был безосновательно скомпрометирован другими центрами сертификации или злоумышленниками, а также восстанавливаем повреждённые ключи.
Хочу рассказать Вам об институтах и организациях, поддерживающих наш центр авторизации сертификатов Let'sEncrypt, который был начат как совместный проект EFF, Mozilla и Мичиганского университета.
Этот проект создан для того, чтобы большая часть Интернет-сайтов смогла перейти к шифрованным подключениям HTTPS без оплаты, изменения конфигурации серверов, использования электронной почты, поэтому у нас очень простой процесс установки и настройки TLS-шифрования. Например, на типичном веб-сервере на базе Linux требуется выполнить всего две команды, которые настроят HTTPS шифрование, получат и установят сертификат примерно за 20-30 секунд.
Сейчас он базируется на основе нашей собственной неформальной группы исследований Интернет-безопасности ISRG, крупнешими спонсорами которой являются компании EFF, Mozilla, Cisco, Akamai, IdenTrust и Automatic. Разработку ведут CAS серверы обеспечивают специалисты ISRG и Mozilla, серверные коды создают EFF и Mozilla, клиентские коды – EFF и Мичиганский университет, а политикой, легализацией и бюрократией занимаются все остальные.
Первый сертификат мы планируем выпустить 7 сентября, валидацию и бета-версию клиента запускаем в середине октября, а полнофункциональную версию нашего CA мы представим публике 16 ноября.
Между тем, целую кучу времени отнимают бюрократические процедуры, когда мы выпускаем документ, потом документ на этот документ и так далее. Всё это удорожает сертификацию и растягивает по времени. У нас есть несколько людей, занимающихся всем этим, и если Вас интересуют наши коды, клиент, сервер и спецификации или Вы хотите их взломать, или помочь, или принять участие в наших разработках, добро пожаловать за исходниками на приведённые на слайде ресурсы.
А сейчас я хочу пригласить к микрофону Джеймса, чтобы он рассказал вам более подробно о нашем клиенте и продемонстрировал его работу.
Слово берёт Джеймс Кастен.
Сейчас я увеличу размер шрифта, чтобы происходящее на экране моего ноутбука было Вам хорошо видно. Я запускаю наш клиент, сделанный на языке Python, в виртуальной среде.
В качестве примера я зайду на сайт encryption-example.com, его создал энтузиаст, которые любит учить людей шифрованию, но к несчастью, сам ничего об этом не знает – мы не можем зайти на этот сайт через HTTPS.
К тому же он очень интересуется тем, как делать деньги, поэтому зарегистрировал сайт для получения сертификатов доверия TLS Trust. Здесь есть всё, чтобы Вы чувствовали себя в безопасности – есть и логотип, и иконка с замком, но это всё совершенно не работает с TLS – при попытке зайти сюда через HTTPS страница сайта не открывается.
Вернёмся к нашему клиенту. Он использует сервер Apache. Для продолжения работы Вы должны прочитать соглашение конечного пользователя и иметь ввиду, что данная версия клиента не предназначена для получения публичного сертификата.
Рабочая версия клиента протестирует конфигурацию Вашего сервера и проверит, какие имена Вы используете в качестве хоста, то есть проведёт исследование файлов конфигурации. Затем она внесёт необходимые изменения в конфигурационный файл и настроит TLS так, чтобы сайт стал безопасным и мог открываться через HTTPS.
Вы можете выбрать, какое доменное имя хотите использовать для проверки, в первом тесте я использую протестированный выше encryption-example.com. Наш клиент пройдёт через этот ресурс, обновит конфигурацию настроек безопасности, самоподпишется и сохранит для Вас результат тестирования, о чем сообщит на экране. Весь процесс занял 30 секунд.
Здесь написано, что сайт encryption-example.com стал доступным. Проверим через публичное соединение – действительно, сейчас я могу войти на него через HTTPS. Как видите, результат на лицо.
Хочу заметить, что Вы всегда можете произвести все необходимые изменения с помощью командной строки и вообще не использовать никаких подсказок, наш клиент всё равно установит настройки и решит проблемы сервера. Он также может создать перенаправление с оригинального HTTP-хоста на новый хост. Можно также дополнительно установить дюжину или пару дюжин настроек безопасности, таких как перенаправление HTTP, OCSP stapling и других вариантов конфигурации.
Люди иногда не хотят, чтобы мы трогали их конфигурации, но у нас имеется три точки отката при каждом процессе изменения конфигурации, поэтому можно легко откатить все изменения назад и снова сделать сервер небезопасным для SSL соединения через HTTPS. В данной версии невозможно отозвать сертификат, но у нас будет другая система управления, которая позволяет вручную отозвать все выданные сертификаты при возврате к первоначальной конфигурации настроек безопасности сервера, как будто бы мы ничего не трогали.
Я хотел показать это в демо-режиме, но не смог быстро создать соответствующие коды особенно для такого неоднородного Интернета.
Но Вы должны знать, что если мы пока не поддерживаем Ваш сервер, Вы легко можете использовать другую технологию настроек. Всего у нас имеется три способа аутентификации через клиент Let'sEncrypt.
У нас есть ручной аутентификатор, который не требует рут-прав, а просто создаёт для Вас файл, который нужно разместить на сервере. Есть и автономный аутентификатор, который достаточно просто запустить, после чего математический алгоритм создаст для Вас сертификат и поместит его в правильную директорию сервера.
Вот и всё, что я хотел рассказать. Теперь можно задавать нам вопросы.
Вопрос:
— Насколько трудно было Вам стать Центром авторизации и получить разрешение на это от компании – разработчика и владельца браузера?
Питер:
— Мы об этом не говорили! Скажите, сколько людей в зале считают, что для того, чтобы стать CA, необходимо получить разрешение от браузера? Вы считаете неправильно! Не требуется никаких разрешений от владельца браузера. Всё что нужно для этого – это получить один единственный сертификат аутентификации, который гарантирует Вам по контракту право заверять сертификаты. И тогда Вы можете работать с любыми браузерами, которые прошли сертификацию в существующих CA. Сейчас мы проходим аудит, и Вы не представляете, сколько времени и денег это отнимает и какое количество документации нам нужно подготовить. Но вскоре мы закончим с этим, и хорошо, что подобное нужно пройти всего один раз.
Вопрос:
— Ваша демонстрация возможностей клиента через командную строку была впечатляющий, но планируете ли Вы быть интегрированными в такие продукты, как cPanel или среды для VPS-хостинга?
Питер:
— Да, мы планируем использовать более удобные инструменты, например, API, просто командная строка лучше адаптирована для работы с Python. У нас есть простой интерфейс API для новых серверов, который поможет Вам понять новые типы сервисов.
Вопрос:
— Занимались ли Вы работой со списком отзыва сертификатов CRL?
Питер:
— На самом деле я не могу вспомнить случай, когда бы это нам понадобилось. Такая потребность может возникнуть, если мы будем уверены в том, что Google и люди, отзывающие сертификаты, нуждаются в новом способе осуществления этой процедуры. Наш клиент будет запущен с трёхмесячным окном валидации, поэтому мы рискуем немного меньше в отношении рабочих сертификатов, чем другие CА, так как сейчас механизм отзыва в Интернете практически не работает.
Вопрос:
— Сейчас Ваш клиент работает с движками Apache и Nginx. Имеются ли у Вас планы по интеграции с инструментами управления конфигурацией, такими как Chef и Puppet?
Джеймс:
— Да, у нас есть установщики для Chef и Puppet. Сейчас их использование не является насущной необходимостью, но мы располагаем возможностью их интеграции в наш клиент.
Вопрос:
— Вы используете политику собственного публичного API в своём клиенте, и это хорошо, но не планируете ли Вы где-нибудь использовать сторонние API?
Питер:
— Нет, мы не планируем использовать никакие другие API кроме уже существующих.
Вопрос:
— Почему некоторые люди говорят, что не всем сайтам необходимо иметь SSL? Вероятно, они имеют в виду фишинговые сайты?
Питер:
— У нас есть два плана, вернее, два типа планов по борьбе с фишинговыми сайтами. Но существует формат сертификата открытых ключей X.509, который должен быть заменён более надёжным форматом. Если на сайте с открытым ключом используется иконка замочка, то это выглядит издевательством, так как фактически соединение не является достаточно безопасным. Поэтому мы ищем способы сделать так, чтобы пользователь изначально не попадал на незащищённый сайт, чтобы не подвергнуться фишинговой атаке, например, перенаправление его на доверенный сайт с безопасным доменным именем. Такие сайты мы помечаем особой меткой.
Вопрос:
— Главная цель TLS состоит в том, чтобы ликвидировать угрозу типа «человек посередине». Предположим, что я подсоединюсь к сайту encryption-example.com и мой браузер выбирает порт 80, в таком случае я становлюсь этим самым «человеком посередине» и спокойно обхожу TLS. Как можно избежать этого?
Питер:
— Дело в том, что люди не знают, что должны установить флаг безопасности на свои «кукиз», и огромное количество сайтов не пропускает «кукиз» без такого флага. Поэтому всё, что Вам нужно для обеспечения безопасности сайтов, это установка набора HSTS. Мы собираемся помочь в этом сайтам, но данный способ относится к вещам, способным вызвать неполадки в работе сайта. Поэтому нам нужны хорошие инструменты для быстрого включения HSTS, возврата в предыдущее состояние и возможность сообщить администрации сайта, что вследствие атаки имеются нерабочие страницы, и исправить их. Возможно, это поможет вовремя обнаружить «человека посередине» и изолировать его.
Вопрос:
— Собираетесь ли Вы поддерживать сертификаты более высокого уровня Wildсard?
Питер:
— Используемые API не позволяют поддержку таких сертификатов, но мы не исключаем такую возможность в дальнейшем.
Вопрос:
— Можно ли использовать Ваш клиент для проверки доменов типа .local?
Питер:
Я думаю, что не имеет смысла использовать TLS в этом случае. Нужно стремиться к созданию не конфликтующих доменных имён или создать новый интерфейс браузера для этих доменов. Возможно, должна быть создана новая модель TOFU для этого локального пространства имён, но оно должно быть отделено от пространства публичного веб-нейминга.
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Так вот, какие проблемы волнуют мир, кроме глобального потепления, детского голода и всего подобного? Проблема того, что протоколы защиты транспортного уровня TLS до сих пор не распространены повсеместно, даже в 2015 году. Прошлым летом, когда я захотела воспользоваться сайтом Quora, я зашла на страничку авторизации и увидела, что она реализована на основе простого http, что уже плохо. Кроме того, http открыт для воздействия инструментов злоумышленников и передаёт Ваши пароли в виде открытого текста. Это действительно плохо, если Вы ежедневно видите миллионы активных пользователей, которые входят на сайт подобным образом. Целью Quora является распространение социальных знаний, а может, и дезинформация пользователей, это сайт вопросов-ответов на различные темы.
Есть ещё такой небольшой сайт под названием Google, пусть поднимут руки те, кто о нём слышал, так вот они всегда были достаточно хороши в смысле использования SSL. Однако некоторые странички, как вот этот лендинг приложений Google Ads, до сих пор по умолчанию использует обычный протокол HTTP. Вы можете сказать, что в этом нет ничего страшного, это статичная публичная страница, не требующая ввода пользовательских данных. Но человек вроде меня, который разбирается в этих вопросах, проверит, куда ведёт кнопка Log In. Обычный пользователь, ничего не подозревая, после нажатия на эту кнопку может быть перенаправлен на фишинговый сайт, где и введёт свои регистрационные данные.
И поскольку здесь используется HTTP, это до сих пор является проблемой.
Вторая проблема заключается в том, что получение протоколов защиты транспортного уровня TLS до сих пор является весьма утомительной, даже в 2015 году. Кто слышал об этом, пусть поднимет руку. Вижу, таких много. Если Вы хотите проделать это, то можете зайти на сайт wiki.cremehost.com и ознакомиться с 12 шагами, которые нужно предпринять, чтобы приобрести сертификат электронной подписи, удостоверенный центром сертификации CA. И хотя Вы пока ещё не Анонимные Алкоголики, даже для Вас эта процедура является достаточно утомительной.
Рассмотрим, сколько времени занимает настройка TLS. У меня здесь есть видео по этому поводу. Я говорила со многими своими коллегами из EFF, умеют ли они настраивать TLS, и никто из них не делал этого прежде. Надеюсь, моё видео работает.
Часть 1 – Паркер Хиггинс, активист EFF.
— Привет, Паркер, чем ты занимаешься сегодня?
— Я пытаюсь установить HTTPS на свой тестовый сайт.
— Ну как, это весело?
— Может быть, пока не знаю.
— Я могу снять видео про то, как ты это делаешь?
— Да, можешь!
— Отлично!
А дальше Вы видите, что у него это получается с трудом. Он щелкает по кнопке Помощника, страница грузится снова и снова, но у него ничего не получается. Я говорю ему, что наверное, сегодня у него это не получится, и ухожу.
Часть 2 – Ноа.
Здесь продолжается аналогичный процесс, который в общей сложности занял у Ноа почти 9 часов. Он не может понять, что происходит с его почтой и как настроить сертификат, поэтому отправляется пить кофе. Через три часа я возвращаюсь к нему.
— Вот этот сайт, который мы пытаемся защитить. И эта кнопка снова в неактивном состоянии. Я не могу прикрутить сюда сертификат. Приходит сообщение: «Заполнены не все поля». Попробую заполнить их заново. Так, выскочила надпись «Поздравляем»! Это то, ради чего я потратил столько времени?
Хорошо, продолжим, попробуем запустить наш сайт. Находим его в выпадающем меню формы, кликаем по нему, ждём…
На экране высвечивается информация, и Ноа с удивлением произносит: «А это что значит? По-моему, это письмо моей сестры, какой-то счёт, оплата. Это вообще мой браузер»?
Проходит ещё час. Я возвращаюсь к Ноа, который до сих пор ждёт своё письмо с подтверждением успешности получения сертификата ключа безопасности шифрования его сайта. Он говорит, что получил письмо с благодарностью за использование услуги сертификации, но когда пытается пройти по указанной в письме ссылке, у него ничего не выходит, возможно, это связано с проблемами proxy-сервера на его стороне.
Ноа говорит, что прошёл целый час, в течении которого он предпринял ещё несколько безуспешных попыток получить сертификат, но у него ничего не вышло. Прошу извинить меня за это грустное видео.
Итак, мы убедились, что процесс сертификации занимает несколько часов, связан со многими ошибками и часто бывает неуспешным.
Проблема три заключается в том, что TLS обладает запутанной конфигурацией.
Предположим, что у нас всё прошло идеально, мы получили свой сертификат и хотим установить его на сервер. Но все его настройки действительно очень запутаны. Несколько лет назад люди говорили: «у нас есть потоковый шифр RC4, отлично, он очень эффективен»! Но сейчас, в 2015 году такие эксперты, как Ник из сети доставки контента CloudFlare, заявляют, что мы должны уничтожить RС4.
Другой пример – алгоритм криптографического хеширования Secure Hash Algorithm SHA-1, который тоже признан небезопасным, потому что рано или поздно Ваш сайт, который использует это хеширование и цепочки сертификатов будет признан браузерами Chrome и Firefox небезопасным.
Поэтому я предлагаю Вашему вниманию фильм под названием «SHA-256: Избавление». Это кино про человека, которого по ошибке обвинили в использовании SHA-1 на своём сайте и выгнали с работы. Он встречает Моргана Фримена и тратит всё время, чтобы убедить людей в том, в действительности он использовал SHA-256. Смотрите во всех кинотеатрах страны! Это была шутка!
А сейчас перейдём к следующей проблеме под названием «Как защитить сервер от уязвимости POODLE SSlv3». Люди говорят, что они отказались от криптографического протокола SSL v.3, потому что он был подвержен атакам Logjam, которые способны расшифровать или взломать любое TLS-соединение, установленное с неправильно сконфигурированными веб-сервисами или почтовыми серверами.
Хочу показать Вам результаты аудита сайтов, который выполнила независимая лаборатория ssllabs.com. Как видите, наш сайт letsencrypt.org имеет наивысшую оценку А+ и является одним из лучших сайтов в смысле безопасности, потому что ssllabs серьёзная организация и им можно доверять. Мы используем последние шифры из списка рекомендованных. Вы видите другие сайты, которые получили минимальную оценку F. Проблема состоит в том, что многим так и не удаётся правильно настроить SSL и они пользуются сломанным шифрованием.
Проблема №4 заключается в блокировке смешанного контента. Ваш сайт может быть заблокирован, когда Вы пользуетесь SSL, но загружаете все ресурсы через HTTP. Браузер считает, что должен переместить этого пользователя на уровень безопасности HTTPS и поэтому блокирует его контент HTTP. В результате сайт перестаёт функционировать, если Вы загружаете скрипты через HTTP. В случае с Lenovo, которых я проверяла несколько ночей назад, они могли использовать HTTPS, но не могли загрузить даже свои шрифты через него, потому что по умолчанию должны были использовать HTTP. Я покажу Вам на слайде, какие сайты используют только HTTPS.
Питер и я работаем над поддержкой расширения браузера. Поэтому если Вы пользуетесь браузером Chrome, Вы можете увидеть, что все его ресурсы могут быть прочитаны как HTTPS. То есть у нас имеется полезный инструмент для того, чтобы Вы могли превратить свой сайт из незащищённого в безопасный. Если Вы используете сторонний контент и не знаете, поддерживает ли он SSL, то можно воспользоваться инструментом разработчика в виде таблицы и «поиграть» с ней. Это поможет переписать ресурсы, что может очень Вам помочь.
Имеется новый заголовок страницы под названием «upgrade insecure request», «обновление небезопасных запросов», и когда браузер его видит, то понимает, что все субресурсы сайта и ссылки нужно преобразовать в HTTPS, даже если они написаны на HTTP. Так что Вы можете воспользоваться этим заголовком для своих сайтов.
Проблема №5 заключается в том, что существует слишком много доверенных организаций, выдающих сертификаты безопасности. Год назад Питер даже нарисовал очень сложную таблицу, которую Вы видите на экране. Питер, объясни, что она означает!
Питер Эккерсли говорит, что это далеко не полная карта, а всего лишь часть. Она была представлена на DEFCON в 2010 году проектом SSL Odservatory. Мы выяснили, что на то время было 66 центров авторизации в Firefox и почти 150 в IE. Когда мы просканировали Интернет, то убедились, что они все были авторизированны и сертифицированы другими центрами сертификации, и им доверяют браузеры. Существовали тысячи CAS, Центров сервиса аутентификации, которые могли скомпрометировать сотни организаций и доменов в сети, и это выглядело ужасающе. В прошлом году Google обнаружил ошибочные сертификаты, выданные Китайским центром сертификации, так что это не просто теоретическая атака на безопасность сайтов.
А сейчас я передаю слово Питеру, который расскажет, как мы видим мир в будущем.
Я расскажу Вам о том, как мы видим решение перечисленных проблем. Во-первых, можно создать свой собственный Центр Авторизации Сертификатов LetsEncrypt, бесплатный, автоматизированный и открытый. Я вижу, Вам понравилась эта шутка!
В действительности мы нуждаемся в детальном рассмотрении, как безопасности, так и всех сайтов, которые в ней нуждаются. Нам нужно решение, которое одновременно обеспечивало бы и безопасность, и удобство использования.
Люди, которые называют себя веб-разработчиками, не хотят углубляться во все тонкости использования уязвимости SSL и не нуждаются в этом. Поэтому самый важный вопрос, на который мы должны ответить, это то, как мы собираемся выдавать сертификаты. Потому что существующее положение напоминает сцены из Святого Грааля, когда Вам приказывают пойти туда — не знаю куда и принести то — не знаю что. И когда Вы это приносите, выясняется, что это совсем не то, что от Вас требовалось.
Вопрос, который я обозначу цифрой «ноль», называется «Самозагрузка». Здесь имеется в виду использование существующего варианта для создания нового. Какое решение мы должны использовать на основе прежнего шифрования? Обычный ответ на этот вопрос — Domain Validation DV, или легализацию доменного имени. Это не требует тысячедолларовой оплаты, достаточно отослать письмо адрес или разместить запрос на сайте, чтобы сделать апгрейд протокола безопасности.
Какие типы DV использует Let's Encrypt? Для загрузки это протокол DVSNI через порт 443 или простой HTTP через порт 88 для тех, кто использует прокси-сервер. В данном случае CAS проверяет Ваши административные права на управление сайтом, чтобы Вы могли его настроить. По ссылке на ресурс, указанной в письме, мы заходим к Вам и проверяем ответное «рукопожатие» TLS, и проводим несколько тестовых атак на Ваш ресурс, чтобы убедиться в его защищенности.
Многие спрашивают меня о возможности легализации DNS имён, возможно, позже мы реализуем такую функцию для клиентов вместе с возможность апгрейда протокола для доменов DVSNI 2 для портов 443 и 100. Если на Вашем виртуальном хостинге имеются тысячи доменов, Вы сможете внести всего одно изменение в протокол вместо тысячи изменений. Это можно проделать на различных портах, в том числе на особенных, как порт 443, на котором обычно размещают файервол. У нас имеется возможность аудита портов, которые хотят использовать пользователи, путём широкого сканирования Интернета.
Многих пугает всё, что связано с валидацией доменов. Интернет в этом случае представляется тёмной дырой, путём, по которому Вы отправляете пакеты информации, они исчезают на середине пути, а некоторые возвращаются к Вам обратно и говорят: «да, я действительно этот домен»! Будут ли Ваши пакеты съедены злобными монстрами или модифицированы на этом пути, Вы не знаете. Вы можете быть атакованы, если Ваш роутер или DNS сервер не защищён должным образом. Описанные выше методы не слишком совершенны, поэтому мы можем использовать более «продвинутую» методику проверки. Мы можем использовать многовариантный путь проверки, в котором задействуем серверы дата-центров и другие ресурсы мировой «паутины», и создать несколько версий запросов валидации или нескольких версий запросов DNS. Этот способ не защищает Вас от атаки более мощного противника, потому что он может воспользоваться уязвимостью роутера своей жертвы и через него добраться до Вас. Так что DV не является оптимальным способом защиты при создании инфраструктуры безопасности для всего Интернета.
Однако у нас есть лучший вариант защиты. К счастью, описанное выше «путешествие по неосвещённому шоссе Интернета» необходимо совершить только один раз. Мы обсуждали проект изучения всех SSL на конференции DEFCON ещё 5 лет назад, и с тех пор провели серию исследований благодаря поддержке пользователей Firefox и Google, которые выслали нам миллионы сертификатов и благодаря проекту ZMap, которым Джеймс занимается вместе с командой Мичиганского университета. Теперь, когда у нас есть огромная база данных по сертификатам и целый силлабус (список заблуждений), мы можем помочь человеку, даже когда он обращается к нам с просьбой проверить доменное имя Новозеландского банка. Мы никогда не слышали о корпоративной сетевой почте этого банка, но можем посоветовать нашему клиенту посмотреть базу сертификатов и увидеть, что это доменное имя имеет сертификат валидации.
Доступ к базе данных обеспечивается сканированием портов 443, просмотром логов стандарта CT (Certificate Transparency) или по запросу клиента. Мы не собираемся проверять Ваш незашифрованный домен, а просим Вас доказать, что Вы владеете частным ключом существующего легализированного сертификата. Таким образом Вы всегда можете получить наш сертификат или сертификат другого CAS, если уже владеете отпечатком ключа какого-либо авторизованного сертификата безопасности.
Это бывает не слишком удобно, потому что вынуждает Вас искать этот самый ключ. В случае, если Вы его потеряли, Вам придётся проходить всю процедуру сертификации заново и платить за весь пакет настроек.
Если Вы что-либо слышали об аутентификации TOFU, Trust on first use, то знаете, что этот механизм полагается на то, что первая передача ключа не была скомпрометирована, запоминает этот ключ и отвергает подтверждение безопасности при его внезапной смене. Скорее всего, Вы знакомы с ним по модели безопасной оболочки SSH. Это бывает хорошим решением в некоторых случаях.
Следующим важным вопросом являются проблемы TLS и HTTPS. Мы сталкиваемся с этой проблемой при неграмотном конфигурировании TLS, о чём уже говорила Ян. В этом случае Вы уязвимы для poodles, logjam и hotblades атак. Всё, что нужно для решения этой проблемы – это клиент, который запускается на Вашем сервере и волшебным образом конфигурирует его так, как надо. Потому что существует огромное количество сайтов, серверов и огромный массив информации, и нужны серьёзные знания, чтобы соответствовать всем требованиям. Мы же представляем собой маленькую команду людей, которые стараются внести свой вклад в решение проблемы. Мы хотим правильно настроить TLS и поделиться своими инструментами со всеми, кто в этом нуждается.
В чём же заключается цель клиента, который мы собираемся поддерживать? Она состоит в том, что пользователь получает этот клиент на полгода или год и с его помощью поддерживает настройки существующего сервера на движке Apache/Nginx или другом в актуальном состоянии, проводя необходимые изменения и затем устанавливая результирующий сертификат. При этом клиент настраивает функции безопасности оптимальным образом для получения наилучшего результата для конкретной конфигурации Вашего сервера и автоматически обновляет систему безопасности в соответствии с текущими требованиями. То есть он автоматически противодействует случаям нарушения безопасности, которые создают массовые проблемы при использовании HTTP.
Что имеется в виду под автоматизацией безопасности? Это целый спектр задач различной сложности, которые решаются в автоматическом режиме. К легким задачам относятся настройка наборов шифрования Cipher, OCSP stapling и апгрейд CSP. Более сложным является трансляция HTTP 302 (код перенаправления) в HTTPS для современных клиентов, потому что при этом может быть заблокирован смешанный контент даже в случае обновления параметров безопасности, и здесь нужно использовать смешанные сертификаты: новый для нового контента и старый для старого HTTP-контента. Задачей средней сложности также является автообновление и переназначение ключей в случае изменения доменных имён, потому что нужно опять-таки иметь набор для старого имени и набор для нового.
Сложной задачей является полное переписывание сертификатов и HSTS. HSTS это механизм, активирующий форсированное защищённое соединение через протокол HTTPS вместо использования HTTP-протокола, что позволяет сразу же устанавливать безопасное соединение. Если Вы не используете HSTS, Ваш сайт совершенно не защищён, однако этом механизм обладает некоторыми секретными свойствами, которые способны «положить» Ваш сайт при некорректной работе настроек безопасности.
Самой сложной задачей является аудит и исправление смешанного контента. Её решение возможно, однако является серьёзной инженерной задачей.
Третьим важным вопросом является то, что центры авторизации CA сами по себе являются ужасающими вещами, потому что контролируют безопасность всего Интернета, и мы пытаем создать автоматический гигантский центр сертификации, такую безумную машину, которой сами побаиваемся. Какой дизайн безопасности мы выбираем для этого гиганта?
Запуск вашего собственного СА является не менее ужасающей вещью, однако мы не только проводим исследования существующих угроз, но и планируем заранее обнаруживать и отражать угрожающие безопасности события, чтобы нацелить на них нашего автоматического гиганта.
Далее рассмотрим вопрос защиты от самих себя, то есть защиты своей репутации как СА. Она подразумевает полную прозрачность процессов сертификации:
- открытую публикацию серверных логов ACME и производимых нами трансакций;
- публикацию полной истории верификации сертификатов;
- публикацию логов стандарта Certificate Transparency.
Для защиты от других CA мы предоставляем поддержку HPKP, или HTTP Public Key Pinning, если Вы достаточно смелый или сумасшедший человек. Key Pinning – это привязывание публичного ключа к сетевому ресурсу (по имени или по адресу) на стороне клиента. При такой технологии изменение отпечатка ключа позволяет обнаружить подмену ключей при атаке по схеме «человек посередине».
Кроме этого, мы предоставляем услуги ресертификации, если Ваш ресурс был безосновательно скомпрометирован другими центрами сертификации или злоумышленниками, а также восстанавливаем повреждённые ключи.
Хочу рассказать Вам об институтах и организациях, поддерживающих наш центр авторизации сертификатов Let'sEncrypt, который был начат как совместный проект EFF, Mozilla и Мичиганского университета.
Этот проект создан для того, чтобы большая часть Интернет-сайтов смогла перейти к шифрованным подключениям HTTPS без оплаты, изменения конфигурации серверов, использования электронной почты, поэтому у нас очень простой процесс установки и настройки TLS-шифрования. Например, на типичном веб-сервере на базе Linux требуется выполнить всего две команды, которые настроят HTTPS шифрование, получат и установят сертификат примерно за 20-30 секунд.
Сейчас он базируется на основе нашей собственной неформальной группы исследований Интернет-безопасности ISRG, крупнешими спонсорами которой являются компании EFF, Mozilla, Cisco, Akamai, IdenTrust и Automatic. Разработку ведут CAS серверы обеспечивают специалисты ISRG и Mozilla, серверные коды создают EFF и Mozilla, клиентские коды – EFF и Мичиганский университет, а политикой, легализацией и бюрократией занимаются все остальные.
Первый сертификат мы планируем выпустить 7 сентября, валидацию и бета-версию клиента запускаем в середине октября, а полнофункциональную версию нашего CA мы представим публике 16 ноября.
Между тем, целую кучу времени отнимают бюрократические процедуры, когда мы выпускаем документ, потом документ на этот документ и так далее. Всё это удорожает сертификацию и растягивает по времени. У нас есть несколько людей, занимающихся всем этим, и если Вас интересуют наши коды, клиент, сервер и спецификации или Вы хотите их взломать, или помочь, или принять участие в наших разработках, добро пожаловать за исходниками на приведённые на слайде ресурсы.
А сейчас я хочу пригласить к микрофону Джеймса, чтобы он рассказал вам более подробно о нашем клиенте и продемонстрировал его работу.
Слово берёт Джеймс Кастен.
Сейчас я увеличу размер шрифта, чтобы происходящее на экране моего ноутбука было Вам хорошо видно. Я запускаю наш клиент, сделанный на языке Python, в виртуальной среде.
В качестве примера я зайду на сайт encryption-example.com, его создал энтузиаст, которые любит учить людей шифрованию, но к несчастью, сам ничего об этом не знает – мы не можем зайти на этот сайт через HTTPS.
К тому же он очень интересуется тем, как делать деньги, поэтому зарегистрировал сайт для получения сертификатов доверия TLS Trust. Здесь есть всё, чтобы Вы чувствовали себя в безопасности – есть и логотип, и иконка с замком, но это всё совершенно не работает с TLS – при попытке зайти сюда через HTTPS страница сайта не открывается.
Вернёмся к нашему клиенту. Он использует сервер Apache. Для продолжения работы Вы должны прочитать соглашение конечного пользователя и иметь ввиду, что данная версия клиента не предназначена для получения публичного сертификата.
Рабочая версия клиента протестирует конфигурацию Вашего сервера и проверит, какие имена Вы используете в качестве хоста, то есть проведёт исследование файлов конфигурации. Затем она внесёт необходимые изменения в конфигурационный файл и настроит TLS так, чтобы сайт стал безопасным и мог открываться через HTTPS.
Вы можете выбрать, какое доменное имя хотите использовать для проверки, в первом тесте я использую протестированный выше encryption-example.com. Наш клиент пройдёт через этот ресурс, обновит конфигурацию настроек безопасности, самоподпишется и сохранит для Вас результат тестирования, о чем сообщит на экране. Весь процесс занял 30 секунд.
Здесь написано, что сайт encryption-example.com стал доступным. Проверим через публичное соединение – действительно, сейчас я могу войти на него через HTTPS. Как видите, результат на лицо.
Хочу заметить, что Вы всегда можете произвести все необходимые изменения с помощью командной строки и вообще не использовать никаких подсказок, наш клиент всё равно установит настройки и решит проблемы сервера. Он также может создать перенаправление с оригинального HTTP-хоста на новый хост. Можно также дополнительно установить дюжину или пару дюжин настроек безопасности, таких как перенаправление HTTP, OCSP stapling и других вариантов конфигурации.
Люди иногда не хотят, чтобы мы трогали их конфигурации, но у нас имеется три точки отката при каждом процессе изменения конфигурации, поэтому можно легко откатить все изменения назад и снова сделать сервер небезопасным для SSL соединения через HTTPS. В данной версии невозможно отозвать сертификат, но у нас будет другая система управления, которая позволяет вручную отозвать все выданные сертификаты при возврате к первоначальной конфигурации настроек безопасности сервера, как будто бы мы ничего не трогали.
Я хотел показать это в демо-режиме, но не смог быстро создать соответствующие коды особенно для такого неоднородного Интернета.
Но Вы должны знать, что если мы пока не поддерживаем Ваш сервер, Вы легко можете использовать другую технологию настроек. Всего у нас имеется три способа аутентификации через клиент Let'sEncrypt.
У нас есть ручной аутентификатор, который не требует рут-прав, а просто создаёт для Вас файл, который нужно разместить на сервере. Есть и автономный аутентификатор, который достаточно просто запустить, после чего математический алгоритм создаст для Вас сертификат и поместит его в правильную директорию сервера.
Вот и всё, что я хотел рассказать. Теперь можно задавать нам вопросы.
Вопрос:
— Насколько трудно было Вам стать Центром авторизации и получить разрешение на это от компании – разработчика и владельца браузера?
Питер:
— Мы об этом не говорили! Скажите, сколько людей в зале считают, что для того, чтобы стать CA, необходимо получить разрешение от браузера? Вы считаете неправильно! Не требуется никаких разрешений от владельца браузера. Всё что нужно для этого – это получить один единственный сертификат аутентификации, который гарантирует Вам по контракту право заверять сертификаты. И тогда Вы можете работать с любыми браузерами, которые прошли сертификацию в существующих CA. Сейчас мы проходим аудит, и Вы не представляете, сколько времени и денег это отнимает и какое количество документации нам нужно подготовить. Но вскоре мы закончим с этим, и хорошо, что подобное нужно пройти всего один раз.
Вопрос:
— Ваша демонстрация возможностей клиента через командную строку была впечатляющий, но планируете ли Вы быть интегрированными в такие продукты, как cPanel или среды для VPS-хостинга?
Питер:
— Да, мы планируем использовать более удобные инструменты, например, API, просто командная строка лучше адаптирована для работы с Python. У нас есть простой интерфейс API для новых серверов, который поможет Вам понять новые типы сервисов.
Вопрос:
— Занимались ли Вы работой со списком отзыва сертификатов CRL?
Питер:
— На самом деле я не могу вспомнить случай, когда бы это нам понадобилось. Такая потребность может возникнуть, если мы будем уверены в том, что Google и люди, отзывающие сертификаты, нуждаются в новом способе осуществления этой процедуры. Наш клиент будет запущен с трёхмесячным окном валидации, поэтому мы рискуем немного меньше в отношении рабочих сертификатов, чем другие CА, так как сейчас механизм отзыва в Интернете практически не работает.
Вопрос:
— Сейчас Ваш клиент работает с движками Apache и Nginx. Имеются ли у Вас планы по интеграции с инструментами управления конфигурацией, такими как Chef и Puppet?
Джеймс:
— Да, у нас есть установщики для Chef и Puppet. Сейчас их использование не является насущной необходимостью, но мы располагаем возможностью их интеграции в наш клиент.
Вопрос:
— Вы используете политику собственного публичного API в своём клиенте, и это хорошо, но не планируете ли Вы где-нибудь использовать сторонние API?
Питер:
— Нет, мы не планируем использовать никакие другие API кроме уже существующих.
Вопрос:
— Почему некоторые люди говорят, что не всем сайтам необходимо иметь SSL? Вероятно, они имеют в виду фишинговые сайты?
Питер:
— У нас есть два плана, вернее, два типа планов по борьбе с фишинговыми сайтами. Но существует формат сертификата открытых ключей X.509, который должен быть заменён более надёжным форматом. Если на сайте с открытым ключом используется иконка замочка, то это выглядит издевательством, так как фактически соединение не является достаточно безопасным. Поэтому мы ищем способы сделать так, чтобы пользователь изначально не попадал на незащищённый сайт, чтобы не подвергнуться фишинговой атаке, например, перенаправление его на доверенный сайт с безопасным доменным именем. Такие сайты мы помечаем особой меткой.
Вопрос:
— Главная цель TLS состоит в том, чтобы ликвидировать угрозу типа «человек посередине». Предположим, что я подсоединюсь к сайту encryption-example.com и мой браузер выбирает порт 80, в таком случае я становлюсь этим самым «человеком посередине» и спокойно обхожу TLS. Как можно избежать этого?
Питер:
— Дело в том, что люди не знают, что должны установить флаг безопасности на свои «кукиз», и огромное количество сайтов не пропускает «кукиз» без такого флага. Поэтому всё, что Вам нужно для обеспечения безопасности сайтов, это установка набора HSTS. Мы собираемся помочь в этом сайтам, но данный способ относится к вещам, способным вызвать неполадки в работе сайта. Поэтому нам нужны хорошие инструменты для быстрого включения HSTS, возврата в предыдущее состояние и возможность сообщить администрации сайта, что вследствие атаки имеются нерабочие страницы, и исправить их. Возможно, это поможет вовремя обнаружить «человека посередине» и изолировать его.
Вопрос:
— Собираетесь ли Вы поддерживать сертификаты более высокого уровня Wildсard?
Питер:
— Используемые API не позволяют поддержку таких сертификатов, но мы не исключаем такую возможность в дальнейшем.
Вопрос:
— Можно ли использовать Ваш клиент для проверки доменов типа .local?
Питер:
Я думаю, что не имеет смысла использовать TLS в этом случае. Нужно стремиться к созданию не конфликтующих доменных имён или создать новый интерфейс браузера для этих доменов. Возможно, должна быть создана новая модель TOFU для этого локального пространства имён, но оно должно быть отделено от пространства публичного веб-нейминга.
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Комментарии (7)
andreykp
01.04.2018 12:30Забыли описать Content Security Policy — та еще заноза…
Особенно если не дай бог у тебя что-то аяксом подтягивается с субдомена или своей CDN
Pilat
01.04.2018 12:52Надо только на видном месте написать, что статья трёхлетней давности, и некоторые вещи уже устарели (например вопрос про wildcard сертификаты)
powerman
01.04.2018 22:08— Можно ли использовать Ваш клиент для проверки доменов типа .local?
Питер:
Я думаю, что не имеет смысла использовать TLS в этом случае.Ага, отличная идея. Особенно при необходимости протестировать https-ный сайт в CI или запустить его в докер-контейнере на машине разработчика, с целью убедиться что https/HSTS/secure cookies/etc. реализованы корректно. Получается, они рекомендуют делать две версии сайта — одну с https/HSTS/secure cookies и вторую без всего этого чтобы можно было удобно тестировать и разрабатывать сайт? Мало того, что это лишняя работа и лишние баги, так ещё и всегда остаётся вероятность нечаянно запустить в продакшне версию без, например, secure cookie.
Идея сделать для компании/проекта свой CA и подписывать им сертификаты для .local тоже очень так себе. Если в CI ещё можно поставить сертификат своего CA как доверенный, то в браузере разработчика это делать уже не хочется, ибо открывает возможность для злоупотреблений и использования этого CA для выдачи сертификата для сайтов вроде gmail.com и использования компанией MiTM-атак. Особенно для фрилансеров, которые работают с кучей компаний и не имеют оснований доверять им настолько, чтобы позволить им всем ставить сертификаты собственных CA в браузер фрилансера "для тестирования проекта".
dmitriylyalyuev
Прошлым летом, когда я захотела воспользоваться сайтом Quora, я зашла на страничку авторизации и увидела, что она сделана на основе простого HTML, что уже плохо. Кроме того, HTML открыт для воздействия инструментов злоумышленников и передаёт Ваши пароли в виде открытого текста.
И что же они предлагают использовать вместо html?
porutchik
Надо Flash добавить и немного java-аплетов.
OPECT
В оригинале вродь говорится что «страница логина передается по http» (а не в зашифрованном виде, по https). Автор перевода почему то взял html и начал вокруг этого сочинять перевод.
HostingManager Автор
Премного благодарен, исправил неточность.