Вимкнути резервну копію SSL та використовувати лише TLS для вихідних з'єднань у .NET? (Пом’якшення пуделя)

Я намагаюся пом’якшити нашу вразливість до нападу пуделя SSL 3.0 Fallback . Наші адміністратори вже почали відключати SSL на користь TLS для вхідних підключень до наших серверів. А також ми порадили нашій команді вимкнути SSL у своїх веб-браузерах. Зараз я розглядаю нашу кодову базу .NET, яка ініціює з'єднання HTTPS з різними службами через System.Net.HttpWebRequest . Я вважаю, що ці з'єднання можуть бути вразливими для атаки MITM, якщо вони дозволять відновлювати з TLS до SSL. Ось що я визначив поки що. Може хтось, будь ласка, повторно перевірив це, щоб переконатися, що я правий? Ця вразливість є абсолютно новою, тому я ще не бачив ніяких вказівок від Microsoft щодо її зменшення в .NET:

1. Дозволені протоколи для класу System.Net.Security.SslStream, який лежить в основі захищеного зв'язку в .NET, встановлюються глобально для кожного AppDomain через властивість 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 і вище:

Як згадував проф. Фон Lemongargle нижче, починаючи з версії 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 також буде порушена). Однак ми б не шукали такої відповіді, якби це було.

Досліджуючи, виявляється, що для переходу до TLS1.2 на етапі переговорів необхідний протокол переговорів ALPN. Ми взяли це як вихідний пункт і спробували нові версії фреймворку .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, оскільки 4.6 використовує ALPN і повинен підтримувати нові протоколи, якщо не вказано обмеження.

Редагувати 29.04.2019 - Microsoft опублікувала цю статтю в жовтні минулого року. У них є досить хороший конспект їх рекомендацій щодо того, як це слід робити в різних версіях .net фреймворку.

@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#sugges-action

Це не тільки простіше, але припускаючи, що він працює у вашому випадку, набагато надійніший за рішення на основі коду, яке вимагає від розробників відстежувати протокол та розробку та оновлювати весь відповідний код. Сподіваємось, подібні зміни середовища можуть бути внесені для TLS 1.3 і вище, доки .NET залишається досить тупим, щоб не автоматично вибирати найвищий доступний протокол.

ПРИМІТКА . Хоча, згідно зі статтею вище, це повинно вимкнути RC4, і не можна було б думати, що це зміниться, чи дозволено клієнту .NET використовувати TLS1.2 + чи ні, чомусь у нього є це ефект.

ПРИМІТКА . Як зазначає @Jordan Rieger у коментарях, це не рішення для POODLE, оскільки він не вимикає старіші протоколи a - він просто дозволяє клієнту працювати з новішими протоколами, наприклад, коли виправлений сервер відключив старіший протоколи. Однак при атаці MITM, очевидно, компрометований сервер запропонує клієнту старіший протокол, який клієнт потім із задоволенням використовуватиме.

TODO : Спробуйте відключити використання клієнтами TLS1.0 та TLS1.1 на базі клієнта з цими записами реєстру, однак я не знаю, чи дотримуються ці параметри бібліотеки клієнтів .NET http:

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