Comments 81
А центр сертификации-то доверенный? Если нет, то все потуги могут оказаться бесполезными.
На странице на гитхабе, разработчики честно предупреждают, что в настоящее время СА тестовый и к использованию не готов.
Думаю, с ресурсами всех собравшихся спонсоров у этого проекта есть хорошие шансы на старт. По крайней мере, продукты Mozilla должны будут доверять)
Думаю, с ресурсами всех собравшихся спонсоров у этого проекта есть хорошие шансы на старт. По крайней мере, продукты Mozilla должны будут доверять)
Сначала кросс-подписывание с уже доверенным IdenTrust, позже планируют сами стать доверенными. Отсюда: twitter.com/letsencrypt/status/535473089929154560
UFO just landed and posted this here
С той разницей лишь, что бесплатно wildcard они не дают, и что выданный серт могут отозвать, если решат, что он начал использоваться в коммерческих целях.
DANE требует настройки DNSSEC и соответствующей поддержки клиентским софтом, которая пока слабенькая, в особенности по браузерам (в режиме «из коробки»).
Весьма спорное решение — просить пользователя запускать нечто, что будет менять конфиг его веб-сервера. А если я использую нетиповой конфиг, и оно уронит мой сервер?
проще было бы им тупо временно поднимать https-сервер на 443 порту… правда, это работало бы только для первого раза (пока не запущен основной сервер на нем же).
Если вы используете нетиповой сервер и оно уронит ваш сервер — это научит вас аккуратней обращаться с production-серверами. Что тоже хорошо!
Давайте еще раз с начала: есть некая тулза, которая написана неизвестно кем и протестирована на неизвестно каких конфигурациях. Например я использую nginx, и в конфиге у меня есть какая-то непротестированная ситуация, ну например location вложенный в другой location. вложенный в другой location. Что произойдет после запуска этого приложения?
В чем моя неаккуратность использования? Или вы не допускаете возможность того, что в агенте могут быть ошибки?
В чем моя неаккуратность использования? Или вы не допускаете возможность того, что в агенте могут быть ошибки?
Думаю, никто пока не знает, как это будет работать.
И думаю, мало для кого она подойдёт в таком формате, как это описано в статье.
Безотностительно этой спорной утилиты, начинание отличное же.
И думаю, мало для кого она подойдёт в таком формате, как это описано в статье.
Безотностительно этой спорной утилиты, начинание отличное же.
Вам и многим другим эта тулза не подойдет. Ее цель проста — сделать настройку SSL простой для 80% случаев. 20% остальных никто не отменял. И как и все остальное в этом мире, она основана на доверии. Не доверяете — не запускайте.
Изящно. Я потратил немало времени на то, чтобы разобраться со StartSSL. Впрочем, это скорее из-за нехватки опыта.
У меня после регистрации в первый раз в браузере не установился личный сертификат. Подозреваю, что в этом виноват Касперский, после выключения которого всё получилось. Во второй раз, кстати, StartCom даже не стали менять изначальное написание моего адреса, так что получилось даже лучше, чем ожидал.
Забавный случай произошёл позже, когда в списке возможных TLD был.москва, но не было .moscow. Отписал на certmaster, отправили в FAQ, где написано про требование наличия WHOIS. Ответил, что у этих двух TLD один общий WHOIS-сервер (кто бы мог подумать?), так пообещали через несколько дней всё-таки добавить .moscow. Вот уже с первых дней занимаюсь усовершенствованием сервиса :).
P.S. Парсер лох, удаляет пробел между «был» и ".москва".
Забавный случай произошёл позже, когда в списке возможных TLD был.москва, но не было .moscow. Отписал на certmaster, отправили в FAQ, где написано про требование наличия WHOIS. Ответил, что у этих двух TLD один общий WHOIS-сервер (кто бы мог подумать?), так пообещали через несколько дней всё-таки добавить .moscow. Вот уже с первых дней занимаюсь усовершенствованием сервиса :).
P.S. Парсер лох, удаляет пробел между «был» и ".москва".
Я, кстати, запорол сертификат свой, то ли ввел не то, то ли еще что-то. Восстановить, как я понимаю только за деньги?
У StartSSL есть геморрой с сертификатами для аутентификации в личном кабинете. Через два года сертификат истекает и стандартной процедурой описанной в FAQ является новая регистрация и письмо в саппорт с данными старой и новой учётки. Это как-то ненормально.
Я после этого ушёл на gogetssl, где годовой Comodo PositiveSSL стоит в районе $6. По-моему, разница с $0 в годичном периоде довольно незначительна, чтобы устраивать себе геморрой. К тому же, комодовский можно сразу на 5 лет выпустить.
Я после этого ушёл на gogetssl, где годовой Comodo PositiveSSL стоит в районе $6. По-моему, разница с $0 в годичном периоде довольно незначительна, чтобы устраивать себе геморрой. К тому же, комодовский можно сразу на 5 лет выпустить.
Не очень понял, а полученный сертификат можно будет использовать для подписывания сертификатов для доменов следующих уровней?
Просто бесплатный сертификат на домен можно сейчас получить и у StartSSL, но если хочешь подписать им поддомены свыше своего example.com, нужно заплатить.
Просто бесплатный сертификат на домен можно сейчас получить и у StartSSL, но если хочешь подписать им поддомены свыше своего example.com, нужно заплатить.
StartSSL как минимум с сентября: «Over Capacity»
Давно не «общался» с ними, использую самоподписанные, так что не в курсе. Печально.
Я буквально вчера выписывал себе новый Class 1 Intermediate, плюс обновлял существующие — всё работает нормально у них.
У них это периодически бывает, ещё по выходным до 10 утра МСК профилактика, а так в принципе работает.
Если я правильно понимаю код, то генерируемый сертификат не предназначен для подписания других сертификатов:
— tools.ietf.org/html/rfc5280#page-39
я на всякий случай задал вопрос по поводу поддоменов в Твиттере (хотя, думаю, таких вопросов там уже вагон)
cert.setExtensions([
{ name: "basicConstraints", cA: false },
{ name: "keyUsage", digitalSignature: true, keyEncipherment: true },
{ name: "extKeyUsage", serverAuth: true },
{ name: "subjectAltName", altNames: [{ type: 2, value: commonName }] }
]);
The cA boolean indicates whether the certified public key may be used to verify certificate signatures.
— tools.ietf.org/html/rfc5280#page-39
я на всякий случай задал вопрос по поводу поддоменов в Твиттере (хотя, думаю, таких вопросов там уже вагон)
Можно чуть подробнее с этого места? Допустим, я купил у СА сертификат для основного домена, у меня есть закрытый ключ и сертификат, подписанный вышестоящим центром, могу ли я им подписывать дальше поддомены своего домена?
В зависимости от того какой сертификат Вам выдан. askbow наглядно продимонстрировал опцию, которая отвечает за это в одном из генераторов. StartSSL например за денежку выдавал сертификат которым в дальнейшем можно было подписывать сертификаты для поддоменов.
хорошо, а как мне это проверить? сертификат у меня уже на руках.
Хотелось бы определить наличие такой возможности либо по какому-то полю в стандартном окошке свойств сертификата, либо командой openssl вывести требуемый набор полей и по нему понять, что я могу подписывать сертификаты «дальше по цепочке»
Хотелось бы определить наличие такой возможности либо по какому-то полю в стандартном окошке свойств сертификата, либо командой openssl вывести требуемый набор полей и по нему понять, что я могу подписывать сертификаты «дальше по цепочке»
А в чём проблема у StartSSL попросить сертификаты для всех нужных поддоменов? Я вот именно так и сделал.
Имхо с SSL — только одна проблема — цена. Все эти челенжи муть какая-то, с ними проблем будет больше чем с обычной процедурой получения и продления сертификата. Главное что бы был бесплатный и доверенный.
Да вообще говоря, в районе 5$ в год стоит SSL-сертификат, что ненамного дороже расходов на домен. Чем тратить время на подобные поиски халявы, можно лучше чего-нибудь полезного сделать :).
Если доменов 20 — это уже $100 минимум только на сертификаты. Уже есть смысл озаботиться оптимизацией расходов:)
Много раз встречал эту фразу про $5..10 за серт. Когда лез разбираться — ни wildcard за разумные деньги, ни даже честных $5 не находил. Да, если купить на 10 лет, то «удельный» ценник станет $5.95, но это если $59.5 разом заплатить. Про wildcard молчу, хотя выписывание их тратит столько же CPU — они всегда стоят дороже.
Поделитесь, где можно задешево и хорошо разжиться сертификатом?
Поделитесь, где можно задешево и хорошо разжиться сертификатом?
Wildcard — совсем другая тема :-)
Можно посмотреть gogetssl, например. Ну и вообще positivessl можно найти дешевле $5 при оплате за 2-3 года, 10 лет необязательно покупать.
Можно посмотреть gogetssl, например. Ну и вообще positivessl можно найти дешевле $5 при оплате за 2-3 года, 10 лет необязательно покупать.
ни даже честных $5 не находил
PositiveSSL
Позавчера как раз брал. Честные $4.99. Можно сразу на 5 лет, чтобы не париться с продлениями.
UFO just landed and posted this here
насколько я понял (не изучал информацию подробно), будут предлагаться только базовые (domain control validated) сертификаты.
EV-сертификаты, приносящие основную прибыль, остаются за общепризнанными СА.
EV-сертификаты, приносящие основную прибыль, остаются за общепризнанными СА.
А зачем эти EV-сертификаты вообще нужны?
Во всех нормальных браузерах (т. е. кроме IE) нельзя воткнуть свой CA, выдающий EV.
Если вы видели на, скажем, банковском сайте EV-сертификат, а потом там оказался обычный валидный не-EV, то это может означать поптыку MitM'а (с инъекцией фальшивого CA в доверенные).
Правда, никто не мешает пересобрать браузер при необходимости…
Если вы видели на, скажем, банковском сайте EV-сертификат, а потом там оказался обычный валидный не-EV, то это может означать поптыку MitM'а (с инъекцией фальшивого CA в доверенные).
Правда, никто не мешает пересобрать браузер при необходимости…
Читал — читал и так и не понял: закрытый ключ передаётся этому ЦС или нет.Только CSR и подпись сообщений, приватный ключ остается на сервере.
Потому как если да, то в топку такой ЦС.
Если нет то…
Вообще не понял, как этот скрипт собирается автоматически создавать DNS-записи при использовании внешнего DNS-хостинга.
В оригинале сказано
Т. е. перевод не очень корректный. Агент получает набор возможных способов подтверждения владения доменом, далее подтверждает как минимум одним способом. Может, например, создать rr в dns, а может дать доступ к специально сформированному файлу по заранее указанному пути.
Непонятно, как оно будет бороться с dns spoofing и cache poisoning, хотя текущие механизмы domain validation (dns rr, http resource & hostmaster email) от этого не защищены.
These are different ways that the agent can prove control of the domain. For example, the CA might give the agent a choice of either:
- Provisioning a DNS record under example.com, or
- Provisioning an HTTP resource under a well-known URI on example.com/
Along with the challenges, the Let’s Encrypt CA also provides a nonce that the agent must sign with its private key pair to prove that it controls the key pair.
The agent software completes one of the provided sets of challenges.
Т. е. перевод не очень корректный. Агент получает набор возможных способов подтверждения владения доменом, далее подтверждает как минимум одним способом. Может, например, создать rr в dns, а может дать доступ к специально сформированному файлу по заранее указанному пути.
Непонятно, как оно будет бороться с dns spoofing и cache poisoning, хотя текущие механизмы domain validation (dns rr, http resource & hostmaster email) от этого не защищены.
По мне так CA это в первую очередь огромная ответственность для хозяев CA, которые за это имею денежку. А в случае бесплатного CA кто будет переживать чтоб не скомпрометировали его? Будут рекламу у себя на сате крутить или пожертвования от неких «спонсоров» получать? Что произойдет, когда всплывёт факт компрометации CA? Кто за него отвечать будет?
Вы кто создает CA прочитали? Или сразу комментировать пошли?
«EFF при поддержке Mozilla, Cisco, Akamai, IdenTrust»
Что вам в списке «спонсоров» непонятно? Какое название незнакомо?
«EFF при поддержке Mozilla, Cisco, Akamai, IdenTrust»
Что вам в списке «спонсоров» непонятно? Какое название незнакомо?
Прошу прощения, так долго читал «суть», что забыл, что там в первых строчках было.
Спонсорство спонсорством, но всё же неясно, как коммерческие предприятия буду прилагать усилия по верификации личности подателя, если последний за это не платит.
Вспоминается, как покупался сертификат в своё время от одной известной компании в ЮАР, так они позвонили мне(!!) с просьбой указать доверенных лиц, которые бы могли подтвердить мою личность(!!) Это было бы очень смешно, если бы за эту прекрасную услугу не хотели $150. Что будет за бесплатно, можно только догадываться.
Вспоминается, как покупался сертификат в своё время от одной известной компании в ЮАР, так они позвонили мне(!!) с просьбой указать доверенных лиц, которые бы могли подтвердить мою личность(!!) Это было бы очень смешно, если бы за эту прекрасную услугу не хотели $150. Что будет за бесплатно, можно только догадываться.
Если у них все получится — будет круто. Хостинг провайдеры включаться в работу. Проект заточен на Интернет в целом, но некоторые подходы не очень радуют.
Пример:
Если у тебя простенькие сайт-визитка без авторизации пользователей. Контора платит за него 180 рублей в месяц и все довольны.
Под этим соусом популярные веб-браузеры внедрят фичу — сайт не надёжен, потому что не https… так же, как сделали с Adobe Flash Player и JRE.
И для обычных пользователей будет геморой тыкать во что-то типа «Разрешить и сохранить» или «Продолжить» (на свой страх и риск).
Пример:
Если у тебя простенькие сайт-визитка без авторизации пользователей. Контора платит за него 180 рублей в месяц и все довольны.
Под этим соусом популярные веб-браузеры внедрят фичу — сайт не надёжен, потому что не https… так же, как сделали с Adobe Flash Player и JRE.
И для обычных пользователей будет геморой тыкать во что-то типа «Разрешить и сохранить» или «Продолжить» (на свой страх и риск).
Сейчас современный хром показывает, что сайт ненадежен, если какой-нибудь из сертификатов в цепочке использует sha1With*. Например, это относится к любимому банками thawte Extended Validation SSL CA (sha1WithRSAEncryption). Что уж говорить о том, что некоторые корневые CA используют md5WithRSAEncryption.
Может просто суппорты CA нужно завалить жалобами на WithRSA?
Пока мы не реагируем — они свято уверены, что у них всё хорошо…
Пока мы не реагируем — они свято уверены, что у них всё хорошо…
С RSA проблемы пока нет вообще. По md5/sha1 я тоже несколько перегнул.
Практическая атака 2008 на CA, подписывающие с использованием md5WithRSAEncryption и предсказуемым serial (на примере rapidssl) стоила порядка 2 дней и 21k$ ресурсов (200 PS3 + <1k$ на покупку сертификатов). В результате исследователи получили подписанный доверенным intermediate ca фальшивый ca, который может подписывать сертификаты для любых сайтов. После публикации информации по этому исследованию в конце 2008 CA перестали использовать md5 для новых сертификатов.
Эта атака не работает для sha1* и самоподписанных (в том числе корневых) сертификатов с md5*. При этом, ca должны быть готовы к переходу на sha2 если атака станет ощутимо ближе к практической реализации, чем сейчас. Догадываюсь, что это может быть требование регулирующих органов после примера с md5*.
Но момент, когда подбор коллизии sha1 будет стоить относительно дешево приближается. И Google с Mozilla Foundation чешутся об этом заранее, что выглядит разумным.
Интересные оценки есть здесь (в предположении, что закон Мура будет выполняться и дальше):
Оценка по деньгам может быть занижена на порядок, но она всё равно выглядит очень сурово. И это учитывает только работу на CPU.
Там же, в комментариях есть прекрасное:
Практическая атака 2008 на CA, подписывающие с использованием md5WithRSAEncryption и предсказуемым serial (на примере rapidssl) стоила порядка 2 дней и 21k$ ресурсов (200 PS3 + <1k$ на покупку сертификатов). В результате исследователи получили подписанный доверенным intermediate ca фальшивый ca, который может подписывать сертификаты для любых сайтов. После публикации информации по этому исследованию в конце 2008 CA перестали использовать md5 для новых сертификатов.
Эта атака не работает для sha1* и самоподписанных (в том числе корневых) сертификатов с md5*. При этом, ca должны быть готовы к переходу на sha2 если атака станет ощутимо ближе к практической реализации, чем сейчас. Догадываюсь, что это может быть требование регулирующих органов после примера с md5*.
Но момент, когда подбор коллизии sha1 будет стоить относительно дешево приближается. И Google с Mozilla Foundation чешутся об этом заранее, что выглядит разумным.
Интересные оценки есть здесь (в предположении, что закон Мура будет выполняться и дальше):
$2.77M in 2012
$700K by 2015
$173K by 2018
$43K by 2021
Оценка по деньгам может быть занижена на порядок, но она всё равно выглядит очень сурово. И это учитывает только работу на CPU.
Там же, в комментариях есть прекрасное:
It's also worth noting that everyone in the Bitcoin network is currently doing about 2^44 hash operations per second total. The network could produce a SHA-1 collision at that rate in about 18 hours
он наступит скоро, нужно только подождать
Как-то тут с безопасностью не ок.
Ну допустим, мы ломанули сайт некоего банка или там даже интернет-магазина. Ну как ломанули, просто как-то получили доступ к файловой системе сайта на запись. Подобрали пароль админа к cms или ftp, например. Дальше мы размещаем файлик, получаем сертификат, удаляем файлик. Всё, взлома сайта как бы и не было.
Дальше поднимаем шэдоу прокси и атакуем уже клиентов этого сайта. Подменяем hosts или поднимаем фейковую точку доступа, указываем на наш прокси и спокойно собираем пароли, ключи и куки. Так как сертификат есть и он валиден, ничего нигде не ругается. После сбора возвращаем всё как было. Следов атаки ноль, а пароли-то вот они.
С одной стороны, всеобщий https в эпоху открытых вайфаев и сормов — это благо.
С другой, конкретно такая автоматическая реализация это зло, дискредитирующее всю суть современной PKI. Нужно как минимум проверять наличие у сайта действующего сертификата и обязательно отправлять письмо админу домена на указанный в домене емейл.
Ну допустим, мы ломанули сайт некоего банка или там даже интернет-магазина. Ну как ломанули, просто как-то получили доступ к файловой системе сайта на запись. Подобрали пароль админа к cms или ftp, например. Дальше мы размещаем файлик, получаем сертификат, удаляем файлик. Всё, взлома сайта как бы и не было.
Дальше поднимаем шэдоу прокси и атакуем уже клиентов этого сайта. Подменяем hosts или поднимаем фейковую точку доступа, указываем на наш прокси и спокойно собираем пароли, ключи и куки. Так как сертификат есть и он валиден, ничего нигде не ругается. После сбора возвращаем всё как было. Следов атаки ноль, а пароли-то вот они.
С одной стороны, всеобщий https в эпоху открытых вайфаев и сормов — это благо.
С другой, конкретно такая автоматическая реализация это зло, дискредитирующее всю суть современной PKI. Нужно как минимум проверять наличие у сайта действующего сертификата и обязательно отправлять письмо админу домена на указанный в домене емейл.
Не очень понимаю, что мешает сделать тоже самое с любым другим центром сертификации? В том же StartSSL авторизация происходит примерно по тому же пути только вручную. Автоматизация тут не причем, лишь сэкономит время злоумышленнику также как и владельцу.
Итого получается DV-only не комильфо и лучше такие магазинчики обходить стороной
Тем, что в случае startssl всё-таки есть человек, который, ну, удивится запросу на сертификат для google.com или там examplebank.ru с мыла sdh34hsadfg@hotmail.com. Плюс куча следов остаётся.
Проект интересен, но не нов (в желании обеспечить бОльшую доступность SSL сертификатов). Выше уже упоминали CAcert.org — не будучи поддержанный вендорами браузеров, он все же был включен в некоторые дистрибутивы открытых OS, однако и из большинства значимых его в концов исключили: en.wikipedia.org/wiki/CAcert.org#Inclusion_status. Причины: подозрения/обвинения в том, что упрощенная система получения сертификатов приводит к использованию для фишинга и т.п.
Так и здесь — палка о двух концах.
Так и здесь — палка о двух концах.
Бесплатные ssl это замечательно!
Куча мелких сайтов висящих на шаред хостингах правда переходить не станет, так как для https нужен выделенный ip.
Куча мелких сайтов висящих на шаред хостингах правда переходить не станет, так как для https нужен выделенный ip.
так как для https нужен выделенный ip.Не обязательно
nginx.org/ru/docs/http/configuring_https_servers.html
Ищите SNI
о, полезная инфа.
сенкс!
сенкс!
Только нужно учитывать, что SNI не поддерживается любым Internet Explorer и Safari на Windows XP, а также любым браузером на Android 2, который использует HTTPS-стек от ОС (например, кроме стандартного, ещё и Dolphin).
Если в первом случае ещё можно сказать посетителю, чтобы он не заходил в интернет с устаревших браузеров (для Windows XP последние версии Internet Explorer и Safari вышли в 2009 и 2012 году соответственно), то во втором случае для установки другого браузера может не быть свободного места + плохой user experience в целом. 10% Android-устройств всё ещё работает на Android 2.x. Как вариант, можно запустить сайт на HTTPS без SNI и сначала накопить достаточную статистику.
Если в первом случае ещё можно сказать посетителю, чтобы он не заходил в интернет с устаревших браузеров (для Windows XP последние версии Internet Explorer и Safari вышли в 2009 и 2012 году соответственно), то во втором случае для установки другого браузера может не быть свободного места + плохой user experience в целом. 10% Android-устройств всё ещё работает на Android 2.x. Как вариант, можно запустить сайт на HTTPS без SNI и сначала накопить достаточную статистику.
Кстати, про Chrome неправильно написано: Chrome (Windows-версия также поддерживает SNI только на Vista и выше). На самом деле поддерживает на XP с версии 6, а ведь она вышла 4 года назад.
Сегодня на волне информации о получении Let's Encrypt'ом кросс-подписей проверил текущую версию клиента. Все работает, однако сертификаты по прежнему выдаются с CN = happy hacker fake CA. Ждем официального старта, т.е. 16 ноября.
Sign up to leave a comment.
SSL-сертификаты: всем, каждому, и пусть никто не уйдёт обиженным