✖


Jump to content

Центр сертификации

(Перенаправлено из Центра сертификации )

В криптографии центр сертификации или центр сертификации ( CA ) — это объект, который хранит, подписывает и выдает цифровые сертификаты . Цифровой сертификат удостоверяет право собственности на открытый ключ названного субъекта сертификата. Это позволяет другим (проверяющим сторонам) полагаться на подписи или утверждения о закрытом ключе, который соответствует сертифицированному открытому ключу. Центр сертификации действует как доверенная третья сторона, которой доверяет как субъект (владелец) сертификата, так и сторона, полагающаяся на сертификат. [1] Формат этих сертификатов определяется стандартом X.509 или EMV .

Одним из наиболее распространенных способов использования центров сертификации является подписание сертификатов, используемых в HTTPS , протоколе безопасного просмотра во Всемирной паутине. Другое распространенное использование — выдача удостоверений личности национальными правительствами для использования в электронной подписи документов. [2]

Обзор

[ редактировать ]

Доверенные сертификаты можно использовать для создания безопасных подключений к серверу через Интернет. Сертификат необходим для того, чтобы обойти злонамеренную сторону, которая находится на пути к целевому серверу, который действует так, как если бы он был целью. Такой сценарий обычно называют атакой «человек посередине» . Клиент использует сертификат ЦС для аутентификации подписи ЦС на сертификате сервера в рамках авторизации перед запуском безопасного соединения. [3] Обычно клиентское программное обеспечение, например браузеры, включает в себя набор доверенных сертификатов ЦС. Это имеет смысл, поскольку многим пользователям необходимо доверять своему клиентскому программному обеспечению. Вредоносный или скомпрометированный клиент может пропустить любую проверку безопасности и при этом обмануть своих пользователей, заставив их поверить в обратное.

Клиентами ЦС являются администраторы серверов, которые запрашивают сертификат, который их серверы будут выдавать пользователям. Коммерческие центры сертификации взимают плату за выдачу сертификатов, и их клиенты ожидают, что сертификат центра сертификации будет содержаться в большинстве веб-браузеров, поэтому безопасные соединения с сертифицированными серверами работают эффективно сразу после установки. Количество интернет-браузеров, других устройств и приложений, доверяющих определенному центру сертификации, называется повсеместностью. Mozilla , являющаяся некоммерческой организацией, выдает несколько коммерческих сертификатов CA для своих продуктов. [4] В то время как Mozilla разработала свою собственную политику, CA/Browser Forum разработал аналогичные рекомендации для доверия CA. Один сертификат ЦС может использоваться несколькими ЦС или их реселлерами . Сертификат корневого ЦС может служить основой для выдачи нескольких промежуточных сертификатов ЦС с различными требованиями проверки.

Помимо коммерческих центров сертификации, некоторые некоммерческие организации бесплатно выдают общедоступные цифровые сертификаты, например Let's Encrypt . Некоторые крупные компании, занимающиеся облачными вычислениями и веб-хостингом, также являются общедоступными центрами сертификации и выдают сертификаты службам, размещенным в их инфраструктуре, например IBM Cloud , Amazon Web Services , Cloudflare и Google Cloud Platform .

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

Коммерческие банки, выпускающие платежные карты EMV, подчиняются Центру сертификации EMV. [5] схемы платежей, которые направляют платежные транзакции, инициированные в торговых терминалах ( POS ), в банк-эмитент карты для перевода средств с банковского счета держателя карты на банковский счет получателя платежа. Каждая платежная карта вместе с данными своей карты предоставляет в POS сертификат эмитента карты. Сертификат эмитента подписан сертификатом EMV CA. POS извлекает открытый ключ ЦС EMV из своего хранилища, проверяет сертификат эмитента и подлинность платежной карты перед отправкой запроса платежа в схему оплаты.

Браузеры и другие клиенты обычно позволяют пользователям добавлять или удалять сертификаты CA по своему желанию. Хотя сертификаты серверов обычно действуют в течение относительно короткого периода времени, сертификаты CA продлеваются дальше. [6] Таким образом, для неоднократно посещаемых серверов менее подвержено ошибкам импорт и доверие к выданному центру сертификации, а не подтверждение исключения безопасности каждый раз при обновлении сертификата сервера.

Реже надежные сертификаты используются для шифрования или подписи сообщений. Центры сертификации также выдают сертификаты конечных пользователей, которые можно использовать с S/MIME . получателя Однако для шифрования требуется открытый ключ , и, поскольку авторы и получатели зашифрованных сообщений, очевидно, знают друг друга, полезность доверенной третьей стороны остается ограниченной проверкой подписи сообщений, отправленных в публичные списки рассылки.

Провайдеры

[ редактировать ]

Во всем мире бизнес центров сертификации фрагментирован: на внутреннем рынке доминируют национальные или региональные поставщики. Это связано с тем, что многие виды использования цифровых сертификатов, например, для юридически обязательных цифровых подписей, связаны с местным законодательством, правилами и схемами аккредитации центров сертификации.

Однако рынок серверных сертификатов TLS/SSL, которым доверяют во всем мире , в основном принадлежит небольшому числу транснациональных компаний. Этот рынок имеет значительные барьеры для входа из-за технических требований. [7] Хотя это и не требуется по закону, новые поставщики могут пройти ежегодный аудит безопасности (например, WebTrust). [8] для центров сертификации в Северной Америке и ETSI в Европе [9] ), который будет включен в качестве доверенного корня веб-браузером или операционной системой.

По состоянию на 24 августа 2020 г. , 147 корневых сертификатов, представляющих 52 организации, являются доверенными в веб-браузере Mozilla Firefox , [10] 168 корневых сертификатов, представляющих 60 организаций, являются доверенными для macOS . [11] и 255 корневых сертификатов, представляющих 101 организацию, являются доверенными для Microsoft Windows . [12] Начиная с Android 4.2 (Jelly Bean), Android в настоящее время содержит более 100 центров сертификации, которые обновляются с каждым выпуском. [13]

18 ноября 2014 года группа компаний и некоммерческих организаций, в том числе Electronic Frontier Foundation , Mozilla, Cisco и Akamai, объявила о создании Let's Encrypt , некоммерческого центра сертификации, который предоставляет бесплатные сертификаты X.509 с проверкой домена , а также программное обеспечение для обеспечения установка и обслуживание сертификатов. [14] Let's Encrypt управляется недавно созданной исследовательской группой по интернет-безопасности , калифорнийской некоммерческой организацией, признанной освобожденной от федеральных налогов. [15]

По данным Netcraft в мае 2015 года, отраслевого стандарта для мониторинга активных сертификатов TLS: «Хотя глобальная экосистема [TLS] является конкурентоспособной, в ней доминирует несколько крупных центров сертификации — на три центра сертификации (Symantec, Comodo, GoDaddy) приходится три -четверти всех выданных сертификатов [TLS] на общедоступных веб-серверах. Первое место занимает Symantec (или VeriSign до того, как он был куплен Symantec) с момента начала [нашего] исследования, и в настоящее время на его долю приходится чуть менее четверти всех выпущенных сертификатов [TLS] на общедоступных веб-серверах. треть всех сертификатов. Чтобы проиллюстрировать эффект различных методологий, среди миллиона самых загруженных сайтов Symantec выдала 44% действующих и надежных сертификатов, что значительно превышает ее общую долю на рынке». [16]

По данным независимой исследовательской компании Netcraft , в 2020 году «DigiCert станет крупнейшим в мире центром сертификации с высокой степенью надежности, контролирующим 60% рынка сертификатов расширенной проверки и 96% сертификатов, проверенных организациями во всем мире. [17]

По состоянию на июль 2024 г. исследовательская компания W3Techs, которая собирает статистику использования центров сертификации среди 10 миллионов крупнейших веб-сайтов Alexa и 1 миллиона лучших веб-сайтов Tranco, приводит список шести крупнейших центров сертификации по абсолютной доле использования, как показано ниже. [18]

Классифицировать Эмитент Использование Доля рынка
1 Давайте зашифруем 52.5% 56.3%
2 ГлобалСайн 13.1% 14.0%
3 ИденТраст 11.6% 12.4%
4 Sectigo (Комодо Кибербезопасность) 6.8% 7.3%
5 ДигиСерт Группа 5.0% 5.3%
6 GoDaddy Группа 4.2% 4.4%

Стандарты валидации

[ редактировать ]

Коммерческие центры сертификации, которые выдают большую часть сертификатов для серверов HTTPS, обычно используют метод, называемый « проверкой домена », для аутентификации получателя сертификата. Методы, используемые для проверки домена, различаются в разных центрах сертификации, но в целом методы проверки домена предназначены для доказательства того, что соискатель сертификата контролирует данное доменное имя , а не какую-либо информацию о личности заявителя.

