Отключить резервный SSL и использовать только TLS для исходящих соединений в .NET? (Смягчение пуделей)

Я пытаюсь уменьшить нашу уязвимость к атаке Poodle SSL 3.0 Fallback . Наши администраторы уже начали отключать SSL в пользу TLS для входящих подключений к нашим серверам. И мы также посоветовали нашей команде отключить SSL в своих веб-браузерах. Теперь я смотрю на нашу кодовую базу .NET, которая инициирует HTTPS-соединения с различными службами через System.Net.HttpWebRequest . Я считаю, что эти соединения могут быть уязвимы для атаки MITM, если они позволяют откат с TLS на SSL. Вот что я определил до сих пор. Не мог бы кто-нибудь перепроверить это, чтобы убедиться, что я прав? Эта уязвимость совершенно новая, поэтому мне еще предстоит увидеть какие-либо инструкции от Microsoft по устранению ее в .NET:

1. Разрешенные протоколы для класса System.Net.Security.SslStream, который поддерживает безопасную связь в .NET, устанавливаются глобально для каждого домена приложения через свойство System.Net.ServicePointManager.SecurityProtocol .

2. Значение этого свойства по умолчанию в .NET 4.5 равно Ssl3 | Tls(хотя я не могу найти подтверждающую документацию). SecurityProtocolType - это перечисление с атрибутом Flags, так что это побитовое ИЛИ этих двух значений. Вы можете проверить это в своей среде с помощью этой строки кода:

   Console.WriteLine (System.Net.ServicePointManager.SecurityProtocol.ToString ());

3. Это следует изменить на просто Tlsили, возможно Tls12, до того, как вы инициируете какие-либо подключения в своем приложении:

   System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls;

4. Важное замечание : поскольку свойство поддерживает несколько побитовых флагов, я предполагаю, что SslStream не будет автоматически переходить к другим неуказанным протоколам во время рукопожатия. В противном случае какой смысл поддерживать несколько флагов?

Обновление TLS 1.0 против 1.1 / 1.2:

По словам эксперта по безопасности Google Адама Лэнгли, TLS 1.0 позже оказался уязвимым для POODLE, если не был реализован правильно , поэтому вам следует подумать о переходе исключительно на TLS 1.2.

Обновление для .NET Framework 4.7 и выше:

Как упоминается ниже профессором фон Лемонгарглом , начиная с версии 4.7 .NET Framework, нет необходимости использовать этот хакерский прием, поскольку настройка по умолчанию позволяет ОС выбирать наиболее безопасную версию протокола TLS. Дополнительные сведения см. В разделе « Передовые методы безопасности транспортного уровня (TLS) с .NET Framework» .

Мы делаем то же самое. Чтобы поддерживать только TLS 1.2 и не использовать протоколы SSL, вы можете сделать следующее:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

SecurityProtocolType.Tls - это только TLS 1.0, а не все версии TLS.

В качестве стороны: если вы хотите проверить, что ваш сайт не разрешает SSL-соединения, вы можете сделать это здесь (я не думаю, что на это повлияет вышеуказанный параметр, нам пришлось отредактировать реестр, чтобы заставить IIS использовать TLS. для входящих подключений): https://www.ssllabs.com/ssltest/index.html

Чтобы отключить SSL 2.0 и 3.0 в IIS, см. Эту страницу: https://www.sslshopper.com/article-how-to-disable-ssl-2.0-in-iis-7.html

Ответ @Eddie Loeffen кажется самым популярным ответом на этот вопрос, но он имеет плохие долгосрочные последствия. Если вы просмотрите страницу документации для System.Net.ServicePointManager.SecurityProtocol здесь, раздел примечаний подразумевает, что фаза согласования должна просто решить эту проблему (и принудительное использование протокола является плохой практикой, потому что в будущем TLS 1.2 также будет скомпрометирован). Однако, если бы это было так, мы бы не стали искать этот ответ.

Исследования показывают, что протокол согласования ALPN необходим для доступа к TLS1.2 на этапе согласования. Мы взяли это за отправную точку и попробовали более новые версии инфраструктуры .Net, чтобы увидеть, где начинается поддержка. Мы обнаружили, что .Net 4.5.2 не поддерживает согласование с TLS 1.2, но .Net 4.6 поддерживает.

Итак, даже если принудительное использование TLS1.2 позволит выполнить свою работу, я рекомендую вам вместо этого перейти на .Net 4.6. Поскольку это проблема PCI DSS на июнь 2016 года, окно короткое, но новая структура - лучший ответ.

ОБНОВЛЕНИЕ: Работая по комментариям, я построил это:

ServicePointManager.SecurityProtocol = 0;    
foreach (SecurityProtocolType protocol in SecurityProtocolType.GetValues(typeof(SecurityProtocolType)))
    {
        switch (protocol)
        {
            case SecurityProtocolType.Ssl3:
            case SecurityProtocolType.Tls:
            case SecurityProtocolType.Tls11:
                break;
            default:
                ServicePointManager.SecurityProtocol |= protocol;
            break;
        }
    }

