Вибір ciphersuites для TLS і вразливість Logjam. Досвід Яндекса

Зараз на тлі уразливості Logjam все в індустрії вкотре обговорюють проблеми і особливості TLS. Я хочу скористатися цією можливістю, щоб поговорити про одну з них, а саме — про налаштування ciphersiutes. Ми вже не раз писали на Хабре про те, як впроваджуємо шифрування трафіку на сервісах Яндекса: наприклад, про це досить докладно розповідав Ельдар kyprizel Заитов, але ciphersiutes були однією з речей, які в той раз залишилися в основному за кадром. До речі, хочу всіх заспокоїти і сказати, що на серверах Яндекса ніколи не використовувався експортний варіант алгоритму Діффі-Хеллмана.

Отже, Ciphersuite — це сукупність алгоритмів, використовуваних в конкретній TLS–сесії. Сюди відносяться:

  • алгоритм вироблення сесійних ключів шифрування;
  • алгоритм, використовуваний для аутентифікації сервера;
  • власне симетричний алгоритм шифрування трафіку;
  • і, нарешті, алгоритм контролю цілісності (MAC, message authentication code).
Для того щоб зрозуміти, яка роль кожного з алгоритмів, давайте коротко розглянемо процес ініціалізації TLS–з'єднання в застосуванні до HTTPS (зрозуміло, TLS можливий і для інших TCP і UDP протоколи, але зараз ми розглядати не будемо). За подробицями можна звернутися в RFC5246.

image

У TLS є власний механізм поділу на повідомлення, званий record protocol. Кожне TLS-повідомлення не зобов'язана бути одно TCP сегменту, воно може бути більше або менше.

TLS з'єднання починає клієнт — пересиланням повідомлення ClientHello. Найцікавіша для нас частина повідомлення ClientHello — якраз список підтримуваних клієнтом ciphersuite. Також клієнт посилає список відомих йому еліптичних кривих.

ClientHello

У відповідь сервер пересилає повідомлення ServerHello, що містить вибраний ciphersuite:

ServerHello

В даному випадку це TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Цей варіант означає, що для генерації сеансових ключів буде використаний алгоритм Діффі-Хеллмана на еліптичних кривих, аутентифікація сервера буде проводиться за допомогою RSA, а в якості алгоритму шифрування трафіку буде використовуватися AES з довжиною ключа 128 біт в режимі GCM. Уважний читач помітить, що GCM є AEAD-алгоритмом і таким чином не вимагає додаткової функції MAC. Навіщо ж вона потрібна? Відповідь криється в механізмі вироблення сеансових ключів, але спочатку давайте обговоримо деякі варіанти кожного алгоритму в ciphersuite. З повним списком всіх можливих варіантів можна ознайомитися на сайті IANA.

Отже, в якості алгоритму вироблення сеансових ключів можуть використовуватися:
  • класичний алгоритм Діффі-Хеллмана, він позначається DH і DHE;
  • варіант алгоритму Діффі-Хеллмана на еліптичних кривих, він позначається ECDH і ECDHE;
  • генерація випадкового числа клієнтом і подальше його шифрування на публічному ключі сервера, в реальних ситуаціях майже завжди застосовується RSA.
Різниця між варіантами DH без суфікса E і з суфіксом E полягає в ефемерності ключа. У разі DHE і ECDHE ключ дійсно виробляється в ході повноцінного DH-обміну, де параметри шифрування не зберігаються і таким чином досягається властивість PFS. У ciphersuites DH і ECDH приватний ключ сервера і клієнта, якщо він є) є приватним ключем для DH-обміну і таким чином властивість PFS не досягається.

В якості алгоритму аутентифікації у практичних реаліях використовується майже виключно RSA, ECDSA робить перші кроки, але ми сподіваємося, що він буде більше поширений.

Як симетричних алгоритмів шифрування широко поширені AES з довжиною ключа 128 і 256 біт в режимах CBC і GCM, RC4 і 3DES. Можна зустріти ciphersuite з одиночним DES, CHACHA20 і навіть NULL — це означає, що ніякого шифрування насправді застосовуватися не буде.

В якості алгоритмів MAC зустрічаються MD5, SHA1, SHA256 і, рідко, SHA384.