Многие центры сертификации также предлагают сертификаты расширенной проверки (EV) в качестве более строгой альтернативы сертификатам с проверкой домена. Расширенная проверка предназначена для проверки не только контроля над доменным именем, но и дополнительной идентификационной информации, которая будет включена в сертификат. Некоторые браузеры отображают эту дополнительную идентификационную информацию в зеленом поле в строке URL-адреса. Одним из ограничений EV как решения недостатков проверки домена является то, что злоумышленники все равно могут получить проверенный сертификат для домена-жертвы и развернуть его во время атаки; если бы это произошло, пользователь-жертва мог бы заметить отличие в отсутствии зеленой полосы с названием компании. Существует некоторый вопрос относительно того, смогут ли пользователи признать это отсутствие признаком продолжающейся атаки: тест с использованием Internet Explorer 7 в 2009 году показал, что отсутствие предупреждений EV в IE7 не было замечено пользователями, однако текущий браузер Microsoft , Edge , показывает значительно большую разницу между сертификатами EV и сертификатами, проверенными доменом: сертификаты, проверенные доменом, имеют полый серый замок.

Слабые стороны валидации

[ редактировать ]

Проверка домена страдает от определенных структурных ограничений безопасности. В частности, он всегда уязвим для атак, которые позволяют злоумышленнику наблюдать за проверками домена, которые отправляют центры сертификации. К ним могут относиться атаки на протоколы DNS, TCP или BGP (в которых отсутствует криптографическая защита TLS/SSL) или компрометация маршрутизаторов. Такие атаки возможны либо в сети рядом с ЦС, либо рядом с самим доменом-жертвой.

Один из наиболее распространенных методов проверки домена включает отправку электронного письма, содержащего токен аутентификации или ссылку на адрес электронной почты, который, вероятно, несет административную ответственность за домен. домена Это может быть адрес электронной почты технического контакта, указанный в записи WHOIS , или административный адрес электронной почты, например админ@ , администратор@ , веб-мастер@ , хостмастер@ или postmaster@ домен. [19] [20] Некоторые центры сертификации могут принимать подтверждение с помощью корень@ , [ нужна ссылка ] информация@ или support@ в домене. [21] Теория, лежащая в основе проверки домена, заключается в том, что только законный владелец домена сможет читать электронные письма, отправленные на эти административные адреса.

Реализации проверки домена иногда были источником уязвимостей безопасности. В одном случае исследователи безопасности показали, что злоумышленники могли получить сертификаты для сайтов веб-почты, потому что центр сертификации был готов использовать адрес электронной почты, например [email protected] для домена.com, но не все системы веб-почты зарезервировали имя пользователя «ssladmin», чтобы злоумышленники не смогли его зарегистрировать. [22]

До 2011 года не существовало стандартного списка адресов электронной почты, который можно было использовать для проверки домена, поэтому администраторам электронной почты было неясно, какие адреса необходимо зарезервировать. В первой версии базовых требований CA/Browser Forum , принятой в ноябре 2011 года, был указан список таких адресов. Это позволило почтовым хостам зарезервировать эти адреса для административного использования, хотя такие меры предосторожности по-прежнему не являются универсальными. В январе 2015 года финн зарегистрировал имя пользователя «hostmaster» в финской версии Microsoft Live и смог получить подтвержденный доменом сертификат для live.fi, несмотря на то, что не был владельцем доменного имени. [23]

Выдача сертификата

[ редактировать ]
Процедура получения сертификата открытого ключа

Центр сертификации выдает цифровые сертификаты , содержащие открытый ключ и личность владельца. Соответствующий закрытый ключ не доступен публично, но хранится в секрете конечным пользователем, сгенерировавшим пару ключей. Сертификат также является подтверждением или подтверждением со стороны ЦС того, что открытый ключ, содержащийся в сертификате, принадлежит лицу, организации, серверу или другому объекту, указанному в сертификате. Обязанностью ЦС в таких схемах является проверка учетных данных заявителя, чтобы пользователи и проверяющие стороны могли доверять информации в выданном сертификате. Для этого центры сертификации используют различные стандарты и тесты. По сути, центр сертификации отвечает за то, чтобы сказать: «Да, этот человек тот, кем он себя называет, и мы, центр сертификации, подтверждаем это». [24]

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

Пример

[ редактировать ]

Криптография с открытым ключом может использоваться для шифрования данных, передаваемых между двумя сторонами. Обычно это может произойти, когда пользователь входит на любой сайт, реализующий протокол HTTP Secure . В этом примере предположим, что пользователь входит на домашнюю страницу своего банка www.bank.example, чтобы воспользоваться онлайн-банкингом. Когда пользователь открывает домашнюю страницу www.bank.example, он получает открытый ключ вместе со всеми данными, которые отображает его веб-браузер. Открытый ключ можно использовать для шифрования данных, передаваемых клиентом на сервер, но безопаснее всего использовать его в протоколе, который определяет временный общий симметричный ключ шифрования; Сообщения в таком протоколе обмена ключами могут быть зашифрованы открытым ключом банка таким образом, что только банковский сервер имеет закрытый ключ для их чтения. [26]

