Как стать автором
Обновить

Комментарии 53

Исчерпывающая и очень полезная статья. Большое спасибо за перевод!
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Все эти оды за https систематически умалчивают одну неприятную деталь. А именно, вся эта конфиденциальность и приватность никак не появляется «изниоткуда», а просто переносится из под ответственности провайдеров в ответственность большой сети CA. А те, кто склонен заниметься сетевым вредительством, уже привык внедряться в обычные сети, но ещё не привык внедряться в деятельность CA по причине относительной новизны и до недавнего времени малой распространённости https. Не беспокойтесь, и туда они встроятся со временем.
MITM'ить https сайты, для которых вы являетесь сетевым (быть хостингом не требуется) провайдером в одной из инстанций уже возможно элементарно — тот же let's encrypt без каких бы то ни было проблем выдаст вам для этого DV-сертификат. Ну а если у вас побольше связей, то будет несложно найти достаточно сговорчивое CA, которое выпишет вам сертификат к чему угодно.
Так что https следует воспринимать исключительно как защиту от случайных хулиганов и не более того.

Всё так, но, тем не менее, это шаг в правильном направлении.


По большому счёту сама идея CA не выдерживает никакой критики, особенно учитывая тот факт, что за нарушения эти CA зачастую не наказывают вообще, а если и наказывают, то недостаточно жёстко чтобы исключить такие нарушения в будущем. (Очень показательна история про WoSign и StartCom.)


Тем не менее, существуют механизмы, которые смогут обеспечить необходимый уровень безопасности. Просто у них есть своя цена. Скорее всего, постепенно всё это будет реализовано в массовых масштабах, но надо с чего-то начинать, и https в любом виде это неплохой старт.

тот же let's encrypt без каких бы то ни было проблем выдаст вам для этого DV-сертификат.

что для этого надо сделать сетевому провайдеру?
Провести стандартную процедуру получения сертификата. Let's encrypt для проверки владения доменом использует обычные http-запросы, ничем не защищённые.
НЛО прилетело и опубликовало эту надпись здесь
Не понял, о чём вы. Let's encrypt -> цепочка провайдеров/магистралей -> ваш сайт. Провести атаку может любой из цепочки. Владелец сайта, конечно, может заметить что кому-то выдали сертификат к его сайту (и без логов выдачи, которые вряд ли кто-то мониторит на постоянной основе, а просто получив репорт о фейковом сайте с валидным сертификатом), только сделать он с этим вряд ли что-то сможет, кроме как попросить LE отозвать зловредный сертификат. Ну и потом гадать, кто же это сделал из цепочки.
НЛО прилетело и опубликовало эту надпись здесь

Всё верно — ключевой вопрос в TLS это вопрос доверия. Несмотря на то, что все это понимают и, более того, имеют технологические возможности для решения проблемы через механизм DANE, перспективы перехода на новые независимые от внешних структур методы удостоверения туманны.

Отличная статья, все подробно объяснили, спасибо! С HTTPS я знаком только со стороны установки сертификата на сайт, но хотелось бы понимать всю специфику технологии шифрования в целом. Можно на пальцах объяснить, как «стыкуются» ключи условных Боба и Алисы, понятно, что сообщение шифруется публичным ключом, а расшифровывается приватным, но как обеспечивается эта односторонняя зависимость приватного ключа от публичного? Что мешает третьей стороне создать свой приватный ключ из того же публичного сертификата и расшифровать сообщение? Как это происходит в том же, допустим, Телеграмме?
Извиняюсь, если в статье это разжевали, но я все-таки не уловил.
Конфиденциальность

Целостность

Аутентификация
Он гарантирует, что веб-сайт в реальности является тем, за кого себя выдаёт.

Если уж начали перечислять свойства, так и продолжайте перечислять свойства, а не механизмы. По-моему логичным продолжением является термин «подлинность» (authenticity): Свойство, гарантирующее, что субъект или ресурс идентичен заявленному. А не механизм аутентификации (Обеспечение гарантии того, что заявленные характеристики объекта правильны.)
Пожалуй, вы правы, так будет корректнее.
В WHM/cPanel все теперь проще, они дают бесплатный сертификат на домен от AutoSSL.
В меню:
WHM >> Packages >>AutoSSL
Нужно внести домен и гдето в районе 22:00 мск их робот обработает ваш домен.
А мне, как минимум для дева, понравилось использовать Caddy. Очень простое конфигурирование и автоматический HTTPS с автополучением/продлением из коробки: https://caddyserver.com/docs/automatic-https
Извините, напомнило

