Меня зовут Ян Чжу, я работаю инженером по безопасности в Yahoo; Это Питер Кекерсли, старший научный сотрудник Electronic Frontier Foundation и руководитель группы разработки технологий, и Джеймс Кастен, специалист по технологиям и аспирант в области компьютерных наук и инженерии Мичиганского университета.
Итак, кто из вас шокирован возможностью шифрования всего Интернета? Я в восторге от вашего энтузиазма! Итак, какие проблемы волнуют мир, помимо глобального потепления, детского голода и всего такого? Проблема в том, что протоколы безопасности транспортного уровня TLS до сих пор не получили широкого распространения даже в 2015 году.
Прошлым летом, когда я захотел воспользоваться сайтом Quora, я зашёл на страницу авторизации и увидел, что она реализована на основе простого http, который уже есть.
плохой.
Кроме того, http открыт для инструментов злоумышленников и передает ваши пароли в открытом виде.
Это действительно плохо, когда вы видите, как миллионы активных пользователей заходят на ваш сайт каждый день.
Цель Quora — распространение социальных знаний или, возможно, дезинформации среди пользователей.
Это сайт вопросов и ответов на различные темы.
Еще есть небольшой сайт под названием Google, пусть поднимут руки те, кто о нем слышал, но они всегда неплохо справлялись с использованием SSL. Однако некоторые страницы, такие как эта целевая страница приложения Google Реклама, по-прежнему используют обычный протокол HTTP по умолчанию.
Вы можете сказать, что в этом нет ничего плохого, это статическая общедоступная страница, не требующая ввода данных пользователем.
Но человек вроде меня, разбирающийся в этих вопросах, проверит, куда ведет кнопка «Войти».
Обычный пользователь, ничего не подозревая, после нажатия на эту кнопку может быть перенаправлен на фишинговый сайт, где он введет свои регистрационные данные.
А поскольку он использует HTTP, это все еще проблема.
Вторая проблема заключается в том, что получение протоколов безопасности транспортного уровня TLS по-прежнему довольно утомительно даже в 2015 году.
Если кто-нибудь слышал об этом, поднимите руку.
Я вижу, что их много.
Если вы хотите это сделать, вы можете зайти на wiki.cremehost.com и просмотреть 12 шагов, которые необходимо предпринять для приобретения сертификата цифровой подписи, сертифицированного центром сертификации.
И хотя вы еще не являетесь Анонимными Алкоголиками, даже для вас эта процедура довольно утомительна.
Давайте посмотрим, сколько времени занимает настройка TLS. У меня есть видео об этом здесь.
Я разговаривал со многими моими коллегами из EFF о том, знают ли они, как настроить TLS, и никто из них не делал этого раньше.
Надеюсь, мое видео сработает. Часть 1 - Паркер Хиггинс, активист EFF. - Привет, Паркер, что ты делаешь сегодня? — Я пытаюсь установить HTTPS на своем тестовом сайте.
- Ну, это весело? - Возможно, я еще не знаю.
- Могу ли я снять видео, как ты это делаешь? - Да, ты можешь! - Большой! И тут вы видите, что он делает это с трудом.
Он нажимает кнопку «Справка», страница загружается снова и снова, но ничего не происходит. Я ему говорю, что он, наверное, сегодня не сможет, и ухожу.
Часть 2 – Ной.
Здесь продолжается аналогичный процесс, который в общей сложности занял у Ноя почти 9 часов.
Он не может понять, что происходит с его электронной почтой или как настроить сертификат, поэтому идет выпить кофе.
Через три часа я возвращаюсь к нему.
- Это сайт, который мы пытаемся защитить.
И эта кнопка снова неактивна.
Не могу сюда прикрепить сертификат. Появляется сообщение: «Не все поля заполнены».
Попробую заполнить их еще раз.
Итак, выскочила надпись «Поздравляем»! Это то, на что я потратил столько времени? Хорошо, продолжим, попробуем запустить наш сайт. Находим его в выпадающем меню формы, нажимаем на него, ждем.
Информация выводится на экран, и Ной удивленно говорит: «Что это значит? Я думаю, это письмо от сестры, какой-то счет, оплата.
Это вообще мой браузер? Проходит еще час.
Я возвращаюсь к Ною, который все еще ждет письма, подтверждающего успешность получения сертификата ключа шифрования безопасности для его сайта.
Он говорит, что получил письмо с благодарностью за использование сервиса сертификации, но когда он пытается перейти по ссылке, указанной в письме, у него ничего не получается, возможно, это связано с проблемами с прокси-сервером на его стороне.
Ной рассказывает, что прошел целый час, в течение которого он предпринял еще несколько безуспешных попыток получить сертификат, но у него ничего не вышло.
Пожалуйста, простите меня за это грустное видео.
Итак, мы увидели, что процесс сертификации занимает несколько часов, сопряжен с множеством ошибок и зачастую завершается неудачно.
Проблема третья заключается в том, что TLS имеет запутанную конфигурацию.
Предположим, что у нас все прошло отлично, мы получили свой сертификат и хотим установить его на сервер.
Но все его настройки действительно очень запутаны.
Несколько лет назад люди говорили: «У нас есть потоковый шифр RC4, отлично, он очень эффективен»! Но теперь, в 2015 году, такие эксперты, как Ник из сети доставки контента CloudFlare, говорят, что мы должны уничтожить RC4.
Другим примером является криптографический алгоритм хеширования Secure Hash Algorithm SHA-1, который также признан небезопасным, поскольку рано или поздно ваш сайт, использующий такое хеширование и цепочки сертификатов, будет признан небезопасным браузерами Chrome и Firefox. 
Поэтому предлагаю вашему вниманию фильм под названием «SHA-256: Избавление».
Этот фильм рассказывает о человеке, которого по ошибке обвинили в использовании SHA-1 на своем сайте и уволили с работы.
Он знакомится с Морганом Фрименом и проводит все свое время, пытаясь убедить людей, что он действительно использовал SHA-256. Смотрите его во всех кинотеатрах страны! Это была шутка! Теперь перейдем к следующей задаче под названием «Как защитить свой сервер от уязвимости POODLE SSlv3».
Люди говорят, что они отказались от криптографического протокола SSL v.3, потому что он был подвержен атакам Logjam, которые способны расшифровать или перехватить любое TLS-соединение, установленное с неправильно настроенными веб-сервисами или почтовыми серверами.
Хочу показать вам результаты аудита сайта, проведенного независимой лабораторией ssllabs.com. Как видите, наш сайт letencrypt.org имеет высший рейтинг А+ и является одним из лучших сайтов с точки зрения безопасности, ведь ssllabs — серьезная организация и им можно доверять.
Мы используем новейшие шифры из рекомендуемого списка.
Вы видите другие сайты, которые получают минимальный рейтинг F. Проблема в том, что многим так и не удается правильно настроить SSL, и в конечном итоге они используют сломанное шифрование.
Проблема №4 — блокировка смешанного контента.
Ваш сайт может быть заблокирован, если вы используете SSL, но загружаете все ресурсы через HTTP. Браузер считает, что ему следует перевести этого пользователя на уровень безопасности HTTPS, и поэтому блокирует его HTTP-контент. В результате сайт перестает работать, если вы загружаете скрипты по HTTP. В случае с Lenovo, которую я проверял несколько дней назад, они могли использовать HTTPS, но не могли даже загружать через него свои шрифты, поскольку по умолчанию им приходилось использовать HTTP. На слайде я покажу вам, какие сайты используют только HTTPS. 
Питер и я работаем над поддержкой расширений браузера.
Поэтому, если вы используете браузер Chrome, вы можете увидеть, что все его ресурсы читаются как HTTPS. То есть у нас есть полезный инструмент, благодаря которому вы сможете превратить свой сайт из незащищенного в безопасный.
Если вы используете сторонний контент и не знаете, поддерживает ли он SSL, то вы можете воспользоваться инструментом разработчика в виде таблицы и «поиграться» с ним.
Это поможет вам переписать ресурсы, что может вам очень помочь.
Появился новый заголовок страницы под названием «небезопасный запрос на обновление», и когда браузер его видит, он понимает, что все подресурсы и ссылки сайта необходимо конвертировать в HTTPS, даже если они написаны на HTTP. Таким образом, вы можете использовать этот заголовок для своих веб-сайтов.
Проблема №5 заключается в том, что существует слишком много доверенных организаций, выдающих сертификаты безопасности.
Год назад Питер даже нарисовал очень сложную таблицу, которую вы видите на экране.
Питер, объясни, что это значит! Питер Киркерсли говорит, что это не полная карта, а лишь часть.
Он был представлен на DEFCON в 2010 году проектом SSL Odservatory. Мы выяснили, что на тот момент в Firefox было 66 центров авторизации, а в IE — почти 150. Просканировав Интернет, мы убедились, что все они авторизованы и сертифицированы другими центрами сертификации, и браузеры им доверяют. Существовали тысячи 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 (доверие при первом использовании), вы знаете, что этот механизм основан на том, что первая передача ключа не подвергается риску, запоминает этот ключ и отклоняет утверждение безопасности, если оно внезапно меняется.
Скорее всего, вы знакомы с ним по модели защищенной оболочки SSH. В некоторых случаях это может быть хорошим решением.
Следующий важный вопрос — проблемы TLS и HTTPS. Мы сталкиваемся с этой проблемой, когда неправильно настраиваем TLS, как уже упоминал Ян.
В этом случае вы уязвимы для атак пуделей, заторов и горячих лезвий.
Все, что вам нужно для решения этой проблемы, — это клиент, который работает на вашем сервере и волшебным образом настраивает его по мере необходимости.
Потому что сайтов, серверов и информации огромное количество, и чтобы соответствовать всем требованиям, нужны серьезные знания.
Мы небольшая команда людей, которые пытаются внести свой вклад в решение проблемы.
Мы хотим правильно настроить TLS и поделиться нашими инструментами со всеми, кто в них нуждается.
Какова цель клиента, которого мы собираемся поддерживать? Он заключается в том, что пользователь получает данный клиент на полгода-год и с его помощью поддерживает в актуальном состоянии настройки существующего сервера на Apache/Nginx или другом движке, внося необходимые изменения и затем устанавливая полученный сертификат. .
В этом случае клиент настраивает функции безопасности оптимальным образом для получения наилучшего результата для конкретной конфигурации вашего сервера и автоматически обновляет систему безопасности в соответствии с текущими требованиями.
То есть он автоматически противодействует нарушениям безопасности, которые создают серьезные проблемы при использовании HTTP. Что подразумевается под автоматизацией безопасности? Это целый комплекс задач различной сложности, которые решаются в автоматическом режиме.
Простые задачи включают настройку наборов шифрования Cipher, сшивание OCSP и обновления CSP. Сложнее транслировать HTTP 302 (код перенаправления) в HTTPS для современных клиентов, поскольку он может блокировать смешанный контент даже при обновлении настроек безопасности, и здесь нужно использовать смешанные сертификаты: новый для нового контента и старый для старого HTTP-контента.
Задачей средней сложности также является автообновление и переназначение ключей в случае смены доменного имени, потому что вам снова нужно иметь набор для старого имени и набор для нового.
Задача состоит в том, чтобы полностью переписать сертификаты и HSTS. HSTS — это механизм, который обеспечивает принудительное безопасное соединение по протоколу HTTPS вместо использования протокола HTTP, что позволяет немедленно установить безопасное соединение.
Если вы не используете HSTS, ваш сайт совершенно незащищен, но у этого механизма есть некоторые секретные свойства, которые могут привести к сбою вашего сайта, если настройки безопасности работают неправильно.
Самая большая проблема — аудит и исправление смешанного контента.
Ее решение возможно, но это серьезная инженерная задача.
Третий важный вопрос заключается в том, что сами центры сертификации — это страшные вещи, потому что они контролируют безопасность всего Интернета, а мы пытаемся создать автоматический гигантский центр сертификации, такую сумасшедшую машину, которой мы сами боимся.
Какой дизайн безопасности мы выбираем для этого гиганта? Запуск собственного центра сертификации не менее страшен, но мы не только проводим исследования существующих угроз, но также планируем активно обнаруживать события, угрожающие безопасности, и реагировать на них, чтобы наш автоматизированный гигант мог атаковать их.
Далее мы рассмотрим вопрос защиты себя от самих себя, то есть защиты своей репутации как СА.
Это подразумевает полную прозрачность процессов сертификации:
- открытая публикация журналов сервера ACME и выполняемых нами транзакций;
- публикация полной истории проверки сертификатов;
- публикация логов стандарта Certificate Transparency.
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 сентября, в середине октября запустим валидацию и бета-версию клиента, а 16 ноября представим публике полнофункциональную версию нашего ЦС.
Между тем бюрократические процедуры отнимают уйму времени, когда мы выдаем документ, потом документ под этот документ и так далее.
Все это увеличивает стоимость сертификации и удлиняет сроки.
Всем этим у нас занимаются несколько человек, и если вас интересуют наши коды, клиент, сервер и спецификации, или вы хотите их взломать, или помочь, или принять участие в наших разработках, вы можете получить исходники из предоставленных ресурсов.
на слайде.
А теперь я хочу пригласить Джеймса к микрофону, чтобы он мог подробнее рассказать о нашем клиенте и продемонстрировать свою работу.
Джеймс Кастен берет слово.
Теперь я увеличу размер шрифта, чтобы вам было хорошо видно происходящее на экране моего ноутбука.
Я запускаю наш клиент Python в виртуальной среде.
В качестве примера я зайду на сайт Encryption-example.com, он создан энтузиастом, который любит учить людей шифрованию, но, к сожалению, сам о нем ничего не знает — мы не можем зайти на этот сайт по HTTPS. 
Кроме того, его очень интересует, как заработать, поэтому он зарегистрировал сайт для получения сертификатов TLS Trust. Здесь есть все, чтобы вы чувствовали себя в безопасности — есть логотип и иконка с замком, но все это совершенно не работает с TLS — при попытке войти сюда по HTTPS страница сайта не открывается.
Вернемся к нашему клиенту.
Он использует сервер Apache. Чтобы продолжить, необходимо прочитать соглашение с конечным пользователем и учитывать, что данная версия клиента не предназначена для получения общедоступного сертификата.
Рабочая версия клиента проверит конфигурацию вашего сервера и проверит, какие имена вы используете в качестве хоста, то есть проверит файлы конфигурации.
Затем она внесет необходимые изменения в файл конфигурации и настроит TLS, чтобы сайт был безопасным и его можно было открыть через HTTPS. Вы можете выбрать, какое доменное имя вы хотите использовать для тестирования.
В первом тесте я использую шифрования-example.com, протестированного выше.
Наш клиент пройдет через этот ресурс, обновит конфигурацию параметров безопасности, самостоятельно подпишется и сохранит для вас результат теста, который будет отображен на экране.
Весь процесс занял 30 секунд. 
Здесь написано, что сайт шифрования-example.com стал доступен.
Давайте проверим через публичное соединение — действительно, теперь я могу зайти в него по HTTPS. Как видите, результат очевиден.
Хочется отметить, что вы всегда можете внести все необходимые изменения с помощью командной строки и вообще не использовать никаких подсказок; наш клиент все равно будет устанавливать настройки и решать проблемы сервера.
Он также может создать перенаправление с исходного хоста HTTP на новый хост. Вы также можете при желании установить дюжину или пару десятков настроек безопасности, таких как перенаправление HTTP, сшивание OCSP и другие параметры конфигурации.
Иногда люди не хотят, чтобы мы трогали их конфигурации, но у нас есть три точки отката для каждого изменения конфигурации, поэтому можно легко откатить все изменения и снова сделать сервер небезопасным для SSL-соединений через HTTPS. В этой версии невозможно отозвать сертификат, но у нас будет другая система управления, которая позволит нам вручную отозвать все выданные сертификаты, когда мы вернемся к исходной конфигурации параметров безопасности сервера, как будто мы ничего не трогали.
Я хотел показать это в демо-режиме, но не смог быстро создать соответствующие коды, особенно для такого разнородного Интернета.
Но вы должны знать, что если мы еще не поддерживаем ваш сервер, вы легко можете использовать другую технологию настройки.
Всего у нас есть три метода аутентификации через клиент Let’sEncrypt. 
У нас есть ручной аутентификатор, который не требует рут прав, а просто создаёт для вас файл, который нужно разместить на сервере.
Также имеется автономный аутентификатор, который достаточно просто запустить, после чего математический алгоритм создаст для вас сертификат и поместит его в нужную директорию сервера.
Это все, что я хотел вам сказать.
Теперь вы можете задавать нам вопросы.
Вопрос: — Насколько сложно вам было стать Центром авторизации и получить на это разрешение от компании, которая разработала и владела браузером? Питер: - Мы не говорили об этом! Скажите мне, сколько человек в комнате думают, что для того, чтобы стать центром сертификации, вам нужно получить разрешение от браузера? Ты не правильно думаешь! Никакого разрешения от владельца браузера не требуется.
Все, что вам нужно сделать, это получить один сертификат аутентификации, который гарантирует ваше договорное право на сертификацию сертификатов.
И тогда вы сможете работать с любыми браузерами, сертифицированными существующими центрами сертификации.
Сейчас мы проходим аудит, и вы даже не представляете, сколько времени и денег это занимает и какой объем документации нам нужно подготовить.
Но мы скоро с этим покончим, и хорошо, что такое придется пережить лишь один раз.
Вопрос: — Ваша демонстрация возможностей клиента через командную строку была впечатляющей, но планируете ли вы интегрироваться в такие продукты, как cPanel или среды VPS-хостинга? Питер: — Да, мы планируем использовать более удобные инструменты, например API, просто командная строка лучше адаптирована для работы с Python. У нас есть простой API для новых серверов, который поможет вам разобраться в новых типах сервисов.
Вопрос: — Работали ли вы со списком отзыва сертификатов CRL? Питер: «На самом деле, я не могу вспомнить время, когда нам это было нужно».
Такая необходимость может возникнуть, если мы считаем, что Google и людям, отзывающим сертификаты, нужен новый способ сделать это.
Наш клиент будет запущен с трехмесячным окном проверки, поэтому мы несем немного меньший риск в отношении рабочих сертификатов, чем другие центры сертификации, поскольку механизм отзыва через Интернет в настоящее время по большей части нефункционален.
Вопрос: — Ваш клиент сейчас работает с движками Apache и Nginx. Планируете ли вы интегрироваться с инструментами управления конфигурациями, такими как Chef и Puppet? Джеймс: — Да, у нас есть установщики Chef и Puppet. Сейчас их использование не является острой необходимостью, но у нас есть возможность интегрировать их в наш клиент. Вопрос: — Вы используете в клиенте собственную политику публичного API, и это хорошо, но планируете ли вы где-нибудь использовать сторонние API? Питер: — Нет, мы не планируем использовать какие-либо другие API, кроме уже существующих.
Вопрос: — Почему некоторые говорят, что не всем сайтам нужен SSL? Вероятно, они имеют в виду фишинговые сайты? Питер: — У нас есть два плана, точнее, два типа планов по борьбе с фишинговыми сайтами.
Но существует формат сертификата открытого ключа X.509, который следует заменить более безопасным форматом.
Если на сайте с открытым ключом используется значок замка, то это выглядит как издевательство, поскольку на самом деле соединение недостаточно безопасно.
Поэтому мы ищем способы гарантировать, что пользователь изначально не попадет на незащищенный сайт, чтобы не подвергнуться фишинговой атаке, например, перенаправляя его на доверенный сайт с безопасным доменным именем.
Мы отмечаем такие сайты специальной меткой.
Вопрос: «Основная цель TLS — устранить угрозу «человек посередине».
Допустим, я подключаюсь к шифрования-example.com, и мой браузер выбирает порт 80, и в этом случае я становлюсь посредником и легко обхожу TLS. Как этого избежать? Питер: — Дело в том, что люди не знают Теги: #информационная безопасность #Хостинг #ит-инфраструктура #Конференции #tls #SSL #Letsencrypt #TOFU #hpkp #hsts #Шифрование Интернета
-
День Инвестора Addventure
19 Oct, 24 -
Мастера Иллюстратора По Программированию
19 Oct, 24 -
Посмотрите В Корень: Java.lang.object
19 Oct, 24 -
Кто Такой Ux-Дизайнер И За Что Ему Платят?
19 Oct, 24