Як було сказано вище, у випадку алгоритму шифрування AES в режимі GCM контроль цілісності забезпечується власне режимом шифрування. Тому необхідності в окремій MAC–функції немає. В RFC на TLS1.2 спеціально зазначено, що крім власне функції аутентифікації MAC-алгоритм в ciphersuite виконує ще і роль псевдовипадковою функції (PRF). Коли спільне між клієнтом і сервером випадкове число виробляється за рахунок того або іншого варіанта DH або просто генерується клієнтом, воно носить назву pre-master key. Після отримання pre-master key на його основі (а також на основі випадкових значень повідомлень ClientHello і ServerHello) виробляється master key шляхом застосування PRF функції: master_secret = PRF(pre_master_secret, «master secret», ClientHello.random + ServerHello.random). Згодом master key з допомогою тієї ж функції PRF обчислюється весь необхідний ключовий матеріал: ключі для шифрування, ключі для MAC, инициализационные вектори.

Ciphersuites в реальному житті
Тепер, коли базова теорія зрозуміла, давайте розглянемо налаштування ciphersuites на деяких популярних сайтах. Для цього можна використовувати сканер SSLLabs, хоча у нас в Яндексі для внутрішніх потреб використовується написаний kyprizel інструмент. В принципі, можна використовувати команду openssl s_client з ключем-cipher або спробувати cipherscan, який по суті є обгорткою на bash для виклику openssl.

Для того що б тестувати варіанти ciphersuites локально, зручно використовувати команду openssl ciphers, яка дозволить подивитися, у що саме перетвориться пропонований набір умов для ciphersuite.

Отже, власне, Яндекс. Список підтримуваних сервером ciphersuites досить великий:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA (0x5)
TLS_ECDHE_RSA_WITH_RC4_128_SHA


Спочатку йдуть сучасні ciphersuites з виробленням pre-master ключа через ECDHE. Ми воліємо AES-128 в режимі GCM. Я особисто не бачу великої користі від AES256, але для yandex.ru ми зберегли цей набір шифрів для більш параноїдальних користувачів. Після різних варіантів ECDHE ciphersuites йдуть варіанти з шифруванням AES, але без PFS. Такі варіанти використовуються браузерами типу старої Opera версії 12.x), і тому ми змушені їх зберегти.

Потім йде два варіанти з шифруванням 3DES: їх ми зберігаємо в першу чергу для браузерів Internet Explorer на Windows XP з встановленим SP3. Internet Explorer використовує системну бібліотеку Schannel, і в XP з SP3 нарешті з'явилася підтримка 3DES — застарілого, але все ще стійкого алгоритму шифрування. Нарешті, для нещасних з Internet Explorer 6 на XP ми зберігаємо шифри RC4 — інших варіантів на цій платформі просто немає. При цьому ми усвідомлюємо ймовірність того, що цей шифр вразливий, тому він доступний тільки в разі хендшейка по протоколу SSLv3. Якщо клієнт підключається з більш сучасним протоколом — TLS 1.0, TLS 1.1 або TLS 1.2 — ciphersuite на основі RC4 не пропонується.

Сервери пошуку таким чином пропонують трейдофф між безпекою для сучасних клієнтів і необхідністю підтримувати старі.

Інша ситуація на серверах Яндекс.Пошти. Тут, наприклад, команда прийняла продуктове рішення не підтримувати IE6 (навіть у так званої «легкої» верстці) і це відбилося у підтримці на рівні TLS:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA


Логіка збережена тією ж, але трейдофф зрушено в бік більшої безпеки і меншою сумісності з застарілими браузерами. Спочатку — сучасні ciphersuite для TLS1.2: наш улюблений ECDHE + AES128 в режимі GCM, потім те ж саме, але в режимі CBC і, нарешті, варіант з більш слабким SHA1. Наступні три варіанти — те ж саме, але без PFS. Замикає набір ciphersuite для IE8: 3DES в режимі CBC з SHA1 і без PFS. Дуже хочемо від нього відмовитися, тому в Пошті ми почали кампанію по оновленню браузерів користувачів. Якщо ви налаштовуєте комп'ютери своїм батькам, не полінуйтеся — встановити сучасний браузер. Виконайте те ж саме і в своїй організації.

