Contents of this directory is archived and no longer updated.

Недавно в интернете читал интересное обсуждение, в котором утверждалось, что самоподписанные сертификаты подвержены атаке Man-in-The-Middle (MiTM). Давайте разберёмся, что это такое. Есть 2 узла (А и Б). Узел А инициирует соединение с узлом Б отправляя запрос для предъявления сертификата (SSL). Узел Б посылает свой сертификат узлу А. И тут между узлами А и Б появляется узел В (злоумышленник), который перехватывает сертификат и вместо него отправляет свой поддельный сертификат. Узел А думает, что это сертификат узла Б и начинает шифровать этим сертификатом данные, передавая узлу Б. Но на самом деле узел А шифрует данные поддельным сертификатом узла В и злоумышленник читает все шифрованные (а это могут быть и конфиденциальные данные) данные.

Я не берусь судить, откуда растут ноги у этого мифа, но он достаточно устойчив. Давайте посмотрим существующие алгоритмы шифрования:

  • Симметричное шифрование

Самый простой, но и небезопасный метод:

symmetric encryption

  1. John Smith хочет безопасно отправить конфиденциальные данные Mary Jane.
  2. John генерирует симметричный ключ и шифрует им документ. Документ теперь зашифрован и может быть передан через интернет.
  3. Mary Jane получает зашифрованный документ.
  4. Mary Jane применяет *тот же самый* симметричный ключ и получает текст в незашифрованной форме.

Минус такого сценария заключается в том, что используется один и тот же ключ как для шифрования и дешифрования. Следовательно, чтобы Mary Jane смогла расшифровать данные ей нужно иметь тот же самый ключ. Этот ключ не должен передаваться вместе с документом, а какими-нибудь другими методами (например, по телефону). Чем больше получателей этого документа, тем выше вероятность, что ключ станет известен ещё кому-то и не существует механизмов, которые бы позволяли определять статус ключа (скомпрометирован или нет). Плюс такого сценария — высокая скорость. Симметричное шифрование выполняется достаточно быстро и не потребляет большого количества процессорных ресурсов. Идеально подходит для шифрования больших объёмов данных.

  • Асимметричное шифрование

Метод более сложный, но и более безопасный:

Asymmetric encryption

  1. John Smith хочет отправить конфиденциальные данные Mary Jane.
  2. John использует открытую часть сертификата (с открытым ключом) Mary Jane и этим открытым ключом шифрует данные.
  3. Mary Jane получает зашифрованный документ.
  4. Mary Jane применяет *закрытый ключ* от своего сертификата и расшифровывает данные.

В нашем сценарии Mary Jane — это веб-сервер, которому нужно передать конфиденциальные данные. А John Smith — клиент, который хочет эти данные передать на сервер. Чисто технически злоумышленник может перехватить открытую часть сертификата Mary Jane и вместо него подложить свой поддельный сертификат с таким же именем. Без дополнительных мер безопасности, John не смог бы отличить настоящий сертификат от поддельного. И здесь появляется важный момент. Перед шифрованием данных John Smith должен проверить этот сертификат на доверие и отзыв. Сертификаты содержат различные средства определения статуса закрытого ключа через списки отзыва. Если сертификат помещён в список отзыва, ему доверять нельзя и использовать его крайне опасно. В случае с самоподписанными сертификатами определить отзыв не представляется возможным. Но можно (как минимум) убедиться, что сертификат выпущен доверенным лицом (или центром сертификации). Для этого John Smith пропускает сертификат через Certificate Chaining Engine (CCE). Если издатель сертификата (или сам сертификат) хранится у John'а в Trusted Root CAs, можно с уверенностью сказать, что сертификат не был подделан злоумышленником и выдан доверенным лицом. Если же сертификата там нет, невозможно убедиться, что это действительно сертификат самой Mary Jane. В таком случае приложение выдаёт ошибку или предупреждение, что не удалось проверить сертификат. Когда пользователь получил такое предупреждение, он должен незамедлительно отменить операцию шифрования (если это ещё не сделало само приложение).

Поскольку закрытый ключ от сертификата хранится только у Mary Jane и он никогда не раскрывается никому, злоумышленнику бесполезно использовать перехваченные пакеты, поскольку закрытый ключ (который нужен для расшифровки данных) никогда не покидает Mary Jane. Хотя тут есть 2 момента. Поскольку самоподписанные сертификаты не имеют централизованного издателя, при большом количестве таких сертификатов появляется вопрос доверия к таким сертификатам:

  1. Самое простое — игнорировать ворненги ошибок сертификатов. В таком случае можно надурить отправителя и подсунуть поддельный и недоверенный сертификат. Если вы игнорируете ворненги — вы ССЗБ. Против этого метода защиты не существует.
  2. Чуть сложнее — все сертификаты участников обмена шифрованными данными устанавливать в Trusted Root CAs. Тогда ворненгов и не будет. Но при большом количестве таких сертификатов можно ошибочно установить поддельный сертификат к себе в хранилище. И тогда вы будете доверять сертификату злоумышленника.

Следовательно, чисто технически очень сложно организовать атаку MiTM даже с самоподписанными сертификатами. Единственное на что можно рассчитывать — на человеческий фактор. А против человеческого фактора защиты нет никакой. Разве что его можно попытаться снизить за счёт использования централизованного доверенного издателя (центр сертификации). В таком случае придётся установить только один корневой сертификат в Trusted Root CAs. И если сертификат у какого-то участника обмена ВНЕЗАПНО стал недоверенным, можно с определённой уверенностью сказать, что это поддельный сертификат. Но, как я уже отмечал, оба вышеупомянутых пункта относятся как к самоподписанным сертификатам, так и к сертификатам выпущенных централизованным издателем.


Share this article:

Comments:

Алексей
Алексей 06.12.2012 09:38 (GMT+2) Самоподписанные сертификаты и атака Man-in-The-Middle (MiTM)

Автор пытается сказать: 1) Что это утверждение миф: "самоподписанные сертификаты подвержены атаке Man-in-The-Middle". Потому что: 1) "Если вы игнорируете ворненги — вы ССЗБ" 2) "все сертификаты участников обмена шифрованными данными устанавливать в Trusted Root CAs. Тогда ворненгов и не будет. Но при большом количестве таких сертификатов можно ошибочно установить поддельный сертификат к себе в хранилище. И тогда вы будете доверять сертификату злоумышленника." 3) "оба вышеупомянутых пункта относятся как к самоподписанным сертификатам, так и к сертификатам выпущенных централизованным издателем." Мысли от меня: Оба пункта НЕ !!! относятся к сертификатам заверенным удостоверяющим центром. Так как: 1) ворненги не будут вообще появляться, так как все в порядке - сертификат подписан и предупреждать не о чем. 2) Ошибочно установить поддельный сертификат также не возможно так как все они подписаны и по цепочке подписей их все можно проверить. При попытке установить подделку появляются ворнинги - и тут как раз не надо быть ССЗБ, чтобы все было в порядке. С уважением, Алексей.

Vadims Podāns
Vadims Podāns 06.12.2012 16:00 (GMT+2) Самоподписанные сертификаты и атака Man-in-The-Middle (MiTM)

> Ошибочно установить поддельный сертификат также не возможно так как все они подписаны и по цепочке подписей их все можно проверить. как вы проверите цепочку корневого сертификата?

Алексей
Алексей 07.12.2012 07:11 (GMT+2) Самоподписанные сертификаты и атака Man-in-The-Middle (MiTM)

Да, действительно корневой сертификат автоматически проверить электронными средствами невозможно. Как раз потому, что он по своей сути самоподписанный. Эта проблема в криптосистемах с открытым ключом решается двумя способами: 1) "Открытый ключ центра сертификации распространяется настолько широко, что ещё до установления связи Алиса и Боб будут иметь этот ключ, и злоумышленник ничего не сможет с этим поделать." - на практике это означает что сертификаты основных УЦ, устанавливаются в системы их производителями (например). 2) Если же вы хотите использовать корневой сертификат некого местного удостоверяющего центра(который не установлен в систему производителем), то для проверки этих сертификатов используются бумажные распечатки, полученные из УЦ, содержащие определенную информацию: как правило, так называемые цифровые отпечатки, либо сами открытые ключи. Проще и гораздо надежнее проверить несколько корневых сертификатов и потом доверять их подписям и цепочкам, нежели безосновательно доверять множеству самоподписанных сертификатов. Ведь проверить подменен ли самоподписанный сертификат при его передаче невозможно, то есть невозможно знать: есть ли злоумышленник посередине, перехватывает ли он данные или подменяет их внутри якобы шифрованного канала. С уважением.

Comments are closed.