Получение сертификата x.509 и личная безопасность
Возможно ли получить сертификат x.509, самостоятельно создав пару ключей, а центру сертификации предоставив только открытый ключ?
На публичных серверах сертификатов, например http://www.trustcenter.de, предлагает создать сразу пару ключей. Мне кажется это как-то не очень конфиденциально и приватно, ведь они могут у себя оставить копию закрытого ключа, и теоретически, потом силовые органы могут потребовать его у этого
центра сертификации...
комментариев: 11558 документов: 1036 редакций: 4118
Сертификат всегда ассоциируется с явным email, в этом его назначение, в ином случае не происходило бы наследования доверия. В Outlook вроде бы есть расширения для связывания сертификата с определённой записью в Exchange, но как это работает, я не проверял, и есть ли что-то подобное в Outlook Express — не знаю (хотя наверняка и нету).
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 510 документов: 110 редакций: 75
комментариев: 11558 документов: 1036 редакций: 4118
"Чистое" шифрование с открытым ключом никогда не применяется в прикладных криптосистемах. Изредка — в протоколах, да и то для аутентификации. Причина — не только неоправданная вычислительная нагрузка: тот же RSA вскрывается по известному открытому или подобранному шифртексту, можно шифровать только блок данных, не превышающий длину ключа и т.д. Если же открытый ключ зашифровывает непредсказуемый симметричный ключ, это снимает отмеченные проблемы.
комментариев: 9796 документов: 488 редакций: 5664
При этом все нормально шифруется-проверяется (именно командами OpenSSL, обычные почтовые клиенты и сертификационные центры могут такой нестандартный сертификат не принять).
А вот симметричный алгоритм жестко задан стандартом – только 3DES и никакого другого. Не знаю, может в новых реализациях OpenSSL допускается что-то новое, но я сомневаюсь.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Да, похоже такое ограничение конкретно для S/MIME ([-des] [-des3] [-rc2-40] [-rc2-64] [-rc2-128]) ничем не обоcновано. При том, что в этой же версии OpenSSL для других типов шифрования (кроме S/MIME) работают и другие, более современные шифры.
комментариев: 9796 документов: 488 редакций: 5664
Генерируем пару сертификатов (подписанный-фальшивый) с MD5-коллизиями.
получении письма от ранее неизвестного адресата? Там что то говорится о наследовании доверия от поставщика.
Я могу вручную поставить определенный уровень доверия, но вручную это
вручную, т.е. в этом нет никакого смысла. Происходит ли какая-либо автоматическая проверка через центр сертификации, как это происходит и как я могу проследить, прошла ли такая сверка?
Этот же вопрос было бы интересно знать по работе https (ssl) – вопрос
доверия сайтам.
Спасибо.
комментариев: 11558 документов: 1036 редакций: 4118
Открытые ключи большинства крупнейших УЦ поставляются в составе дистрибутивов браузеров и мэйл-клиентов, что обеспечивает прямое доверие корневым сертификатам PKI. Получив S/MIME- или PEM-подписанное письмо, Ваш мэйл-клиент импортирует сертификат отправителя и сверяет с него ЭЦП с помощью априорно доверенного открытого ключа соответствующего удостоверяющего центра.
Если подпись на сертификате верна, мэйл-клиент считает сертификат отправителя достоверным, а содержание подписанного сообщения — подлинным. Если подпись неверна или повреждена — мэйл-клиент сигнализирует об этом факте, свидетельствующем о возможной попытке подделать сообщение. Если же сертификат отправителя не несёт доверенной подписи УЦ, а подписан УЦ, открытого ключа которого нет в хранилище мэйл-клиента (то есть данный УЦ не имеет априорного доверия), либо вообще имеет только автоподпись, мэйл-клиент не может определить подлинность сообщения, предоставляя пользователю решать самому (мэйл-клиент в этом случае может только судить о целостности сообщения, исходя из состояния цифровой подписи отправителя).
Вы можете самостоятельно выбирать, доверяете ли Вы тому или иному удостоверяющему центру и выпущенным им сертификатам; либо можете запретить наследование доверия для конкретного пользовательского сертификата, если по каким-то причинам считаете его поддельным или скомпрометированным.
SSL-сертификаты — это те же X.509 с несколько иными полями, поэтому к ним применяются такие же правила. Если сервер поддерживает SSL-шифрование, то при обращении к нему клиента, сервер передаёт ему свой сертификат. Клиент проводит проверку, аналогичную описанной выше. Однако следует помнить, что SSL лишь защищает от перехвата трафик, передаваемый между клиентом и сервером, а X.509 только препятствует спуфингу, т.е. атакам по типу "человек в середине" и подделке адресов защищённых сайтов. Сертификат не является поручительством в доверии серверу: его оператор волен выдать третьей стороне весь переданный трафик без всякого ведома пользователя.
... Забыл отметить, что кроме проверки подписи УЦ с полученного сертификата, клиентская программа, запросив от УЦ реестр аннулированных сертификатов (CRL, адрес которого, как правило, указан в самом сертификате отправителя письма или SSL-сертификате), проверяет, не был ли он аннулирован отправителем или самим удостоверяющим центром. В случае, если в запрошенном CRL оказывается серийный номер данного сертификата, программа выводит предупреждение.
Что такое PEM подписанное письмо?
Если я получил письмо подписанное сертификатом УЦ которого нет вхранилище браузера или майл-клиента, но УЦ существует. Я должен вручную установить сертификат УЦ, если я верно рассуждаю. В данном случае уровень доверия решается опять же мной лично? Есть ли способ все таки проверить подлинность?
комментариев: 11558 документов: 1036 редакций: 4118
По второму пункту Ваши рассуждения верны. Вы сами должны установить корневой сертификат УЦ (с его сайта, вероятно). И надеяться, что полученная копия не подменена. :) Некоторые УЦ позволяют сверять отпечатки своих корневых сертификатов по телефону.
Ни один УЦ внесенный в список браузеров и почтовых клиентов не заслуживает никакого доверия (вы договор прочитайте — и поймете, что деньги они просят ни за что: это просто рэкет)
В своей практике я сталкивался только с двумя людьми, которые пользовались почтой S/MIME, и в обеих случаях это было связано с их работадателем — государством (США и Республики Ирландии, соответственно). PGP распространено значительно больше (скорее всего на несколько порядков).
В случае SSL статистика есть: примерно 99% всех https серверов работают с либо само-подписанными сертификатами, либо с сертификатами "непризнанных" УЦ, которых в списках браузеров при установки нет.
Пользуются услугами "признанных" УЦ в основном банки и страховые компании (а также преступники занимающиеся phishing-ом, и некоторые лохи), для которых сертификат — электронный эквивалент гранитно-мраморной облицовки офиса: показательная трата денег в целях подачи сигналов респектабельности. К безопасности это не имеет никакого отношения, что прекрасно иллюстрирует размер колоссальных убытков от phishing.
комментариев: 11558 документов: 1036 редакций: 4118
Как говорится, привет от Иана Григга. :)