Ще один варіант — Яндекс.Паспорт. Тут ми пробували зберегти класичний DH, оскільки помічали ситуації, коли перебували браузери, які все таки воліли його і, можливо, не мали підтримки ECDH (один час це відносилося до Firefox на RedHat Linux, де з юридичних міркувань були відсутні протоколи з еліптичної криптографією). При цьому задовго до публікації атаки Logjam ми розуміли необхідність вирівнювання довжин ключів і марність використання 1024-бітного DH при 2048-бітних RSA ключах у сертифікатах. passport.yandex.ru доступний DHE, але 2048-бітний, створений спеціально для цього випадку, і сервіс не схильний Logjam. Інша логіка така: спочатку ECDH з AES в різних варіантах, потім DH з AES, потім AES без PFS і, нарешті, fallback в 3DES без PFS.

Давайте подивимося і на «їхні звичаї». Ось приклад з gmail.com.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 
TLS_ECDHE_RSA_WITH_RC4_128_SHA 
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA


Мені в цілому зрозуміла логіка пріоритетів: спочатку ECDH і AES. Зверніть увагу, що Google вирішив спробувати шифр CHACHA20, про який я писав вище. Мені здається, що головна його мета — полегшити навантаження на CPU (і, відповідно, витрата енергії) в смартфонах на базі Android. Що і говорити, домінування має свої переваги — контролюючи і сервіс, і платформу можна робити недоступні іншим речі. Цікаво, що Google використовує свій форк OpenSSL під назвою BoringSSL. Його корисна властивість — можливість задавати ciphersuites рівних пріоритетів. Так у цьому випадку (хоча ssllabs цього не показує), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 і TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 мають однаковий пріоритет і серед них клієнт визначає, який ciphersuite вважає пріоритетним.

Ось twitter.com:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA


І знову зрозуміла логіка, дуже схожа на нашу Пошту: спочатку ECDHE, навіщо AES без PFS і fallback на 3DES.

Логіка на vk.com мені незрозуміла. Здається, тут просто взяли всі шифри і викинули з них MD5 і RC4. Думаю, схожий набір можна отримати командою openssl ciphers 'ALL:!RC4:!MD5'. Шифр CAMELLIA? Are serious?

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA


У mail.ru спочатку ECDHE, потім DHE, потім — шифри без PFS, але знову ж — CAMELLIA, SEED. Здається, і тут ніхто не обирав ciphersuites, а поклався на варіанти, пропоновані OpenSSL за замовчуванням.

Цікаво, що до недавнього часу сервер nsa.gov мав дуже слабкий набір ciphersuites, найкращим варіантом там був RC4 без PFS, але зараз ситуацію виправили з тією ж самою логікою, що і у нас: ECDHE і AES, RSA і AES, fallback на 3DES. Аналогічно виглядає https на сайті ЦРУ. Цікаво, що на сайтах ФСБ і СЗР взагалі не працює https.

Втім, за моєю особистою оцінкою, сайтом з найгіршими ciphersuites в інтернеті був сайт Держпослуг уряду Москви login.mos.ru. Свого часу він пропонував ciphersuite TLS_NULL_WITH_NULL_NULL — тобто без аутентифікації і без шифрування. Втім, зараз вжиті заходи: затримка на установку з'єднання з TLS sslabs.com встановлений таким чином, що сканер відвалюється по таймауту. Але і ciphersuites поправлені, хоча вищим пріоритетом стоять RC4-MD5, RC4-SHA і 3DES-SHA, у списку можна знайти ECDH — це можна перевірити вручну командою openssl s_client з ключем-cipher.

Рекомендації по вибору ciphersuite
Які налаштування можна порекомендувати звичайного сайту? Ось такий рекомендований конфіг nginx ми використовуємо в Яндексі за замовчуванням:

ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers kEECDH+AESGCM+AES128:kEECDH+AES128:kRSA+AESGCM+AES128:kRSA+AES128:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;


Якщо необхідна підтримка IE8 на XP, можна використовувати такий набір, він включить 3DES:
ssl_ciphers kEECDH+AESGCM+AES128:kEECDH+AES128:kRSA+AESGCM+AES128:kRSA+AES128:kRSA+3DES:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;


Якщо потрібна підтримка IE6 на XP, можна включити RC4, але в таких випадках ми рекомендуємо нашим системним адміністраторам проконсультуватися зі службою інформаційної безпеки, щоб точно представляти свої ризики. Я не впевнений, що якимось сайтів за межами першої півсотні найпопулярніших в рунеті дійсно необхідна така підтримка.

До речі, знайдете цікаві налаштування ciphersuite в інтернеті, пишіть.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.