форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Проект Let's Encrypt представил модуль для http-сервера Apache"	+/–
Сообщение от opennews (??) on 17-Окт-17, 21:53
Некоммерческий удостоверяющий центр Let’s Encrypt, контролируемый сообществом и предоставляющий сертификаты безвозмездно всем желающим, представил (https://letsencrypt.org//2017/10/17/acme-support-in-apache-h...) выпуск mod_md 1.0 (https://github.com/icing/mod_md), модуля  к http-серверу Apache  для автоматизации (https://github.com/icing/mod_md/wiki) получения и обслуживания сертификатов с использованием протокола ACME (https://tools.ietf.org/html/draft-ietf-acme-acme-07) (Automatic Certificate Management Environment). При помощи mod_md можно упростить процесс сопровождения сертификатов на серверах с большим числом сайтов или в системах массового хостинга. При наличии mod_md пользователям  не нужно заботиться об обновлении сертификатов, модуль сам получит необходимые сертификаты в сервисе Let’s Encrypt при первом запуске, организует их загрузку в mod_ssl (указание директив SSLCertificate* не требуется)  и периодически будет обновлять сертификаты при приближении к истечению срока действия. Модуль mod_md  уже принят (https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/md/) в экспериментальную ветку Apache httpd и запланирован к бэкпортированию в стабильную ветку 2.4.x. Из нововведений экспериментальной ветки httpd также отмечается новая директива SSLPolicy (https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslpolicy), упрощающая корректную настройку параметров TLS, благодаря  выбору готовых типовых настроек вместо перечисления списка допустимых шифров. Предложено три базовых режима: modern - включение только самых передовых шифров, поддерживаемых в современных браузерах; intermediate - возможность отката на не самые современные, но не устаревшие шифры для старых клиентов; old - возможность использования устаревших шифров для таких систем, как Windows XP/Internet Explorer 6. URL: https://letsencrypt.org//2017/10/17/acme-support-in-apache-h... Новость: http://www.opennet.me/opennews/art.shtml?num=47403
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+10 +/–
Сообщение от Аноним (??) on 17-Окт-17, 21:53
> mod_md Чтобы никто не догадался?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+4 +/–
	Сообщение от eRIC (ok) on 17-Окт-17, 22:02
	> Чтобы никто не догадался? ага, могли бы mod_acme или mod_letsencrypt назвать
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	7. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+3 +/–
	Сообщение от Аноним (??) on 17-Окт-17, 22:57
	https://github.com/icing/mod_md/issues/46
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	3. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+13 +/–
	Сообщение от ZimniY (ok) on 17-Окт-17, 22:03
	mod_mod будет загадочнее
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
	Сообщение от . on 17-Окт-17, 22:42
	> > mod_md > Чтобы никто не догадался? ManagedDomain. Чтобы тоже никто не догадался.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+4 +/–
Сообщение от Уборщица on 17-Окт-17, 22:16
mod_markdown? лил
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–2 +/–
Сообщение от A on 17-Окт-17, 23:00
Может для Nginx такое не просто появится, но и в поставку войдет? Наконец Symantec и компания зачешутся!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
	Сообщение от Аноним (??) on 18-Окт-17, 01:40
	Ну для nginx уже давно есть. Правда довольно муторно для настройки.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	16. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от istepan (ok) on 18-Окт-17, 07:32
	certbot не сложен в настройке. Там на симлинках все.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

10. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–19 +/–
Сообщение от Онаним on 18-Окт-17, 00:35
Неужели Апачем до сих пор кто-то пользуется на продакшн-серверах?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+8 +/–
	Сообщение от Олег Михайлович Сиденко on 18-Окт-17, 01:22
	Ещё как! Покуда это единственный сервер в котором программисты могут сами себе реврайтить и пхп конфиги менять он будет жить.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–10 +/–
	Сообщение от SSHServerNode.jsGolangElixir... on 18-Окт-17, 01:29
	Неужели ПХП до сих пор кто-то пользуется на продакшн-серверах?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	14. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Аноним (??) on 18-Окт-17, 06:05
	social network
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	15. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Аноним (??) on 18-Окт-17, 07:25
	Facebook, vk и куча овна на wordpress'е
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	18. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–2 +/–
	Сообщение от Онаним on 18-Окт-17, 08:44
	И чё, Facebook и vk гоняют PHP через Apache? А WordPress - это не продакшн, 99% это любительские недосайтики по определению.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	45. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от _ (??) on 18-Окт-17, 17:07
	>А WordPress - это не продакшн, 99% это любительские недосайтики по определению. Да где ты видел чтоб софт юзали для того, для чего он делался? :-) Зайди на любой он-лайн магазин, с нехилой вероятностью он окажется на WP+woocoоmmertZe :) Хотя казалось бы что может быть _менее_ подходящим для этого?!
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	66. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от пох on 19-Окт-17, 13:58
	> Зайди на любой он-лайн магазин, с нехилой вероятностью он окажется на WP+woocoоmmertZe это если открывается. А если вместо магазина какая-то херь про "b_cache_tag" - можешь быть уверены, это "cофт юзают для того, для чего он делается".
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	63. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от SSHServerNode.jsGolangElixir... on 18-Окт-17, 23:17
	Facebook, Wikipedia и WordPress гоняют через HHVM
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	33. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Аноним (??) on 18-Окт-17, 13:23
	> Facebook, vk и куча овна на wordpress'е Вот я прям как жопой чувствовал, что Facebook и vk на wordpress'е работают.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–1 +/–
	Сообщение от istepan (ok) on 18-Окт-17, 07:34
	> Неужели ПХП до сих пор кто-то пользуется на продакшн-серверах? Пых слишком хорош, чтоб о нем так просто забыли. Альтернативы? Их нет.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	19. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Вадик (??) on 18-Окт-17, 09:19
	Плагины текут у него безбожно. Хоть бы кто и valgrind'ом прогнал бы...
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	21. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от лютый жабист__ on 18-Окт-17, 09:24
	>Пых слишком хорош, чтоб о нем так просто забыли. Во(и)стену! Весь хайлоад крутится на пыхе+апач. Ещё тарантуул и вообще выходит непобедимо!
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	47. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от _ (??) on 18-Окт-17, 17:56
	На весь хайлоад работает менее 1% всех ЫненеГров. Вот к примеру ты - не работаешь. Так что тебе, чтоб было что пожрать, приходится те же *сено*сайтики писать, но на жабе ... что есть особенно извращённая пытка :)
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	72. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от лютый жабист__ on 20-Окт-17, 07:33
	>На весь хайлоад работает менее 1% всех ЫненеГров Плох тот инженегр, который не хочет спать с генералом ;) Вообще, я больше по backend. И ЗП у меня несколько выше, чем у пыхеров. В остальном да, разницы никакой, ггг.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	20. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–3 +/–
	Сообщение от Аноним (??) on 18-Окт-17, 09:23
	Ну, если говорить о "продакшн" серверах, то нгинкс там не более чем фронтенд. А значит и модуль к нему гоношить бессмысленно, один хрен он другими сервисами как новогодняя ёлка игрушками обвешен, одним больше, одни меньше...
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	22. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+3 +/–
	Сообщение от Аноним (??) on 18-Окт-17, 09:42
	Он ещё и терминирует https(ssl), так-что смысл в модуле в apache более сомнителен.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	23. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–5 +/–
	Сообщение от пох on 18-Окт-17, 10:12
	> Он ещё и терминирует https(ssl) сейчас модно внутренний траффик тоже пускать overssl и непременно http/2, чтоб в случае чего - хрен что просто так можно было посмотреть/поотлаживать. И да, тут уже засветился минимум один горе-админ,который для такого траффика использует letsencrypt'овые сертификаты вместо самоподписанных с validity 10 лет. Тоже, видимо, чтоб жизнь медом не казалась. А так-то модуль для летсенкрипта как раз правильно отражает _подходящую_ для него область применения - меганагруженные аж тремя посетителями в сутки сайтики на LAMP, которым ssl "нахрен не нужен, но пусть будет, халява же ж".
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	49. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
	Сообщение от _ (??) on 18-Окт-17, 18:00
	>которым ssl "нахрен не нужен, но пусть будет, халява же ж". пох, ты закусывай - середина недели же. Сайтикам ssl нужен потому что без него гуголь бровсер начинает такие истерики, что хомячкофф разрывает на части. Да - это единственная причина. Да - серьёзно! :-/
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	54. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от пох on 18-Окт-17, 19:01
	>>которым ssl "нахрен не нужен, но пусть будет, халява же ж". > Сайтикам ssl нужен потому что без него гуголь бровсер начинает такие истерики, да лана, не читай вместо завтрака опеннетовские комменты,пока ничего не предвещает. Вот сейчас специально ради тебя обновлю хромого (которым тестирую свою совсем-не-ssl-поделку) - и вряд ли увижу в адре...какойнахещеадрес, в строке поиска что-то кроме серой (i) (опа - ну да, ну да) Нет, если в нее потыкать пальчиком, она тебе скажет что все очень insecure, но редкий юзер туда жырным пальцом попадет, нарочно ж сделано крохотной, в отличие от больших-зеленых-блямб, а разбирать эти мелкие буковки и подавно не станет. Чтобы увидеть хотя бы перечеркнутый красным "http://" надо пять стилусов железных износить, тыкая по галкам settings. Ну да, попап-оконцев он у меня не открывает, канешна. (хм, и форма не спросила, точно ли я хочу слить ее всяму интернету - может, у меня хромой сломался? settings вроде сбрасываю регулярно. Нет, там, понятно, нет поля password) А истерика и страница "произошло что-то очень страшное, нажмите сюда для котиков" будет, если я им зайду на сайт со своим startssl'евским сертификатом. Без всякой возможности вообще хоть как-то продолжить работу (для юзера, конечно, впрочем, горе-админы, не знающие даже, как внезапно выяснилось, для чего вообще нужны CA, тоже вряд ли справятся).
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

24. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+2 +/–
Сообщение от Ilya Indigo (ok) on 18-Окт-17, 10:53
Не то что прямо уж сильно нужно, но не помешает. > mod_md Название конечно.., Чем их название mod_le не устроило? А вайлдкарды, по dns оно сможет регистрировать? Вот у меня вопрос, НЕ холивара и хайпа ради, на офф форуме, пока, не решился задать, из-за моего английского. Допустим мне, да и не только мне, нужна только domain validation (DV), про расширенную (EV) пока не говорю, хотя le только с DV и работает. почему бы просто, не создавать самоподписанный сертификат, причём на любые домены, к которым есть доступ для добавления DNS-записи, любым алгоритмом который поддерживают браузеры, и на любой срок, после чего "слепок" (modules) ключа поместить в специальную DNS-запись для соответствующих A и AAAA записей. Браузер обнаруживает самоподписанный сертификат, обращается к этой DNS-записи, сверяет отпечатки, и если они соответствуют, то считает сертификат и соединение надёжными, а если DNS-запись установлена и она или пустая или не соответсвует сертификату, пускай даже валидный и подписанный УЦ, но она не соответствует этому сертификату, то браузер люто ругается и блокирует ресурс. Вроде все счастливы были бы, и безопасность и скорость и надёжность на порядке выше, а УЦ, вроде LE, вообще были бы не нужны! Разве что только для EV и лентяям, которые привыкли просто платить и не думать. Почему так не происходит, а вместо этого существует LE? Какую кардинально-важную деталь я упускаю, кроме EV?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–2 +/–
	Сообщение от Аноним (??) on 18-Окт-17, 11:11
	я в твоей схеме не понимаю, что помешает злоумышленнику, получившему контроль над твоей DNS записью, изменить и А запись, и слепок? В итоге - угоняем домен и у всех "светится" валидный сертификат.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	26. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+4 +/–
	Сообщение от Ilya Indigo (ok) on 18-Окт-17, 11:22
	> я в твоей схеме не понимаю, что помешает злоумышленнику, получившему контроль над > твоей DNS записью, изменить и А запись, и слепок? В итоге > - угоняем домен и у всех "светится" валидный сертификат. Если у Вас угнали доступы к DNS, то тут уже ничего Вам не поможет, кроме их восстановления у своего регистратора. В классической схеме абсолютно аналогично, но это не проблема и даже не задача валидации!
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	28. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
	Сообщение от КО on 18-Окт-17, 12:13
	>Если у Вас угнали доступы к DNS У клиента же. Речь про то, что сертификат это способ проверки того, куда направляет DNS сервер. Если же проверка сертификата будет зависеть от того же DNS сервера, то сертификат нафиг не нужен - ибо MITM DNS в купе с MITM трафика браузера не "невероятная вещь".
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	29. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Ilya Indigo (ok) on 18-Окт-17, 12:23
	Не совсем удачный вы выбрали ник. > куда направляет DNS сервер Куда в A или AAAA записях будет прописано, туда и отправит в любом случае. Суть сертификата подтвердить что сервер именно тот, за кого себя выдаёт, а не кто-то левый, собственно это и может удостоверить соответствие слепка, хранимого в DNS слепку, полученному из сертификата сервера. И как тут может вклиниться кто то левый (MITM), если 1 Он не будет обладать закрытым ключом и 2 Даже если он будет обладать валидным, но иным сертификатом, то слепок у него будет другой и он пойдёт лесом, в отличие от классической схемы. Уже молчу про отсутствие проверок всяких откатов сертификата (SSLUseStapling) и прочего мусора, который тут просто не нужен.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	58. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+2 +/–
	Сообщение от angra (ok) on 18-Окт-17, 21:04
	Злоумышленник подсовывает _конкретному клиенту_ свои записи DNS, вместо твоих. И в этих записях будет и нужный IP и нужный слепок для фейкового сертификата по этому IP. От этого как раз и защищает классическая схема. Но про неудачный ник ты правильно сказал, данный вариант далеко не для всех очевиден.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	60. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Ilya Indigo (ok) on 18-Окт-17, 22:00
	Благодарю! Понял.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	32. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Аноним (??) on 18-Окт-17, 12:49
	>>Если у Вас угнали доступы к DNS > У клиента же. Речь про то, что сертификат это способ проверки того, > куда направляет DNS сервер. Если же проверка сертификата будет зависеть от > того же DNS сервера, то сертификат нафиг не нужен - ибо > MITM DNS в купе с MITM трафика браузера не "невероятная вещь". Сертификат DV не является средством проверки DNS. Его выдача при любой схеме так или иначе завязана на DNS, кто имеет может рулить записями, тот может и сертификат получить. Без вариантов. Защитить от этого могут только EV-сертификаты.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	38. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Ilya Indigo (ok) on 18-Окт-17, 14:53
	> Защитить от этого могут только EV-сертификаты. Я никогда не использовал EV-сертификаты, но полагаю, что от этого и они тоже не защитят. Ведь если вместо EV-сертификата подсунуть валидный DV-сертификат, то браузер также примет соединение, и покажет замочек, хоть и без большой зелёной полоски. Большинство пользователей и не обратят на это внимание, а если и обратят, то подумают что ничего страшного, ведь замочек-то есть. Смысл от EV-сертификата будет только тогда, когда браузер будет знать, что к этому ресурсу можно обращаться только через EV-сертификат, посредством чего-то наподобие HSTS-списков.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	40. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Аноним (??) on 18-Окт-17, 15:16
	> Ведь если вместо EV-сертификата подсунуть валидный DV-сертификат, то браузер также примет > соединение, и покажет замочек, хоть и без большой зелёной полоски. > Большинство пользователей и не обратят на это внимание, а если и обратят, > то подумают что ничего страшного, ведь замочек-то есть. Ну это уже другая история. Можно сказать, что никакие сертификаты ни от чего не защитят, потому что пользователь, жаждя поскорее дорваться до прона, добавит левый сертификат в доверенные. > Смысл от EV-сертификата будет только тогда, когда браузер будет знать, что к > этому ресурсу можно обращаться только через EV-сертификат, посредством чего-то наподобие > HSTS-списков. Есть HPKP, и для него не имеет значения, халявный у тебя сертификат или платный.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	73. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от КО on 21-Окт-17, 08:59
	>Сертификат DV не является средством проверки DNS и >>куда направляет DNS сервер это не одно и то же. Хотспот в кафе может вместо 8.8.8.8 (подставьте любой адрес) направлять куда ему вздумается. И там www.вашлюбимыйбанк.com могут отресолвить в то, что им угодно. Но для получения валидного сертификата этого не достаточно. Надо еще то же провернуть с доверенным центром сертификации.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	30. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–7 +/–
	Сообщение от пох on 18-Окт-17, 12:35
	да тут пичаль полная - клиент безнадежен, даже со второго раза до него не доходит. ну вот такие люди у нас и идут в админы, других сто лет не делают.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	31. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
	Сообщение от Аноним (??) on 18-Окт-17, 12:43
	> почему бы просто, не создавать самоподписанный сертификат, причём на любые домены, к которым есть доступ для добавления DNS-записи DANE уже давно придумали. Но у него есть два недостатка: во-первых, он имеет смысл только при повсеместном использовании DNSSEC, а во-вторых, он ну очень сильно помешает УЦ торговать воздухом, даже сильнее, чем Let's Encrypt.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	34. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–2 +/–
	Сообщение от пох on 18-Окт-17, 13:35
	> он имеет смысл только при повсеместном использовании DNSSEC он даже при повсеместном не имеет никакого смысла, потому что мы просто вернем юзеру not found на попытку запросить подписи. Ну или подпишем, чем мы хуже? dnssec работает только пока у тебя твой ns - trusted, и ты уверен что корневые подписи не подменены (ибо тоже можно). У обычного пользователя даже первый пункт отсутствует. А если начать совать подписи ns в операционные системы (к чему все идет) - мы, скорее всего, быстренько вернемся к торговле воздухом. Правильное же решение - в выкидывании на помойку истории всех "удостоверяющих центров", и замена их индивидуальным доверием пользователя каждому конкретному сертификату для каждого индивидуального сервера. Который может быть (для дополнительной малоэффективной защиты) подписан кем-то, но совершенно точно не должен меняться раз в неделю, как это заставляет всех делать letsdecrypt.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	36. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Ilya Indigo (ok) on 18-Окт-17, 14:45
	> DANE уже давно придумали. DANE - это совсем другое, это механизм аутентификации, а не валидации.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	39. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Аноним (??) on 18-Окт-17, 15:12
	Зато в нём нет лишних сущностей, коей является УЦ.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	44. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
	Сообщение от XoRe (ok) on 18-Окт-17, 16:53
	> Какую кардинально-важную деталь я упускаю, кроме EV? Провайдера клиента. Провайдер может и DNS записи подменить и трафик до сайта спроксировать. И будет у клиента валиднейший https до прокси провайдера, подтвержденный подписью в DNS.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	46. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–2 +/–
	Сообщение от Ilya Indigo (ok) on 18-Окт-17, 17:29
	>> Какую кардинально-важную деталь я упускаю, кроме EV? > Провайдера клиента. > Провайдер может и DNS записи подменить и трафик до сайта спроксировать. > И будет у клиента валиднейший https до прокси провайдера, подтвержденный подписью в > DNS. И как же эту "величественную" проблему решает классическая схема с УЦ?
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	48. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+2 +/–
	Сообщение от XoRe (ok) on 18-Окт-17, 17:58
	>>> Какую кардинально-важную деталь я упускаю, кроме EV? >> Провайдера клиента. >> Провайдер может и DNS записи подменить и трафик до сайта спроксировать. >> И будет у клиента валиднейший https до прокси провайдера, подтвержденный подписью в >> DNS. > И как же эту "величественную" проблему решает классическая схема с УЦ? За счет списка доверенных УЦ на клиенте. Сертификат УЦ лежит на клиенте, клиент его не запрашивает через интернет каждый раз. Следовательно, провайдер здесь не может просто так вклиниться и подсунуть свой сертификат. Я согласен, что у доверенных УЦ есть свои минусы. Но в вашей схеме серификат передается вообще по нешифрованным каналам - DNS. Это сводит на нет все дальнейшее шифрование.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	55. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Ilya Indigo (ok) on 18-Окт-17, 19:44
	> За счет списка доверенных УЦ на клиенте. > Сертификат УЦ лежит на клиенте, клиент его не запрашивает через интернет каждый > раз. > Следовательно, провайдер здесь не может просто так вклиниться и подсунуть свой сертификат. А что мешает провайдеру, получившему контроль над ДНС, зарегистрировать валидный сертификат и использовать его? А также, что бы именно вклинится в трафик, а не просто подменить ресурс своим, провайдер должен обладать закрытым ключом сервера, а так он сможет лишь подменить сервер, как в моей, так и в классической реализации.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	59. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+2 +/–
	Сообщение от angra (ok) on 18-Окт-17, 21:14
	> А что мешает провайдеру, получившему контроль над ДНС, зарегистрировать валидный сертификат и использовать его? Ну пойди зарегистрируй(кстати, они подписываются, а не регистрируются) валидный сертификат на google.com. Расскажешь об успехах. > А также, что бы именно вклинится в трафик, а не просто подменить > ресурс своим, провайдер должен обладать закрытым ключом сервера, а так он > сможет лишь подменить сервер, как в моей, так и в классической > реализации. Используется два соединения. Одно от тебя к провайдеру(злоумышленику), второе от провайдера к серверу. В твоей схеме это работает на ура, в классической не получится сделать первое соединение доверенным, браузер ругаться будет.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	61. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Ilya Indigo (ok) on 18-Окт-17, 22:13
	>> А что мешает провайдеру, получившему контроль над ДНС, зарегистрировать валидный сертификат и использовать его? > Ну пойди зарегистрируй(кстати, они подписываются, а не регистрируются) валидный сертификат на google.com. Расскажешь об успехах. Да без проблем, скидывайте доступы на их ДНС, и я через сабж получу подписанный серт, при условии если они не заметят слив и не перекроют мне доступ раньше. Но из Хрома этим сертом всё равно не получится воспользоваться. > Используется два соединения. Одно от тебя к провайдеру(злоумышленику), второе от провайдера > к серверу. В твоей схеме это работает на ура, в классической > не получится сделать первое соединение доверенным, браузер ругаться будет. Стало ещё яснее. А всё же если объединить обе схемы, то есть используя подписанный УЦ серт, и ДНС запись со слепком, и что бы браузер обнаружив её требовал и валидности серта и соответствие его слепку из ДНС, причём этот слепок не должен кешироваться у клиента, а запрашиваться у ДНС при каждом запросе, то такая схема была бы ещё надёжнее и защищала от левых УЦ. И конечно же эту ДНС-запись в обязательном порядке должны запрашивать и учитовать все популярные браузеры.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	68. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
	Сообщение от XoRe (ok) on 19-Окт-17, 17:21
	> Стало ещё яснее. > А всё же если объединить обе схемы, то есть используя подписанный УЦ > серт, и ДНС запись со слепком, и что бы браузер обнаружив > её требовал и валидности серта и соответствие его слепку из ДНС, > причём этот слепок не должен кешироваться у клиента, а запрашиваться у > ДНС при каждом запросе, то такая схема была бы ещё надёжнее > и защищала от левых УЦ. > И конечно же эту ДНС-запись в обязательном порядке должны запрашивать и учитовать > все популярные браузеры. Есть несколько другой вариант - CAA записи. https://www.opennet.me/tips/3028_ssl_https_caa_cert_dns.shtml
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	71. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Ilya Indigo (ok) on 19-Окт-17, 20:06
	> Есть несколько другой вариант - CAA записи. > https://www.opennet.me/tips/3028_ssl_https_caa_cert_dns.shtml Этот вариант мне известен и уже применяется мной. Но, к сожалению, пока нет обязательного требования от всех УЦ, учитывать CAA-записи. :-( LE её конечно же учитывает, а какой-нибудь Восайн или Комодо могут и проигнорировать, да скорее так и делают.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	56. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Ilya Indigo (ok) on 18-Окт-17, 19:54
	> Я согласен, что у доверенных УЦ есть свои минусы. > Но в вашей схеме серификат передается вообще по нешифрованным каналам - DNS.   > Это сводит на нет все дальнейшее шифрование. Ничего подобного! Сертификат состоит из пары закрытого и открытого ключей. Открытый ключ передаётся всегда всем и как угодно! Закрытый ключ лежит только на сервере и он никому никогда не передаётся. В ДНС прописан отпечаток ключа, а не сам ключ.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	65. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
	Сообщение от Аноним (??) on 19-Окт-17, 09:07
	s/нешифрованным/ненадёжным/
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	67. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
	Сообщение от XoRe (ok) on 19-Окт-17, 17:19
	> В ДНС прописан отпечаток ключа, а не сам ключ. Провайдеру ничего не мешает сгенерить серитифкат, а в DNS отдавать его слепок. Если все ограничивается только ненадежным DNS, без дополнительных проверок чего-либо ещё, вам придется верить DNS на слово. А что туда записать - технический момент.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	50. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–1 +/–
	Сообщение от XoRe (ok) on 18-Окт-17, 18:06
	Вообще есть технология HTTP Public Key Pinning, там в DNS прописываются отпечатки сертификатов. Т.е. защита от подмены сертификата на другой, даже валидный. Но там очень легко выстрелить себе в ногу так, что оторвет голову. Если неправильно настроить, можно закешировать на клиентах запись о том, что ваш текущий сертификат - фигня. И все, нужен новый сертификат.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	52. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
	Сообщение от пох on 18-Окт-17, 18:27
	> Вообще есть технология HTTP Public Key Pinning, там в DNS прописываются отпечатки > сертификатов. мда, у нас сегодня парад анонов, где-то слышавших звон? pkp не имеет ни малейшего отношения к dns. И да, это защита от подмены сертификата на другой, подписанный настоящим Trusted Authority, но не твой. > Т.е. защита от подмены сертификата на другой, даже валидный. _после_ того, как ты каким-то чудом получил правильный хэш и сохранил его в браузере. Без всякого dns, банальным http заголовком. Понятно, что если ты гугль, а браузер хром, чудо осуществляется довольно легко (правда, тебе еще могут подменить сам хромой, но это уже сложнее). > Но там очень легко выстрелить себе в ногу так, что оторвет голову. это единственная верная фраза > Если неправильно настроить, можно закешировать на клиентах запись о том, что ваш > текущий сертификат - фигня. этого как раз сделать не особо-то получится. > И все, нужен новый сертификат. и вот этого, что характерно, тоже - и вот тут действительно выстрел себе в жoпу. Очень легко можно сделать так, что поменять свой валидный но немного запаленный сертификат не получится, потому что он гвоздиком прибит (а его, например, УЦ отозвал, потому что ты просохатил логин - или чем-то этому УЦ не понравился. Или после маски-шоу в датацентре неизвестно, сколько и у кого стало его копий). Полагается на этот случай прибивать гвоздиком не один, а сразу несколько - при этом второй и третий хранить где-то в надежном не подключенном к интернетам месте, и выводить на сервера только в случае факапа с первым. Опять же, если ты гугль, в этом нет никакой проблемы - сколько надо, столько сам себе заранее и выдал. Если же ты платишь за них по $90 штучка (или по $800 за EV), то тут у тебя начинаются некоторые проблемы, а startssl'я-то, который мог напечь тебе хоть сотню этих EV бесплатно, больше нет. Возможно, еще и это послужило истиной причиной его ликвидации. Поэтому, в реальном мире, pkp используется не для чего-то хорошего, а ровно наоборот - те самые, которым ничего не стоит ни добавить свои сертификаты вместе с суммами правильных прямо в исходный код, ни понавыпускать самим себе десяток запасных, если с первым что не так, защищают подобным образом свой траффик от изучения - угадай-ка, кто это у нас?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	69. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от XoRe (ok) on 19-Окт-17, 17:26
	> pkp не имеет ни малейшего отношения к dns. Да, неправильно написал. Там заголовки в HTTP ответе. > Если же ты платишь за них по $90 штучка (или по $800 > за EV), то тут у тебя начинаются некоторые проблемы Если проект коммерческий и вышел на некоторую прибыль, 90$ - не проблема.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	70. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от пох on 19-Окт-17, 18:42
	> Если проект коммерческий и вышел на некоторую прибыль, 90$ - не проблема. обычно таким проектам по многим причинам приходится раскошеливаться на EV, а там 90 внезапно превращаются в около-900. И их уже выкидывать стопками ради очень сомнительного улучшизма могут разьве что "коммерческие проекты" размером с  мордокнигу. А для маргинального проектика с копеейчной прибылью, еле-еле покрывающей расходы, _еще_раз_ $90 за воздух - уже совсем лишняя трата. А вот microsofтогуглегрызку - оно на халяву дается. Поэтому при попытке назойливо поинтересоваться, что это такое они о тебе сливают хозяевам - тебя ждет pkp'шный облом.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	74. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от XoRe (ok) on 22-Окт-17, 02:39
	> А для маргинального проектика с копеейчной прибылью, еле-еле покрывающей расходы, _еще_раз_ > $90 за воздух - уже совсем лишняя трата. Маргинальному проектику зеленый свет в сторону let's encrypt. А в крупных компаниях - да, трудновато будет уговорить перевести все на LE.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	57. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Ilya Indigo (ok) on 18-Окт-17, 20:09
	> Вообще есть технология HTTP Public Key Pinning, там в DNS прописываются отпечатки > сертификатов. > Т.е. защита от подмены сертификата на другой, даже валидный. > Но там очень легко выстрелить себе в ногу так, что оторвет голову. > Если неправильно настроить, можно закешировать на клиентах запись о том, что ваш > текущий сертификат - фигня. > И все, нужен новый сертификат. Я так понимаю Вы имеете ввиду HTTP Public Key Pinning (HPKP). Это тоже не то, так как она, как Вы ране упомянули, кеширует у клиента отпечаток ключа, не давая возможности, до истечения срока кеша, изменить сертификат самому серверу, что очень не удобно. Мне кажется это лишнее и ненужное действе. Не нужно кешировать слепок ключа, его нужно при каждом обращении сверять с ДНС, что бы сервер мог, при желании, хоть каждый день их менять, и при этом не у кого их не подписывать в ограниченном количестве. А пользователь будет уверен, что он общается с этим сервером. А если клиент, то есть администратор ресурса, не доверяет своему собственному регистратору домена, то тут уже ничего не поможет, да и классическая схема от этого не защищает.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	62. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Аноним (??) on 18-Окт-17, 23:07
	> не давая возможности, до истечения срока кеша, изменить сертификат самому серверу, что очень не удобно. Не совсем так. Просто о замене сертификата надо побеспокоиться заранее, и запинить два публичных ключа — текущий и следующий, для которого сертификат ещё не выписан. > его нужно при каждом обращении сверять с ДНС Это именно то, что делает DANE. И DNS тут является слабым звеном, потому что для DNSSEC сильная криптография всё ещё встречается редко.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	51. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–4 +/–
	Сообщение от пох on 18-Окт-17, 18:10
	ты все же феноменально тyпой. То есть ладно, еще - быть админом но не понимать и не знать элементарного, тыщи этих недоучек. Но еще и делать глубокомысленные выводы из своего незнания? Да, именно эту проблему - возможность mitm тем, кто контролирует каналы или dns, и только ее - решает УЦ и не решает https сам по себе. Именно для этой цели и придумана вся технология. Как можно этого не понимать, и при этом работать в IT - вообще в голове не укладывается. Нет, это просто п-ц какой-то...
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

27. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
Сообщение от Аноним (??) on 18-Окт-17, 12:12
осталось написать модуль админки под это в виде mod_mdadm (with zfs support)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от Аноним (??) on 18-Окт-17, 16:14
	Ага, и mod_luks.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

35. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
Сообщение от qwe (??) on 18-Окт-17, 14:06
Почему не сделать выдачу на пол/целый год?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	37. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	–1 +/–
	Сообщение от Andrey Mitrofanov on 18-Окт-17, 14:50
	> Почему не сделать выдачу на пол/целый год? В маркетинге сказали, что, мол, чем больше они за нами бегают, тем лучше Товар. Они-то знают!!
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	41. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+2 +/–
	Сообщение от Аноним (??) on 18-Окт-17, 15:19
	> Почему не сделать выдачу на пол/целый год? https://letsencrypt.org/2015/11/09/why-90-days.html
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	42. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 18-Окт-17, 15:46
	>> Почему не сделать выдачу на пол/целый год? > https://letsencrypt.org/2015/11/09/why-90-days.html %) "Как научиться про[полимеры]вать ключи и перестать беспокоиться. Опера-балет в двух актах, коротенько."
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	53. "Проект Let's Encrypt представил модуль для http-сервера Apac..."	+/–
	Сообщение от пох on 18-Окт-17, 18:39
	> %) "Как научиться про[полимеры]вать ключи и перестать беспокоиться. > Опера-балет в двух актах, коротенько." обрати только внимание - правдивый ответ - во втором акте. "мы таким образом *заставим* вас использовать [нашу] автоматику" (запудрив вам мозги про беспокойство о просере ключей) Соответственно - лишим вас возможности не хранить нешифрованные ключи на сервере, а ваших пользователей - доверять вашему _сертификату_, а не только нашей подписи под ним -  для чего, полагаю, все и затеяно на самом деле. Ну и попутно заставим либо исполнять свои кривые скрипты, либо вообще втыкать в веб-сервер наши модули - а что они там делают (и что будет делать версия x.y.z+1 ) - тебе знать необязательно. Но это так, побочная фишка, скорее всего.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема