LINUX.ORG.RU

Халявные сертификаты для нищебродов без гемора. LetsEncrypt вместо Wosign и их подводные камни.

 , , ,


1

4

Салам Алейкум, братухи.

P.S. Читаем до конца, тут Вам не толксы.
P.P.S. Прошу проверить работоспособность на MS Outlook с IMAP, если есть такая возможность.


Недавно LetsEncrypt перешла в бету и теперь доступна всем публично. Очевидно, что многие об этом даже не знали, т.к. в новости ЛОРа принято писать о IT-феминистках, скандалах и игрулях, а не о реально важных вещах и технологиях. Но речь в этом треде пойдёт не деградации ЛОРа и попустительской редакционной политике.

Суть LetsEncrypt в том, чтобы автоматически генерировать ВАЛИДНЫЕ (и подписанные глобальным CA) сертификаты.

https://letsencrypt.readthedocs.org/en/latest/intro.html http://www.msxfaq.de/signcrypt/letsencrypt.htm

Сертификаты выдаются только на 3 месяца для предотвращения инцидентов безопасности.

Летсэнкрипт запускается в виде скрипта на сервера и не требует никакой регистрации на сайте. Скрипт работает так:
1. генерирует пару ключей (локально)
2. подписывает публичный ключ у ЦА (не путайте с ЦП! ЦА подтверждает Ваш ключ, чтобы быть уверенным в том, что ЦП не будет перехвачена спецслужбами или подменена обычным контентом)
3. получает от ЦА сертификат.
4. опционально автоматически настраивает апач и nginx домены на использование https и стойкой криптографии для безопасной передачи ЦП. Также автоматически ставится сервис в крон для автообновления сертификатов.

Не смотря на то, что закрытый ключ не покидает систему, Вы должны проверить наличие ФОРСИРОВАННОГо диффи-хельмана при установке https-соединения для генерации отказуемых симметричных сессионных ключей. Иначе, в случае утечки закрытого ключа, можно будет восстановить все симметричные ключи и расшифровать все сессии. Что может привести не только к нежелательной утечки конфиденциальной информации (ЦП), но и финансовых реквизитов.

Также учите, что спецслужбы по всему миру владеют закрытыми ключами ЦА, что позволяет им устраивать MitM-атаки, просматривать и подменять ЦП. Для критичных систем убедитесь, что Ваша система доверяет только Вашему ЦА. Также используйте плагины для браузера EFF SSL Observatory, HTTPS Enywhere, HTTP Nowhere для гарантии соответствия ЦА истинному подписавшему ЦА, а также для предотвращения перехода на HTTP-данные.

Сразу хочу предупредить, что LetsEncrypt, WoSign и StartSSL Free не поддерживаются IE6 и устаревшими системами! Также будут проблемы с хромом и сафари на WinXP (они используют богомерзкий АНБшный CryptoAPI винды). Windows 7 (от IE8. по умолчанию) поддерживает все данные CA. Firefox поддерживает LetsEncrypt и Wosign с версии 1.0 (но реально проверял только с четвёртой). StartSSL в 4.0 и прочих древних FF может не поддерживаться.

Также учтите: если нужна поддержка legacy (например ie6), то надо отключить SNI (передача доменного имени до начала криптосессии), а также включить поддержку старых протоколов и алгоритмов шифрования.

Также могут возникнуть проблемы со старыми линуксами (curl и wget не будут работать без форсированного флага). Так например: В Ubuntu 12.04.5 (без обновлений, с обновлениями всё ок):
1. wget с LetsEncrypt НЕ работает.
2. curl с LetsEncrypt работает.
3. wget с wosign НЕ работает.
4. curl с wosign работает.
5. wget с startssl НЕ работает.
6. wget с startssl НЕ работает.

В CentOS 5.6:
1. wget с LetsEncrypt НЕ работает.
2. curl с LetsEncrypt НЕ работает.
3. wget с wosign НЕ работает.
4. curl с wosign НЕ работает.
5. wget с startssl НЕ работает.
6. wget с startssl НЕ работает.

Из этого всего могу дать следующие рекомендации:
0. Если есть бабки - покупайте платный сертификат в любом случае. Также платный сертификат можно купить на три года, что удобно для устаревшего серверного ПО (MS Exchange, например).
1. Если Вы - нищебродное днище, либо если Ваш проект не требует поддержки старого говна, то советую использовать LetsEncrypt.
2. Если у Вас ситуация аналогичная первой, но нет возможности постоянно обновлять сертификат (1. Вы используете морально устаревшие системы, например MS IIS на Windows Server, 2. используете НЕ для веба (jabber, почта и т.п.) 3. система изолирована внутри локальной сети ), то рекомендую использовать WoSign.
3. У Вас крупный проект или махровый ынтерпрайз, то однозначно лучше купить сертификат у нормального CA.
4. Если Вы используете Java или Pidgin, тогда необходимо покупать сертификат у нормального CA.
5. Если у Вас over9000 доменов (например, у Вас тумблер хостится) стоит задуматься о покупке wildcard сертификата.

Далее информация о поддержке LetsEncrypt (в скобках может дополнение о других сертификатах):
0. https://community.letsencrypt.org/t/which-browsers-and-operating-systems-supp...
1. Firefox. Как мимимум с 4.0 (возможно с 1.0) работает. (StartSSL в древних лисах работать не будет). Все современные лисы работают всеми CA.
2. Pidgin не работает (используйте startssl)
3. Thunderbird. Точно все современные версии на всех ОС (включая wosign. StartSSL в древних версиях не поддерживается)
4. IE и Edge. Минимум 8 версия для всех. IE6 точно не поддерживается, по IE7 в зависимости от условий. (со всеми CA)
5. Chrome и Cromium. Поддержка ОС аналогично встроенной ОС криптоапи (древние макоси, линуксы и винхп не будут работать ни с каким CA). (со всеми CA)
6. Safari на всех современных Apple-устройствах точно работает (со всеми CA).
7. Android точно работает с версии 4.2 со всеми . Версия 2.0.6 (Android browser 2.0.6 Webkit 530.17) точно НЕ работает.
8. Устройства Blackberry не работают со всеми CA.
9. Java не работает с letsencrypt.
10. WinPhone работает со всеми.
11. WinCE устройства любых версий НЕ работают со всеми.
12. Symbian НЕ поддерживает все CA.
13. Links работает аналогично curl (см. выше).
14. wget и curl могут не работать на старых системах (см. выше).

Для проверки устройств и серверов можете использовать следующие ресурсы:
https://dev.windows.com/en-us/microsoft-edge/tools/screenshots/#https://check... (IE6 тут врёт, не смотрите на него)
http://browsershots.org/ (тут линукс не работает. больше 7 скриншотов не выставляйте) http://netrenderer.de/index.php (тут IE тестируйте)


https://pirate-party.ru/ (подписан letsencrypt)
https://community.letsencrypt.org/ (подписан letsencrypt)
https://www.checkmyping.com/ (подписан wosign)
https://fkurz.net/ (подписан startssl)



Последнее исправление: maxcom (всего исправлений: 4)

Ответ на: комментарий от AnyGov_security

Для текущей схемы см. выше.

Хром вроде отсылает репорты, если на гугловый сайт подменили сертификат от доверенного CA. Не думаю, что возможно реализовать эту схему в общем случае. Например я себе на сайт настраивал Key Pinning, потом, конечно, все ключи потерял (на самом деле бэкапы можно выкопать, но мне лень) и сгенерил новые ключи и сертификаты. При этом всё легально и ничего не случилось.

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