Чтобы проверить концепцию, я объединил SSL3 и TLS1.2 и запустил код, ориентированный на сервер, который поддерживает только TLS 1.0 и TLS 1.2 (1.1 отключен). С протоколами or'd вроде нормально подключается. Если я перейду на SSL3 и TLS 1.1, мне не удастся подключиться. Моя проверка использует HttpWebRequest из System.Net и просто вызывает GetResponse (). Например, я попробовал это и не смог:

        HttpWebRequest request = WebRequest.Create("https://www.contoso.com/my/web/resource") as HttpWebRequest;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls11;
        request.GetResponse();

пока это работало:

        HttpWebRequest request = WebRequest.Create("https://www.contoso.com/my/web/resource") as HttpWebRequest;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12;
        request.GetResponse();

Это имеет преимущество перед принудительным использованием TLS 1.2 в том, что если инфраструктура .Net обновлена ​​так, чтобы в Enum было больше записей, они будут поддерживаться кодом как есть. У него есть недостаток по сравнению с использованием .Net 4.6, поскольку он использует ALPN и должен поддерживать новые протоколы, если не указано никаких ограничений.

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

@watson

В формах окна это доступно, вверху класса поставьте

  static void Main(string[] args)
    {
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
       //other stuff here
    }

поскольку окна являются однопоточными, это все, что вам нужно, в случае, если это служба, вам нужно поместить ее прямо над вызовом службы (поскольку неизвестно, в каком потоке вы будете).

using System.Security.Principal 

тоже нужен.

Если вам интересно, какие протоколы поддерживает .NET, вы можете попробовать HttpClient на https://www.howsmyssl.com/.

// set proxy if you need to
// WebRequest.DefaultWebProxy = new WebProxy("http://localhost:3128");

File.WriteAllText("howsmyssl-httpclient.html", new HttpClient().GetStringAsync("https://www.howsmyssl.com").Result);

// alternative using WebClient for older framework versions
// new WebClient().DownloadFile("https://www.howsmyssl.com/", "howsmyssl-webclient.html");

Результат потрясающий:

Ваш клиент использует TLS 1.0, который очень старый, возможно, восприимчивый к атаке BEAST, и не имеет лучших доступных наборов шифров. Такие дополнения, как AES-GCM и SHA256 для замены MD5-SHA-1, недоступны для клиента TLS 1.0, а также для многих других современных наборов шифров.

Как объясняет Эдди выше, вы можете включить лучшие протоколы вручную:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11; 

Я не знаю, почему он изначально использует плохие протоколы. Это кажется плохим выбором настройки, равносильно серьезной ошибке безопасности (держу пари, что многие приложения не меняют настройки по умолчанию). Как мы можем сообщить об этом?

Мне пришлось преобразовать целочисленный эквивалент, чтобы обойти тот факт, что я все еще использую .NET 4.0.

System.Net.ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
/* Note the property type  
   [System.Flags]
   public enum SecurityProtocolType
   {
     Ssl3 = 48,
     Tls = 192,
     Tls11 = 768,
     Tls12 = 3072,
   } 
*/

Я обнаружил, что самое простое решение - добавить две записи в реестр следующим образом (запустите это в командной строке с правами администратора):

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:32

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:64

Эти записи, похоже, влияют на то, как .NET CLR выбирает протокол при создании безопасного соединения в качестве клиента.

Дополнительная информация об этой записи реестра находится здесь:

https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/2960358#suggested-actions

Это не только проще, но и, если предположить, что это работает в вашем случае, гораздо более надежно, чем решение на основе кода, которое требует от разработчиков отслеживания протокола и разработки и обновления всего соответствующего кода. Будем надеяться, что аналогичные изменения среды могут быть сделаны для TLS 1.3 и более поздних версий, если .NET остается достаточно глупой, чтобы автоматически не выбирать самый высокий доступный протокол.

ПРИМЕЧАНИЕ . Несмотря на то, что, согласно приведенной выше статье, это должно отключать только RC4, и никто бы не подумал, что это изменит, разрешено ли клиенту .NET использовать TLS1.2 + или нет, по какой-то причине у него есть это эффект.

ПРИМЕЧАНИЕ . Как отметил @Jordan Rieger в комментариях, это не решение для POODLE, поскольку оно не отключает старые протоколы a - оно просто позволяет клиенту работать с новыми протоколами, например, когда исправленный сервер отключил старые протоколы. протоколы. Однако при атаке MITM очевидно, что скомпрометированный сервер предложит клиенту более старый протокол, который затем клиент с радостью будет использовать.

ЗАДАЧА : попробуйте отключить использование TLS1.0 и TLS1.1 на стороне клиента с помощью этих записей реестра, однако я не знаю, соблюдают ли клиентские библиотеки .NET эти параметры или нет:

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-10

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-11