Есть ли что-то более небезопасное в использовании подстановочного SSL-сертификата вместо обычного SSL-сертификата?
Мы планируем реализовать веб-приложение с поддоменом (а-ля FreshBooks и BaseCamp, где пользователи выбирают поддомен), и один из членов нашей команды обеспокоен тем, что подход SSL с подстановочными знаками недостаточно безопасен (если да, то как это делают FreshBooks и BaseCamp? Это?!?).
Альтернативное решение - использовать один субдомен, например https://ssl.domain.com и когда пользователь вводит http://user.domain.com мы устанавливаем субдомен в сеансе и немедленно перенаправляем будущие запросы пользователя на "https://ssl.domain.com"и используйте информацию о сеансе, чтобы показать информацию о пользователе.
Меня беспокоит то, что если пользователь хочет отправить ссылку на свой домен другу, он скопирует / вставит URL-адрес в браузере (сейчас https://ssl.domain.com), которая будет нашей главной домашней страницей, а не домашней страницей пользователя.
Кстати, если я пропустил основную передовую практику для такого сценария, пожалуйста, дайте мне знать.
Насколько мне известно, нет разницы между подстановочными и обычными сертификатами. Пока у вас есть полный контроль над domain.comDNS, то нет причин не использовать подстановочный знак. На самом деле, я бы порекомендовал это в вашем случае. Что вас по ним беспокоит?
(IMO, перенаправления, такие как тот, который вы предлагаете, всегда немного выдумка, когда они видны конечному пользователю.)
С технической точки зрения это было бы так же безопасно. Вы все равно будете использовать то же шифрование, что и для сертификата без подстановочных знаков. Что они считают менее безопасным?
Я согласен с другими ответами, что сертификаты с подстановочными знаками небезопасны по своей сути.
Однако неправильное использование сертификатов с подстановочными знаками может вызвать проблемы с безопасностью. Следующая проблема безопасности не возникнет, если ваши сертификаты действительны только для одного домена.
Представьте, что изначально у вас есть один сервер, на котором размещены все поддомены. Злоумышленник подписывается на вашу службу и получает домен evil.example.com. Это, как и все ваши клиенты, покрывается сертификатом на *.example.com.
Противник устраивает evil.example.com для получения большого количества трафика, поэтому в конечном итоге этому домену будет выделен выделенный сервер. Теперь у вас есть два физических сервера с одинаковым сертификатом.
На этом этапе злоумышленник начинает выполнять атаки MITM (происходит ли это через отравление DNS или злонамеренные точки доступа, не имеет значения). Злоумышленник направляет пользователей legitimate.example.com на IP-адрес evil.example.com. Поскольку в сертификате написано *.example.com это действительно.
Однако выделенный сервер для evil.example.com не знает доменное имя legitimate.example.com, поэтому он отвечает содержимым виртуального хоста по умолчанию, который будет evil.example.com потому что у этого выделенного сервера нет других доменов.
Этого сценария атаки можно избежать, если каждый сервер, содержащий сертификат, может отвечать на запросы для всех поддоменов. Это вполне приемлемо, если иногда это означает проксирование запроса с одного сервера на другой. Пока прокси-сервер защищен от атак MITM.
В правильной конфигурации выделенный сервер для evil.example.com будет только получать запросы на legitimate.example.com после попытки злоумышленника выполнить MITM-атаку на пользователей. Он не сможет серверить контент и вместо этого проксирует запрос на реальный сервер, размещающий legitimate.example.com.
Если злоумышленнику предоставлен достаточный контроль над хостингом выделенного сервера evil.example.com чтобы отключить это прокси, у вас действительно есть проблема с безопасностью.
Как указывает SmallClanger, до тех пор, пока у вас есть полный контроль над доменом и любыми возможными субдоменами, внутренних проблем с безопасностью нет. Одним из возможных недостатков является то, что вы не можете получить сертификат EV с подстановочными знаками, поэтому для тех немногих пользователей, которые его ищут, нет зеленой полосы.
Сертификаты с подстановочными знаками в некоторых случаях создают дополнительный риск. Применимы ли эти сценарии к вам, и если да, то считаете ли вы приемлемым дополнительный риск - это то, что вам нужно будет определить в контексте.
Допустим, все ваши поддомены находятся на одном сервере. В этом случае практически не имеет значения, есть ли у вас сертификат с подстановочными знаками, сертификат с несколькими именами или отдельные сертификаты для каждого сайта. Если злоумышленник скомпрометирует ваш сервер до такой степени, что сканирует, украдет закрытые ключи для сертификатов, он, вероятно, может украсть их все, а не только один.
Теперь предположим, что вы добавляете еще один поддомен, который должен иметь более высокий уровень безопасности, чем существующие, возможно, сайт платежей. Вы помещаете этот поддомен на собственный сервер и получаете его собственный сертификат.
Если вы использовали отдельные сертификаты или сертификат с несколькими именами на первом сервере, сертификат / ключ с первого сервера нельзя было использовать для олицетворения второго сервера.
Если вы использовали сертификат с подстановочными знаками на первом сервере, то сертификат / ключ с первого сервера можно было бы использовать для олицетворения второго сервера.
P.S. Сертификат "страховка" является змеиным.