| |
| 2.2, eRIC (ok), 22:02, 17/10/2017 [^] [^^] [^^^] [ответить]
| +4 +/– |
 > Чтобы никто не догадался?
ага, могли бы mod_acme или mod_letsencrypt назвать
| | |
| 2.5, . (?), 22:42, 17/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> > mod_md
> Чтобы никто не догадался?
ManagedDomain. Чтобы тоже никто не догадался.
| | |
|
| 1.8, A (?), 23:00, 17/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Может для Nginx такое не просто появится, но и в поставку войдет? Наконец Symantec и компания зачешутся!
| | |
| |
| 2.13, Аноним (-), 01:40, 18/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну для nginx уже давно есть. Правда довольно муторно для настройки.
| | |
|
| |
| |
| |
| |
| 5.18, Онаним (?), 08:44, 18/10/2017 [^] [^^] [^^^] [ответить]
| –2 +/– | |
И чё, Facebook и vk гоняют PHP через Apache?
А WordPress - это не продакшн, 99% это любительские недосайтики по определению.
| | |
| |
| 6.45, _ (??), 17:07, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
>А WordPress - это не продакшн, 99% это любительские недосайтики по определению.
Да где ты видел чтоб софт юзали для того, для чего он делался? :-)
Зайди на любой он-лайн магазин, с нехилой вероятностью он окажется на WP+woocoоmmertZe :)
Хотя казалось бы что может быть _менее_ подходящим для этого?!
| | |
| |
| 7.66, пох (?), 13:58, 19/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Зайди на любой он-лайн магазин, с нехилой вероятностью он окажется на WP+woocoоmmertZe
это если открывается. А если вместо магазина какая-то херь про "b_cache_tag" - можешь быть уверены, это "cофт юзают для того, для чего он делается".
| | |
|
|
| 5.33, Аноним (-), 13:23, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Facebook, vk и куча овна на wordpress'е
Вот я прям как жопой чувствовал, что Facebook и vk на wordpress'е работают.
| | |
|
| 4.17, istepan (ok), 07:34, 18/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Неужели ПХП до сих пор кто-то пользуется на продакшн-серверах?
Пых слишком хорош, чтоб о нем так просто забыли.
Альтернативы?
Их нет.
| | |
| |
| 5.19, Вадик (??), 09:19, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
Плагины текут у него безбожно. Хоть бы кто и valgrind'ом прогнал бы...
| | |
| 5.21, лютый жабист__ (?), 09:24, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
>Пых слишком хорош, чтоб о нем так просто забыли.
Во(и)стену! Весь хайлоад крутится на пыхе+апач. Ещё тарантуул и вообще выходит непобедимо!
| | |
| |
| 6.47, _ (??), 17:56, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
На весь хайлоад работает менее 1% всех ЫненеГров. Вот к примеру ты - не работаешь.
Так что тебе, чтоб было что пожрать, приходится те же *сено*сайтики писать, но на жабе ... что есть особенно извращённая пытка :)
| | |
| |
| 7.72, лютый жабист__ (?), 07:33, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
>На весь хайлоад работает менее 1% всех ЫненеГров
Плох тот инженегр, который не хочет спать с генералом ;)
Вообще, я больше по backend. И ЗП у меня несколько выше, чем у пыхеров. В остальном да, разницы никакой, ггг.
| | |
|
|
|
|
|
| 2.20, Аноним (-), 09:23, 18/10/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
Ну, если говорить о "продакшн" серверах, то нгинкс там не более чем фронтенд. А значит и модуль к нему гоношить бессмысленно, один хрен он другими сервисами как новогодняя ёлка игрушками обвешен, одним больше, одни меньше...
| | |
| |
| 3.22, Аноним (-), 09:42, 18/10/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
Он ещё и терминирует https(ssl), так-что смысл в модуле в apache более сомнителен.
| | |
| |
| 4.23, пох (?), 10:12, 18/10/2017 [^] [^^] [^^^] [ответить]
| –5 +/– | |
> Он ещё и терминирует https(ssl)
сейчас модно внутренний траффик тоже пускать overssl и непременно http/2, чтоб в случае чего - хрен что просто так можно было посмотреть/поотлаживать.
И да, тут уже засветился минимум один горе-админ,который для такого траффика использует letsencrypt'овые сертификаты вместо самоподписанных с validity 10 лет. Тоже, видимо, чтоб жизнь медом не казалась.
А так-то модуль для летсенкрипта как раз правильно отражает _подходящую_ для него область применения - меганагруженные аж тремя посетителями в сутки сайтики на LAMP, которым ssl "нахрен не нужен, но пусть будет, халява же ж".
| | |
| |
| 5.49, _ (??), 18:00, 18/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>которым ssl "нахрен не нужен, но пусть будет, халява же ж".
пох, ты закусывай - середина недели же.
Сайтикам ssl нужен потому что без него гуголь бровсер начинает такие истерики, что хомячкофф разрывает на части.
Да - это единственная причина. Да - серьёзно! :-/
| | |
| |
| 6.54, пох (?), 19:01, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
>>которым ssl "нахрен не нужен, но пусть будет, халява же ж".
> Сайтикам ssl нужен потому что без него гуголь бровсер начинает такие истерики,
да лана, не читай вместо завтрака опеннетовские комменты,пока ничего не предвещает.
Вот сейчас специально ради тебя обновлю хромого (которым тестирую свою совсем-не-ssl-поделку) - и вряд ли увижу в адре...какойнахещеадрес, в строке поиска что-то кроме серой (i)
(опа - ну да, ну да)
Нет, если в нее потыкать пальчиком, она тебе скажет что все очень insecure, но редкий юзер туда жырным пальцом попадет, нарочно ж сделано крохотной, в отличие от больших-зеленых-блямб, а разбирать эти мелкие буковки и подавно не станет. Чтобы увидеть хотя бы перечеркнутый красным "http://" надо пять стилусов железных износить, тыкая по галкам settings. Ну да, попап-оконцев он у меня не открывает, канешна. (хм, и форма не спросила, точно ли я хочу слить ее всяму интернету - может, у меня хромой сломался? settings вроде сбрасываю регулярно. Нет, там, понятно, нет поля password)
А истерика и страница "произошло что-то очень страшное, нажмите сюда для котиков" будет, если я им зайду на сайт со своим startssl'евским сертификатом. Без всякой возможности вообще хоть как-то продолжить работу (для юзера, конечно, впрочем, горе-админы, не знающие даже, как внезапно выяснилось, для чего вообще нужны CA, тоже вряд ли справятся).
| | |
|
|
|
|
|
| 1.24, Ilya Indigo (ok), 10:53, 18/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Не то что прямо уж сильно нужно, но не помешает.
> mod_md
Название конечно..,
Чем их название mod_le не устроило?
А вайлдкарды, по dns оно сможет регистрировать?
Вот у меня вопрос, НЕ холивара и хайпа ради, на офф форуме, пока, не решился задать, из-за моего английского.
Допустим мне, да и не только мне, нужна только domain validation (DV), про расширенную (EV) пока не говорю, хотя le только с DV и работает.
почему бы просто, не создавать самоподписанный сертификат, причём на любые домены, к которым есть доступ для добавления DNS-записи, любым алгоритмом который поддерживают браузеры, и на любой срок, после чего "слепок" (modules) ключа поместить в специальную DNS-запись для соответствующих A и AAAA записей.
Браузер обнаруживает самоподписанный сертификат, обращается к этой DNS-записи, сверяет отпечатки, и если они соответствуют, то считает сертификат и соединение надёжными, а если DNS-запись установлена и она или пустая или не соответсвует сертификату, пускай даже валидный и подписанный УЦ, но она не соответствует этому сертификату, то браузер люто ругается и блокирует ресурс.
Вроде все счастливы были бы, и безопасность и скорость и надёжность на порядке выше, а УЦ, вроде LE, вообще были бы не нужны! Разве что только для EV и лентяям, которые привыкли просто платить и не думать.
Почему так не происходит, а вместо этого существует LE?
Какую кардинально-важную деталь я упускаю, кроме EV?
| | |
| |
| 2.25, Аноним (-), 11:11, 18/10/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
я в твоей схеме не понимаю, что помешает злоумышленнику, получившему контроль над твоей DNS записью, изменить и А запись, и слепок? В итоге - угоняем домен и у всех "светится" валидный сертификат.
| | |
| |
| 3.26, Ilya Indigo (ok), 11:22, 18/10/2017 [^] [^^] [^^^] [ответить]
| +4 +/– |
> я в твоей схеме не понимаю, что помешает злоумышленнику, получившему контроль над
> твоей DNS записью, изменить и А запись, и слепок? В итоге
> - угоняем домен и у всех "светится" валидный сертификат.
Если у Вас угнали доступы к DNS, то тут уже ничего Вам не поможет, кроме их восстановления у своего регистратора.
В классической схеме абсолютно аналогично, но это не проблема и даже не задача валидации!
| | |
| |
| 4.28, КО (?), 12:13, 18/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Если у Вас угнали доступы к DNS
У клиента же. Речь про то, что сертификат это способ проверки того, куда направляет DNS сервер. Если же проверка сертификата будет зависеть от того же DNS сервера, то сертификат нафиг не нужен - ибо MITM DNS в купе с MITM трафика браузера не "невероятная вещь".
| | |
| |
| 5.29, Ilya Indigo (ok), 12:23, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
Не совсем удачный вы выбрали ник.
> куда направляет DNS сервер
Куда в A или AAAA записях будет прописано, туда и отправит в любом случае.
Суть сертификата подтвердить что сервер именно тот, за кого себя выдаёт, а не кто-то левый, собственно это и может удостоверить соответствие слепка, хранимого в DNS слепку, полученному из сертификата сервера.
И как тут может вклиниться кто то левый (MITM), если 1 Он не будет обладать закрытым ключом и 2 Даже если он будет обладать валидным, но иным сертификатом, то слепок у него будет другой и он пойдёт лесом, в отличие от классической схемы.
Уже молчу про отсутствие проверок всяких откатов сертификата (SSLUseStapling) и прочего мусора, который тут просто не нужен.
| | |
| |
| 6.58, angra (ok), 21:04, 18/10/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Злоумышленник подсовывает _конкретному клиенту_ свои записи DNS, вместо твоих. И в этих записях будет и нужный IP и нужный слепок для фейкового сертификата по этому IP. От этого как раз и защищает классическая схема.
Но про неудачный ник ты правильно сказал, данный вариант далеко не для всех очевиден.
| | |
|
| 5.32, Аноним (-), 12:49, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
>>Если у Вас угнали доступы к DNS
> У клиента же. Речь про то, что сертификат это способ проверки того,
> куда направляет DNS сервер. Если же проверка сертификата будет зависеть от
> того же DNS сервера, то сертификат нафиг не нужен - ибо
> MITM DNS в купе с MITM трафика браузера не "невероятная вещь".
Сертификат DV не является средством проверки DNS. Его выдача при любой схеме так или иначе завязана на DNS, кто имеет может рулить записями, тот может и сертификат получить. Без вариантов. Защитить от этого могут только EV-сертификаты.
| | |
| |
| 6.38, Ilya Indigo (ok), 14:53, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Защитить от этого могут только EV-сертификаты.
Я никогда не использовал EV-сертификаты, но полагаю, что от этого и они тоже не защитят.
Ведь если вместо EV-сертификата подсунуть валидный DV-сертификат, то браузер также примет соединение, и покажет замочек, хоть и без большой зелёной полоски.
Большинство пользователей и не обратят на это внимание, а если и обратят, то подумают что ничего страшного, ведь замочек-то есть.
Смысл от EV-сертификата будет только тогда, когда браузер будет знать, что к этому ресурсу можно обращаться только через EV-сертификат, посредством чего-то наподобие HSTS-списков.
| | |
| |
| 7.40, Аноним (-), 15:16, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Ведь если вместо EV-сертификата подсунуть валидный DV-сертификат, то браузер также примет
> соединение, и покажет замочек, хоть и без большой зелёной полоски.
> Большинство пользователей и не обратят на это внимание, а если и обратят,
> то подумают что ничего страшного, ведь замочек-то есть.
Ну это уже другая история. Можно сказать, что никакие сертификаты ни от чего не защитят, потому что пользователь, жаждя поскорее дорваться до прона, добавит левый сертификат в доверенные.
> Смысл от EV-сертификата будет только тогда, когда браузер будет знать, что к
> этому ресурсу можно обращаться только через EV-сертификат, посредством чего-то наподобие
> HSTS-списков.
Есть HPKP, и для него не имеет значения, халявный у тебя сертификат или платный.
| | |
|
| 6.73, КО (?), 08:59, 21/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
>Сертификат DV не является средством проверки DNS
и
>>куда направляет DNS сервер
это не одно и то же.
Хотспот в кафе может вместо 8.8.8.8 (подставьте любой адрес) направлять куда ему вздумается. И там www.вашлюбимыйбанк.com могут отресолвить в то, что им угодно.
Но для получения валидного сертификата этого не достаточно. Надо еще то же провернуть с доверенным центром сертификации.
| | |
|
|
|
| 3.30, пох (?), 12:35, 18/10/2017 [^] [^^] [^^^] [ответить]
| –7 +/– | |
да тут пичаль полная - клиент безнадежен, даже со второго раза до него не доходит.
ну вот такие люди у нас и идут в админы, других сто лет не делают.
| | |
|
| 2.31, Аноним (-), 12:43, 18/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> почему бы просто, не создавать самоподписанный сертификат, причём на любые домены, к которым есть доступ для добавления DNS-записи
DANE уже давно придумали. Но у него есть два недостатка: во-первых, он имеет смысл только при повсеместном использовании DNSSEC, а во-вторых, он ну очень сильно помешает УЦ торговать воздухом, даже сильнее, чем Let's Encrypt.
| | |
| |
| 3.34, пох (?), 13:35, 18/10/2017 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> он имеет смысл только при повсеместном использовании DNSSEC
он даже при повсеместном не имеет никакого смысла, потому что мы просто вернем юзеру not found на попытку запросить подписи. Ну или подпишем, чем мы хуже?
dnssec работает только пока у тебя твой ns - trusted, и ты уверен что корневые подписи не подменены (ибо тоже можно).
У обычного пользователя даже первый пункт отсутствует.
А если начать совать подписи ns в операционные системы (к чему все идет) - мы, скорее всего, быстренько вернемся к торговле воздухом.
Правильное же решение - в выкидывании на помойку истории всех "удостоверяющих центров", и замена их индивидуальным доверием пользователя каждому конкретному сертификату для каждого индивидуального сервера. Который может быть (для дополнительной малоэффективной защиты) подписан кем-то, но совершенно точно не должен меняться раз в неделю, как это заставляет всех делать letsdecrypt.
| | |
| 3.36, Ilya Indigo (ok), 14:45, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> DANE уже давно придумали.
DANE - это совсем другое, это механизм аутентификации, а не валидации.
| | |
|
| 2.44, XoRe (ok), 16:53, 18/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Какую кардинально-важную деталь я упускаю, кроме EV?
Провайдера клиента.
Провайдер может и DNS записи подменить и трафик до сайта спроксировать.
И будет у клиента валиднейший https до прокси провайдера, подтвержденный подписью в DNS.
| | |
| |
| 3.46, Ilya Indigo (ok), 17:29, 18/10/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> Какую кардинально-важную деталь я упускаю, кроме EV?
> Провайдера клиента.
> Провайдер может и DNS записи подменить и трафик до сайта спроксировать.
> И будет у клиента валиднейший https до прокси провайдера, подтвержденный подписью в
> DNS.
И как же эту "величественную" проблему решает классическая схема с УЦ?
| | |
| |
| 4.48, XoRe (ok), 17:58, 18/10/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
>>> Какую кардинально-важную деталь я упускаю, кроме EV?
>> Провайдера клиента.
>> Провайдер может и DNS записи подменить и трафик до сайта спроксировать.
>> И будет у клиента валиднейший https до прокси провайдера, подтвержденный подписью в
>> DNS.
> И как же эту "величественную" проблему решает классическая схема с УЦ?
За счет списка доверенных УЦ на клиенте.
Сертификат УЦ лежит на клиенте, клиент его не запрашивает через интернет каждый раз.
Следовательно, провайдер здесь не может просто так вклиниться и подсунуть свой сертификат.
Я согласен, что у доверенных УЦ есть свои минусы.
Но в вашей схеме серификат передается вообще по нешифрованным каналам - DNS.
Это сводит на нет все дальнейшее шифрование.
| | |
| |
| 5.55, Ilya Indigo (ok), 19:44, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> За счет списка доверенных УЦ на клиенте.
> Сертификат УЦ лежит на клиенте, клиент его не запрашивает через интернет каждый
> раз.
> Следовательно, провайдер здесь не может просто так вклиниться и подсунуть свой сертификат.
А что мешает провайдеру, получившему контроль над ДНС, зарегистрировать валидный сертификат и использовать его?
А также, что бы именно вклинится в трафик, а не просто подменить ресурс своим, провайдер должен обладать закрытым ключом сервера, а так он сможет лишь подменить сервер, как в моей, так и в классической реализации.
| | |
| |
| 6.59, angra (ok), 21:14, 18/10/2017 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> А что мешает провайдеру, получившему контроль над ДНС, зарегистрировать валидный сертификат и использовать его?
Ну пойди зарегистрируй(кстати, они подписываются, а не регистрируются) валидный сертификат на google.com. Расскажешь об успехах.
> А также, что бы именно вклинится в трафик, а не просто подменить
> ресурс своим, провайдер должен обладать закрытым ключом сервера, а так он
> сможет лишь подменить сервер, как в моей, так и в классической
> реализации.
Используется два соединения. Одно от тебя к провайдеру(злоумышленику), второе от провайдера к серверу. В твоей схеме это работает на ура, в классической не получится сделать первое соединение доверенным, браузер ругаться будет.
| | |
| |
| 7.61, Ilya Indigo (ok), 22:13, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> А что мешает провайдеру, получившему контроль над ДНС, зарегистрировать валидный сертификат и использовать его?
> Ну пойди зарегистрируй(кстати, они подписываются, а не регистрируются) валидный сертификат на google.com. Расскажешь об успехах.
Да без проблем, скидывайте доступы на их ДНС, и я через сабж получу подписанный серт, при условии если они не заметят слив и не перекроют мне доступ раньше.
Но из Хрома этим сертом всё равно не получится воспользоваться.
> Используется два соединения. Одно от тебя к провайдеру(злоумышленику), второе от провайдера
> к серверу. В твоей схеме это работает на ура, в классической
> не получится сделать первое соединение доверенным, браузер ругаться будет.
Стало ещё яснее.
А всё же если объединить обе схемы, то есть используя подписанный УЦ серт, и ДНС запись со слепком, и что бы браузер обнаружив её требовал и валидности серта и соответствие его слепку из ДНС, причём этот слепок не должен кешироваться у клиента, а запрашиваться у ДНС при каждом запросе, то такая схема была бы ещё надёжнее и защищала от левых УЦ.
И конечно же эту ДНС-запись в обязательном порядке должны запрашивать и учитовать все популярные браузеры.
| | |
| |
| 8.68, XoRe (ok), 17:21, 19/10/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Есть несколько другой вариант - CAA записи https www opennet ru tips 3028_ssl... текст свёрнут, показать | | |
|
|
|
| 5.56, Ilya Indigo (ok), 19:54, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Я согласен, что у доверенных УЦ есть свои минусы.
> Но в вашей схеме серификат передается вообще по нешифрованным каналам - DNS.
> Это сводит на нет все дальнейшее шифрование.
Ничего подобного!
Сертификат состоит из пары закрытого и открытого ключей.
Открытый ключ передаётся всегда всем и как угодно!
Закрытый ключ лежит только на сервере и он никому никогда не передаётся.
В ДНС прописан отпечаток ключа, а не сам ключ.
| | |
| |
| 6.67, XoRe (ok), 17:19, 19/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> В ДНС прописан отпечаток ключа, а не сам ключ.
Провайдеру ничего не мешает сгенерить серитифкат, а в DNS отдавать его слепок.
Если все ограничивается только ненадежным DNS, без дополнительных проверок чего-либо ещё, вам придется верить DNS на слово.
А что туда записать - технический момент.
| | |
|
|
| 4.50, XoRe (ok), 18:06, 18/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вообще есть технология HTTP Public Key Pinning, там в DNS прописываются отпечатки сертификатов.
Т.е. защита от подмены сертификата на другой, даже валидный.
Но там очень легко выстрелить себе в ногу так, что оторвет голову.
Если неправильно настроить, можно закешировать на клиентах запись о том, что ваш текущий сертификат - фигня.
И все, нужен новый сертификат.
| | |
| |
| 5.52, пох (?), 18:27, 18/10/2017 [^] [^^] [^^^] [ответить] | +1 +/– | мда, у нас сегодня парад анонов, где-то слышавших звон pkp не имеет ни малейшег... большой текст свёрнут, показать | | |
| |
| 6.69, XoRe (ok), 17:26, 19/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> pkp не имеет ни малейшего отношения к dns.
Да, неправильно написал.
Там заголовки в HTTP ответе.
> Если же ты платишь за них по $90 штучка (или по $800
> за EV), то тут у тебя начинаются некоторые проблемы
Если проект коммерческий и вышел на некоторую прибыль, 90$ - не проблема.
| | |
| |
| 7.70, пох (?), 18:42, 19/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Если проект коммерческий и вышел на некоторую прибыль, 90$ - не проблема.
обычно таким проектам по многим причинам приходится раскошеливаться на EV, а там 90 внезапно превращаются в около-900. И их уже выкидывать стопками ради очень сомнительного улучшизма могут разьве что "коммерческие проекты" размером с мордокнигу.
А для маргинального проектика с копеейчной прибылью, еле-еле покрывающей расходы, _еще_раз_ $90 за воздух - уже совсем лишняя трата.
А вот microsofтогуглегрызку - оно на халяву дается. Поэтому при попытке назойливо поинтересоваться, что это такое они о тебе сливают хозяевам - тебя ждет pkp'шный облом.
| | |
| |
| 8.74, XoRe (ok), 02:39, 22/10/2017 [^] [^^] [^^^] [ответить] | +/– | Маргинальному проектику зеленый свет в сторону let s encrypt А в крупных компан... текст свёрнут, показать | | |
|
|
|
| 5.57, Ilya Indigo (ok), 20:09, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Вообще есть технология HTTP Public Key Pinning, там в DNS прописываются отпечатки
> сертификатов.
> Т.е. защита от подмены сертификата на другой, даже валидный.
> Но там очень легко выстрелить себе в ногу так, что оторвет голову.
> Если неправильно настроить, можно закешировать на клиентах запись о том, что ваш
> текущий сертификат - фигня.
> И все, нужен новый сертификат.
Я так понимаю Вы имеете ввиду HTTP Public Key Pinning (HPKP).
Это тоже не то, так как она, как Вы ране упомянули, кеширует у клиента отпечаток ключа, не давая возможности, до истечения срока кеша, изменить сертификат самому серверу, что очень не удобно.
Мне кажется это лишнее и ненужное действе. Не нужно кешировать слепок ключа, его нужно при каждом обращении сверять с ДНС, что бы сервер мог, при желании, хоть каждый день их менять, и при этом не у кого их не подписывать в ограниченном количестве. А пользователь будет уверен, что он общается с этим сервером.
А если клиент, то есть администратор ресурса, не доверяет своему собственному регистратору домена, то тут уже ничего не поможет, да и классическая схема от этого не защищает.
| | |
| |
| 6.62, Аноним (-), 23:07, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> не давая возможности, до истечения срока кеша, изменить сертификат самому серверу, что очень не удобно.
Не совсем так. Просто о замене сертификата надо побеспокоиться заранее, и запинить два публичных ключа — текущий и следующий, для которого сертификат ещё не выписан.
> его нужно при каждом обращении сверять с ДНС
Это именно то, что делает DANE. И DNS тут является слабым звеном, потому что для DNSSEC сильная криптография всё ещё встречается редко.
| | |
|
|
| 4.51, пох (?), 18:10, 18/10/2017 [^] [^^] [^^^] [ответить]
| –4 +/– | |
ты все же феноменально тyпой. То есть ладно, еще - быть админом но не понимать и не знать элементарного, тыщи этих недоучек. Но еще и делать глубокомысленные выводы из своего незнания?
Да, именно эту проблему - возможность mitm тем, кто контролирует каналы или dns, и только ее - решает УЦ и не решает https сам по себе. Именно для этой цели и придумана вся технология. Как можно этого не понимать, и при этом работать в IT - вообще в голове не укладывается.
Нет, это просто п-ц какой-то...
| | |
|
|
|
| 1.27, Аноним (-), 12:12, 18/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
осталось написать модуль админки под это в виде mod_mdadm (with zfs support)
| | |
| |
| 2.37, Andrey Mitrofanov (?), 14:50, 18/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Почему не сделать выдачу на пол/целый год?
В маркетинге сказали, что, мол, чем больше они за нами бегают, тем лучше Товар. Они-то знают!!
| | |
| |
| |
| 4.53, пох (?), 18:39, 18/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> %) "Как научиться про[полимеры]вать ключи и перестать беспокоиться.
> Опера-балет в двух актах, коротенько."
обрати только внимание - правдивый ответ - во втором акте.
"мы таким образом *заставим* вас использовать [нашу] автоматику" (запудрив вам мозги про беспокойство о просере ключей)
Соответственно - лишим вас возможности не хранить нешифрованные ключи на сервере, а ваших пользователей - доверять вашему _сертификату_, а не только нашей подписи под ним - для чего, полагаю, все и затеяно на самом деле.
Ну и попутно заставим либо исполнять свои кривые скрипты, либо вообще втыкать в веб-сервер наши модули - а что они там делают (и что будет делать версия x.y.z+1 ) - тебе знать необязательно. Но это так, побочная фишка, скорее всего.
| | |
|
|
|
|
