Записки IT специалиста

​​Самоподписанные сертификаты. Мифы и реальность

Вокруг самоподписанных сертификатов каких только мифов не собрано. Если не вдаваться в подробности, то все они сводятся к тому, что самоподписанный сертификат не безопасен и не предоставляет надежного шифрования. И ставить его в продакшен – ну такое…

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

Начнем с того, что надежность шифрования не зависит от сертификата, сертификат нужен нам для формирования ключей шифрования, а надежность шифрования зависит от применяемого набора шифров.

Мы вполне можем использовать «настоящий» сертификат и слабые шифры и это будет менее надежно, чем самоподписанный сертификат и сильные шифры.

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

После того, как мы поместим корневой сертификат CA в хранилище доверенных корневых сертификатов мы можем проверить любой выданный этим удостоверяющим центром сертификат и убедиться в том, что он действителен.

Также мы можем проверить сертификат на отзыв, при помощи все того же удостоверяющего центра.

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

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

Для этого нужно сравнить цифровой отпечаток с предоставленным вам по надежным каналам владельцем сертификата или с опубликованным в официальном источнике.

А теперь перейдем к самоподписанным сертификатам. При его создании не используется никакой удостоверяющий центр и сертификат подписывает себя самостоятельно собственной сигнатурой.

Таким образом мы не можем проверить действительность сертификата и установить с ним доверительные отношения. Нам остается только поверить или проверить его цифровой отпечаток запросив его у владельца сертификата.

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

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

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

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

Основная проблема самоподписанного сертификата – это вопрос доверия, точнее крайняя сложность в установлении доверительных отношений, если только вы сами не являетесь стороной выпустившей такой сертификат.

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

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

www.tgoop.com/interface31/4242

2.3K viewsMay 15 at 19:13

​​Самоподписанные сертификаты. Мифы и реальность

Вокруг самоподписанных сертификатов каких только мифов не собрано. Если не вдаваться в подробности, то все они сводятся к тому, что самоподписанный сертификат не безопасен и не предоставляет надежного шифрования. И ставить его в продакшен – ну такое…

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

Начнем с того, что надежность шифрования не зависит от сертификата, сертификат нужен нам для формирования ключей шифрования, а надежность шифрования зависит от применяемого набора шифров.

Мы вполне можем использовать «настоящий» сертификат и слабые шифры и это будет менее надежно, чем самоподписанный сертификат и сильные шифры.

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

После того, как мы поместим корневой сертификат CA в хранилище доверенных корневых сертификатов мы можем проверить любой выданный этим удостоверяющим центром сертификат и убедиться в том, что он действителен.

Также мы можем проверить сертификат на отзыв, при помощи все того же удостоверяющего центра.

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

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

Для этого нужно сравнить цифровой отпечаток с предоставленным вам по надежным каналам владельцем сертификата или с опубликованным в официальном источнике.

А теперь перейдем к самоподписанным сертификатам. При его создании не используется никакой удостоверяющий центр и сертификат подписывает себя самостоятельно собственной сигнатурой.

Таким образом мы не можем проверить действительность сертификата и установить с ним доверительные отношения. Нам остается только поверить или проверить его цифровой отпечаток запросив его у владельца сертификата.

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

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

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

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

Основная проблема самоподписанного сертификата – это вопрос доверия, точнее крайняя сложность в установлении доверительных отношений, если только вы сами не являетесь стороной выпустившей такой сертификат.

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

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

BY Записки IT специалиста