Convergence — возможная замена Certification Authority System



    Доброго всем времени суток!

    Сразу хотелось бы дать две ссылки на материалы, на основе которых составлена эта заметка. Можно ознакомиться непосредственно с источниками и не читать топик, представляющий из себя всего-навсего мой вольный перевод-пересказ основных моментов с небольшим количеством отсебятины.
    BlackHat USA 2011: SSL And The Future Of Authenticity
    Moxie Marlinspike :: Blog — SSL And The Future Of Authenticity


    Вводная


    Пару дней назад на хабре прошла статья, посвященная получению SSL/TLS сертификата. Но мое внимание привлекла не столько сама статья, сколько комментарии к ней, само обсуждение данной предметной области, а вернее сказать, по большому счету, его отсутствие. Разворачивать дискуссию на месте не стал и решил, что имеет смысл завести отдельный топик, в котором можно было бы осветить проблему вместе с вариантами ее решения, а так же обсудить все это дело в комментариях.

    Позвольте процитировать пару комментариев из обозначенной выше статьи:
    Сертификаты — прекрасный пример торговли воздухом. Причем за вполне себе реальные деньги получаешь набор байт, который ничего не гарантирует и ни от чего не защищает.… (с) angry_elf
    и ответ на него:
    Предложите свой вариант защиты от MiM! Тогда вы будите торговать воздухом или станете на столько богатым и популярным, что вообще ничего не нужно будет делать. (с) okazymyrov.
    Там же еще ряд комментариев, из которых ясно, что людей как и раньше волнуют следующие темы, проблемы и вопросы:
    • Торговля сертификатами — торговля воздухом? За что мы платим деньги ?
    • Справляются ли удостоверяющие центры (УЦ) с возложенными на них обязанностями и можно ли считать, что они предоставляют реальную защиту, или это можно ставить под сомнение ?
    • Что делать горемышным Алисе и Бобу чтобы защитить себя от коварного Человека-По-Середине ?

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

    Немного теории


    Защищенная передача данных между узлами в сети Интернет происходит посредством протокола HTTPS (расширение протокола HTTP), в котором передаваемые данные инкапсулируются в криптографический протокол SSL/TLS (TLS — это разработанный на основе SSL 3.0 стандарт), который в свою очередь базируется на использовании алгоритма асимметричного шифрования с открытым ключом — RSA. А общая проблема всей асимметричной криптографии – сложность проверки аутентичности открытых ключей. Поэтому во всех криптографических протоколах, основанных на алгоритмах с открым ключом принципиальное значение имеет вопрос доверия. А именно как быть уверенным в том, что полученый от сервера открытый ключ действительно тот ключ, который использует сервер с которым вы хотите установить защищенный канал связи, а не ключ, расположившегося в Вашем сегменте сети Человека-По-Середине, который заворачивает весь Ваш HTTPS траффик на свой sslsniff. Имеется проблема доверия.

    Удостоверяющие центры


    Исторически так сложилось, что проблему доверия стали решать с помощью такой технологии аутентификации как PKI (Public Key Infrastructure). Это комплексная система мер, которая связывает открытые ключи с личностью пользователя посредством УЦ. В основе PKI лежит использование криптографической системы с открытым ключом и несколько основных принципов:
    1. Закрытый ключ известен только его владельцу.
    2. УЦ создает сертификат открытого ключа, таким образом удостоверяя этот ключ.
    3. Никто не доверяет друг другу, но все доверяют УЦ.
    4. УЦ подтверждает или опровергает принадлежность открытого ключа заданному лицу, которое владеет соответствующим закрытым ключом.

    Фактически, PKI представляет собой систему, основным компонентом которой является УЦ и пользователи, взаимодействующие между собой посредством УЦ.
    Работает это так: Боб хочет разрешить Алисе и другим своим подругам устанавливать с ним защищенные соединения. Он приходит в УЦ со своим открытым ключом, а так же прочими данными (имя, адрес и тд — все то, что будет в сертификате), тем или иным способом верифицирует свою личность (многие это делают просто по e-mail) и регистрирует свой ключ. УЦ выдает ему сертификат. Дальше Боб передает его своим подругам, которые могут убедится в том, что он действительно принадлежит Бобу, проверив цивровую подпись УЦ, которому они полностью доверяют.

    Проблема


    В чем проблема? Проблема в том что за Вас решают кому Вам доверять. В тот самый момент, когда хозяин ресурса решает, что получать сертификат он будет, скажем, у Comodo — он решает за Вас кому Вы должны будете доверять. Кто-то возможно скажет, что его ресурс — ему и решать у кого ему получать сертификат. Да, но данные то (например credit card data) этот ресурс процессит Ваши! И это, мать ее, проблема! Все бы ничего, если бы надежность существующей системы удостоверяющих центров никто не ставил под сомнение и они б безукоризненно выполняли свою работу, но это не так. УЦ представляют собой частные компании, в них работают живые неизвестные Вам люди, которые могут преследовать свои корыстные интересы, могут быть подкуплены, запуганы, шантажированы. УЦ может быть скомпрометирован сторонними злоумышленниками (ака хакирами). Можно вспомнить достаточно шумную историю с Comodo УЦ, случившуюся весной этого года (линк), в ходе которой он жидко обоср был скомпрометирован злоумышленниками и буквально на днях произошедшию оказию с DigiNotar УЦ (линк1, линк2). С DigiNotar проблему как-то худо-бедно решили — к черту вырезали их из списка корневых сертификатов в браузерах и дело с концом (Because the extent of the mis-issuance is not clear, we are releasing new versions of Firefox… shortly that will revoke trust in the DigiNotar root). Но Comodo не DigiNotar, покрупнее рыба. Что было с Comodo? Все поворчали, поворчали да забыли. Как был Comodo в списке корневых сетификатов браузеров, так и остался, как продавал сертификаты, так и продает. Можете спать спокойно, продолжайте доверять тем, кто у Вас прописан в Certificate Authority листе Вашего браузера. И это ведь только те случаи, которые были освещены в прессе, а сколь было тех, о которых всем не рассказали, тех о которых даже и не узнали сами, сколько на данный момент существует формально валидных по факту, но левых по своей природе сертификатов? И даже если исключить фактор неизвестных злоумышленников, компрометирующих работу удостоверящих центров сертификации со стороны, то что насчет того, что творится за кулисами самих этих центров? Что насчет представителей спец. служб? Бред параноика? Взгляните на эту статью и на материалы по ссылкам в ней — Устройства сил правопорядка подрывают SSL. Вообщем небольшие проблемы как ни крути, но имеются, только слепой их не видит.

    Решение


    Как известно существует две модели организации инфраструктуры сертификатов: централизованная (PKI) и децентрализованная (реализуемая на основе т. н. сетей доверия — web of trust), на данный момент получившая наибольшее распространение в сетях PGP/GPG. О всех прелестях централизованной модели сказано выше. Остановимся на распределённой системе, в которой нет единого источника сертификации, напротив, каждый пользователь самостоятельно решает, кому он доверяет, а кому не доверяет в удостоверении других открытых ключей, создавая тем самым личную сеть доверия. Такой подход обеспечивает гибкость и устойчивость системы к любому злонамеренному воздействию: можно повлиять на один узел распределённой системы (в этом случае исключить его из сети доверия), но остальные сохранят надёжность.

    Можно пересмотреть централизованную модель, на основе которой доверительные отношения инициирует сам ресурс, запрашивая сертификат в конкретном УЦ, тем самым впоследствие обязуя всех своих клиентов взаимодействовать именно с этим УЦ для проверки своей подлиности и применить децентрализованный подход, в ходе которого доверительные отношения между клиентом и сервером инициирует сам клиент и взаимодействие осуществляется следующим образом:
    1. Клиент хочет установить защищенный канал связи с неким сайтом. Он обращается к этому сайту и получает от него SSL-сертификат. Встает вопрос — это в самом деле сертификат этого сайта или сертификат, который подсунул Человек-По-Середине? Нужно проверить.
    2. Клиент обращается к сформированному им списку удостоверяющих серверов и спрашивает у каждого из них — «какой сертификат ты видишь на этом сайте ?».
    3. В ответ на запрос сервера обращаются к заданному сайту и тоже получают от него сертификат, а затем пересылают их запрашивающему клиенту, заверяя своей подписью.
    4. Клиент сравнивает сертификат, который он получил непосредственно от сервера с сертификатами полученными от удостоверяющих серверов.
    5. Если сертификаты совпадают — все нормально, работаем. Не совпадают — где-то рядом Человек-По-Середине и возможно быть беде.


    Реализация


    На традиционно прошедней в начале прошлого месяца в Лас-Вегасе конференции BlackHat, небезызвестный в исследовательских кругах security-специалистов Moxie Marlinspike представил проект под названием Convergence (An agile, distributed, and secure alternative to the Certificate Authority system), в котором и реализовал обозначенные идеи. В рамках проекта удостоверяющие сервера были названы Notary (Нотариус).

    Кочаем и ставим FireFox плагин — Сonvergence:


    Формируем Notary-лист. Для этого можно воспользоваться списоком уже существующих серверов — Notary list, можно поднять свои Notary-сервера — Running-a-Notary, можно сделать и первое и второе.



    Из особенностей настройки системы — можно регулировать порог паранои, изменяя опцию Verification Treshold.


    Раньше, при использовании традиционной Certification Authority System было:


    Активируем плагин, переходим на Convergence:


    Приятные мелочи:
    • Администраторам сайтов ничего не нужно делать на стороне сервера. Нет нужды устраивать миграцию Интернета на новую систему аутентификации. Все уже работает, осталось только реализовать плагины для всех основных браузеров.
    • Больше нет предупреждений о самоподписанных сертификатах, так как клиенту не важно кем он подписан, клиенту важно быть уверенным в том, что он использует сертификат предоставляемый сервером а не Человеком-По-Середине.


    Заключение


    Who do I Have to trust?
    … and for how long?
    A prescribed set of people forver,
    Or time to try Convergence ?
    Поделиться публикацией

    Комментарии 55

      0
      1. Не хозяин ресурса, вообще говоря, решает кому доверять пользователю. А поставщик ОС/браузера (не хозяин ресурса устанавливает сертификаты корневых центров)
      2. Что помешает подменить удостоверяющие сервера списка?
        0
        3. В моем мире выбор между «делать администратору на стороне сервера»
          0
          … много меньше «реализовать плагины для всех основных браузеров + установить их всем пользователям»
          хабр съел часть комментария
          0
          1. Вообще говоря, поставщик ОС/браузера определяет список кому якобы можно доверять, а имеено хозяин ресурса уже решает у кого из этого списка приобретать сертификат: Comodo, DigiCert, GoDaddy, VeriSign или иного продавца. Но это не важно, важно то, что определяете не Вы.
          2. Пожалуйсто, разверните Вашу мысль по-подробней
            0
            2.
            >> Клиент обращается к сформированному им списку удостоверяющих серверов и спрашивает у каждого из них — «какой сертификат ты видишь на этом сайте ?».
            Подменен каждый из удостоверяющих серверов (великим китайским/великим иранским/беларусским файрволами)
            Защита не сработает?
              0
              Что значит подменен? Ответ ведь эти сервера Вам не просто в виде «Success» или «Fail, Ahtung!» дают, они подписывают свой ответ своим закрытым ключом. И Вы, используя на своей стороне их открытый ключ, уже можете убедится что ответ пришел именно от них.
                0
                Откуда на моей стороне взялся их открытый ключ?
                  0
                  Вы его прописали сами при добавлении Notary. Тоесть тут уже Вы решаете кого себе прописывать, кого наоборот удалять, кому доверять, а не производители ОС/браузеров.
                    0
                    А если открытый ключ подделан гэбнёй уже на этапе добавления?
              0
              >> 1. Вообще говоря, поставщик ОС/браузера определяет список кому якобы можно доверять,
              А что мешает это сделать вам? Вы с лёгкостью можете удалить все сертификаты и добавить свои. Вопрос только в следующем: сколько друзей (коллег, бизнес-партнёров) вы к этому подключите, так чтобы вы (вам) доверяли. Плюс возникает вопрос к компрометацией ключей или вывода их из системы (ака архивирование/уничтожение).

              За вас это уже сделали и предлагают свои услуги. А покупать их или доверять им — это уже ваше дело. С точки зрения криптографии всё отлично. Другое дело нечеловеческий фактор и несовершенство реализации таких систем.

              Вы рассмотрите УЦ, которые предоставляют услуги госструктурам Украины (думаю, что в России похожая ситуация). Там только аппаратная реализация всех криптопреобразований + оценка угроз и т.д. и т.п.
            0
            Т.е. каждое https соединение — это n+1 соединений для сервера, где n — среднее число нотариусов? Дорого же такая технология обойдется владельцам сайтов! Параноики — они и так знают каким CA доверять, а каким нет. Гугли и банки будут наверняка использовать class 3 у известного имени вроде Verisign, плюс EV сертификаты, а для более мелких и казуальных SSL каналов игра не стоит свеч, ни для защитников, ни для взломщиков.
              0
              На самом деле каждый раз мучать сервер не нужно, вопрос решается за счет кэширования как на клиенте, так и на нотариусе. Дополнительная нагрузка незначительна. Насчет гуглей и банков, класс3, EV сертификатов и прочего — тут как бы не о том речь совсем. Речь о том, как клиенту подстраховаться от Человека-По-Середине. И тут не важно что там за сертификат на сервере — class3 или self-signed. Тут только сам клиент уже для себя решает какую систему использовать — централизованную классическую CA System или Convergence и ничто не влияет на его решение.
                +5
                Кэширования? О, боги, только не кэширование, не то начнется бесконечное количество false positives из-за тормознутых нотариусов. Впрочем, это мелочи. Идея сама понятна, красива, но не очень жизненна.

                Речь о том, как клиенту подстраховаться от Человека-По-Середине. И тут не важно что там за сертификат на сервере — class3 или self-signed.

                Я не соглашусь. Людям абсолютно наплевать на виды и названия атак. Им нужно подтверждение абонента. Если меня заставили поверить в фальшивого абонента, то по последствиям мне все равно где был «Человек»: посредине, с краю, или кто-то DNS заспуфил и увел меня вообще не туда. Что приводит нас к следующей мысли: безопасность — мера комплексная! Она никогда не решалась и не решится только технически как минимум потому, что нам необходимо подтверждение живого/юридического абонента, а он по жизни подтверждается не техникой, а паспортом/документом о создании компании. Вот здесь и вступают в дело проверки, адвокаты, class 3 сертификаты, extended validation. Именно та бюрократия, которая позволит перевести доверие из real life в наборы байт. А с бюрократией мы получаем целый букет жизненных (в дополнение к техническим!) проблем: безопасность личного ключа CA, доверие к персоналу, сейфы, бункеры, бэкапы на другом континенте, служба безопасности, служба аудита и т.д. и т.п. Всё это в комплексе более-менее решает задачу подтверждения, а не только конкретная защита от MitM. Convergence — не панацея. Он точно так же позволит обкуренной и непонятно как попавшей в списки root CA конторе выдать/подтвердить фальшивый сертификат, создавая тем самым дыру в безопасности. Пример очень показателен: с технической точки зрения у голландцев не было никаких проблем. Дыра оказалась именно в той части CA guidelines, которая относится к чистой бюрократии.
                  0
                  На самом деле я не думаю и не говорю что Convergence — панацея. Но если проводить паралели с системой CA, то оно смотрится удачнее. Хотя признаю, что еще удачнее смотрится вариант в котором оба подхода сочитаются и закрывают слабые стороны друг-друга, мое упущение что не рассмотрел это в статье. В этом случае, если не в виде замены, то в виде одной из составляющих комплексной меры — идея очень жиненна и красива.
                    0
                    А кэш может быть кстати и на руку, смотрите коммент ниже
                    +2
                    > Convergence — не панацея. Он точно так же позволит обкуренной и непонятно как попавшей в списки root CA конторе выдать/подтвердить фальшивый сертификат, создавая тем самым дыру в безопасности

                    даже лучше: конвергенс позволит мне сделать фальшивый сертификат *без* обкуренного CA!

                    то есть берем какой-то домен, типа go0g1e.com, выписываем себе сертификат на имя «Google Inc.» и все «нотариусы» его радостно подтверждают.

                    каким местом тут web of trust, я не понимаю — именно *сети* доверия нет.
                +4
                > Больше нет предупреждений о самоподписанных сертификатах, так как клиенту не важно кем
                > он подписан, клиенту важно быть уверенным в том, что он использует сертификат предоставляемый
                > сервером а не Человеком-По-Середине.

                Да-да. DNS сломали, сайт ведёт на левый хост, который мимикрирует под указанный. Все видят один сертификат — поддельный.
                  0
                  Это уже не проблема MitM, а больше проблема из разряда Человека-который-внутри. Но в целом да, традиционная модель при прочих равных (если закрыть на все остальные ее минусы глаза), в данном случае дает надежность в отличии от предлагаемой.
                  +2
                  Кроме спуфинга DNS, означенного выше, есть еще проблема MtM, имеющего доступ к трафику датацентра. Т.е. если влезть между сервером и внешним миром, то нотариусы ничего подозрительного не обнаружат.
                    0
                    Вообще, если предположить, что MtM не работает 100% времени и устанавливается не в момент запуска сервера, то MtM с кэшем/историей проверок могут сработать. Т.е. они будут обращаться к исходному серверу не при каждом запросе клиента, а будут кэшировать данные и смотреть — не меняется ли issuer со временем.
                      0
                      Да, в этом случае notary consensus'а не получится и можно будет обоснованно насторожиться.
                    +5
                    Эта штука не решает проблему mitm, так как атакующий может сидеть на канале сервера (датацентр, апстрим провайдер, магистральный канал, и.т.д.). В таком случае все сервера Notary получат сертификат созданный атакующим. То-же самое произойдет при взломе DNS.
                    К тому-же CA выдающий сертификаты удостоверяет что сертификат принадлежит конкретному человеку/компании, а для EV SSL сертификатов — еще и что сертификат выдан серьезному бизнесу, а не шарашкиной конторе зарегистрированной на бомжа вчера вечером. Соответственно браузер показывает КОМУ вы передаете свои личные данные и кредитные карты. А Notary подтверждает только то, что соединение установлено хрен знает с кем, но оно устанавливается именно с ним из разных точек интернета.
                    Еще одна проблема — отказоустойчивость этой системы. Что делать если один из серверов Notary не отвечает? А если не отвечают все? А если злонамеренный провайдер заблокировал все эти сервера и ждет пока мы полезем на митмимый сайт (а мы полезем, никуда не денемся, коль нет другого варианта).
                      0
                      А также атакующий может сидеть на канале клиента (маршрутизатор, троян). В таком случае клиент получит положительный ответ от всех Notary.

                      Вывод. Где бы ни сидел атакующий, эта штука не решает проблему MitM.

                      Или мы что-то упустили?
                        0
                        Пропустили. Общение с Notary идет с использованием DSA.
                          0
                          Подробнее, пожалуйста. DSA это что в данном случае, «цифровая подпись»?
                          Или ссылку дайте, где почитать.
                            0
                            Да, именно. Notary подписывают свои ответы.
                              0
                              А еще подробнее? :/
                              Сертификаты как бы тоже подписываются, однако же…
                                0
                                Да, подписываются, но кем — определяете не Вы, и в случае чего что случись — Вы тоже ничего не решаете и не определяете по большому счету (ну не будете же вы у себя из корня comodo сертификат выпиливать?). А в данном случае список notary формируете для себя Вы сами, если хотите можете даже свои notary-серевера понаподнимать — исходники notary серверов доступны.
                      +1
                      ИМХО удовлетворительным решение проблемы взлома CA и злонамеренных CA будет принятие разработчиками всех браузеров соглашения, согласно которому при обнаружении фальшивого сертификата корневой сертификат CA немедленно удаляется невзирая на то, что от него зависят 100500 сайтов. Одна ошибка — расстрел. Тогда только достойные останутся в живых.
                        0
                        Даже при принятия такого решения, где гарантии того, что в случае избежания публичной огласки инцидента, оно будет соблюдаться? Ну и остальные неприятные моменты, когда непонятно что творится не по ошибке, а намеренно.
                          0
                          Чтобы решение соблюдалось, обнаружение инцидентов должно выполняться третьей стороной, а лучше несколькими, чтобы не возникло желание «договориться» с проштрафившимся CA. После обнаружения инцидента должна следовать немедленная огласка. А после огласки — исключение потерявшего доверие CA.

                          > Ну и остальные неприятные моменты, когда непонятно что творится не по ошибке, а намеренно.
                          Главное правило: доверие дается один раз. А как оно потеряно: по ошибке или намеренно — неважно. В природе появился сертификат выданный на чужие идентификационные данные — прощай бизнес. CA не может предоставить документы доказывающие что подозрительный сертификат выдан тому, кому заявлено — он считается фальшивым, со всеми вытекающими.
                          0
                          вариант имеет некую долю справедливости, только последствия…
                          Представьте, сколько бизнесов не смогу в один прекрасный день работать, и, что более важно для пользователей сертификатов — сколько будет стоить каждый такой сертификат? Ведь компании сразу загнут стоимость сертификатов, оправдывая это затратами на обеспечение 200% надежности, ведь «второго шанса» у них не будет.
                            +1
                            Интересно Вы, однако, рассуждаете. Тогда что же это такое получается, щас никто не загибает цен и эти самые компании расслаблены от того, что понимают, что у них будет и второй и третий шанс? Ну на деле то так оно конечно и выходит и все это понимают, но что бы вот так вот запросто это прям принимать — нет уж. По Вашим словам тогда выходит, что компаниям априори можно обсераться, лишь бы цены за свои байты не взвинчивали. Или я неправильно понял?
                              0
                              Стоимость сертификатов и так задрана, а чтобы обеспечить безболезненную ликвидацию потерявшего доверие CA, можно (при условии содействия со стороны CA) временно разрешить сертификаты созданные задолго до даты компрометации. Затем даем месяц чтобы CA оповестил всех своих клиентов о своей ликвидации, и окончательно блокируем корневой сертификат. Если же CA не оказывает содействия и пытается замолчать инцидент, то корневой сертификат блокируется немедленно, параллельно с громким разоблачением везде где только можно.
                              Жесткие меры, да, но цифровые нотариальные услуги — это высокоответственный бизнес, где допустимо только безупречное доверие. Раз лидеры рынка, Verisign и Thawte могут держать планку, то другим пора подтягиваться или сдохнуть.
                            +3
                            Да начнётся же холивар (так нужно было закончить статью)!

                            Присоединяюсь к вышеперечисленным вопросам, так как их много и ещё приведу парочку.
                            1. DDOS на определённый сайт. Представьте себе 100 Гб/с трафик на сайт, который будет обрабатывать лишь запросы сертификатов. Пример. Пусть есть 20 пользователей, у которых в списке есть 10 доверенных «центров». Каждый из 20 пользователей обращается к www.google.com и пошли по пунктам. В конечном итоге получаем 20*10=200 запросов (и это хорошо, если дело обходится без шифрования). Теперь умножьте всё на 10^6 пользователей (как минимум) и на 10 доверенных центров.
                            2. Выше уже спросили про DNS, про то как выбирать доверенные сайты и т.д. Я лишь добавлю, что по мимо обычных пользователей (которыми мы с вами являемся), есть ещё госструктуры, банки, коммерческие организации, которым по мимо слов «посмотрите это работает», нужны ещё гарантии, оценка рисков и т.д.

                            P.S. По поводу воздуха. Попробуйте прикинуть сколько нужно вложить денег на создание и обслуживание 1 УЦ, так чтобы им заинтересовались корпоративные пользователи. Т.е. вы обеспечили достаточный уровень гарантий. А ещё прибавьте к пользователям гостструктуры, и посмотрите что выйдет.
                              0
                              А где, собственно, рассказ про принцип работы этой самой Convergence?
                                0
                                Принцип работы можете почитать на вики в разделе PGP.
                                  0
                                  Блин, да так бы и сказали, что user-centred trust. Я уж думал, там кто-то что-то новое придумал.
                                    0
                                    Дык в статье ж и написано:
                                    >> Решение

                                    >>Как известно существует две модели организации инфраструктуры сертификатов: централизованная >>(PKI) и децентрализованная (реализуемая на основе т. н. сетей доверия — web of trust), на данный >>момент получившая наибольшее распространение в сетях PGP/GPG.
                                      0
                                      Пардон, пролистывал описание PKI, пропустил.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  +3
                                  Я конечно рискую нарваться на грубость, но, на мой взгляд, предпосылки создания Convergence появились из-за непонимания принципов PKI.

                                  УЦ не продает воздух под видом сертификатов. Идеологический принцип УЦ — перемещение ответственности за принятие решения о доверии тому или иному открытому ключу на организацию, которая выдала сертификат (удостоверение) открытого ключа.
                                  То есть Вы платите не за набор бит, а за ответственность, которую несет УЦ, удостоверяя Ваш открытый ключ. Чем выше ответственность, тем серьезнее будут проверки перед выдачей сертификата (EV-сертификаты)

                                  По поводу стоимости сертификатов — УЦ несет финансовую и другую ответственность за то, что он выдал сертификат именно владельцу открытого ключа. Исходя из этого, УЦ крайне заинтересован в том, чтобы его инфраструктура была в безопасности в разрезе конфиденциальность-целостность-доступность. В случае нарушения одного из этих свойств — с УЦ может быть привлечен к ответственности. Для примера, в России минимальный размер обеспечения ответственности УЦ — 5 млн. рублей.

                                  Поэтому системы типа Convergence — только для частных пользователей, играющих в безопасность. Эта система немасштабируема и нежизнеспособна при пересчете в деньги.
                                    0
                                    Нет, не рискуете, так как вы говорите правильные вещи. Правда на счёт «немасштабируема» — вы ошибаетесь. Наоборот, её очень легко расширять. Правда смотря с чем сравнивать.
                                      0
                                      > УЦ несет финансовую и другую ответственность за то, что он выдал сертификат именно владельцу открытого ключа
                                      Вот возьмем VeriSign и его сертификат «VeriSign Class 3 Public Primary Certification Authority — G5», которым сейчас является корнем цепочки, удостоверяющей сайт Сбербанк Онлайн (ну и много чего ещё, конечно).
                                      Судя по сайту VeriSign, тотальная их ответственность за данный сертификат перед всеми клиентами не превышает $100000. Т.е. если кто-то подделает сертификат сайта Сбера (так или иначе) и получит доступ к счетам пользователей, максимум на что пострадает УЦ VeriSign — эти самые $100000.
                                      Я считаю, это несколько маловато, по сравнению с суммами, которые сертификат защищает.
                                        0
                                        Ну Вы же должны понимать, что сертификат — своего рода страховка. Здесь Вы также, как и при страховании, перекладываете ответственность.
                                        УЦ, в свою очередь, оценивает риски (риск что УЦ вводят в заблуждение, риск компрометации закрытого ключа УЦ и пр.), соотношение между величиной этих рисков и затратами на их минимизацию (стоимость проверки владельца открытого ключа по определенному уровню контроля, стоимость защиты инфраструктуры УЦ и пр.), страховую премию (стоимость сертификата) и из этих величин выводит стоимость страховой выплаты (величина ответственности).

                                        Это всего лишь значит, что Сбербанк эта сумма страховой выплаты устраивает. Вот и все. В противном случае для Сбера сертификат стоил бы дороже, так как повышается ответственность УЦ.
                                          0
                                          > Это всего лишь значит, что Сбербанк эта сумма страховой выплаты устраивает. Вот и все.
                                          Постановка выплаты не такая.
                                          Суммарная компенсация всем в мире, кто доверился сертификату VeriSign Class 3 — $100000.
                                          Т.е. если пострадает 1000 организаций, каждой из них причитается около $100.
                                          Я считаю, что именно это и есть торговля воздухом.
                                            0
                                            Наверное, Вы правы.
                                            Я так думаю, здесь уже вступила в силу оптимизация расходов со стороны УЦ.
                                        0
                                        Не, докладчик там вполне себе даже на уровне. Известный уважаемый человек ) Он даже встретился (по его словам) с автором SSL чтобы уточнить некоторые детали.
                                        И он правильно озвучил проблему (в своем видеодокладе, перевод немного в другом ключе) — сейчас единожды став центром сертификации, компания остается им навсегда — по крайней мере если наберет достаточно большую базу абонентов, чтобы ключевым игрокам не выгодно было связываться. Другой вопрос, что альтернатива предложена ужасная.
                                        0
                                        Скажите, я переизобрел PGP?:

                                        На мой взгляд у существующей системы две проблемы — невозможность прекратить доверять любому издателю сертификатов не прекращая при этом доверять известным тебе сертифицированным им персонам. Проблему, как мне кажется, можно решить созданием персонального, личного хранилища доверенных и недоверенных ключей, которое всегда доступно пользователю. Однажды доверившись какому-то публичному ключу и убедившись, что стоящие за ним люди не желают тебе зла, нет нужды вновь и вновь проверять его. «Проверка сертификата» нужна лишь для первого знакомства. Убедившись, что люди, стоящие за неким ключем не достойны нашего доверия, мы перемещаем ключ в хранилище недоверенных. И нам уже не важно, насколько хорош его сертификат.

                                        Однако, как принять предварительное решение о доверии новому ключу? Нужна возможность получать доступ к личным хранилищам сертификатов тех персон, которых мы считаем авторитетами. Это аккуратно, сознательно отобранный список. Или несознательно сокопированный у кого-то из авторитетов. Наших друзей, наших учителей, наших родителей, наших кумиров, наших противников. И всяких специальных компаний, кому мы доверям, в намерения которых мы и правда сами верим.
                                        Принимая первое решение, мы должны видеть в легко воспринимаемой форме, кто из них знает, кто из знающих доверяет, а кто — нет полученному ключу.

                                        И только мы сами должны иметь возможность принимать решение о том, в какой список внести новый ключ или о том, стоит ли его перемещать между списками.

                                        Выходя на мировую сцену новому участнику нужно будет получить доверие некоторых крупных компаний — аудиторов. Нескольких компаний, верных своей репутации, которую в такой системе очень легко потерять. Чем серьезнее намерения участника, тем более широкому кругу специалистов он о них расскажет. Тем большее их число ему поверит.
                                        А нам останется лишь понять (рекурсивно воспользовавшись указанным алгоритмом), доверяем ли мы этим аудиторам.
                                          0
                                          Вычитал собственный текст, исправляюсь:
                                          неясно перечисленный проблемы существующей системы:
                                          1) усложненный контроль над тем, кому мы доверяем.
                                          2) невозможность прекратить доверять издателям сертификатов, не прекращая доверять пользователям.

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

                                          И каждому принятию или изменению решения должна быть опциональная возможность сопоставить комментарий. Который позже можно будет увидеть самому, чтобы освежить в памяти причины, например, опрометчивых действий. Так же его смогут увидеть люди, которые считают вас авторитетами, и это, возможно, поможет им в выборе.

                                          Система не требует ото всех участников публиковать свои решения о доверии, не требует публиковать все решения.
                                          0
                                          Однажды доверившись какому-то публичному ключу и убедившись, что стоящие за ним люди не желают тебе зла, нет нужды вновь и вновь проверять его. «Проверка сертификата» нужна лишь для первого знакомства.
                                          Здесь ошибка. Сертификат может быть скомпрометирован в любое время, даже без ведома владельца. Поэтому нужен механизм отзыва.
                                            0
                                            А кто может отозвать сертификат без ведома владельца?
                                              0
                                              Тот кто его выдал, разумеется.
                                                0
                                                По какому поводу?
                                                  0
                                                  В такой системе сертификат каждый выдает себе сам. И я, конечно, согласен, что владельцу ключа нужна возможность объявить о прекращении доверии к самому себе (собственному ключу, точнее).

                                                  Хорошо бы иметь возможность наделить нескольких лиц правом объявления о компроментации ключа, и, если большинство из них поместит его в недоверенный список — это будет так же серъезным поводом для отказа в коммуникации.

                                                  Но позволять кому-то безоговорочно решать, что я — это не я… это тот тоталитаризм, от которого хотелось бы уйти.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое