Comments 53
Исчерпывающая и очень полезная статья. Большое спасибо за перевод!
UFO landed and left these words here
HTTP Public Key Pinning (HPKP),

Пациент скорее мёртв, чем жив.
и что в примерах используются 2048-битные RSA-ключи

Там это пояснено- промежуточные ключи всё равно часто 2048 битные, и оверхед на 4096 весьма большой.
П.С. Это ответ на комментарий выше.
UFO landed and left these words here
У нас есть разные ключи — RSA-4096, ECC на одной кривой, ECC на другой кривой, NTRU и т.д. — и подпись считается действительной только если выполнена на всех ключах.

И коннект на мобильном будет идти секунд 30.
Ну, защита ключей от кражи, в т.ч. хостингом — уже другая проблема, которую тоже надо решать соответственно.

LE её решает сильно ограниченным сроком выдачи сертификата. А вот как быть, если скомпрометируют ваш вечный, как я понимаю, набор ключей- для меня загадка.
Пользователь может и выбрать, сервисы с какими длинами ключей использовать.

Под пользователем вы имеете в виду владельца сайта? А то странно читать про пользователей, выбирающих сайты по длине ключа.
Но даже если не выберет — когда ключ скомпрометируют

Суть в том, что к тому времени сертификаты будут просрочены. Поэтому и пишут, что 4096 битные ключи- ненужный оверхед на данный момент.
UFO landed and left these words here
Если только на совсем слабых или древних, но едва ли под них будет соответствующее ПО.

Не факт.
Никак. Просто не допускать этого.

Хорошая отмазка. Так можно вообще обмениваться ключом для AES, главное не допускать его попадания в неблагонадёжные руки.
Алгоритм взлома RSA есть, технологии использования алгоритма есть → RSA ненадёжен.

Алгоритм взлома любого шифра, кроме одноразовых блокнотов, есть: называется полный перебор.
UFO landed and left these words here
Откуда на нормальном аппаратном и программном обеспечении взяться тормозам?

От вычислений? Криптография- не быстрая вещь, что поделать. И тормозить будет не только клиент, но и сервер.
Про обмен ключом AES — лишнее, т.к. криптография нужна для защиты информации в ненадёжной среде.

И я про что. Даём всем один ключ AES, пускай шифруют трафик. А если вдруг ключ попадёт неблагонадёжному человеку- ваша вина, смотреть надо, кому даёте.
Но квантовые компьютеры уже создаются, например, притом точно неизвестно, как далеко уже зашли в этой области (информация, которую дают нам, может быть неполной).

Отлично, переходим на эллиптические кривые. Зачем в вашей связке уязвимый, по вашему мнению, RSA?
UFO landed and left these words here
Сколько нужно ключей, чтобы появились тормоза?

Больше ключей- больше тормозов, что очевидно.
Хм, а ведь из того коммента всё должно было быть понятно.

Да мне понятно, что в криптографии вы не разбираетесь. Ни один криптограф не предложил бы такую схему, которая имеет больше недостатков, чем достоинств.
UFO landed and left these words here
UFO landed and left these words here
А Вы либо троллите, либо не заинтересованы в безопасности.

Я весьма заинтересован в безопасности. Просто суть в том, что есть миллион способов наделать ошибок с криптографией. Да, я тоже не криптограф. Но я понимаю ограниченность своих знаний и то, что я ошибусь. И вы ошиблись, хоть я и не знаю где. А вы этого не понимаете.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Все эти оды за 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, примерно один раз, так как логи выдачи публичные, и увидев там свой сайт, его владелец обеспокоится и всё всплывёт наружу.
Не понял, о чём вы. Let's encrypt -> цепочка провайдеров/магистралей -> ваш сайт. Провести атаку может любой из цепочки. Владелец сайта, конечно, может заметить что кому-то выдали сертификат к его сайту (и без логов выдачи, которые вряд ли кто-то мониторит на постоянной основе, а просто получив репорт о фейковом сайте с валидным сертификатом), только сделать он с этим вряд ли что-то сможет, кроме как попросить LE отозвать зловредный сертификат. Ну и потом гадать, кто же это сделал из цепочки.
Провести атаку может любой из цепочки.

Не думаю, что это реалистично. Маршруты могут меняться в зависимости от нагрузки, так что только провайдер Let's encrypt и сайта будут стабильны.
но после таких приколов со стороны провайдера от него уйдут все адекватные и не очень пользователи. Никто не будет рисковать своей репутацией ради невнятной выгоды. Вот атака по этой схеме со стороны правительства возможна, но у него есть куча других путей.

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

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

Целостность

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

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

PS
Есть один издатель Ява-приложений (каталоги), я так и не смог заставить их связываться с центральным сервером через fiddler — приложение упорно ругается на нарушение конфендинциальности. Больше такого не встречал.
Какая-то дрянь уже научилась делать это самостоятельно в фоне?

Конечно, на ноутбуках некоторых фирм были сертификаты со всеми политиками применения в хранилище доверенных сертификатов. И это было даже не вредоносное ПО, а вполне легальный софт, идущий в комплекте с ноутом.
Скандал помню, но сам механизм установки доверенного сертификата там не описан. Скорее всего юзер тапает не читая на тулбокс окно.
В Windows, если там ничего не поменялось со времён XP, хранилище сертификатов это просто ветка в реестре. Имея администраторские права, можно по-тихому добавить туда своё сертификат. Если у пользователя активирован UAC, то можно запросить диалог повышения прав, например, при установке ПО, что не вызовет подозрений.
Правда для подписи системного кода, начиная с XP x64, нужен сертификат за подписью MS (никто не знает как это обойти?), но к нашему случаю это не относится.
Если у пользователя активирован 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 по возможности.
Let's Encrypt я установить не смог

LE- это не программа, а сервис в сети. Если не работает официальная утилита, то можно использовать одну из многих сторонних, API открыт.

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


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

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

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

Ударим автопробегом HTTPS-ом по бездорожью невежеству и разгильдяйству наших законотворцев...

Упущен один момент.

Не обязательно делать 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, раз это теперь основной адрес.
Only those users with full accounts are able to leave comments. Log in, please.