onion + namecoin, если я правильно понял твою идею. Но в реальном мире это невозможно. Всегда идёт эволюция и побеждает то решение, которое более-менее совместимо с миллиардом существующих сайтов и программ.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

Поэтому сертификат ему подменят уже при первом посещении сайта и он ничего не узнает.

Если сертификат валидный, то его можно хоть по три раза на дню менять и от разных ЦА делать, юзер ничего не увидет.

И мотивации у него больше: получить данные кредитки, например.

Или, ещё хуже, подменить твоё ЦП на обычный контент.

AnyGov_security
() автор топика
Ответ на: комментарий от Legioner

Хром вроде отсылает репорты, если на гугловый сайт подменили сертификат от доверенного CA

Да, именно так оба инцидента и были спалены. Но это ТОЛЬКО для гуглосервисов.

Не думаю, что возможно реализовать эту схему в общем случае.

В чём проблема то? Только в хомяках и браузерописалетях. Всё можно уже сейчас реализовать в виде обычного расширения к браузеру.

более-менее совместимо с миллиардом существующих сайтов и программ.

Тогда извольте иметь гэбню, копрократию, анальный лок, и копроэкономику. А вообще это очевидно, я говорю про то, что с технической стороны проблем нет, и это делается уже сейчас на базе уже имеющихся технологий (по сути прикрутка нормального DNSа к тору и биткоину).

AnyGov_security
() автор топика
Ответ на: комментарий от Legioner

Этот сертификат будет обнаружен и в результате этого инцидента корневой сертификат CA будет отозван из всех браузеров.

И как он будет обнаружен? Если браузер будет молчать, а вредитель не признается, что вся инфа юзеров просматривается.

«Вовсю» в данном случае неприменимо. Это не «вовсю», а «попробовали и тут же получили по лбу».

CINNIC закрыт?

Посмотрит отпечаток сертификата LOR-овского сертификата, сравнит с отпечатком товарища из США, например и обнаружит подмену.

Бугагашечка. Ещё раз - единственная известная мне причина, по которой покупались сертификаты у СА - это чтоб юзеры не напрягались когда окошечко вылазит. Ты полагаешь эти юзеры что-то будут сверять?

И что ты будешь делать, когда тебе нужно будет самому заменить сертификат сайта? Обзванивать всех юзеров и заверять их, что всё правильно и тебя не взломали?

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

Stanson ★★★★★
()
Ответ на: комментарий от Legioner

Ты альтернативу-то опиши, я пока не понимаю тебя. Trusted CA это как демократия. Всем понятны проблемы, но лучшего решения не существует. Вот я захожу на https://linux.org.ru/ браузер получает некий самоподписанный сертификат. Как дальше надо действовать, чтобы иметь какую-то уверенность, что меня не прослушивает кто-либо? Я должен встретиться с макскомом, проверить его паспорт (а кстати как? Вдруг паспорт поддельный), сверить хеш ключа и работать с сайтом? Или ты предлагаешь другие варианты?

Например, поинтересоваться в других местах, а какой хэш должен быть у LOR и посмотреть, сопадает ли он.

Во всяком случае тебе будет настойчиво предложено проверить сертификат любым доступным образом, что не происходит вообще при использовании «Trusted» CA.

Stanson ★★★★★
()
Ответ на: комментарий от anonymous

Поэтому сертификат ему подменят уже при первом посещении сайта и он ничего не узнает.

Для этого вредитель должен быть как минимум уверен, что посещение первое. Иначе он спалится.

В случае же CA вредитель может в любой момент подменить сертификат, пользователь ничего не заметит.

на самоподписанный атаку может провести кто угодно, начиная с твоего соседа-кулхацкера?

