подстановочный знак ssl небезопасен?
Можно использовать DRBD, но использование виртуальных гостей существует проблема наличия нескольких избыточных путей между машинами для heartbeat. Без них мы нашли, серверы будут иногда входить в ситуацию, где они не видели друг друга, каждый сервер думал другой, каждый умер и стал "основным", и "мозговое разделением" условие закончилось - который было трудно разрешить.
Это могло возможно быть смягчено путем выполнения физического последовательного кабеля между 2 хостами VMware и привязки клиентов DRBD с этими физическими интерфейсами - хотя это удаляет способность жить, перемещают гостевые машины, так в конечном счете мы никогда не пробовали это.
В тестовой среде это, вероятно, приемлемо. Мы выполнили DRBD в производстве (и все еще сделайте ограниченным способом) на виртуальных машинах VMware в течение нескольких лет и этих мозговых разделением проблемах, наряду с низкой производительностью, были наши окончательные причины отодвигания. Однако я все еще чувствую, что DRBD является отличным решением при выполнении на реальных машинах.
К моему знанию нет никакого различия между подстановочным знаком и нормальными сертификатами. Пока Вы имеете полный контроль domain.comDNS, затем нет никакой причины не использовать подстановочный знак. На самом деле я рекомендовал бы это в Вашем случае. Каковы Ваши определенные проблемы с ними?
(IMO, Перенаправления, такие как то, которое Вы предлагаете, являются всегда чем-то вроде выдумки, когда они видимы конечному пользователю.)
Как SmallClanger указывает, пока Вы имеете полный контроль над доменом и любыми возможными субдоменами, нет свойственных проблем безопасности. Один возможный недостаток состоит в том, что Вы не можете получить Подстановочный знак Сертификат EV, таким образом, никакая зеленая панель для нескольких пользователей, которые ищут его.
Я согласен с другими ответами, что сертификаты с подстановочными знаками не являются небезопасными по своей сути.
Однако можно создать проблему безопасности, неправильно используя сертификаты с подстановочными знаками. Следующая проблема безопасности не возникнет, если ваши сертификаты действительны только для одного домена каждый.
Представьте, что изначально у вас есть один сервер, на котором размещены все поддомены. Злоумышленник подписывается на вашу службу и получает домен evil.example.com . Это, как и все ваши клиенты, покрывается сертификатом для *. Example.com .
Злоумышленник принимает меры к evil.example.com для получения большого количества трафика, так что в конечном итоге этому домену выделяется выделенный сервер. Теперь у вас есть два физических сервера с одинаковым сертификатом.
На этом этапе злоумышленник начинает выполнять атаки MITM (происходит ли это через отравление DNS или злонамеренные точки доступа, не имеет значения). Злоумышленник направляет пользователей legal.example.com на IP-адрес evil.example.com . Поскольку в сертификате указано *. Example.com , он действителен.
Однако выделенный сервер для evil.example.com не знает законное доменное имя . example.com , поэтому он отвечает контентом с виртуального хоста по умолчанию, которым будет evil.example.com , потому что у этого выделенного сервера нет других доменов.
This сценария атаки можно избежать, если каждый сервер, имеющий сертификат, сможет отвечать на запросы для всех поддоменов. Это вполне приемлемо, если иногда это означает проксирование запроса с одного сервера на другой. Пока прокси-сервер защищен от атак MITM.
В правильной конфигурации выделенный сервер для evil.example.com начал бы получать запросы только для legal.example.com ] после того, как злоумышленник попытается выполнить MITM-атаку на пользователей. Он не сможет серверить контент и вместо этого передает запрос на реальный сервер, на котором размещается legal.example.com .
Если злоумышленнику предоставлен достаточный контроль над хостингом выделенного сервера evil.example.com , чтобы отключить прокси, тогда у вас действительно есть проблема безопасности.
Подстановочные сертификаты в некоторых сценариях создают дополнительный риск. Применимы ли эти сценарии к вам, и если да, то считаете ли вы приемлемым дополнительный риск - это то, что вам нужно будет определить в контексте.
Допустим, все ваши поддомены находятся на одном сервере. В этом случае практически не имеет значения, есть ли у вас сертификат с подстановочными знаками, сертификат с несколькими именами или отдельные сертификаты для каждого сайта. Если злоумышленник скомпрометирует ваш сервер до такой степени, что сканирует, украдет закрытые ключи для сертификатов, он, вероятно, может украсть их все, а не только один.
Теперь допустим, вы добавляете еще один поддомен, который должен иметь более высокий уровень безопасности, чем существующие, возможно сайт платежей. Вы помещаете этот поддомен на его собственный сервер и получаете его собственный сертификат.
Если вы использовали отдельные сертификаты или сертификат с несколькими именами на первом сервере, сертификат / ключ с первого сервера не может использоваться для олицетворения второго сервер.
Если вы использовали сертификат с подстановочными знаками на первом сервере, то сертификат / ключ с первого сервера можно было бы использовать для олицетворения второго сервера.
PS Сертификат "страховка" является змеиным.