image
image

Такой механизм я использую в fiddler — добавил его корневой сертификат в доверенные системы и пропускаю необходимый для прослушивания «шифрованный» трафик через него. Но! Я сам, с правами админа, руками добавил сертификат fiddler в доверенные. Какая-то дрянь уже научилась делать это самостоятельно в фоне?

PS
Есть один издатель Ява-приложений (каталоги), я так и не смог заставить их связываться с центральным сервером через fiddler — приложение упорно ругается на нарушение конфендинциальности. Больше такого не встречал.
НЛО прилетело и опубликовало эту надпись здесь
Скандал помню, но сам механизм установки доверенного сертификата там не описан. Скорее всего юзер тапает не читая на тулбокс окно.
НЛО прилетело и опубликовало эту надпись здесь
Если у пользователя активирован UAC, то можно запросить диалог повышения прав, например, при установке ПО, что не вызовет подозрений.

Именно это я и имел в виду. Классический ССЗБ получается…
Правда для подписи системного кода, начиная с XP x64, нужен сертификат за подписью MS (никто не знает как это обойти?), но к нашему случаю это не относится.

К какому именно случаю не относится?
НЛО прилетело и опубликовало эту надпись здесь
Kaspersky Internet Security так делает по умолчанию. У кого стоит, посмотрите кем выдан сертификат тому же Хабру. Пока вроде бы есть настройка отключать возможность MitM.

На сегодняшний день на LE можно подписать эллиптический ключ, правда пока вручную, но всё же.

Шикарная статья, спасибо!
На машинке под Debian 7 Wheezy (VPS далеко в Западной Европе) Let's Encrypt я установить не смог — через полдня боданий с побитыми dependicies и засовыванием backports кучи всякого из Debian 8 уткнулся в необходимость сначала полного удаления, а потом установки заново из backport'a всех библиотек cURL. Т.к. cURL у меня одна из ключевых, то как-то стремно удалить ее, а потом не смочь поставить… Мог бы помочь актуальный снимок машины, на котором провести точные тесты. Но снимок виртуалки хостинг-провайдер обещает делать несколько часов после полного шатдауна… Два раза писал им после сбора статистики утром воскресенья, что хорошо бы сегодня ночью (3...4 часа ночи) сделать слепок, но их саппорт тупит :(

Так что лучеш все-таки уходить на Debian 8 по возможности.
НЛО прилетело и опубликовало эту надпись здесь

Официальный certbot совершенно не обязателен.
Можно использовать любую альтернативную реализацию, например, dehydrated.


Конечно, вопрос обновления файлов конфигурации вебсервера придется решать самостоятельно.

Кэп! Неужели это Вы? :)

Certbot является неотъемлемым компонентом этого сервиса. Можно, конечно, попробовать вариант установки для случая без shell access, но на данном сервере крутится несколько сайтов и ухудшение скорости работы такого варианта тоже оптимизма не добавляет… Так что пока этот вариант оставил на закуску.
Упущен один момент.

Не обязательно делать CSR там, где он будет ставится, например, можно сделать через openssl, а потом закинуть сертификат в IIS. Просто там два притопа три прихлопа с бубном надо:
openssl pkcs12 -export -out certificate_iis.pfx -inkey private-key.key -in certificate.crt
А иначе сертификат будет в хранилище, но IIS его не узрит.
Случай актуален для wildcard, по большому счёту.

https://www.ssl.com/how-to/create-a-pfx-p12-certificate-file-using-openssl/
https://certsimple.com говорит:
CertSimple isn't yet available in this country.

Руанда и Уганда — есть, России и Украины — нет (

Спасибо, довольно интересная статья. Я понимаю, что переход на https пр факту не гарантирует конфиденциальность, но тем не менее, направление правильное, на мой взгляд.

В _полном_ руководстве ожидал увидеть подробную информацию про HSTS и инструкции для плавного переезда сайта на HTTPS без потери ранка и индекса в популярных поисковиках.
Если сайт после перехода работает только по https, нужно обеспечить доступ по http для robots.txt и sitemap.xml. Поисковые роботы отказываются читать их по https.
А нет, не нужо обеспечивать доступ к http://example.com/robots.txt. А нужно в robots.txt в Host и Sitemap прописать https, раз это теперь основной адрес.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации