Назад | Перейти на главную страницу

Каковы риски доверия самозаверяющему сертификату на машине разработки?

У нас есть машины для разработки, которые тестируют разрабатываемые веб-приложения по https, потому что развернутое приложение работает по https.

У нас есть пара внутренних URL-адресов, настроенных в нашем файле hosts, так что https: // проект-разработчик и https: // проект-www можно использовать для тестирования разных веток. Мы также отлаживаем в Windows Azure dev Fabric, что приводит к тому, что приложение переходит https://127.0.0.1. Для этого есть еще один сертификат, но он автоматически создается фабрикой разработки.

Чтобы наши браузеры игнорировали небезопасные сертификаты, мы перетаскиваем их из личных в доверенные корневые центры сертификации.

Делает ли это каким-либо образом наши машины разработки уязвимыми? Если да, то как?

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

Потенциально, если выйдет закрытый ключ вашего сертификата, это может позволить кому-то MITM вас.

Вывод: не совсем.

Всегда есть небольшой риск, но вы - пара разработчиков, на которых кто-то должен будет явно нацелиться, чтобы это произошло.

Возможно, я о чем-то не думаю, но как-то Я думаю, ты справишься.

Самоподписанный сертификат не более уязвим, чем сертификат, подписанный центром сертификации. Он становится небезопасным из-за поведения пользователей, которые привыкнут слепо принимать их и доверять им. Если вы добавите сертификат в доверенные корневые центры сертификации, то ваш компьютер будет доверять любому сертификату, подписанному этим сертификатом. Поэтому, если один из ваших самоподписанных сертификатов будет скомпрометирован, все машины, на которых он установлен, станут уязвимыми для человека в средней атаке. Хуже всего то, что у вас не может быть списка отзыва для них, и вам придется удалить их вручную, если он будет скомпрометирован.

Лучший подход - использовать внутренний центр сертификации и подписывать ВСЕ внутренние сертификаты с вашим ЦС. Это одновременно очень безопасно, удобно и дешево.

Чтобы настроить ЦС:

  1. Создайте физический компьютер, который будет использоваться в качестве центра сертификации. Только доверенные администраторы должны иметь доступ к этому ящику (в идеале - 2 человека).
  2. Создайте сервер отзыва, он должен отличаться от компьютера CA. (сервер со списком отозванных сертификатов, который будет доступен хотя бы в вашей организации)
  3. Создайте корневой сертификат.
  4. Создайте промежуточный сертификат, который будет использоваться для подписания.
  5. Распечатайте закрытый ключ корневого центра сертификации на бумаге и поместите ее в надежный сейф.
  6. Уничтожьте корневой закрытый ключ CA с сервера CA.
  7. Распространите сертификат CA по всей компании и установите его как доверенный CA.
  8. Распространите промежуточный сертификат CA и установите его как промежуточный CA (ненадежный).
  9. Подпишите все сертификаты промежуточным сертификатом CA. Не допускайте истечения срока годности более 1-2 лет. Не допускайте асимметричных ключей меньше 2048.
  10. Добавить в список отзыва все скомпрометированные сертификаты.