Остальная часть связи затем продолжается с использованием нового (одноразового) симметричного ключа, поэтому, когда пользователь вводит некоторую информацию на страницу банка и отправляет страницу (отправляет информацию обратно в банк), тогда данные, которые пользователь ввел на страницу будут зашифрованы их веб-браузером. Таким образом, даже если кто-то может получить доступ к (зашифрованным) данным, которые были переданы пользователем на сайт www.bank.example, такой перехватчик не сможет прочитать или расшифровать их.

Этот механизм безопасен только в том случае, если пользователь может быть уверен, что в своем веб-браузере он видит именно тот банк. Если пользователь вводит www.bank.example, но его общение перехватывается и поддельный веб-сайт (который выдает себя за веб-сайт банка) отправляет информацию о странице обратно в браузер пользователя, поддельная веб-страница может отправить поддельный открытый ключ. пользователю (для которого поддельный сайт имеет соответствующий закрытый ключ). Пользователь заполнит форму со своими личными данными и отправит страницу. После этого поддельная веб-страница получит доступ к данным пользователя.

Именно это и призван предотвратить механизм центра сертификации. Центр сертификации (CA) — это организация, которая хранит открытые ключи и их владельцев, и каждая сторона связи доверяет этой организации (и знает ее открытый ключ). Когда веб-браузер пользователя получает открытый ключ от www.bank.example, он также получает цифровую подпись ключа (с некоторой дополнительной информацией в так называемом сертификате X.509 ). Браузер уже обладает открытым ключом ЦС и, следовательно, может проверить подпись, доверять сертификату и открытому ключу в нем: поскольку www.bank.example использует открытый ключ, заверенный центром сертификации, поддельный www.bank.example может использовать только один и тот же открытый ключ. Поскольку поддельный www.bank.example не знает соответствующего закрытого ключа, он не может создать подпись, необходимую для проверки его подлинности. [27]

Безопасность

[ редактировать ]

Трудно гарантировать правильность соответствия между данными и объектом, когда данные передаются в центр сертификации (возможно, через электронную сеть), а также когда также предоставляются учетные данные лица/компании/программы, запрашивающей сертификат. Вот почему коммерческие центры сертификации часто используют комбинацию методов аутентификации, включая использование правительственных бюро, платежной инфраструктуры, баз данных и услуг третьих сторон, а также пользовательскую эвристику. В некоторых корпоративных системах для получения сертификата могут использоваться локальные формы аутентификации, такие как Kerberos, которые, в свою очередь, могут использоваться внешними проверяющими сторонами. Нотариусы обязаны в некоторых случаях лично знать сторону, подпись которой нотариально заверяется; это более высокий стандарт, чем тот, которого достигают многие центры сертификации. Согласно плану Американской ассоциации юристов по управлению онлайн-транзакциями, основные положения федеральных законов и законов штатов США, принятых в отношении цифровых подписей, заключаются в том, чтобы «предотвратить противоречивые и чрезмерно обременительные местные правила и установить, что электронные письменные документы удовлетворяют традиционным требованиям, связанным с бумажными документами». " В дополнение к статуту США об электронной подписи и предлагаемому коду UETA. [28] помогите убедиться, что:

  1. подпись, контракт или другая запись, относящаяся к такой сделке, не может быть лишена юридической силы, действительности или возможности исполнения только потому, что она находится в электронной форме; и
  2. договор, относящийся к такой сделке, не может быть лишен юридической силы, действительности или исковой силы только потому, что при его составлении использовалась электронная подпись или электронная запись.

Несмотря на меры безопасности, принятые для правильной проверки личности людей и компаний, существует риск того, что один центр сертификации выдаст поддельный сертификат самозванцу. Также возможна регистрация физических лиц и компаний с одинаковыми или очень похожими названиями, что может привести к путанице. Чтобы свести к минимуму эту опасность, по прозрачности сертификатов инициатива предлагает проверять все сертификаты в общедоступном журнале, который невозможно подделать, что может помочь в предотвращении фишинга . [29] [30]

В крупномасштабных развертываниях Алиса может быть не знакома с центром сертификации Боба (возможно, у каждого из них есть разные серверы ЦС), поэтому сертификат Боба может также включать открытый ключ его ЦС, подписанный другим ЦС 2 , который предположительно узнаваем Алисой. Этот процесс обычно приводит к созданию иерархии или сетки центров сертификации и сертификатов центров сертификации.

Отзыв сертификата

[ редактировать ]
Основная статья: Отзыв сертификата

Сертификат может быть отозван до истечения срока его действия, что означает, что он больше не действителен. Без отзыва злоумышленник сможет использовать такой скомпрометированный или неправильно выданный сертификат до истечения срока его действия. [31] Следовательно, отзыв является важной частью инфраструктуры открытых ключей . [32] Отзыв выполняется выдающим центром сертификации, который создает криптографически заверенное заявление об отзыве. [33]

