Warning: mkdir(): No space left on device in /var/www/group-telegram/post.php on line 37

Warning: file_put_contents(aCache/aDaily/post/interface31/--): Failed to open stream: No such file or directory in /var/www/group-telegram/post.php on line 50
Записки IT специалиста | Telegram Webview: interface31/4242 -
Telegram Group & Telegram Channel
​​Самоподписанные сертификаты. Мифы и реальность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



group-telegram.com/interface31/4242
Create:
Last Update:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




Share with your friend now:
group-telegram.com/interface31/4242

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

For example, WhatsApp restricted the number of times a user could forward something, and developed automated systems that detect and flag objectionable content. The last couple days have exemplified that uncertainty. On Thursday, news emerged that talks in Turkey between the Russia and Ukraine yielded no positive result. But on Friday, Reuters reported that Russian President Vladimir Putin said there had been some “positive shifts” in talks between the two sides. Perpetrators of such fraud use various marketing techniques to attract subscribers on their social media channels. He adds: "Telegram has become my primary news source." In 2014, Pavel Durov fled the country after allies of the Kremlin took control of the social networking site most know just as VK. Russia's intelligence agency had asked Durov to turn over the data of anti-Kremlin protesters. Durov refused to do so.
from br


Telegram Записки IT специалиста
FROM American