Ответы:
Интересный вопрос, это зависит от использования на мой взгляд. Вы по-прежнему защищены с точки зрения того, что сеанс зашифрован, но вы не можете сказать, является ли это правильным сертификатом SSL, предоставленным вам, если вы не передаете свой корневой сертификат CA пользователям / клиентам. Для внутреннего тестирования / разработки проектов это будет работать отлично, вы создаете сертификат корневого центра сертификации, который вы используете, распространяете среди своих пользователей (это можно сделать с помощью групповой политики в Windows и через командную строку openssl в Linux / BSD), а затем используете этот корневой сертификат для подписав свой CSR. Пользователи не увидят предупреждение или что-либо еще, и вы знаете, что сертификат подписан вашим внутренним центром сертификации.
Для внешних сайтов, где вы не можете это гарантировать, я бы сказал, что самоподписанный сертификат лучше, чем отсутствие SSL вообще, если вы отправляете пароли или другую конфиденциальную информацию по соединению.
Однако, с другой стороны, существует множество очень дешевых «коммерческих» эмитентов сертификатов, в том числе GoDaddy . Вы можете получить сертификат примерно за 40 евро в год. GoDaddy даже предлагает бесплатные сертификаты для сайтов проекта OpenSource.
Я собираюсь не согласиться, один раз на узких технических основаниях, и один раз на общих основаниях.
Узкое техническое основание состоит в том, что OP спрашивал о самозаверяющих сертификатах, а некоторые другие ответы относятся к сертификатам, подписанным частными CA, что является немного другой проблемой. Но не очень отличается, так что это на самом деле только записка мимоходом.
Основное возражение состоит в том, что я думаю, что, если коммерчески подписанные сертификаты обходятся не просто тривиально - а 40 долларов в год - это не тривиальные расходы для многих людей на этой планете - самозаверяющие сертификаты играют важную роль в интернет-безопасности, при условии признания их ограничений .
Самоподписанный сертификат похож на ключ ssh из моего known_hostsфайла. Без независимой проверки я не смогу заверить меня в том, что я говорю с той системой, в которую верю; но это может заверить меня, что система, с которой я сейчас разговариваю, - это та же система, с которой я говорил в прошлый раз, когда мне показалось, что я разговаривал с ней. Мы постоянно кешируем ssh-ключи, и я еще никогда не встречал системного администратора, который независимо проверял бы более чем часть открытых ключей в своем known_hostsфайле.
Самозаверяющие сертификаты (и, в этом отношении, сертификаты, подписанные не общедоступными центрами сертификации) намного лучше, чем вообще отсутствие SSL, при условии, что люди понимают, что, если они не проверяют их, они только защищают связь для себя, сервера на другом конце записи DNS, и любые посредники, которые в настоящее время находятся на линии. Если они независимо проверяют сертификат, то аутентификация и шифрование, по меньшей мере, столь же надежны, как и сертификат, подписанный признанным центром сертификации.
Кроме того, тех , кто хочет представить использование сертификатов , подписанных признанный CA как одно-и только панацея безопасности Интернет , возможно , придется серьезно подумать о таких вопросах, как включение CA подписания китайского правительства в стандартной Mozilla пачке , и мошеннические SSL-сертификаты, подписанные Comodo .
known_hostsтом, на что ссылается @MadHatter.
Для внешних сайтов, где у пользователей не установлен сертификат CA (что является наиболее распространенным случаем), да, самозаверяющий сертификат дает ложное чувство безопасности , и, следовательно, это хуже, чем бесполезно:
Во-первых, без предварительно установленного сертификата CA, как пользователь проверяет, что сертификат действительно исходит от вас, а не от злоумышленника? Сопоставляя поля сертификата (CN, отпечатки пальцев и т. Д.), Конечно - но против чего? Так что теперь вам нужен побочный канал для проверки сертификата - и в тех немногих случаях, которые я видел, операторы линии поддержки (которые должны были служить побочным каналом для проверки) не имеют ни малейшего представления о том, что это должно означать; Кроме того, работа с таким побочным каналом на несколько порядков дороже, чем получение сертификата, подписанного доверенным центром сертификации, поэтому пользователь должен слепо доверять вам.
Во-вторых, страшное предупреждение, которое получает пользователь, страшно по уважительной причине: поскольку пользователь не может / не будет проверять представленный сертификат, он может безопасно передавать данные в Elbonian Haxx0r D00dz.
В-третьих, и что хуже всего, вы десенсибилизируете пользователей : «ну, они сказали мне, что я должен игнорировать это предупреждение на https://mysite.example.com/ , и наковальня не упала мне на голову, и мой Золотая рыбка тоже не умерла, оооочень, это означает, что это просто еще одно окно с предупреждением без какого-либо реального значения, поэтому я могу игнорировать это окно всякий раз, когда сталкиваюсь с ним - в любом случае я получаю этот красивый значок замка, и это важно ».
Другими словами, уровень защиты сравним с обычным HTTP (за исключением прослушивания по проводам: хотя данные шифруются при передаче, это довольно анемичная функция без проверки конечной точки), но ощущение защиты неоправданно высоко , Плохая автомобильная аналогия: «У меня есть ABS, так что теперь я могу ездить безопаснее в плохих условиях» - за исключением того, что ABS есть только в рекламной брошюре автомобиля, фактически не присутствуя в автомобиле.
Рекомендуемое чтение: лучшие практики OWASP SSL
TL; DR. Используя самозаверяющие сертификаты на общедоступных сайтах, вы делаете сеть еще хуже, один невежественный пользователь за раз.
Зависит. Если вы думаете, что это делает вас более безопасным, тогда это увеличивает ваш риск, поскольку вы решаете делать более рискованные вещи со своим ложным чувством безопасности. Если вы относитесь к нему функционально эквивалентно HTTP, то я бы сказал, что вы немного более защищены.
Без SSL / HTTPS любой, у кого есть Wireshark в вашей сети (или в локальной сети любого, кто входит в систему), может легко прослушивать и записывать имя пользователя / пароли, отправленные в виде простого текста.
С самозаверяющим SSL они не могут просто прослушивать, но теперь они должны подделать ваш сайт, потенциально изменить DNS, чтобы атаковать человека посредине (MITM). Это все еще угроза, но ее значительно сложнее осуществить.
Другая проблема с использованием самоподписанного SSL состоит в том, что многие браузеры рассматривают самоподписанные сертификаты как серьезную угрозу безопасности и предупреждают вас перед входом (например, chrome) с гигантской красной страницей. http://www.sslshopper.com/article-ssl-certificates-in-google-chrome.html Это может быть серьезным неудобством.
Итак, суть заключается в следующем: если вы запускаете что-то, что не должно быть особенно безопасным (например, нет данных кредитной карты, нет номеров социального страхования) и не можете позволить себе надлежащий сертификат, самозаверяющий сертификат может иметь некоторый смысл (скажем, запретить другим пользователям сети легко перехватывать информацию для входа в систему).
Это зависит от того, что вы имеете в виду под «безопасностью», и в какой степени.
Например, ваш браузер поставляется с набором CA, принятым по умолчанию. Это означает, что любой сертификат, выданный этим центром сертификации, принимается вашим браузером (до тех пор, пока он не совпадет с именем DNS). Теперь представьте, что какое-то злое правительство владеет ЦС или может заставить ЦС выдать сертификат для сайта, который вы посещаете. Затем сделать MITM очень просто: они могут прокси-сервер вашего соединения, отправив вашему браузеру сертификат, который у них есть, и ваш браузер примет его, так как он приходит из «доверенного» CA. Пока они не являются DNS-прозрачными (что является основой для MITM), это нормально.
Таким образом, «список принятых CA» по сути является большой дырой в безопасности, пока один из этих CA не будет сотрудничать с каким-то злым правительством. Наличие собственного CA намного лучше.
Конечно, вы можете сделать это в своей компании или на своем домашнем сервере, потому что вы можете установить свой собственный сертификат CA в клиент, которым вы также управляете. На общедоступном сервере вы не можете иметь дело с каким-либо пользователем, попросив его добавить исключение или добавить свой сертификат.
Итак, это зависит от того, что вы подразумеваете под «безопасностью», и от объема. Если вы владеете клиентами, НАДЕЖНО, самоподписанный безопаснее, пока вы не установите на самом клиенте сертификат своего собственного ЦС.
Конечно, вы не можете сделать это на общедоступном веб-сайте, поскольку вы не являетесь владельцем всех клиентов. Таким образом, вы будете подвергнуты опасности другого поведения, что небезопасно.