Расширенный SSL: промежуточный центр сертификации и развертывание встроенных блоков

Question

Окей. Усовершенствованные сотрудники SSL. Ребята, я добавлю награду после двухдневного периода, так как считаю, что это сложная тема, которая заслуживает награды для всех, кто вдумчиво отвечает.

Некоторые из допущений здесь просто: предположения или, точнее, обнадеживающие догадки.Считайте, что это головоломка, просто сказать: «Это невозможно» - упустить смысл.

Альтернативные и частичные решения приветствуются, личный опыт, если вы сделали что-то «подобное».Я хочу извлечь уроки из этого, даже если весь мой план неверен.

Вот сценарий:

Я занимаюсь разработкой на встроенной системе Linux и хочу, чтобы ее веб-сервер мог обслуживатьготовый, без проблем SSL.Вот критерии дизайна, к которым я стремлюсь:

Must Haves:

• Я не могу позволить пользователю добавить свой доморощенный сертификат CA в свой браузер
• Я не могу позволить пользователю добавить статически сгенерированный (во время mfg) самоподписанный сертификат в свой браузер
• Я не могу позволить пользователю добавить динамически сгенерированный (во время загрузки)самозаверяющий сертификат для их браузера.
• Я не могу установить HTTP по умолчанию и имею возможность включить / отключить переключатель для SSL.Это должен быть SSL.
• Как встроенный блок, так и клиент веб-браузера могут иметь или не иметь доступ к Интернету, поэтому предполагается, что он работает правильно без доступа к Интернету.Единственные корневые центры сертификации, на которые мы можем положиться, это те, которые поставляются с операционной системой или браузером.Давайте представим, что этот список «в основном» одинаков для всех браузеров и операционных систем, т. Е. У нас будет ~ 90% успеха, если мы будем полагаться на них.
• Я не могу использовать операцию «на лету»т. е. Информационный центр SSL-сертификатов Fast Eddie - с такими низкими ценами наши серверы ДОЛЖНЫ быть взломаны!1034 * Я не хочу, чтобы пользователь предупреждал, что имя хоста сертификата не совпадает с именем хоста в браузере.Я считаю, что это хорошо иметь, потому что это может быть невозможно.

Не хочу:

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

Да, да, я знаю ..

• Я могу предоставить пользователю механизм загрузки своего собственного сертификата / ключа, но ярассмотреть этот «расширенный режим» и выходит за рамки этого вопроса.Если пользователь достаточно продвинут, чтобы иметь свой собственный ЦС или купить ключи, тогда он великолепен, и я люблю его.

Время ограничения мышления

Мой опыт работы с SSL заключался в создании сертификатов / ключей для подписи «настоящим» root, а также в активизации моей игрынемного с созданием собственного внутреннего ЦС, распространением внутренних «самозаверяющих» сертификатов.Я знаю, что вы можете связать сертификаты, но я не уверен, каков порядок операций.То есть браузер «проходит» по цепочке, видит ли действительный корневой центр сертификации и видит ли это действительный сертификат - или вам нужно пройти проверку на каждом уровне?

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

Сумасшедшая идея # 1

• Получитьпромежуточный сертификат центра сертификации, подписанный «настоящим» ЦС.(ICA-1)
  • ROOT_CA -> ICA-1
• Этот сертификат будет использоваться во время изготовления для создания уникальной пары паролей промежуточных сертификатов без промежуточных сертификатов для каждого блока,
  • ICA-1 -> ICA-2
• Используйте ICA-2 для генерации уникального сертификата / ключа сервера. Предостережение заключается в том, можете ли вы сгенерировать ключ / пару для IP (а не DNS-имени?)? т. е. потенциальный вариант использования этого мог бы состоять в том, что пользователь сначала подключается к устройству через http, а затем перенаправляет клиента на службу SSL, используя IP-адрес в URL-адресе перенаправления (чтобы браузер не жаловался на несоответствия). Это может быть карта, которая разрушает дом. Поскольку соединение SSL должно быть установлено до того, как произойдет какое-либо перенаправление, я вижу, что это также является проблемой. Но, если бы все работало волшебно
• Могу ли я затем использовать ICA-2 для генерации новых пар сертификат / ключ каждый раз, когда ящик меняет IP-адрес, чтобы при возврате веб-сервера он всегда получал «действительную» цепочку ключей.
  • ICA-2 -> SP-1

Хорошо, ты такой умный

Скорее всего, мое запутанное решение не сработает, но было бы замечательно, если бы оно сработало. У вас была похожая проблема? Что ты сделал? Какие были компромиссы?

Answer 1

По сути, нет, вы не можете делать это так, как надеетесь.

Вы не являетесь промежуточным SSL-полномочием и не можете себе его позволить.Даже если бы вы были, ни в коем случае не было бы права распространять среди потребителей все необходимое для создания новых действительных сертификатов для любого домена, которому по умолчанию доверяют все браузеры.Если бы это было возможно, вся система рухнула бы (не то, чтобы у нее уже не было проблем).

Обычно вы не можете заставить государственные органы подписывать сертификаты, выданные на IP-адреса, хотя ничего неттехнически это предотвращается.

Имейте в виду, что если вы действительно распространяете закрытые ключи не в защищенных от несанкционированного доступа криптомодулях, то ваши устройства на самом деле не защищены SSL.Любой, у кого есть одно из устройств, может получить закрытый ключ (особенно если он не имеет пароля) и проводить действительные, подписанные MITM-атаки на все ваши устройства.Вы препятствуете случайному прослушиванию, но это все.

Ваш лучший вариант - это, вероятно, получить и подписать сертификаты для действующего поддоменов в Интернете, а затем заставить устройство отвечать за этот поддомен.Если в исходящем пути это сетевое устройство, вы, вероятно, можете применить магию маршрутизации, чтобы он отвечал для домена, аналогично тому, как работает много систем в окружении стен.У вас может быть что-то вроде «system432397652.example.com» для каждой системы, а затем сгенерировать ключ для каждого поля, соответствующего этому поддомену.Имейте прямой IP-доступ, перенаправляющий к домену, и или сделайте, чтобы коробка перехватила запрос, или сделайте некоторую хитрость DNS в Интернете, чтобы домен разрешил к правильному внутреннему IP для каждого клиента.Для этого используйте специализированный хост-домен, не делитесь им с другими бизнес-сайтами.

Платить больше за сертификаты на самом деле не делает их более или менее законными.К тому времени, когда компания стала корневым центром сертификации, она уже далеко не летала.Вам следует проверить и проверить, подходит ли StartSSL для ваших нужд, поскольку они не взимают плату за каждый сертификат.