Я понимаю, почему нужны предупреждения SSL и почему пользователи, даже опытные, должны быть лишены возможности легко их игнорировать. Я также понимаю, что в целом подход «белого списка» или доверенного ненадежного корневого CA является наилучшим подходом при работе на вашей повседневной рабочей станции, на которой вы также осуществляете банковские операции, торговлю или электронную почту.
Тем не менее, если я использую Internet Explorer 8только что подготовленный тестовый ящик, не имеющий доступа к Интернету, мне нет смысла постоянно нажимать одну или две кнопки, чтобы управлять сервером https://my-vm-213.goofy.localили чем-то еще. И если мы имеем дело с хостами, которые будут скакать вверх-вниз и вбок в больших количествах, мне нет смысла тратить время на добавление корневых CA, которые глупо добавлять и которые не будут иметь смысла в течение нескольких часов.
У меня такой вопрос: есть ли способ «всегда проходить» проверки SSL:
- На уровне ОС Windows? (та же подсистема, которая администрируется графическим
Certificatesmmcинтерфейсом иcertutilт. д.) - На уровне браузера? - для любого основного браузера, особенно
Internet Explorer - На самом низком возможном уровне в Unix-подобных системах? (Я предполагаю, что это так,
OpenSSLно на самом деле я не знаю)
Для меня это было бы что-то вроде:
( X ) Always validate SSL certificates (DANGEROUS!)
Более подробное обоснование ниже
Если вы знаете, что работаете в лабораторной среде, недавно созданной среде или среде малого бизнеса, строго над системными вопросами, то нет никакой выгоды с точки зрения конфиденциальности или целостности (или осознания их отсутствия), когда вывсегдаподавляйте предупреждения SSL, потому что вы уже знаете, что они появятся. Я полагаю, вы могли бы возразить: «А что, если кто-то знает, что вы так небрежны в этом вопросе, и использует это, специально нацеливаясь на те типы хостов, которые вы хотите подавить», но этот аргумент имеет смысл только в том случае, если a) есть какие-либо очевидные способы использовать ваше тестирование совместимости браузера IE8 для приложения Intranet, b) вы неправильно настроили сетевое взаимодействие своей виртуальной машины и фактически позволили ей передавать или получать пакеты через свой шлюз, и по другим причинам, но самое главное,в) вы когда-либо делали что-либоиначев результате этого предупреждения при работе на хосте, который, как вы знаете, выдаст это предупреждение.
решение1
Если вам нужна безопасность, то используйте SSL, и используйте его правильно. Если вам не нужна безопасность, то не используйте SSL.
Неправильное использование SSL наносит больший ущерб безопасности, удобству использования и доступности, чем его полное отсутствие.
Современные браузеры наконец-то усилили безопасность, и это нормальная эволюция.
решение2
Центрального места нет.
Для Internet Explorer вы можете взломать некоторые DLL и заменить существующую функциональность. И вам может потребоваться сделать это для каждой версии Windows, которую вы используете, и поддерживать ее в актуальном состоянии после обновлений ОС. У hrome и Firefox есть свои собственные стеки SSL (NSS), которые вам нужно будет изменить. Похожая ситуация и в Mac OS X, где Safari использует один стек TLS, а Chrome и Firefox используют свои собственные стеки TLS (опять же NSS). А в системе UNIX вам в основном придется иметь дело с Firefox и Chrome, которые снова в настоящее время используют стек NSS.
Усилия, необходимые для взлома всех этих мест, вероятно, превышают усилия, необходимые для добавления пользовательского центра сертификации, который вы используете для своих тестовых сайтов.
решение3
Возможно, вам лучше добавить прозрачный прокси, который удаляет SSL, или создает соответствующие сертификаты на лету в качестве атаки в стиле MITM. Таким образом, нужен только один частный CA. Это должно быть легко при использовании любой системы предоставления.