Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 167
Отлично. Теперь помимо домена и хостинга нужно еще и сертификат покупать.
С другой стороны, возможно в связи с этим сертификаты хоть немного упадут в цене.
17 баксов в год — не так уж и много с другой стороны.
Можете скинуть в ЛС CA, в котором сертификаты столько стоят?
А чего ЛС-то, вот тут брал: rapidsslonline.com
Могу и по $3.20 подсказать: cheapsslsecurity.com/
OMG, оказывается и по 2.90 бывают. Я со своей ссылкой в пролете :)
wot считает репутацию этого сайта плохой почему-то… Вы сами-то их пробовали? А где по 2.90 есть?
Всё бы ничего, только вы забыли упомянуть что цена 2.90 доступна только при покупке сертификата на 5 лет.
А ведь есть вариант получить бесплатный сертификат, он вполне себе нормальный.
Да ладно. Ну, и как мне получить бесплатный сертификат для домена .tk?
От добра добра не ищут. И домен бесплатный и сертификат. Уж 100 рублей на домен можно найти, если понадобилось https. И да, почему нельзя получить сертификат для .tk?
На Хабре уже не раз обсуждалось
У меня без особых проблем оттуда два сертификата.
У меня без особых проблем оттуда два сертификата.
Дело не в цене, а в открытости интернета. Зависимость от какого-либо органа снижает независимость интернета. Представьте что вы проживаете в стране, денежные потоки которой блокирует SWIFT. Таким образом у вас остается меньше шансов запустить сайт, так как вам нужено приобрести сертификат.
Есть и бесплатные способы получения SSL-сертификата. Однако это не меняет того факта что веб станет менее открытым.
Есть и бесплатные способы получения SSL-сертификата. Однако это не меняет того факта что веб станет менее открытым.
А как в такой стране купить gtld? Через посредников за местную валюту по местным платежкам? Ну так и с сертификатами тоже самое.
Ну а если скажете что мол такому гипотетическому человеку и местячкового ctld будет достаточно, ну так мы можем предположить что в этом Интранете (да, да, это уже не Интернет, а Интранет какой-то) будут и свои СА.
Ну а если скажете что мол такому гипотетическому человеку и местячкового ctld будет достаточно, ну так мы можем предположить что в этом Интранете (да, да, это уже не Интернет, а Интранет какой-то) будут и свои СА.
Как раз таки наоборот, если они станут необходимы, то цена увеличится. Хотя и сейчас сертификаты являются идеальным примером платы за воздух…
Дело не в том, станут необходимы или нет. А в том, что спрос повысится, что сделает цену ниже. Законы рынка.
Из-за повышенного спроса цена растет.
Прежде чем рассуждать о законах рынка, неплохо бы их знать. Цена становится ниже при увеличении предложения, а при увеличении спроса она как раз поднимается.
Это в условиях ограниченного ресурса. Сертификатов же бесконечно много, кто-то поднимет цену — появится конкурент с меньшими запросами.
А если их бесконечно много, то они вообще ничего не стоят.
Именно!
Ну так самопальных сертификатов и так уже бесконечно много — их может сгенерировать любой. Соответственно и цена у них нулевая. Только такие сертификаты браузеры считают недоверенными.
А доверенными они считают сертификаты лишь некоторых известных им фирм. Список этих фирм — ресурс ограниченный и при возрастании спроса цена на сертификаты тоже поднимется, а не упадет, как считают некоторые юноши, находящиеся в плену метафизических идей.
А доверенными они считают сертификаты лишь некоторых известных им фирм. Список этих фирм — ресурс ограниченный и при возрастании спроса цена на сертификаты тоже поднимется, а не упадет, как считают некоторые юноши, находящиеся в плену метафизических идей.
А что в вашем понятии есть цена за воздух? Цена за информацию?
Сертификат — просто набор байт, который я могу сгенерировать и сам. Почему я должен платить за него деньги? Для защиты от MITM хватит и проверки владения доменом, которую WebMoney, Google, Yandex и вообще все проводят абсолютно бесплатно.
Самоподписанный сертификат виден в браузере как недоверенный.
Вот мы и добрались до истины — платный сертификат даёт возможность одеть «зеленые штаны». И более ничего, насколько я могу судить.
Недавно была статья, что как раз самоподписанные недоверенные по умолчанию сертификаты более безопасны, т.к. есть бОльшая вероятность, что секретный ключ только у владельца сайта (а не у АНБ) и в наличии повышенное внимание посетителя.
Недавно была статья, что как раз самоподписанные недоверенные по умолчанию сертификаты более безопасны, т.к. есть бОльшая вероятность, что секретный ключ только у владельца сайта (а не у АНБ) и в наличии повышенное внимание посетителя.
Если я правильно понимаю суть PKI, то ради зеленых штанов все и городится?
Интересно почитать, насколько предупреждения в браузерах посетителей повышают эффективность работы сайтов — и каких именно.
Пока что немного похоже на рекламу в блоках noscript, которую типа как можно таргетировать на самых прошаренных пользователей :))
Интересно почитать, насколько предупреждения в браузерах посетителей повышают эффективность работы сайтов — и каких именно.
Пока что немного похоже на рекламу в блоках noscript, которую типа как можно таргетировать на самых прошаренных пользователей :))
Информация здесь — не просто набор байтов из которых состоит сертификат. Вы платите за то, что за вас поручается авторитетный источник. Т.е. основная информация — это та, которую передаст СА юзеру о том, что ваш сайт защищен. Шире ж смотреть нужно.
Для хостинга скорее всего будет что-то вроде wildcard, один сертификат на все домены хостинга и да, скорее всего будет платной услугой. С другой стороны сертификат стоит 1500 рублей в год. И по хорошему его нужно покупать на все финансовые или использующие персональные данные проекты.
habrahabr.ru/post/127643/ вот кстати. Как я понял если нет какой то работы с деньгами прямо на сайте (например оплата идет через посредника) то бесплатной версии хватит.
10$ в год за сертификат для нормального проекта это мелочь. С другой стороны говоносайты не смогут обеспечить себя ими.
Так что я за. Открытые Wi-Fi сети становятся все более популярными, а безопасность страдает.
Так что я за. Открытые Wi-Fi сети становятся все более популярными, а безопасность страдает.
Зачем минусовать и спамить ссылкой?
www.namecheap.com/ssl-certificates/geotrust-ssl-certificates.aspx
Вот, один из вариантов. Вообще лучше это в пост добавить цены, а то некоторые думают, что все стоит по 50-100$
www.namecheap.com/ssl-certificates/geotrust-ssl-certificates.aspx
Вот, один из вариантов. Вообще лучше это в пост добавить цены, а то некоторые думают, что все стоит по 50-100$
Для персонального проекта, некоммерческого?
А тут не сказали что сертификат должен быть кем-то заверен. Может можно будет сгенерировать свой собственный сертификат, а если он не заверен, то будет выводится уведомление пользователю.
А что делать с MitM атаками?
А это пускай пользователь решает, доверят ли он самоподписанному (или подписанному неизвестным его браузеру/оси ЦА) сертификату.
А кто вообще в состоянии отличить самоподписанный сертификат автора сайта от самоподписанного сертификата MitM?
У кого есть открытый ключ автора сайта, полученный из доверенного источника.
Да, это логично.
А у «обычного пользователя» © какой может быть доверенный источник, помимо предустановленных в браузере/ОС RootCA? Он с автором сайта сходил на keysigning party? ;)
А у «обычного пользователя» © какой может быть доверенный источник, помимо предустановленных в браузере/ОС RootCA? Он с автором сайта сходил на keysigning party? ;)
Сходил к автору в офис. Или получил от автора нотариально заверенное письмо с дампом ключа. Или скопировал от кого-то кому доверяет и кто сходил или получил письмо.
Ну это понятно все, просто не очень применимо к обычным массовым пользователям.
С другой стороны, если речь идет о крупных важных сервисах (почта, социальные сети, и т.п.), то, в принципе, при регистрации на этом сервисе можно человеку пересылать сразу сертификат, чтобы он его добавил себе — тогда последующий MitM будет легко обнаружим.
Чего только не придумаешь, лишь бы не использовать RootCA от АНБ ;)
С другой стороны, если речь идет о крупных важных сервисах (почта, социальные сети, и т.п.), то, в принципе, при регистрации на этом сервисе можно человеку пересылать сразу сертификат, чтобы он его добавил себе — тогда последующий MitM будет легко обнаружим.
Чего только не придумаешь, лишь бы не использовать RootCA от АНБ ;)
можно человеку пересылать сразу сертификат,
Как вы его пересылать будете? И почему получатель должен ему поверить?
Потому, что человек только что зарегился на сервисе и только что получил письмо с ссылкой для подтверждения своего email.
Вклиниться уже на стадии регистрации?.. Хмм.
Вклиниться уже на стадии регистрации?.. Хмм.
Вклиниться уже на стадии регистрации?.. Хмм.
Например. Второй вариант — подменить содержимое письма. А если письмо подписано — то возникает вопрос о том, как проверить эту подпись, если публичному ключу автора мы еще не верим.
Тогда уж вообще неясно, не был ли заспуфлен DNS in the first place.
По-моему, из общих соображений тут нельзя обойтись без третьего доверенного лица.
Любая схема с третьим лицом подразумевает централизацию (привет, АНБ), а распределенная p2p схема… привет, bitcoin. Или namecoin?
По-моему, из общих соображений тут нельзя обойтись без третьего доверенного лица.
Любая схема с третьим лицом подразумевает централизацию (привет, АНБ), а распределенная p2p схема… привет, bitcoin. Или namecoin?
По-моему, из общих соображений тут нельзя обойтись без третьего доверенного лица.
Конечно. О том и речь, что вся суть этого вопроса — в том, кому именно доверять, поскольку хоть кому-то доверять придется.
а распределенная p2p схема… привет, bitcoin. Или namecoin?
Про такие схемы ничего не могу сказать, не разбираюсь в этой технологии.
Доверие в известных мне p2p схемах основано на вычислительном превосходстве большинства участников сети. Когда в совместно хранимой истории возникает новый факт, то он весьма быстро распространяется по сети и подписывается, после чего оспорить его становится тем труднее, чем больше совокупная вычислительная мощность сети.
Сейчас сеть Bitcoin фигачит 51 EFLOPS, тогда как суперкомпьютер-лидер top500 всего 0.055 EFLOPS, а ближайшие подобные сети, по-моему, сейчас набирают не более 10 EFLOPS
Сейчас сеть Bitcoin фигачит 51 EFLOPS, тогда как суперкомпьютер-лидер top500 всего 0.055 EFLOPS, а ближайшие подобные сети, по-моему, сейчас набирают не более 10 EFLOPS
Почтой России. Потому что нотариально заверен.
Потери в этом канале уже упали до нормального уровня? =)
Нотариальное же заверение… знаете, мокрую печать сейчас подделать труда не составляет. Сканер, бумага, на которой чернила не держатся, струйный принтер, 0.5-2 часа работы. Нотариальный бланк для свидельства подлинности подписи не требуется, насколько я знаю. И это все при условии, что вы доверяете нотариусу. И чем это лучше доверия известному CA?
Нотариальное же заверение… знаете, мокрую печать сейчас подделать труда не составляет. Сканер, бумага, на которой чернила не держатся, струйный принтер, 0.5-2 часа работы. Нотариальный бланк для свидельства подлинности подписи не требуется, насколько я знаю. И это все при условии, что вы доверяете нотариусу. И чем это лучше доверия известному CA?
Ладно, а мокрую печать с ключом, даже само наличие которого является секретом? ;)
По-моему, какое-нибудь заказное отправление первого класса с уведомлением (нужно подчеркнуть), все-таки доставляется хорошо. TCP, так сказать :)
По-моему, какое-нибудь заказное отправление первого класса с уведомлением (нужно подчеркнуть), все-таки доставляется хорошо. TCP, так сказать :)
Ладно, а мокрую печать с ключом, даже само наличие которого является секретом? ;)
В мокрую печать не верим, а вот shared secret — штука хорошая. Только требует надежного канала передачи… и тут мы возвращаемся к тому, с чего и начали. Напряженка у нас с дешевыми, безопасными, быстрыми, удобными и надежными каналами передачи.
Письменная корреспонденция довольно шустро и без потерь почти :)
Ну, если нотариально заверенным документам не доверять, то чему вообще в этом мире доверять можно?
Ну, если нотариально заверенным документам не доверять, то чему вообще в этом мире доверять можно?
Нет, как раз это именно то, что должны делать «обычные массовые пользователи». Ну, это примерно как посмотреть в лицо человеку, только в виртуальном мире.
Да зачем дамп, отпечатка достаточно.
Вопрос только, не треснет ли доверенный источник каждому пользователю безопасно передавать этот самоподписанный сертификат? В этом прелесть схемы с CA (при условии его добросовестности) — можно взять сертификат из любого источника и выяснить, можно ли ему доверять.
Тогда вся схема на смарку, ведь mitm атака подразумевает генерацию своего сертификата.
Когда внедрят DANE, сертификаты можно будет подписывать самому через DNSSEC.
Кроме того, всегда есть бесплатный startssl.com
Кроме того, всегда есть бесплатный startssl.com
Никто же не заставляет всех переходить на 2.0
Пусть тогда заодно и альтернативу современным CA придумают. Сервисы вроде StartSSL частично улучшают общее положение дел, но это все равно слишком коммерциализированная область.
Непонятна боль.
Никто ведь не отбирает у вас HTTP/1, пользуйтесь им.
Никто ведь не отбирает у вас HTTP/1, пользуйтесь им.
Все ведь догадываются что то что называется «HTTP 2.0» должно когда-нибудь заместить «HTTP 1.x».
А фраза
чем-то мне напоминает приёмы при закручивании гаек соответствующими организациями при продвижении закона о реестре запрещённых сайтов итд.
А фраза
Никто ведь не отбирает у вас
чем-то мне напоминает приёмы при закручивании гаек соответствующими организациями при продвижении закона о реестре запрещённых сайтов итд.
Ну а к тому времени, как начнут отбирать, рынок сертификатов может быть совсем другим. Или будет найдено решение, как все-таки заставить HTTP/2 работать без них. Или еще что-нибудь.
В интернете отказ от поддержки осуществляются медленно — знаете, сколько лет браузеры еще поддерживали Gopher?
В интернете отказ от поддержки осуществляются медленно — знаете, сколько лет браузеры еще поддерживали Gopher?
Вот типа выше пишут про wiki.mozilla.org/Security/DNSSEC-TLS-details
Сейчас вот в моде HTML5, но если вам все его фичи не нужны — HTML 4.01 отлично рендерится. В чем проболема? Стандарты «расширяются» а не замещаются. Единственный контрпример — IPv6, да и то по сугубо техническим, а не политическим, причинам.
Все ведь догадываются что то что называется «HTTP 2.0» должно когда-нибудь заместить «HTTP 1.x».
Ага, как IPv6 должно заменить IPv4, но что-то всё никак. Преимущественно вообще никак.
Что ж, в этом случае 'уполномоченным организациям' (из тех, что могут попросить себе у CA сертификат на любое имя) из коробки будет доступно прослушивание всего HTTP/2-траффика.
Сейчас им, конечно, делать это ещё проще, ведь большая часть трафика не зашифрована вообще.
Однако, с введением повсеместного TLS это общее больное место интернета исчезнет, и будет намного меньше стимулов развивать действительно безопасные способы коммуникации.
Сейчас им, конечно, делать это ещё проще, ведь большая часть трафика не зашифрована вообще.
Однако, с введением повсеместного TLS это общее больное место интернета исчезнет, и будет намного меньше стимулов развивать действительно безопасные способы коммуникации.
Ближайшее будущее, повсеместно наступил IPv6. Любое оборудование, поддерживающее IPv6, должно (ранее «MUST», сейчас «SHOULD») поддерживать IPSec для шифрования на сетевом уровне.
Поверх этого работает HTTP/2.0, и у него обязательно включен SSL, который используется для шифрования на уровне представления.
Вопрос: зачем столько шифрования, и когда вебостроители будущего договорятся, наконец, друг с другом?
Поверх этого работает HTTP/2.0, и у него обязательно включен SSL, который используется для шифрования на уровне представления.
Вопрос: зачем столько шифрования, и когда вебостроители будущего договорятся, наконец, друг с другом?
* Шифрование нужно для безопасности. Всюду где это не в ущерб быстродействию сети.
* IPv6 не придет в один момент
* HTTP/2.0 не придет в один момент
и самое главное
* IP используется не только для HTTP
* IPv6 не придет в один момент
* HTTP/2.0 не придет в один момент
и самое главное
* IP используется не только для HTTP
Вот-вот, «не в ущерб». Похожая ситуация: из IPv6 убрали контрольную сумму за ненадобностью. IP, более низкий уровень, уже считает контрольную сумму пакета, и незачем считать её дважды. Так и тут, зачем принуждать пользователей использовать SSL, если эта задача уже решена на более низком уровне?
И вообще, HTTP — протокол 7 уровня OSI, а SSL — 6-го (если я ничего не путаю). За каким чёртом HTTP должен знать, о том, какой более низкий слой его обеспечивает? Это что, чтобы сделать
Безусловно, IP используется не только для HTTP, но ведь и использовать IPSec для всех-вообще соединений никто не требует.
И вообще, HTTP — протокол 7 уровня OSI, а SSL — 6-го (если я ничего не путаю). За каким чёртом HTTP должен знать, о том, какой более низкий слой его обеспечивает? Это что, чтобы сделать
GET / HTTP/2.0 на localhost, мне нужно будет SSL поднимать?Безусловно, IP используется не только для HTTP, но ведь и использовать IPSec для всех-вообще соединений никто не требует.
IP, более низкий уровеньЧто-то я запутался, какой уровень более низкий по отношению к какому.
HTTP ничего не знает про SSL. Он просто себе бегает поверх него. Требование только в спецификации. Технически, сами понимаете, SSL не обязателен. Это как использование TCP вместо UDP для транспорта HTTP: на практике можно использовать любой, но спецификация рекомендует TCP, потому что он более надежный для подобных задач.
IPSec в IPv6 поддерживается на уровне стандарта, но не обязательно его включать. Его будут использовать как сейчас — для шифрования трафика между конечными точками.
Между «оборудование должно поддерживать» и «оборудование должно всегда включать» очень большая разница. Плюс шифрование на уровне IPSec вроде как осуществляется хостами (грубо — железками), а на уровне SSL между клиентом и сервером (софтинами).
Кэширующие сервера, распределённые кэширующие сервера. Всё решили похоронить.
Отчего же. Например cloudflare, а думаю что и все остальные крупные игроки, работает с ssl.
Или вы о чем то другом?
Или вы о чем то другом?
Нешифрованные статические данные легко кешировать за счет их неизменяемости. В случае шифрования одна и та же статическая страница, зашифрованная для разных пользователей, будет представлять из себя разный набор байт, который не очевидно как кешировать.
Ну я не говорю что это как два пальца об асфальт.
У того же cloudflare \ к которому я вообще никакого отношения не имею\ план с ssl стоит от 20 баксов в месяц, а без него можно и бесплатно получить. Хотя там за те 20 зеленых еще немного функционала.
У того же cloudflare \ к которому я вообще никакого отношения не имею\ план с ssl стоит от 20 баксов в месяц, а без него можно и бесплатно получить. Хотя там за те 20 зеленых еще немного функционала.
Поправьте меня, если я не прав, но cloudflare либо шифрует изначально незашифрованный вашим сервисом ответ, либо операция идет по принципу
А что делать всяким реверсивным прокси, которые никаких деталей про ваш сертификат, в отличие от cloudflare, не знают?
Клиент->SSL_2->Cloudflare->SSL_1->Ваш сервис, так?А что делать всяким реверсивным прокси, которые никаких деталей про ваш сертификат, в отличие от cloudflare, не знают?
А зачем шифровать по разному для разных пользователей публичную страницу?
Потому шифрование безопасно только со случайным инициализационным вектором.
Есть две стратегии — паблик и приват. Они уже есть в стратегиях кэширования.
Приват мы шифруем, а паблик ПОДПИСЫВАЕМ. Кэширующий прокси спокойно себе хранит подписанную страничку, отдает всем пока ТТЛ не закончится, при этом подменить ее содержимое он не может ибо у него нет подписи.
Поправьте меня если я не прав.
Приват мы шифруем, а паблик ПОДПИСЫВАЕМ. Кэширующий прокси спокойно себе хранит подписанную страничку, отдает всем пока ТТЛ не закончится, при этом подменить ее содержимое он не может ибо у него нет подписи.
Поправьте меня если я не прав.
В свете недавних откровений NSA, SSL защищает только от школоты с снифферами трафика. Подмена сертификата на другой происходит без предупреждений пользователю, а список доверенных сертификатов… Кто решил, что им можно доверять?
Если тобой интересуется компетентные органы то не все ли ровно как они получат информацию?
Применят термокриптоанализ или сертификат это же не изменит конечную ситуацию — данные они получат.
Применят термокриптоанализ или сертификат это же не изменит конечную ситуацию — данные они получат.
Есть огромная разница между анализом роботами и персональным вниманием.
Если честно не очень понял к чему вы это.
Лично я о том что «школота» наверное все же не осилит взлом ssl на лету в ближайшей перспективе, а некие госструктуры получат любые данные при первом желании (утрирую). Так что заявление о бесполезности шифрования преувеличенна.
Хотя шифрование это явно не панацея.
Лично я о том что «школота» наверное все же не осилит взлом ssl на лету в ближайшей перспективе, а некие госструктуры получат любые данные при первом желании (утрирую). Так что заявление о бесполезности шифрования преувеличенна.
Хотя шифрование это явно не панацея.
Отмахиваться от методов защиты, ссылаясь на априорный паяльник в заднице — это вполне позиция. Но я её не принимаю и принимать не собираюсь.
Указанные проблемы вполне себе актуальны и требуют решения. Проблема номер 1 — отсутствие уведомления пользователя о подмене сертификата на другой валидный. Проблема номер 2 — создатели браузеров решают за пассивное большинство, кому они доверяют, причём делают это с делегацией доверия вообще неизвестным лицам.
Указанные проблемы вполне себе актуальны и требуют решения. Проблема номер 1 — отсутствие уведомления пользователя о подмене сертификата на другой валидный. Проблема номер 2 — создатели браузеров решают за пассивное большинство, кому они доверяют, причём делают это с делегацией доверия вообще неизвестным лицам.
По поводу второго — я агитирую за выпуск браузеров вообще без ЦС. Все ЦС, которым ты доверяешь, ты обязан установить в браузер самостоятельно. А то там по умолчанию такая куча наименований, кто все эти люди? Я их не знаю.
И что тогда делать владельцам сервисов? К кому идти за сертификатом, если Вася доверяет только A-CA, а Петя — B-CA?
А как делают сейчас банки? Не знаете? Они выпускают свои сертификаты и именно их именно вы должны своими руками вставить в хранилище. И это правильный подход.
Что, все еще делают? Давно такого не видел. С самоподписаным сертификатом нужен секьюрный канал его первоначальной передачи клиенту. Иначе, какие у вас гарантии, что сертификат принадлежит именно тому, кому вы думаете?
Так есть такой канал — визит в банк.
У этого подхода есть некоторые проблемы с масштабируемостью. В банк я, может, и схожу, а вот в офисы владельцев всех используемых сервисов — вряд ли. Много их, офисы далеко, да и не всегда есть.
Владельцы могут выслать сертификат почтой. Как электронной, так и обычной, нотариально удостоверенной.
А сообщению электропочты мы по какой причине доверять будем? Неужели потому, что текст сообщения (… барабанная дробь ...) подписан приватным ключом? И как мы его проверим, если у нас еще нет публичного ключа отправителя, которому бы мы доверяли?
Он может отправлять сертификат через почту, которой доверяет и он, и мы.
Это уже другая проблема, доверяете вы сообщению из электропочты или сертификату с флешки, присланной по почте. Важно здесь то, что вы явным образом выражаете своё доверие к сертификату, самостоятельно установив его в браузер. Сравните: вы скачали браузер по http, в нём какие-то сертификаты. С какой стати вы доверяете вообще им?
Сравните: вы скачали браузер по http, в нём какие-то сертификаты.
Решил проверить ваше предположение, пошел на www.google.com/intl/en/chrome/browser/ — сразу получил редирект на https-версию. Файрфокс тоже скачивается через https. Остается Опера, та действительно качается по http. Ну так мне она и не нужна.
Ну давайте не будем судить по себе. Я вот вообще браузеры с сайта не качаю, ставлю из репозитория, где пакеты подписаны — но это не значит, что все делают так же.
Мало ли из какой клоаки взялся дистрибутив — в любом случае пользователь не то, чтобы не выражал явное согласие и доверие всем этим ЦС, он даже не подозревает, сколько их там и какие они.
Мало ли из какой клоаки взялся дистрибутив — в любом случае пользователь не то, чтобы не выражал явное согласие и доверие всем этим ЦС, он даже не подозревает, сколько их там и какие они.
Я вот вообще браузеры с сайта не качаю, ставлю из репозитория, где пакеты подписаны — но это не значит, что все делают так же.
Ну вы сами предложили скачать браузер по http. Я пошел, проверил — два из трех качаются по https.
Мало ли из какой клоаки взялся дистрибутив — в любом случае пользователь не то, чтобы не выражал явное согласие и доверие всем этим ЦС, он даже не подозревает, сколько их там и какие они
Мне кажется, что множество пользователей, дистрибутив которых берется из какой-нибудь клоаки, и множество тех, кто будет 5 дней ждать нотариально заверенную флешку для регистрации по почте — практически не пересекается.
Для начала починили бы бесполезную систему CA, а потом уже вводили что угодно. А так от этого радость исключительно выдающим сертификаты.
(которые относятся к числу тех, кто наиболее активно выступают за более активное использование криптографии)
В нашей конторе из тридцати двух сотрудников по штату двадцать восемь называли себя: «Золотое перо республики». Мы трое в порядке оригинальности назывались — серебряными. Дима Шер, написавший в одной корреспонденции: «Искусственная почка — будничное явление наших будней», слыл дубовым пером.
Простите, я не со злобы, исключительно чтобы ввернуть юморную цитату моего любимого писателя.
Тотальное «шифрование» настораживает. В итоге, может оказаться, что оно будет реализовано абы как (специалистов то ограниченное количество), поэтому пользователи будут думать, что всё защищено, хотя ничего не защищено. Вопрос доверия к центрам сертификации осложнится. Откуда будет известно, что они не будут сливать все сертификаты по запросу? Доверию к открытым алгоритмам, и открытому ПО, реализующему эти алгоритмы, подмочено.
И ещё, не понятно, от кого эта защита будет работать?
И ещё, не понятно, от кого эта защита будет работать?
Откуда будет известно, что они не будут сливать все сертификаты по запросу?
Да пусть хоть обсливаются!
Скрытый текст
-----BEGIN CERTIFICATE-----
MIIGWjCCBUKgAwIBAgIDBXfiMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0
YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg
MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIxMjEwMDU0NzQz
WhcNMTMxMjExMTM0OTE3WjBtMRkwFwYDVQQNExA1THVlWWxYVkdoWjV5ODdkMSQw
IgYDVQQDDBtuaWtpdGEua2lwcml5YW5vdkBnbWFpbC5jb20xKjAoBgkqhkiG9w0B
CQEWG25pa2l0YS5raXByaXlhbm92QGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAOIvuRZ2Qm9wQaiO4Fdb/wXEC3cwXsU81WejHTU5KvW6
AF9pxzFayLoCI4dh+xe5rii4pLb7J5nFgKKtKw4ZojpmrLpPR707GEwmfhkypEqn
kxdRQkBuEOzqpQb7HRGbUQ/hMudc+Qrae816iY/08UUBRAYcjzG0j5mrN9VY5FC3
981UPgGCbMfNRkbEPC8zUkhuhkMO93ubHkiDbvQ0A9Se49WVkgfjzDeJ38UmWFuY
EvVQWI5JgWspz7plKXZCvA7Tp6nTqADG5Q3iqFHitIkBGZbBaGllII5dDQ+DwPtk
j81PoZ+oTqYb/2WsIC87yfj3u4I5pw/12RO47mNrpT0CAwEAAaOCAuEwggLdMAkG
A1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF
BQcDBDAdBgNVHQ4EFgQU7iPhuR/eEqjNhfRT45tnN1+WDbswHwYDVR0jBBgwFoAU
U3Ltkpzg2ssBXHx+ljVO8tS4UYIwJgYDVR0RBB8wHYEbbmlraXRhLmtpcHJpeWFu
b3ZAZ21haWwuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC
ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5w
ZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3Jk
aW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRo
ZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRl
bmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkg
b2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi
LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh
cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEANxf/VCUJSbqHXOq1F13FqIVF
9Lotv8VWmvZ33DX4shXLDX0iudjiShuSx/F89QrGDv58UuBrDZY1GuQoE9fd+4KF
hMVNxMULYzpVcR7ADRJNY4xpnJJ2Z2L4OeAgTH6ixULmIAvyLCsmy4HtzcFdvMDx
ajqrM5IWLgWStC3YxknKxwxL7QUlNj3AyO3U+jrClNhClWccBoIs1iiXcuoxaaKf
uj97kvtcxDAdKm2gGJExOvgdFOYllLG73QmPwSwpawTCYiLsHtWmIvtD95byoeEs
6LbnnmMnANj0B+HFiHcP1kkQrxV4R6chg5KUnaFtPk6z3qbzKQR/FqFEEJ1sOQ==
-----END CERTIFICATE-----
MIIGWjCCBUKgAwIBAgIDBXfiMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0
YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg
MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIxMjEwMDU0NzQz
WhcNMTMxMjExMTM0OTE3WjBtMRkwFwYDVQQNExA1THVlWWxYVkdoWjV5ODdkMSQw
IgYDVQQDDBtuaWtpdGEua2lwcml5YW5vdkBnbWFpbC5jb20xKjAoBgkqhkiG9w0B
CQEWG25pa2l0YS5raXByaXlhbm92QGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAOIvuRZ2Qm9wQaiO4Fdb/wXEC3cwXsU81WejHTU5KvW6
AF9pxzFayLoCI4dh+xe5rii4pLb7J5nFgKKtKw4ZojpmrLpPR707GEwmfhkypEqn
kxdRQkBuEOzqpQb7HRGbUQ/hMudc+Qrae816iY/08UUBRAYcjzG0j5mrN9VY5FC3
981UPgGCbMfNRkbEPC8zUkhuhkMO93ubHkiDbvQ0A9Se49WVkgfjzDeJ38UmWFuY
EvVQWI5JgWspz7plKXZCvA7Tp6nTqADG5Q3iqFHitIkBGZbBaGllII5dDQ+DwPtk
j81PoZ+oTqYb/2WsIC87yfj3u4I5pw/12RO47mNrpT0CAwEAAaOCAuEwggLdMAkG
A1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF
BQcDBDAdBgNVHQ4EFgQU7iPhuR/eEqjNhfRT45tnN1+WDbswHwYDVR0jBBgwFoAU
U3Ltkpzg2ssBXHx+ljVO8tS4UYIwJgYDVR0RBB8wHYEbbmlraXRhLmtpcHJpeWFu
b3ZAZ21haWwuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC
ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5w
ZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3Jk
aW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRo
ZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRl
bmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkg
b2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi
LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh
cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEANxf/VCUJSbqHXOq1F13FqIVF
9Lotv8VWmvZ33DX4shXLDX0iudjiShuSx/F89QrGDv58UuBrDZY1GuQoE9fd+4KF
hMVNxMULYzpVcR7ADRJNY4xpnJJ2Z2L4OeAgTH6ixULmIAvyLCsmy4HtzcFdvMDx
ajqrM5IWLgWStC3YxknKxwxL7QUlNj3AyO3U+jrClNhClWccBoIs1iiXcuoxaaKf
uj97kvtcxDAdKm2gGJExOvgdFOYllLG73QmPwSwpawTCYiLsHtWmIvtD95byoeEs
6LbnnmMnANj0B+HFiHcP1kkQrxV4R6chg5KUnaFtPk6z3qbzKQR/FqFEEJ1sOQ==
-----END CERTIFICATE-----
Ничего вам это не даст. Он и так постоянно пересылается в открытом виде, когда я захожу на сайт, требующий от меня сертификат (и доверяющий startssl).
Приватные ключи CA — другое дело. (Пользовательских приватных ключей у них нет.) Но и тут — проштрафившийся CA можно вынести из списка. И вообще наоборот, пользователь должен всегда сам заполнять список доверенных CA, своими руками, и знать, кого он туда добавил и почему. Ну и конечно, WoT ещё лучше.
Понятно, что речь идёт о приватных. Требовать же от пользователя составлять список доверенных СА слегка смешно. Это как требовать программировать самостоятельно SIM-карту, типа добавлять список доверенных базовых станций. Речь ведь идёт о всех пользователях интернета. А то, что CA — плохой, это ещё узнать нужно.
Понятно, что речь идёт о приватных.
У CA нет приватных ключей от сертификатов, которые они подписывают. Опасность недобросовестного CA в другом — они могут выдать кому попало другой, но настолько же валидный сертификат на ваш домен. И тогда организация, получившая этот левый сертификат, «договорившись» (скорее всего с помощью административно-принудительных мер) с провайдером между вашим сервером и вашим пользователем, может подменить сертификат и провести MitM-атаку, которую пользователь даже не заметит.
В итоге, может оказаться, что оно будет реализовано абы как (специалистов то ограниченное количество), поэтому пользователи будут думать, что всё защищено, хотя ничего не защищено.
Я согласен. У большинства людей сработает шаблон: есть шифрование — значит передавать данные безопасно.
ИМХО система с центрами выдачи сертификатов (СА) дырявая, как говорится, «by Design».
В самом деле, ничто не мешает почти любой спецслужбе в любой стране) попросить по своим каналам центр сертификации CA своей страны выпустить для них копию сертификата для любого сайта.
У меня был интересный случай, когда я отдыхал 4 года назад в Турции. При попытке прочитать свою почту Thunderbird-ом через бесплатный WIFI в отеле, у меня вылезло сообщение, что SSL сертификат Google неправильно подписан — вместо обычного SSL сертификата был подставлен самоподписанный сертификат какого-то файервола. Так случайно нажмешь, не читая, кнопку Ignore и твои пароли от почты, в теории, смогут прочитать совершенно посторонние лица.
При существующей системе с SSL, например правительство Турции может «попросить» TURKTRUST (этот турецкий центр сертификации есть в списке доверенных CA в FireFox) выдать им SSL сертификат для сайта gmail.com, что им даст возможность незаметно следить за перепиской через gmail интересующих их людей.
ИМХО система с центрами выдачи сертификатов (СА) дырявая, как говорится, «by Design».
В самом деле, ничто не мешает почти любой спецслужбе в любой стране) попросить по своим каналам центр сертификации CA своей страны выпустить для них копию сертификата для любого сайта.
Да проще, во все браузеры потребовать встроить свой ЦС. И вуаля.
Я потому и говорю, что сертификаты ЦС каждый пользователь должен добавлять сам.
Строго говоря, не могут. Точнее, они могут, но для этого они должны сначала отозвать ваш сертификат. После чего уже при входе на ваш подлинный сайт клиенты будут видеть «сертификат истёк».
(По крайней мере, OpenSSL не даёт выдать одновременно два сертификата с одинаковыми cn. Можно, наверное, как-то сделать их «вручную», но сомневаюсь, что ЦС будет заморачиваться. И не знаю, как обстоит дело с коллизией SubjectAltName между собой и с CN — если эти коллизии допускаются, то опять же, я ошибаюсь и отзывать сертификат необязатеьно.)
Зато, как вы понимаете, сертификат может выдать любой ЦС, в том числе и не тот, который выдал исходный сертификат. Первый даже не узнает о том, что есть такая порнография. Они и сейчас могут в принципе так выдавать сертификаты — каждый проверит меня и выдаст сертификат для www.example.com.
В общем, спецслужбам достаточно в браузер внедрить свой ЦС.
(По крайней мере, OpenSSL не даёт выдать одновременно два сертификата с одинаковыми cn. Можно, наверное, как-то сделать их «вручную», но сомневаюсь, что ЦС будет заморачиваться. И не знаю, как обстоит дело с коллизией SubjectAltName между собой и с CN — если эти коллизии допускаются, то опять же, я ошибаюсь и отзывать сертификат необязатеьно.)
Зато, как вы понимаете, сертификат может выдать любой ЦС, в том числе и не тот, который выдал исходный сертификат. Первый даже не узнает о том, что есть такая порнография. Они и сейчас могут в принципе так выдавать сертификаты — каждый проверит меня и выдаст сертификат для www.example.com.
В общем, спецслужбам достаточно в браузер внедрить свой ЦС.
Можно и без отзыва, в openssl это делается в одну команду:
До этого этим же CA был выдан сертификат с тем же сабжектом:
Родина прикажет — будет. Тем более, как вы видите, это несложно.
Палевно, всплывет, производители браузеров уберут. Лучше/проще отжать приватный ключ у существующего CA, который продолжит раздавать нормальные сертификаты, и уже целенаправленно при нужде генерировать таргетированные фейки. Меньше шансов, что кто-нибудь это заметит.
~/src/ca❯ openssl x509 -req -CA demoCA/cacert.pem -CAkey demoCA/private/cakey.pem -CAserial demoCA/serial -in fake.req -out fake.crt
Signature ok
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=real.example.com
Getting CA Private Key
Enter pass phrase for demoCA/private/cakey.pem:
До этого этим же CA был выдан сертификат с тем же сабжектом:
~/src/ca❯ openssl x509 -noout -text -in real.crt | grep Subject:
Subject: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=real.example.com
но сомневаюсь, что ЦС будет заморачиваться.
Родина прикажет — будет. Тем более, как вы видите, это несложно.
В общем, спецслужбам достаточно в браузер внедрить свой ЦС.
Палевно, всплывет, производители браузеров уберут. Лучше/проще отжать приватный ключ у существующего CA, который продолжит раздавать нормальные сертификаты, и уже целенаправленно при нужде генерировать таргетированные фейки. Меньше шансов, что кто-нибудь это заметит.
Хм, а поля названия ЦС в 8битной кодировке или юникод? Можно вспомнить про схожие символы и тогда приходит что-то подобное: RootCA делает два промежуточных ЦС с отличием в одной букве (похожей), т.е. даже если браузер будет отображать сразу имена ЦС вроде того как сейчас отображаются имена компаний для EV-сертификатов, то визуально вы не заметите подвоха. Разве что только проверять публичный ключ, но это явно не будет выводиться сразу, т.к. массовому пользователю не нужно.
> У CA нет приватных ключей от сертификатов, которые они подписывают.
Точно. Как не специалист, про механизм подписывания не всегда помню.
Точно. Как не специалист, про механизм подписывания не всегда помню.
А никого не беспокоит, что можно сказать «до свидания» привычной практике «много сайтов на одном IP»? По сути, без IPv6 HTTP/2 не взлетит — не хватит IPv4 адресов.
Нет, не беспокоит, поскольку это уже не так. Ознакомьтесь: en.wikipedia.org/wiki/Server_Name_Indication
Оно работает со сбоями.
Вот я SNI использую можно сказать направо и налево. Про неподдержку древними андроидами и хрюшами — слышал. Про сбои — ни разу не доводилось.
Можно поподробнее?
Можно поподробнее?
Я сам на своём серваке использую. Но в FireFox 1 раз из 10 идёт ругань на сертификат. Нажимаешь F5 — порядок. То есть для использования на проде требуется дополнительное исследование.
Клиент Firefox, сервер(ы) Apache, нет проблем.
Может быть, всё-таки это вы что-то не донастроили?
Может быть, всё-таки это вы что-то не донастроили?
Я без проблем воспроизвожу у себя на домене:
* Открываем сайт
* Закрываем
* Через 30-60 минут снова открываем
Результат: 1 раз из 10 — ssl_error_bad_cert_domain
F5 лечит.
>> Клиент Firefox, сервер(ы) Apache, нет проблем
Аналогично, FF17
>> Может быть, всё-таки это вы что-то не донастроили?
Может быть, но это так же означает, что кто-то другой может не донастроить, получать жалобы от пользователей и не мочь воспроизвести.
* Открываем сайт
* Закрываем
* Через 30-60 минут снова открываем
Результат: 1 раз из 10 — ssl_error_bad_cert_domain
F5 лечит.
>> Клиент Firefox, сервер(ы) Apache, нет проблем
Аналогично, FF17
>> Может быть, всё-таки это вы что-то не донастроили?
Может быть, но это так же означает, что кто-то другой может не донастроить, получать жалобы от пользователей и не мочь воспроизвести.
Хотя это возможно баг Firefox: bugzilla.mozilla.org/show_bug.cgi?id=791568
А нет, только что воспроизвёл и в Хроме. Wireshark показывает, что SNI заголовок не всегда присутствует при установлении SSLv3 соединения. Видимо раз F5 решает проблему, это как-то связано с кешом.
А какой MPM используется в апаче на сервере?
prefork. А при чём здесь апач, если это браузеры не всегда посылают заголовок.
Я вполне представляю себе такую проблему: браузер делает запросы в keepalive, но тут ему потребовалось сделать запрос на другой ssl-виртуалхост, висящий на том же IP-адресе. Браузер решает для этого использовать уже имеющееся соединение с сервером, в результате чего получается Host/SNI mismatch (при установлении соединения было одно имя в SNI, сейчас в рамках этого соединения пришёл запрос с другим именем в заголовке Host). Это может приводить к проблемам.
По логике, в такой ситуации keepalive использовать нельзя, а при попытке использования сервер должен прекращать соединение. Как на это прекращение (вместо ответа) реагирует браузер — вопрос другой. В RFC6066 про keepalive ничего не сказано.
По логике, в такой ситуации keepalive использовать нельзя, а при попытке использования сервер должен прекращать соединение. Как на это прекращение (вместо ответа) реагирует браузер — вопрос другой. В RFC6066 про keepalive ничего не сказано.
Проверьте на www.ssllabs.com/ssltest/index.html
Может быть, но это так же означает, что кто-то другой может не донастроить, получать жалобы от пользователей и не мочь воспроизвести.Классика: 12.7% (по данным свежего скана) всех действительных SSL-цепочек не включают сертификат промежуточного удостоверяющего центра, в итоге у владельцев сайта всё будет нормально (поскольку они закэшировали недостающий ключ в момент подписи или у другого сайта), а у случайных пользователей (особенно со свежеустановленным браузером) будут проблемы (не ssl_error_bad_cert_domain, это просто пример кривой настройки, встречаемой повсюду).
Спасибо за ссылку на тест, есть повод понастроить. Но мы здесь обсуждаем проблему SNI, а они как раз его не поддерживают при тестировании. Пруфлинк: www.ssllabs.com/ssltest/analyze.html?d=apis.google.com&s=173.194.115.14&hideResults=on
Пруф поломался, остался кэш, в прочем это уже не важно. SSLLabs уже несколько месяцев поддерживает SNI. Проблема в кривой настройке гугла и немного в интерфейсе SSLLabs: по общей таблице видно, что SSLLabs заодно проверяют поддомен www. у всех проверяемых доменов, а этот ip возвращает сертификат только для *.google.com, что не соответствует домену четвёртого уровня www.apis.google.com.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HTTP 2.0 будет только по HTTPS