При распространении информации об отзыве среди клиентов своевременность обнаружения отзыва (и, следовательно, возможность злоумышленнику использовать скомпрометированный сертификат) уступает место использованию ресурсов при запросе статусов отзыва и проблемам конфиденциальности. [34] Если информация об отзыве недоступна (либо из-за аварии, либо из-за атаки), клиенты должны решить, следует ли выполнять отказоустойчивую работу и рассматривать сертификат как отозванный (и, таким образом, ухудшать доступность ) или же перейти к отказоустойчивому и рассматривать его как неотозванный (и позволить злоумышленникам обойти отзыв). [35]

Из-за стоимости проверок отзыва и влияния на доступность потенциально ненадежных удаленных служб веб-браузеры ограничивают выполняемые ими проверки отзыва и работают без сбоев там, где они это делают. [36] Списки отзыва сертификатов слишком затратны для повседневного использования, а протокол статуса онлайн-сертификатов создает проблемы с задержкой соединения и конфиденциальностью. Были предложены и другие схемы, позволяющие обеспечить отказоустойчивую проверку, но они еще не были успешно реализованы. [32]

Отраслевые организации

[ редактировать ]

Базовые требования

[ редактировать ]

Форум CA/Browser публикует базовые требования, [42] список политик и технических требований, которым должны следовать центры сертификации. Это требование для включения в хранилища сертификатов Firefox. [43] и Сафари. [44]

Компромиссы CA

[ редактировать ]
См. Также: Атака на цепочку поставок

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

Например, предположим, что злоумышленнику Еве удается заставить центр сертификации выдать ей сертификат, который утверждает, что представляет Алису. То есть в сертификате будет публично указано, что он представляет Алису, и может содержаться другая информация об Алисе. Некоторая информация об Алисе, например имя ее работодателя, может быть правдивой, что повышает доверие к сертификату. Однако у Евы будет важнейший закрытый ключ, связанный с сертификатом. Затем Ева могла использовать сертификат для отправки электронного письма с цифровой подписью Бобу, обманывая Боба, заставляя его поверить, что письмо было от Алисы. Боб может даже ответить зашифрованным электронным письмом, полагая, что его сможет прочитать только Алиса, тогда как Ева действительно сможет расшифровать его с помощью закрытого ключа.

Примечательный случай подрывной деятельности ЦС, подобный этому, произошел в 2001 году, когда центр сертификации VeriSign выдал два сертификата лицу, утверждавшему, что он представляет Microsoft. Сертификаты имеют название «Корпорация Microsoft», поэтому их можно использовать, чтобы обмануть кого-либо, заставив поверить в то, что обновления программного обеспечения Microsoft исходят от Microsoft, хотя на самом деле это не так. Мошенничество было обнаружено в начале 2001 года. Microsoft и VeriSign предприняли шаги, чтобы ограничить последствия проблемы. [45] [46]

В 2008 году реселлер Comodo Certstar продал сертификат mozilla.com Эдди Ниггу, который не имел полномочий представлять Mozilla. [47]

В 2011 году были получены поддельные сертификаты от Comodo и DigiNotar . [48] [49] предположительно иранскими хакерами. Есть доказательства того, что поддельные сертификаты DigiNotar были использованы при атаке «человек посередине» в Иране. [50]

В 2012 году стало известно, что Trustwave выпустила подчиненный корневой сертификат, который использовался для прозрачного управления трафиком (человек посередине), что фактически позволяло предприятию перехватывать внутренний сетевой трафик SSL с использованием подчиненного сертификата. [51]

В 2012 году вредоносная программа Flame (также известная как SkyWiper) содержала модули, у которых была коллизия MD5 с действительным сертификатом, выданным лицензионным сертификатом Microsoft Terminal Server, который использовал сломанный алгоритм хеширования MD5. Таким образом, авторы смогли провести коллизионную атаку с хешем, указанным в сертификате. [52] [53]

В 2015 году китайский центр сертификации MCS Holdings, связанный с центральным реестром доменов Китая, выдал несанкционированные сертификаты для доменов Google. [54] [55] Таким образом, Google удалила MCS и корневой центр сертификации из Chrome и отозвала сертификаты. [56]

Хранение ключей

[ редактировать ]

Злоумышленник, похитивший секретные ключи центра сертификации, может подделать сертификаты, как если бы они были сертификатами центра сертификации, без необходимости постоянного доступа к системам центра сертификации. Таким образом, кража ключей является одним из основных рисков, от которых защищаются органы сертификации. Центры сертификации, пользующиеся общественным доверием, почти всегда хранят свои ключи в аппаратном модуле безопасности (HSM), который позволяет им подписывать сертификаты с помощью ключа, но обычно предотвращает извлечение этого ключа с помощью как физических, так и программных средств контроля. Центры сертификации обычно принимают дополнительные меры предосторожности, сохраняя ключи своих долгосрочных корневых сертификатов в HSM, который хранится в автономном режиме , за исключением случаев, когда это необходимо для подписи промежуточных сертификатов с более коротким сроком действия. Промежуточные сертификаты, хранящиеся в онлайновом HSM, могут выполнять повседневную работу по подписанию сертификатов конечного объекта и поддержанию актуальности информации об отзыве.

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

Слабость реализации схемы доверенной третьей стороны

[ редактировать ]

Критическая слабость способа реализации текущей схемы X.509 заключается в том, что любой центр сертификации, которому доверяет конкретная сторона, может затем выдавать сертификаты для любого домена по своему выбору. Такие сертификаты будут признаны доверяющей стороной действительными независимо от того, являются ли они законными и авторизованными или нет. [57] Это серьезный недостаток, учитывая, что наиболее часто встречающейся технологией, использующей X.509 и доверенные третьи стороны, является протокол HTTPS. Поскольку все основные веб-браузеры распространяются среди своих конечных пользователей, предварительно настроенный на список доверенных центров сертификации, число которых исчисляется десятками, это означает, что любой из этих предварительно утвержденных доверенных центров сертификации может выдать действительный сертификат для любого домена. [58] Реакция отрасли на это была приглушенной. [59] Учитывая, что содержимое предварительно настроенного списка доверенных центров сертификации браузера определяется независимо стороной, которая распространяет или вызывает установку приложения браузера, сами центры сертификации фактически ничего не могут сделать.

Эта проблема стала движущей силой разработки протокола аутентификации именованных объектов на основе DNS (DANE). Принятие DANE в сочетании с расширениями безопасности системы доменных имен (DNSSEC) значительно уменьшит, если не устранит, роль доверенных третьих сторон в PKI домена.

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Чиен, Хун-Ю (19 августа 2021 г.). «Сертификаты динамического открытого ключа с прямой секретностью» . Электроника . 10 (16): 2009. doi : 10.3390/electronics10162009 . ISSN   2079-9292 .
  2. ^ «Что такое центр сертификации (CA)?» .
  3. ^ Вильянуэва, Джон Карл. «Как работают цифровые сертификаты — обзор» . www.jscape.com . Проверено 05 сентября 2021 г.
  4. ^ «Список сертификатов ЦС, включенных в Mozilla — Mozilla» . Мозилла.орг. Архивировано из оригинала 4 августа 2013 г. Проверено 11 июня 2014 г.
  5. ^ «ЭМВ ЦА» . Центр сертификации EMV по всему миру. 2 октября 2010 г. Проверено 17 февраля 2019 г.
  6. ^ Закир Дурумерик; Джеймс Кастен; Майкл Бэйли; Дж. Алекс Халдерман (12 сентября 2013 г.). «Анализ экосистемы сертификатов HTTPS» (PDF) . Конференция по Интернет-измерениям . СИГКОММ . Архивировано (PDF) из оригинала 22 декабря 2013 года . Проверено 20 декабря 2013 г.
  7. ^ «Что такое SSL-сертификат?» . Архивировано из оригинала 03.11.2015 . Проверено 19 марта 2022 г.
  8. ^ «веб-траст» . вебтраст. Архивировано из оригинала 18 августа 2013 г. Проверено 2 марта 2013 г.
  9. ^ Кирк Холл (апрель 2013 г.). «Стандарты и отраслевые правила, применимые к органам сертификации» (PDF) . Тренд Микро. Архивировано (PDF) из оригинала 4 марта 2016 г. Проверено 11 июня 2014 г.
  10. ^ «CA:IncludedCA — MozillaWiki» . Wiki.mozilla.org . Архивировано из оригинала 25 марта 2017 г. Проверено 18 марта 2017 г.
  11. ^ «Список доступных доверенных корневых сертификатов в macOS High Sierra» . Поддержка Apple . Проверено 24 августа 2020 г.
  12. ^ «Список сертификатов включенных центров сертификации Microsoft» . ccadb-public.secure.force.com . Проверено 24 августа 2020 г.
  13. ^ «Безопасность с помощью HTTPS и SSL» . Developer.android.com . Архивировано из оригинала 8 июля 2017 г. Проверено 9 июня 2017 г.
  14. ^ «Давайте зашифруем: доставка SSL/TLS повсюду» (пресс-релиз). Давайте зашифруем. Архивировано из оригинала 18 ноября 2014 г. Проверено 20 ноября 2014 г.
  15. ^ "О" . Давайте зашифруем. Архивировано из оригинала 10 июня 2015 г. Проверено 7 июня 2015 г.
  16. ^ «Подсчет SSL-сертификатов — Netcraft» . news.netcraft.com . 13 мая 2015 г. Архивировано из оригинала 16 мая 2015 г.
  17. ^ «DigiCert — крупнейший в мире центр сертификации высокой надежности | Netcraft» . Trends.netcraft.com .
  18. ^ «Статистика использования центров сертификации SSL для веб-сайтов, август 2024 года — W3Techs» . w3techs.com .
  19. ^ «Базовые требования к выпуску и управлению публично доверенными сертификатами, версия 1.2.3» (PDF) . Архивировано (PDF) из оригинала 23 марта 2015 г. Проверено 20 марта 2015 г.
  20. ^ «CA/Запрещенные или проблемные действия — MozillaWiki» . Wiki.mozilla.org . Архивировано из оригинала 21 июля 2017 г. Проверено 6 июля 2017 г.
  21. ^ «Часто задаваемые вопросы по SSL — Часто задаваемые вопросы — Rapid SSL» . www.rapidssl.com . Архивировано из оригинала 6 февраля 2015 г.
  22. ^ Зусман, Майк (2009). Уголовные обвинения не возбуждены: Взлом PKI (PDF) . DEF CON 17. Лас-Вегас. Архивировано (PDF) из оригинала 15 апреля 2013 г.
  23. ^ «Финн создал эту простую учетную запись электронной почты и получил сертификат безопасности Microsoft» . тиви.фи. ​ Архивировано из оригинала 8 августа 2015 г.
  24. ^ «Обязанности центра сертификации» . Архивировано из оригинала 12 февраля 2015 г. Проверено 12 февраля 2015 г.
  25. ^ «Сетевой мир» . 17 января 2000 г.
  26. ^ Прикладная криптография и сетевая безопасность: Вторая международная конференция, ACNS 2004, Желтая гора, Китай, 8–11 июня 2004 г. Материалы . Спрингер. Июнь 2004 г. ISBN.  9783540222170 .
  27. ^ Краткое руководство по управлению жизненными циклами сертификатов . Realtimepublishers.com. 2006. ISBN  9781931491594 .
  28. ^ «Электронные подписи и записи» (PDF) . Архивировано (PDF) из оригинала 4 марта 2016 г. Проверено 28 августа 2014 г.
  29. ^ «Прозрачность сертификата» . Архивировано из оригинала 1 ноября 2013 г. Проверено 3 ноября 2013 г.
  30. ^ Лори, Бен; Лэнгли, Адам; Каспер, Эмилия (июнь 2013 г.). Прозрачность сертификата . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6962 . ISSN   2070-1721 . РФК 6962 . Экспериментальный. |- |6963 |Лучшая современная практика | П. Сен-Андре (май 2013 г.). Пространство имен универсального имени ресурса (URN) для примеров . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6963 . ISSN   2070-1721 . РФК 6963 . |Обновления RFC 1930. |- |6979 |Informational |Т. Порнин (август 2013 г.). Детерминированное использование алгоритма цифровой подписи (DSA) и алгоритма цифровой подписи на основе эллиптических кривых (ECDSA) . Независимая подача. дои : 10.17487/RFC6979 . ISSN   2070-1721 . РФК 6979 . | |- |6980 |Предлагаемый стандарт | Ф. Гонт (август 2013 г.). Влияние фрагментации IPv6 на безопасность при обнаружении соседей IPv6 . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6980 . ISSN   2070-1721 . РФК 6980 . |Обновления RFC 3971 and 4861. |- |6996 |Best Current Practice |Дж. Митчелл (июль 2013 г.). Резервирование автономной системы (AS) для частного использования . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6996 . ISSN   2070-1721 . БКП 6. RFC 6996 . |Обновления РФК 1930 . |}
  31. ^ Смит, Дикинсон и Симонс 2020 , стр. 1.
  32. ^ Перейти обратно: а б Шеффер, Сен-Андре и Фоссати 2022 , 7.5. Отзыв сертификата.
  33. ^ Чунг и др. 2018 , с. 3.
  34. ^ Смит, Дикинсон и Симонс 2020 , стр. 10.
  35. ^ Лариш и др. 2017 , с. 542
  36. ^ Смит, Дикинсон и Симонс 2020 , стр. 1-2.
  37. ^ «Создан мультивендорный силовой совет для решения проблем цифровых сертификатов» . Сетевой мир . 14 февраля 2013 г. Архивировано из оригинала 28 июля 2013 г.
  38. ^ «Основные центры сертификации объединяются во имя безопасности SSL» . Мрачное чтение . 14 февраля 2013 г. Архивировано из оригинала 10 апреля 2013 г.
  39. ^ «Основатель CA/браузерного форума» . Архивировано из оригинала 23 августа 2014 г. Проверено 23 августа 2014 г.
  40. ^ «Форум CA/браузера» . Архивировано из оригинала 12 мая 2013 г. Проверено 23 апреля 2013 г.
  41. ^ Уилсон, Уилсон. «История форума CA/браузера» (PDF) . ДигиСерт. Архивировано (PDF) из оригинала 12 мая 2013 г. Проверено 23 апреля 2013 г.
  42. ^ «Основные требования» . КАБ Форум. 4 сентября 2013 года. Архивировано из оригинала 7 января 2014 года . Проверено 14 апреля 2017 г.
  43. ^ «Политика корневого хранилища Mozilla» . Мозилла. Архивировано из оригинала 15 апреля 2017 года . Проверено 14 апреля 2017 г.
  44. ^ «Программа корневых сертификатов Apple» . Яблоко. Архивировано из оригинала 20 марта 2017 года . Проверено 14 апреля 2017 г.
  45. ^ «СА-2001-04» . Cert.org. 31 декабря 2001 г. Архивировано из оригинала 2 ноября 2013 г. Проверено 11 июня 2014 г.
  46. ^ Microsoft, Inc. (21 февраля 2007 г.). «Бюллетень по безопасности Microsoft MS01-017: Ошибочные цифровые сертификаты, выданные VeriSign, представляют опасность подделки» . Архивировано из оригинала 26 октября 2011 г. Проверено 9 ноября 2011 г.
  47. ^ Зельцер, Ларри. «Продавец SSL-сертификата продает CSSL-сертификат Mozilla.com какому-то парню» . электронная неделя . Проверено 5 декабря 2021 г.
  48. ^ Брайт, Питер (28 марта 2011 г.). «Независимый иранский хакер взял на себя ответственность за взлом Comodo» . Арс Техника. Архивировано из оригинала 29 августа 2011 года . Проверено 1 сентября 2011 г.
  49. ^ Брайт, Питер (30 августа 2011 г.). «Еще один поддельный сертификат поднимает те же старые вопросы о центрах сертификации» . Арс Техника. Архивировано из оригинала 12 сентября 2011 г. Проверено 1 сентября 2011 г.
  50. ^ Лейден, Джон (6 сентября 2011 г.). «Внутри операции «Черный тюльпан»: анализ взлома DigiNotar» . Регистр . Архивировано из оригинала 3 июля 2017 г.
  51. ^ «Trustwave выдала сертификат посредника» . Служба безопасности H. 07.02.2012. Архивировано из оригинала 13 марта 2012 г. Проверено 14 марта 2012 г.
  52. ^ «Объяснение атаки на коллизию вредоносных программ Flame | Блог MSRC | Центр реагирования на безопасность Microsoft» . msrc.microsoft.com . Проверено 13 октября 2023 г.
  53. ^ Гудин, Дэн (7 июня 2012 г.). «Криптовалютный прорыв показывает, что Flame был разработан учеными мирового уровня» . Арс Техника . Проверено 13 октября 2023 г.
  54. ^ Фишер, Деннис (23 марта 2015 г.). «ЦС, связанный с китайским регистратором, выдал несанкционированные сертификаты Google» . ThreatPost . Проверено 27 сентября 2023 г.
  55. ^ Лэнгли, Адам (23 марта 2015 г.). «Поддержание безопасности цифровых сертификатов» . Блог Google по безопасности . Проверено 27 сентября 2023 г.
  56. ^ Ловенталь, Том (31 марта 2015 г.). «Китайская CNNIC выдает фальшивые сертификаты, что является серьезным нарушением доверия к криптовалютам» . Комитет по защите журналистов . Проверено 13 октября 2023 г.
  57. ^ Осборн, Чарли. «Symantec увольняет сотрудников за выдачу несанкционированных сертификатов Google — ZDNet» . ЗДНет . Архивировано из оригинала 2 октября 2016 г.
  58. ^ «Обнаружены неавторизованные цифровые сертификаты Google» . linkedin.com . 12 августа 2014 г.
  59. ^ «После несанкционированной выдачи сертификатов индийским центром сертификации, могут ли правительственные центры сертификации по-прежнему считаться «доверенными третьими сторонами»?» . casecurity.org . 24 июля 2014 г. Архивировано из оригинала 3 октября 2016 г.

Цитируемые работы

[ редактировать ]
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Certificate_authority&oldid=1238136626"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: c36d4f84dacec21f997b6b6e0838ffb3__1722578880
URL1:https://arc.ask3.ru/arc/aa/c3/b3/c36d4f84dacec21f997b6b6e0838ffb3.html
Заголовок, (Title) документа по адресу, URL1:
Certificate authority - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)