Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
1. Не хозяин ресурса, вообще говоря, решает кому доверять пользователю. А поставщик ОС/браузера (не хозяин ресурса устанавливает сертификаты корневых центров)
2. Что помешает подменить удостоверяющие сервера списка?
2. Что помешает подменить удостоверяющие сервера списка?
3. В моем мире выбор между «делать администратору на стороне сервера»
1. Вообще говоря, поставщик ОС/браузера определяет список кому якобы можно доверять, а имеено хозяин ресурса уже решает у кого из этого списка приобретать сертификат: Comodo, DigiCert, GoDaddy, VeriSign или иного продавца. Но это не важно, важно то, что определяете не Вы.
2. Пожалуйсто, разверните Вашу мысль по-подробней
2. Пожалуйсто, разверните Вашу мысль по-подробней
2.
>> Клиент обращается к сформированному им списку удостоверяющих серверов и спрашивает у каждого из них — «какой сертификат ты видишь на этом сайте ?».
Подменен каждый из удостоверяющих серверов (великим китайским/великим иранским/беларусским файрволами)
Защита не сработает?
>> Клиент обращается к сформированному им списку удостоверяющих серверов и спрашивает у каждого из них — «какой сертификат ты видишь на этом сайте ?».
Подменен каждый из удостоверяющих серверов (великим китайским/великим иранским/беларусским файрволами)
Защита не сработает?
>> 1. Вообще говоря, поставщик ОС/браузера определяет список кому якобы можно доверять,
А что мешает это сделать вам? Вы с лёгкостью можете удалить все сертификаты и добавить свои. Вопрос только в следующем: сколько друзей (коллег, бизнес-партнёров) вы к этому подключите, так чтобы вы (вам) доверяли. Плюс возникает вопрос к компрометацией ключей или вывода их из системы (ака архивирование/уничтожение).
За вас это уже сделали и предлагают свои услуги. А покупать их или доверять им — это уже ваше дело. С точки зрения криптографии всё отлично. Другое дело нечеловеческий фактор и несовершенство реализации таких систем.
Вы рассмотрите УЦ, которые предоставляют услуги госструктурам Украины (думаю, что в России похожая ситуация). Там только аппаратная реализация всех криптопреобразований + оценка угроз и т.д. и т.п.
А что мешает это сделать вам? Вы с лёгкостью можете удалить все сертификаты и добавить свои. Вопрос только в следующем: сколько друзей (коллег, бизнес-партнёров) вы к этому подключите, так чтобы вы (вам) доверяли. Плюс возникает вопрос к компрометацией ключей или вывода их из системы (ака архивирование/уничтожение).
За вас это уже сделали и предлагают свои услуги. А покупать их или доверять им — это уже ваше дело. С точки зрения криптографии всё отлично. Другое дело нечеловеческий фактор и несовершенство реализации таких систем.
Вы рассмотрите УЦ, которые предоставляют услуги госструктурам Украины (думаю, что в России похожая ситуация). Там только аппаратная реализация всех криптопреобразований + оценка угроз и т.д. и т.п.
Т.е. каждое https соединение — это n+1 соединений для сервера, где n — среднее число нотариусов? Дорого же такая технология обойдется владельцам сайтов! Параноики — они и так знают каким CA доверять, а каким нет. Гугли и банки будут наверняка использовать class 3 у известного имени вроде Verisign, плюс EV сертификаты, а для более мелких и казуальных SSL каналов игра не стоит свеч, ни для защитников, ни для взломщиков.
На самом деле каждый раз мучать сервер не нужно, вопрос решается за счет кэширования как на клиенте, так и на нотариусе. Дополнительная нагрузка незначительна. Насчет гуглей и банков, класс3, EV сертификатов и прочего — тут как бы не о том речь совсем. Речь о том, как клиенту подстраховаться от Человека-По-Середине. И тут не важно что там за сертификат на сервере — class3 или self-signed. Тут только сам клиент уже для себя решает какую систему использовать — централизованную классическую CA System или Convergence и ничто не влияет на его решение.
Кэширования? О, боги, только не кэширование, не то начнется бесконечное количество false positives из-за тормознутых нотариусов. Впрочем, это мелочи. Идея сама понятна, красива, но не очень жизненна.
Речь о том, как клиенту подстраховаться от Человека-По-Середине. И тут не важно что там за сертификат на сервере — class3 или self-signed.
Я не соглашусь. Людям абсолютно наплевать на виды и названия атак. Им нужно подтверждение абонента. Если меня заставили поверить в фальшивого абонента, то по последствиям мне все равно где был «Человек»: посредине, с краю, или кто-то DNS заспуфил и увел меня вообще не туда. Что приводит нас к следующей мысли: безопасность — мера комплексная! Она никогда не решалась и не решится только технически как минимум потому, что нам необходимо подтверждение живого/юридического абонента, а он по жизни подтверждается не техникой, а паспортом/документом о создании компании. Вот здесь и вступают в дело проверки, адвокаты, class 3 сертификаты, extended validation. Именно та бюрократия, которая позволит перевести доверие из real life в наборы байт. А с бюрократией мы получаем целый букет жизненных (в дополнение к техническим!) проблем: безопасность личного ключа CA, доверие к персоналу, сейфы, бункеры, бэкапы на другом континенте, служба безопасности, служба аудита и т.д. и т.п. Всё это в комплексе более-менее решает задачу подтверждения, а не только конкретная защита от MitM. Convergence — не панацея. Он точно так же позволит обкуренной и непонятно как попавшей в списки root CA конторе выдать/подтвердить фальшивый сертификат, создавая тем самым дыру в безопасности. Пример очень показателен: с технической точки зрения у голландцев не было никаких проблем. Дыра оказалась именно в той части CA guidelines, которая относится к чистой бюрократии.
Речь о том, как клиенту подстраховаться от Человека-По-Середине. И тут не важно что там за сертификат на сервере — class3 или self-signed.
Я не соглашусь. Людям абсолютно наплевать на виды и названия атак. Им нужно подтверждение абонента. Если меня заставили поверить в фальшивого абонента, то по последствиям мне все равно где был «Человек»: посредине, с краю, или кто-то DNS заспуфил и увел меня вообще не туда. Что приводит нас к следующей мысли: безопасность — мера комплексная! Она никогда не решалась и не решится только технически как минимум потому, что нам необходимо подтверждение живого/юридического абонента, а он по жизни подтверждается не техникой, а паспортом/документом о создании компании. Вот здесь и вступают в дело проверки, адвокаты, class 3 сертификаты, extended validation. Именно та бюрократия, которая позволит перевести доверие из real life в наборы байт. А с бюрократией мы получаем целый букет жизненных (в дополнение к техническим!) проблем: безопасность личного ключа CA, доверие к персоналу, сейфы, бункеры, бэкапы на другом континенте, служба безопасности, служба аудита и т.д. и т.п. Всё это в комплексе более-менее решает задачу подтверждения, а не только конкретная защита от MitM. Convergence — не панацея. Он точно так же позволит обкуренной и непонятно как попавшей в списки root CA конторе выдать/подтвердить фальшивый сертификат, создавая тем самым дыру в безопасности. Пример очень показателен: с технической точки зрения у голландцев не было никаких проблем. Дыра оказалась именно в той части CA guidelines, которая относится к чистой бюрократии.
На самом деле я не думаю и не говорю что Convergence — панацея. Но если проводить паралели с системой CA, то оно смотрится удачнее. Хотя признаю, что еще удачнее смотрится вариант в котором оба подхода сочитаются и закрывают слабые стороны друг-друга, мое упущение что не рассмотрел это в статье. В этом случае, если не в виде замены, то в виде одной из составляющих комплексной меры — идея очень жиненна и красива.
А кэш может быть кстати и на руку, смотрите коммент ниже
> Convergence — не панацея. Он точно так же позволит обкуренной и непонятно как попавшей в списки root CA конторе выдать/подтвердить фальшивый сертификат, создавая тем самым дыру в безопасности
даже лучше: конвергенс позволит мне сделать фальшивый сертификат *без* обкуренного CA!
то есть берем какой-то домен, типа go0g1e.com, выписываем себе сертификат на имя «Google Inc.» и все «нотариусы» его радостно подтверждают.
каким местом тут web of trust, я не понимаю — именно *сети* доверия нет.
даже лучше: конвергенс позволит мне сделать фальшивый сертификат *без* обкуренного CA!
то есть берем какой-то домен, типа go0g1e.com, выписываем себе сертификат на имя «Google Inc.» и все «нотариусы» его радостно подтверждают.
каким местом тут web of trust, я не понимаю — именно *сети* доверия нет.
> Больше нет предупреждений о самоподписанных сертификатах, так как клиенту не важно кем
> он подписан, клиенту важно быть уверенным в том, что он использует сертификат предоставляемый
> сервером а не Человеком-По-Середине.
Да-да. DNS сломали, сайт ведёт на левый хост, который мимикрирует под указанный. Все видят один сертификат — поддельный.
> он подписан, клиенту важно быть уверенным в том, что он использует сертификат предоставляемый
> сервером а не Человеком-По-Середине.
Да-да. DNS сломали, сайт ведёт на левый хост, который мимикрирует под указанный. Все видят один сертификат — поддельный.
Кроме спуфинга DNS, означенного выше, есть еще проблема MtM, имеющего доступ к трафику датацентра. Т.е. если влезть между сервером и внешним миром, то нотариусы ничего подозрительного не обнаружат.
Вообще, если предположить, что MtM не работает 100% времени и устанавливается не в момент запуска сервера, то MtM с кэшем/историей проверок могут сработать. Т.е. они будут обращаться к исходному серверу не при каждом запросе клиента, а будут кэшировать данные и смотреть — не меняется ли issuer со временем.
Эта штука не решает проблему mitm, так как атакующий может сидеть на канале сервера (датацентр, апстрим провайдер, магистральный канал, и.т.д.). В таком случае все сервера Notary получат сертификат созданный атакующим. То-же самое произойдет при взломе DNS.
К тому-же CA выдающий сертификаты удостоверяет что сертификат принадлежит конкретному человеку/компании, а для EV SSL сертификатов — еще и что сертификат выдан серьезному бизнесу, а не шарашкиной конторе зарегистрированной на бомжа вчера вечером. Соответственно браузер показывает КОМУ вы передаете свои личные данные и кредитные карты. А Notary подтверждает только то, что соединение установлено хрен знает с кем, но оно устанавливается именно с ним из разных точек интернета.
Еще одна проблема — отказоустойчивость этой системы. Что делать если один из серверов Notary не отвечает? А если не отвечают все? А если злонамеренный провайдер заблокировал все эти сервера и ждет пока мы полезем на митмимый сайт (а мы полезем, никуда не денемся, коль нет другого варианта).
К тому-же CA выдающий сертификаты удостоверяет что сертификат принадлежит конкретному человеку/компании, а для EV SSL сертификатов — еще и что сертификат выдан серьезному бизнесу, а не шарашкиной конторе зарегистрированной на бомжа вчера вечером. Соответственно браузер показывает КОМУ вы передаете свои личные данные и кредитные карты. А Notary подтверждает только то, что соединение установлено хрен знает с кем, но оно устанавливается именно с ним из разных точек интернета.
Еще одна проблема — отказоустойчивость этой системы. Что делать если один из серверов Notary не отвечает? А если не отвечают все? А если злонамеренный провайдер заблокировал все эти сервера и ждет пока мы полезем на митмимый сайт (а мы полезем, никуда не денемся, коль нет другого варианта).
А также атакующий может сидеть на канале клиента (маршрутизатор, троян). В таком случае клиент получит положительный ответ от всех Notary.
Вывод. Где бы ни сидел атакующий, эта штука не решает проблему MitM.
Или мы что-то упустили?
Вывод. Где бы ни сидел атакующий, эта штука не решает проблему MitM.
Или мы что-то упустили?
Пропустили. Общение с Notary идет с использованием DSA.
Подробнее, пожалуйста. DSA это что в данном случае, «цифровая подпись»?
Или ссылку дайте, где почитать.
Или ссылку дайте, где почитать.
Да, именно. Notary подписывают свои ответы.
А еще подробнее? :/
Сертификаты как бы тоже подписываются, однако же…
Сертификаты как бы тоже подписываются, однако же…
Да, подписываются, но кем — определяете не Вы, и в случае чего что случись — Вы тоже ничего не решаете и не определяете по большому счету (ну не будете же вы у себя из корня comodo сертификат выпиливать?). А в данном случае список notary формируете для себя Вы сами, если хотите можете даже свои notary-серевера понаподнимать — исходники notary серверов доступны.
ИМХО удовлетворительным решение проблемы взлома CA и злонамеренных CA будет принятие разработчиками всех браузеров соглашения, согласно которому при обнаружении фальшивого сертификата корневой сертификат CA немедленно удаляется невзирая на то, что от него зависят 100500 сайтов. Одна ошибка — расстрел. Тогда только достойные останутся в живых.
Даже при принятия такого решения, где гарантии того, что в случае избежания публичной огласки инцидента, оно будет соблюдаться? Ну и остальные неприятные моменты, когда непонятно что творится не по ошибке, а намеренно.
Чтобы решение соблюдалось, обнаружение инцидентов должно выполняться третьей стороной, а лучше несколькими, чтобы не возникло желание «договориться» с проштрафившимся CA. После обнаружения инцидента должна следовать немедленная огласка. А после огласки — исключение потерявшего доверие CA.
> Ну и остальные неприятные моменты, когда непонятно что творится не по ошибке, а намеренно.
Главное правило: доверие дается один раз. А как оно потеряно: по ошибке или намеренно — неважно. В природе появился сертификат выданный на чужие идентификационные данные — прощай бизнес. CA не может предоставить документы доказывающие что подозрительный сертификат выдан тому, кому заявлено — он считается фальшивым, со всеми вытекающими.
> Ну и остальные неприятные моменты, когда непонятно что творится не по ошибке, а намеренно.
Главное правило: доверие дается один раз. А как оно потеряно: по ошибке или намеренно — неважно. В природе появился сертификат выданный на чужие идентификационные данные — прощай бизнес. CA не может предоставить документы доказывающие что подозрительный сертификат выдан тому, кому заявлено — он считается фальшивым, со всеми вытекающими.
вариант имеет некую долю справедливости, только последствия…
Представьте, сколько бизнесов не смогу в один прекрасный день работать, и, что более важно для пользователей сертификатов — сколько будет стоить каждый такой сертификат? Ведь компании сразу загнут стоимость сертификатов, оправдывая это затратами на обеспечение 200% надежности, ведь «второго шанса» у них не будет.
Представьте, сколько бизнесов не смогу в один прекрасный день работать, и, что более важно для пользователей сертификатов — сколько будет стоить каждый такой сертификат? Ведь компании сразу загнут стоимость сертификатов, оправдывая это затратами на обеспечение 200% надежности, ведь «второго шанса» у них не будет.
Интересно Вы, однако, рассуждаете. Тогда что же это такое получается, щас никто не загибает цен и эти самые компании расслаблены от того, что понимают, что у них будет и второй и третий шанс? Ну на деле то так оно конечно и выходит и все это понимают, но что бы вот так вот запросто это прям принимать — нет уж. По Вашим словам тогда выходит, что компаниям априори можно обсераться, лишь бы цены за свои байты не взвинчивали. Или я неправильно понял?
Стоимость сертификатов и так задрана, а чтобы обеспечить безболезненную ликвидацию потерявшего доверие CA, можно (при условии содействия со стороны CA) временно разрешить сертификаты созданные задолго до даты компрометации. Затем даем месяц чтобы CA оповестил всех своих клиентов о своей ликвидации, и окончательно блокируем корневой сертификат. Если же CA не оказывает содействия и пытается замолчать инцидент, то корневой сертификат блокируется немедленно, параллельно с громким разоблачением везде где только можно.
Жесткие меры, да, но цифровые нотариальные услуги — это высокоответственный бизнес, где допустимо только безупречное доверие. Раз лидеры рынка, Verisign и Thawte могут держать планку, то другим пора подтягиваться или сдохнуть.
Жесткие меры, да, но цифровые нотариальные услуги — это высокоответственный бизнес, где допустимо только безупречное доверие. Раз лидеры рынка, Verisign и Thawte могут держать планку, то другим пора подтягиваться или сдохнуть.
Да начнётся же холивар (так нужно было закончить статью)!
Присоединяюсь к вышеперечисленным вопросам, так как их много и ещё приведу парочку.
1. DDOS на определённый сайт. Представьте себе 100 Гб/с трафик на сайт, который будет обрабатывать лишь запросы сертификатов. Пример. Пусть есть 20 пользователей, у которых в списке есть 10 доверенных «центров». Каждый из 20 пользователей обращается к www.google.com и пошли по пунктам. В конечном итоге получаем 20*10=200 запросов (и это хорошо, если дело обходится без шифрования). Теперь умножьте всё на 10^6 пользователей (как минимум) и на 10 доверенных центров.
2. Выше уже спросили про DNS, про то как выбирать доверенные сайты и т.д. Я лишь добавлю, что по мимо обычных пользователей (которыми мы с вами являемся), есть ещё госструктуры, банки, коммерческие организации, которым по мимо слов «посмотрите это работает», нужны ещё гарантии, оценка рисков и т.д.
P.S. По поводу воздуха. Попробуйте прикинуть сколько нужно вложить денег на создание и обслуживание 1 УЦ, так чтобы им заинтересовались корпоративные пользователи. Т.е. вы обеспечили достаточный уровень гарантий. А ещё прибавьте к пользователям гостструктуры, и посмотрите что выйдет.
Присоединяюсь к вышеперечисленным вопросам, так как их много и ещё приведу парочку.
1. DDOS на определённый сайт. Представьте себе 100 Гб/с трафик на сайт, который будет обрабатывать лишь запросы сертификатов. Пример. Пусть есть 20 пользователей, у которых в списке есть 10 доверенных «центров». Каждый из 20 пользователей обращается к www.google.com и пошли по пунктам. В конечном итоге получаем 20*10=200 запросов (и это хорошо, если дело обходится без шифрования). Теперь умножьте всё на 10^6 пользователей (как минимум) и на 10 доверенных центров.
2. Выше уже спросили про DNS, про то как выбирать доверенные сайты и т.д. Я лишь добавлю, что по мимо обычных пользователей (которыми мы с вами являемся), есть ещё госструктуры, банки, коммерческие организации, которым по мимо слов «посмотрите это работает», нужны ещё гарантии, оценка рисков и т.д.
P.S. По поводу воздуха. Попробуйте прикинуть сколько нужно вложить денег на создание и обслуживание 1 УЦ, так чтобы им заинтересовались корпоративные пользователи. Т.е. вы обеспечили достаточный уровень гарантий. А ещё прибавьте к пользователям гостструктуры, и посмотрите что выйдет.
А где, собственно, рассказ про принцип работы этой самой Convergence?
Принцип работы можете почитать на вики в разделе PGP.
Блин, да так бы и сказали, что user-centred trust. Я уж думал, там кто-то что-то новое придумал.
Я конечно рискую нарваться на грубость, но, на мой взгляд, предпосылки создания Convergence появились из-за непонимания принципов PKI.
УЦ не продает воздух под видом сертификатов. Идеологический принцип УЦ — перемещение ответственности за принятие решения о доверии тому или иному открытому ключу на организацию, которая выдала сертификат (удостоверение) открытого ключа.
То есть Вы платите не за набор бит, а за ответственность, которую несет УЦ, удостоверяя Ваш открытый ключ. Чем выше ответственность, тем серьезнее будут проверки перед выдачей сертификата (EV-сертификаты)
По поводу стоимости сертификатов — УЦ несет финансовую и другую ответственность за то, что он выдал сертификат именно владельцу открытого ключа. Исходя из этого, УЦ крайне заинтересован в том, чтобы его инфраструктура была в безопасности в разрезе конфиденциальность-целостность-доступность. В случае нарушения одного из этих свойств — с УЦ может быть привлечен к ответственности. Для примера, в России минимальный размер обеспечения ответственности УЦ — 5 млн. рублей.
Поэтому системы типа Convergence — только для частных пользователей, играющих в безопасность. Эта система немасштабируема и нежизнеспособна при пересчете в деньги.
УЦ не продает воздух под видом сертификатов. Идеологический принцип УЦ — перемещение ответственности за принятие решения о доверии тому или иному открытому ключу на организацию, которая выдала сертификат (удостоверение) открытого ключа.
То есть Вы платите не за набор бит, а за ответственность, которую несет УЦ, удостоверяя Ваш открытый ключ. Чем выше ответственность, тем серьезнее будут проверки перед выдачей сертификата (EV-сертификаты)
По поводу стоимости сертификатов — УЦ несет финансовую и другую ответственность за то, что он выдал сертификат именно владельцу открытого ключа. Исходя из этого, УЦ крайне заинтересован в том, чтобы его инфраструктура была в безопасности в разрезе конфиденциальность-целостность-доступность. В случае нарушения одного из этих свойств — с УЦ может быть привлечен к ответственности. Для примера, в России минимальный размер обеспечения ответственности УЦ — 5 млн. рублей.
Поэтому системы типа Convergence — только для частных пользователей, играющих в безопасность. Эта система немасштабируема и нежизнеспособна при пересчете в деньги.
Нет, не рискуете, так как вы говорите правильные вещи. Правда на счёт «немасштабируема» — вы ошибаетесь. Наоборот, её очень легко расширять. Правда смотря с чем сравнивать.
> УЦ несет финансовую и другую ответственность за то, что он выдал сертификат именно владельцу открытого ключа
Вот возьмем VeriSign и его сертификат «VeriSign Class 3 Public Primary Certification Authority — G5», которым сейчас является корнем цепочки, удостоверяющей сайт Сбербанк Онлайн (ну и много чего ещё, конечно).
Судя по сайту VeriSign, тотальная их ответственность за данный сертификат перед всеми клиентами не превышает $100000. Т.е. если кто-то подделает сертификат сайта Сбера (так или иначе) и получит доступ к счетам пользователей, максимум на что пострадает УЦ VeriSign — эти самые $100000.
Я считаю, это несколько маловато, по сравнению с суммами, которые сертификат защищает.
Вот возьмем VeriSign и его сертификат «VeriSign Class 3 Public Primary Certification Authority — G5», которым сейчас является корнем цепочки, удостоверяющей сайт Сбербанк Онлайн (ну и много чего ещё, конечно).
Судя по сайту VeriSign, тотальная их ответственность за данный сертификат перед всеми клиентами не превышает $100000. Т.е. если кто-то подделает сертификат сайта Сбера (так или иначе) и получит доступ к счетам пользователей, максимум на что пострадает УЦ VeriSign — эти самые $100000.
Я считаю, это несколько маловато, по сравнению с суммами, которые сертификат защищает.
Ну Вы же должны понимать, что сертификат — своего рода страховка. Здесь Вы также, как и при страховании, перекладываете ответственность.
УЦ, в свою очередь, оценивает риски (риск что УЦ вводят в заблуждение, риск компрометации закрытого ключа УЦ и пр.), соотношение между величиной этих рисков и затратами на их минимизацию (стоимость проверки владельца открытого ключа по определенному уровню контроля, стоимость защиты инфраструктуры УЦ и пр.), страховую премию (стоимость сертификата) и из этих величин выводит стоимость страховой выплаты (величина ответственности).
Это всего лишь значит, что Сбербанк эта сумма страховой выплаты устраивает. Вот и все. В противном случае для Сбера сертификат стоил бы дороже, так как повышается ответственность УЦ.
УЦ, в свою очередь, оценивает риски (риск что УЦ вводят в заблуждение, риск компрометации закрытого ключа УЦ и пр.), соотношение между величиной этих рисков и затратами на их минимизацию (стоимость проверки владельца открытого ключа по определенному уровню контроля, стоимость защиты инфраструктуры УЦ и пр.), страховую премию (стоимость сертификата) и из этих величин выводит стоимость страховой выплаты (величина ответственности).
Это всего лишь значит, что Сбербанк эта сумма страховой выплаты устраивает. Вот и все. В противном случае для Сбера сертификат стоил бы дороже, так как повышается ответственность УЦ.
> Это всего лишь значит, что Сбербанк эта сумма страховой выплаты устраивает. Вот и все.
Постановка выплаты не такая.
Суммарная компенсация всем в мире, кто доверился сертификату VeriSign Class 3 — $100000.
Т.е. если пострадает 1000 организаций, каждой из них причитается около $100.
Я считаю, что именно это и есть торговля воздухом.
Постановка выплаты не такая.
Суммарная компенсация всем в мире, кто доверился сертификату VeriSign Class 3 — $100000.
Т.е. если пострадает 1000 организаций, каждой из них причитается около $100.
Я считаю, что именно это и есть торговля воздухом.
Не, докладчик там вполне себе даже на уровне. Известный уважаемый человек ) Он даже встретился (по его словам) с автором SSL чтобы уточнить некоторые детали.
И он правильно озвучил проблему (в своем видеодокладе, перевод немного в другом ключе) — сейчас единожды став центром сертификации, компания остается им навсегда — по крайней мере если наберет достаточно большую базу абонентов, чтобы ключевым игрокам не выгодно было связываться. Другой вопрос, что альтернатива предложена ужасная.
И он правильно озвучил проблему (в своем видеодокладе, перевод немного в другом ключе) — сейчас единожды став центром сертификации, компания остается им навсегда — по крайней мере если наберет достаточно большую базу абонентов, чтобы ключевым игрокам не выгодно было связываться. Другой вопрос, что альтернатива предложена ужасная.
Скажите, я переизобрел PGP?:
На мой взгляд у существующей системы две проблемы — невозможность прекратить доверять любому издателю сертификатов не прекращая при этом доверять известным тебе сертифицированным им персонам. Проблему, как мне кажется, можно решить созданием персонального, личного хранилища доверенных и недоверенных ключей, которое всегда доступно пользователю. Однажды доверившись какому-то публичному ключу и убедившись, что стоящие за ним люди не желают тебе зла, нет нужды вновь и вновь проверять его. «Проверка сертификата» нужна лишь для первого знакомства. Убедившись, что люди, стоящие за неким ключем не достойны нашего доверия, мы перемещаем ключ в хранилище недоверенных. И нам уже не важно, насколько хорош его сертификат.
Однако, как принять предварительное решение о доверии новому ключу? Нужна возможность получать доступ к личным хранилищам сертификатов тех персон, которых мы считаем авторитетами. Это аккуратно, сознательно отобранный список. Или несознательно сокопированный у кого-то из авторитетов. Наших друзей, наших учителей, наших родителей, наших кумиров, наших противников. И всяких специальных компаний, кому мы доверям, в намерения которых мы и правда сами верим.
Принимая первое решение, мы должны видеть в легко воспринимаемой форме, кто из них знает, кто из знающих доверяет, а кто — нет полученному ключу.
И только мы сами должны иметь возможность принимать решение о том, в какой список внести новый ключ или о том, стоит ли его перемещать между списками.
Выходя на мировую сцену новому участнику нужно будет получить доверие некоторых крупных компаний — аудиторов. Нескольких компаний, верных своей репутации, которую в такой системе очень легко потерять. Чем серьезнее намерения участника, тем более широкому кругу специалистов он о них расскажет. Тем большее их число ему поверит.
А нам останется лишь понять (рекурсивно воспользовавшись указанным алгоритмом), доверяем ли мы этим аудиторам.
На мой взгляд у существующей системы две проблемы — невозможность прекратить доверять любому издателю сертификатов не прекращая при этом доверять известным тебе сертифицированным им персонам. Проблему, как мне кажется, можно решить созданием персонального, личного хранилища доверенных и недоверенных ключей, которое всегда доступно пользователю. Однажды доверившись какому-то публичному ключу и убедившись, что стоящие за ним люди не желают тебе зла, нет нужды вновь и вновь проверять его. «Проверка сертификата» нужна лишь для первого знакомства. Убедившись, что люди, стоящие за неким ключем не достойны нашего доверия, мы перемещаем ключ в хранилище недоверенных. И нам уже не важно, насколько хорош его сертификат.
Однако, как принять предварительное решение о доверии новому ключу? Нужна возможность получать доступ к личным хранилищам сертификатов тех персон, которых мы считаем авторитетами. Это аккуратно, сознательно отобранный список. Или несознательно сокопированный у кого-то из авторитетов. Наших друзей, наших учителей, наших родителей, наших кумиров, наших противников. И всяких специальных компаний, кому мы доверям, в намерения которых мы и правда сами верим.
Принимая первое решение, мы должны видеть в легко воспринимаемой форме, кто из них знает, кто из знающих доверяет, а кто — нет полученному ключу.
И только мы сами должны иметь возможность принимать решение о том, в какой список внести новый ключ или о том, стоит ли его перемещать между списками.
Выходя на мировую сцену новому участнику нужно будет получить доверие некоторых крупных компаний — аудиторов. Нескольких компаний, верных своей репутации, которую в такой системе очень легко потерять. Чем серьезнее намерения участника, тем более широкому кругу специалистов он о них расскажет. Тем большее их число ему поверит.
А нам останется лишь понять (рекурсивно воспользовавшись указанным алгоритмом), доверяем ли мы этим аудиторам.
Вычитал собственный текст, исправляюсь:
неясно перечисленный проблемы существующей системы:
1) усложненный контроль над тем, кому мы доверяем.
2) невозможность прекратить доверять издателям сертификатов, не прекращая доверять пользователям.
А еще, проверка «персонализированного сертификата» (вот этой сборной информации о доверии к ключу твоего личного круга авторитетов) нужна не только при знакомстве, но может быть снова инициирована в любой момент (если у нас возникли подозрения относительно намерений людей, стоящих за ключем).
И каждому принятию или изменению решения должна быть опциональная возможность сопоставить комментарий. Который позже можно будет увидеть самому, чтобы освежить в памяти причины, например, опрометчивых действий. Так же его смогут увидеть люди, которые считают вас авторитетами, и это, возможно, поможет им в выборе.
Система не требует ото всех участников публиковать свои решения о доверии, не требует публиковать все решения.
неясно перечисленный проблемы существующей системы:
1) усложненный контроль над тем, кому мы доверяем.
2) невозможность прекратить доверять издателям сертификатов, не прекращая доверять пользователям.
А еще, проверка «персонализированного сертификата» (вот этой сборной информации о доверии к ключу твоего личного круга авторитетов) нужна не только при знакомстве, но может быть снова инициирована в любой момент (если у нас возникли подозрения относительно намерений людей, стоящих за ключем).
И каждому принятию или изменению решения должна быть опциональная возможность сопоставить комментарий. Который позже можно будет увидеть самому, чтобы освежить в памяти причины, например, опрометчивых действий. Так же его смогут увидеть люди, которые считают вас авторитетами, и это, возможно, поможет им в выборе.
Система не требует ото всех участников публиковать свои решения о доверии, не требует публиковать все решения.
Однажды доверившись какому-то публичному ключу и убедившись, что стоящие за ним люди не желают тебе зла, нет нужды вновь и вновь проверять его. «Проверка сертификата» нужна лишь для первого знакомства.Здесь ошибка. Сертификат может быть скомпрометирован в любое время, даже без ведома владельца. Поэтому нужен механизм отзыва.
А кто может отозвать сертификат без ведома владельца?
Тот кто его выдал, разумеется.
По какому поводу?
В такой системе сертификат каждый выдает себе сам. И я, конечно, согласен, что владельцу ключа нужна возможность объявить о прекращении доверии к самому себе (собственному ключу, точнее).
Хорошо бы иметь возможность наделить нескольких лиц правом объявления о компроментации ключа, и, если большинство из них поместит его в недоверенный список — это будет так же серъезным поводом для отказа в коммуникации.
Но позволять кому-то безоговорочно решать, что я — это не я… это тот тоталитаризм, от которого хотелось бы уйти.
Хорошо бы иметь возможность наделить нескольких лиц правом объявления о компроментации ключа, и, если большинство из них поместит его в недоверенный список — это будет так же серъезным поводом для отказа в коммуникации.
Но позволять кому-то безоговорочно решать, что я — это не я… это тот тоталитаризм, от которого хотелось бы уйти.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Convergence — возможная замена Certification Authority System