Ещё раз. В случае самоподписанного сертификата всегда и везде юзера ткнут носом в то, что стоит проверить сертификат. И это уже проблемы юзера, ибо юзер уведомлён. А вот в случае с СА юзер даже не узнает, что что-то произошло.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Ну так прикрути к сайту HPKP и будет у тебя всё ровно то же, что ты хочешь, прямо сегодня. Если юзер хоть раз зашёл на сайт, браузер запомнит разрешённые ключи и не даст работать сайту при их смене.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Ну так прикрути к сайту HPKP и будет у тебя всё ровно то же, что ты хочешь, прямо сегодня. Если юзер хоть раз зашёл на сайт, браузер запомнит разрешённые ключи и не даст работать сайту при их смене.

Но зачем тогда вообще CA? :) Ну и насколько я помню, HPKP точно так же никак не защитит в случае, если перехвачен первый запрос от юзера. Только в случае HPKP + CA и MitM c левым сертификатом от CA юзер останется без какого-либо уведомления вообще.

Блин, я вообще говорю о том, что существующая ситуация с «Trusted» CA и поведением броузера (отсутствие какого-либо предепреждения и предложения проверить сертификат) приводит к тому, что при сотрудничестве CA со спецслужбами/корпорациями/вредителями и т.п. юзер вообще не заметит подмены сертификата. О каком нахрен шифровании в этом случае вообще можно говорить?

Эту проблему можно хотя бы попытаться решить, например, убрав вообще список «Trusted» CA из пакетов с клиентским софтом и пр., оставив вопрос доверия юзеру, или например всегда показывать окно на предмет предлагаемого сертификата вне зависимости, подписан ли сертификат CA или нет. Да, это не решит всех проблем, но это хотя бы будет fair play. Ну и юзвери понемногу начнут врубаться в тему с сертификатами и т.п. Если хоть пара процентов начнёт задумываться - уже хорошо.

Но с другой стороны, кто же тогда будет платить всяким СА бабки за подписывание сертификатов, если всё равно окошко «раздражающее пользователя» будет всплывать?

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

Но зачем тогда вообще CA? :)

Чтобы защищать от 99% атакующих, не имеющих возможности влиять на CA.

Ну и насколько я помню, HPKP точно так же никак не защитит в случае, если перехвачен первый запрос от юзера. Только в случае HPKP + CA и MitM c левым сертификатом от CA юзер останется без какого-либо уведомления вообще.

Это ничем не отличается от твоего варианта.

Блин, я вообще говорю о том, что существующая ситуация с «Trusted» CA и поведением броузера (отсутствие какого-либо предепреждения и предложения проверить сертификат) приводит к тому, что при сотрудничестве CA со спецслужбами/корпорациями/вредителями и т.п. юзер вообще не заметит подмены сертификата.

Если твой мозг положить в банку и подавать ему нужные данные — ты не заметишь подмены мира.

Можно говорить о том, чтобы проверять HPKP-ключи через независимый прокси-сервер, например с прикреплённым в браузере сертификатом. А выкидывать всё и заменять непонятно на что, причём худшее по ряду параметров, смысла 0. Впрочем ты на своём компьютере можешь это устроить, удалив из доверяемых всех CA.

Эту проблему можно хотя бы попытаться решить, например, убрав вообще список «Trusted» CA из пакетов с клиентским софтом и пр., оставив вопрос доверия юзеру, или например всегда показывать окно на предмет предлагаемого сертификата вне зависимости, подписан ли сертификат CA или нет. Да, это не решит всех проблем, но это хотя бы будет fair play. Ну и юзвери понемногу начнут врубаться в тему с сертификатами и т.п. Если хоть пара процентов начнёт задумываться - уже хорошо.

Нет, это не решит вообще никаких проблем. Таким браузером просто никто не будет пользоваться. Даже 2%. Даже 0.02%.

Но с другой стороны, кто же тогда будет платить всяким СА бабки за подписывание сертификатов, если всё равно окошко «раздражающее пользователя» будет всплывать?

Деятельность CA требует определённых расходов, им надо брать где-то деньги. Их цены вполне рыночные. Проблем тут никаких нет.

Legioner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.