Tls fallback scsv windows

Время на прочтение7 мин

Количество просмотров36K

Картинка с сайта: habr.com

Интересующиеся веб-безопасностью хабражители уже в курсе очередной уязвимости в SSL, именуемой POODLE. Мы подробно рассмотрим, что же собой представляет эта уязвимость и каким именно образом позволяет злоумышленнику добраться до, казалось бы, защищенных данных пользователя, а также расскажем, как с этим зверем справилась команда Mail.Ru Group.

Исчерпывающее объяснение механизма использования POODLE приводится в статье This POODLE Bites: Exploiting The SSL 3.0 Fallback; ниже мы приводим перевод этой статьи.

Тем же, кого не слишком интересуют детали деятельности зловредного пса, напомним, что POODLE – это уязвимость в SSL 3, старой версии протокола, доживающей второй десяток. Существует два способа борьбы с уязвимостью:

• Поставить на сервер патч, запрещающий в процессе хэндшейка откатываться на SSL3 при невозможности подключиться по TLS. Загвоздка в том, что такой метод работает, только если патч стоит и на сервере, и на клиенте. В настоящее время это реализовано только у Google Chrome (начиная с февраля 2014 года) и планируется в ближайшем обновлении Firefox. Получается, что обеспечение безопасности пользователей в определенной мере ложится на плечи самих пользователей.
• Отключить SSL 3 на серверах, да и дело с концом. Просто и элегантно, но есть одно «но». Большая часть браузеров использует TLS версии 1.0 и выше, однако в мире все еще остались люди, не готовые расстаться с наследием прошлого, именуемым Internet Explorer версии 6, который просто не поддерживает новые версии протокола в конфигурации по умолчанию.

Наша статистика показывает, что через IE6 в Почту Mail.Ru заходят 0,2% пользователей. И, хотя в абсолютных величинах это не такая уж маленькая цифра, мы считаем, что безопасность — прежде всего. Поэтому мы отключили возможность соединения с клиентом по SSL3 в Почте, Облаке, Календаре, авторизационном центре и «Mail.Ru для бизнеса».

Для пользователей IE6 это означает, что Почта Mail.Ru, равно как и другие сервисы, выбравшие такой способ борьбы с POODLE, больше не будут им доступны. Вряд ли среди аудитории Хабра много приверженцев IE6, но советуем убедиться, что ваши родственники и друзья, не слишком дружащие с современными технологиями, обновили свои браузеры.

В случае с сервисами, которые предпочли первый способ защиты от уязвимости, если вы – пользователь Chrome, регулярно обновляющегося автоматически, – поздравляем, вы защищены. Если же вы предпочитаете другие браузеры, рекомендуем пользоваться свежим Chrome по крайней мере при доступе к общественному Wi-Fi, ведь именно в этом случае вы уязвимы. Почему именно тогда? Об этом можно узнать из предложенного ниже перевода.

SSL 3.0 [RFC6101] — это устаревший и небезопасный протокол. При решении большинства практических задач его уже заменили преемники, протоколы TLS 1.0 [RFC2246], TLS 1.1 [RFC4346] и TLS 1.2 [RFC5246], однако в них сохраняется обратная совместимость с SSL 3.0 для взаимодействия со старыми системами. Это позволяет избежать проблем с клиентскими устройствами при внедрении новых версий протоколов на серверах.

Но даже если и клиент, и сервер поддерживают TLS, то уровень безопасности в SSL 3.0 — вопрос все еще актуальный, поскольку многие клиенты применяют более старые протоколы, чтобы справляться с багами совместимости с серверами. И здесь мы хотели бы обсудить, как злоумышленники могут использовать эту ситуацию и взламывать протокол SSL 3.0. Речь пойдёт о POODLE-атаке (Padding Oracle On Downgraded Legacy Encryption), благодаря которой можно, например, перехватывать Secure HTTP-куки или содержимое заголовков HTTP-авторизации.

Мы также порекомендуем, какие нужно принять меры на клиентах и серверах, чтобы противостоять подобной атаке. Если простое отключение SSL 3.0 вам не подходит по причинам совместимости, то в имеющихся версиях TLS нужно использовать TLS_FALLBACK_SCSV.

Описание POODLE-уязвимости

Для обеспечения совместимости со старыми версиями серверов многие TLS-клиенты используют downgrade dance: сначала делается попытка установления связи по протоколу последней версии. Если связь не устанавливается, делается новая попытка, но уже по более старому протоколу. В отличие от нормальной процедуры определения версии, поддерживаемой обеими сторонами (например, клиент обращается по протоколу TLS 1.2, а сервер отвечает по TLS 1.0), вышеописанная схема может быть инициирована из-за сетевых ошибок или действий злоумышленников. Если атакующие, контролирующие сеть на участке между клиентом и сервером, вмешиваются и препятствуют установлению соединения с версией протокола TLS 1.0 или выше, то клиенты сами переходят на использование SSL 3.0.

Протокол использует потоковое шифрование RC4, или блочное шифрование в режиме CBC. Главной проблемой RC4 является наличие смещений: чем больше соединений и потоков шифрования используется для отправки одних и тех же данных (например, пароля или HTTP-куки), тем больше можно извлечь из трафика информации, которая помогает осуществить дешифрование. Ниже будет показано, как можно совместить эффективную атаку на CBC-шифрование при использовании SSL 3.0 (при условии, что злоумышленник может модифицировать сетевой обмен между клиентом и сервером). При этом, в отличие от уязвимостей BEAST и Lucky 13, здесь нет каких-то обходных решений. У нас есть только небезопасный протокол SSL 3.0, и чтобы обеспечить надёжное шифрование, нужно избегать его использования.

Самая серьёзная проблема CBC-шифрования в SSL 3.0 заключается в том, что дополнение блоков (паддинг) может быть произвольным (за исключением последнего байта), на него не распространяется MAC (Message Authentication Code). Целостность дополнения не может быть полностью подтверждена в ходе дешифрования, поскольку в SSL 3.0 сообщение сначала подписывается с помощью MAC, затем дополняется паддингом, и уже после — шифруется блочным шифром. Паддинг от 1 до L байт (где L — размер блока в байтах) используется для получения целого числа блоков перед шифрованием. Легче всего пробить защиту, если есть целый блок паддинга, который (до шифрования) состоит из L-1 произвольных байт, за которыми следует одиночный байт со значением L-1. Для обработки входящей зашифрованной записи C₁… C_n, когда также дан вектор инициализации С0 (где каждый C_i — один блок), принимающая сторона сначала определяет P₁… P_n как P_i = D_K(C_i) ⊕ C_i-1 (D_K обозначает расшифровку одного блока с помощью сессионного ключа K). Затем проверяется и удаляется паддинг в конце сообщения и, наконец, проверяется и удаляется подпись MAC.

Если последний блок C_n целиком представляет собой паддинг, и атакующий заменяет C_n на любой более ранний шифрованный блок C_i из того же потока, то сообщение будет всё равно принято, при условии что D_K(C_i) ⊕ C_n-1 имеет последний байт L-1, в противном случае он наверняка будет отклонён, что даёт возможность провести атаку Padding Oracle.

Вне лабораторных условий слабость SSL 3.0 может быть использована в MITM-атаках, когда злоумышленник расшифровывает Secure HTTP-куки, используя методику атаки BEAST. Чтобы осуществить POODLE-атаку, нужно:

• Запустить JS- на www.evil.com, чтобы браузер жертвы отправил содержащий куки HTTPS-запрос на https://example.com
• Перехватить и модифицировать запись SSL так, чтобы был достаточно большой шанс, что example.com примет изменённую запись. Если это произойдёт, то злоумышленник сможет расшифровать один байт из куки

Допустим, что каждый блок С содержит 16 байт — C[0]… C[15]. Также допустим, что нам стал известен размер куки (ниже покажем, как провести атаку, не зная размера куки). Размер MAC в SSL 3.0 обычно равен 20 байтам, так что «под слоем» CBC зашифрованный POST будет выглядеть так:

POST /path Cookie: name=value…\r\n\r\nbody ǁ 20byteMAC ǁ padding

Злоумышленник контролирует path и тело запроса, и потому может инициировать запросы, удовлетворяющие двум условиям:

• Паддинг заполняет весь блок (зашифрованный в C_n)
• Первый, пока ещё неизвестный, байт куки подставляется как последний в более раннем блоке (зашифрованном в C_i)

Далее атакующий заменяет C_n на C_i и перенаправляет эту модифицированную запись на сервер.

Чаще всего сервер её не принимает, и тогда атакующий отправляет новый запрос. Иногда (примерно один раз на 256 попыток) сервер принимает модифицированную запись и атакующий заключает, что D_k(C_i)[15] ⊕ C_n-1[15] = 15, а следовательно P_i[15] = 15 ⊕ C_n-1[15] ⊕ C_i-1[15]. Это раскрывает первый байт куки, до этого неизвестный. Атакующий переходит к следующему байту, одновременно изменяя размеры пути и тела запроса так, чтобы размер запроса не изменился, но местоположение заголовков сдвинулось. Это делается до тех пор, пока кука не будет расшифрована целиком. Ожидаемые общие трудозатраты — 256 запросов SSL 3.0 на один байт.

Поскольку паддинг скрывает точный размер полезного содержимого, размер куки не становится сразу же очевиден. Но запросы GET /, GET /A, GET /AA,… позволяют злоумышленнику вычислить границы блоков. Достаточно максимум 16 подобных запросов, чтобы узнать размер дополнения, а следовательно и размер куки.

Рекомендации

Вышеописанная атака требует соединения по протоколу SSL 3.0, поэтому его отключение в клиенте или на сервере (или с обеих сторон) позволяет полностью избежать неприятностей. Если хотя бы одна сторона поддерживает только SSL 3.0, то здесь медицина бессильна, и необходимо серьёзное обновление, чтобы избежать небезопасного шифрования. Если SSL 3.0 — не единственный поддерживаемый протокол и он не отключён, то тогда атака возможна при downgrade dance (переключении клиента на более низкие версии ради совместимости с сервером).

Отключение SSL 3.0 может быть нецелесообразным, если вам нужно периодически работать со старыми системами. Механизм TLS_FALLBACK_SCSV решает общую проблему для разных версий протокола, и мы полагаем, что это особенно критично для систем, поддерживающих совместимость с SSL 3.0. Ниже объясняется алгоритм работы TLS_FALLBACK_SCSV.

TLS-клиенты, использующие downgrade dance, должны включать значение 0x56, 0x00 в ClientHello.cipher_suites во время каждого даунгрейда версии протокола. Это значение служит сигналом, благодаря которому обновлённые серверы могут отказаться от установления соединения в случае downgrade-атаки. Клиенты должны всегда переходить на следующую более низкую версию (например, если начал с TLS 1.2, то попытаться на TLS 1.1, затем на TLS 1.0, затем SSL 3.0). В случае с TLS_FALLBACK_SCSV, пропуск версии также может помешать успешному соединению.

TLS-серверы, когда во входящем соединении встречается 0x56, 0x00 в ClientHello.cipher_suites, сравнивают ClientHello.cipher_version с самой высокой версией протокола, поддерживаемой сервером. Если сервер поддерживает более высокую версию, чем клиент, то соединение обрывается с ошибкой.

Такое использование TLS_FALLBACK_SCSV даёт уверенность, что SSL 3.0 будет использоваться только при работе со старыми системами: атакующие не могут более инициировать понижение версии протокола. Если же обе стороны допускают использование SSL 3.0, но одна из них не поддерживает TLS_FALLBACK_SCSV, то атака всё ещё возможна.

Список литературы

• [BEAST] T. Duong, J. Rizzo: “Here Come The ⊕ Ninjas”, 2011.
• [draft-ietf-tls-downgrade-scsv-00] B. Möller, A. Langley: “TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks”, Internet-Draft draft-ietf-tls-downgrade-scsv-00, 2014.
• [Lucky13] N.J. AlFardan, K.G. Paterson: “Lucky Thirteen: Breaking the TLS and DTLS Record Protocols”, IEEE Symposium on Security and Privacy, 2013.
• [RC4biases] N.J. AlFardan, D.J. Bernstein, K.G. Paterson, B. Poettering, J.C.N. Schuldt: “On the Security of RC4 in TLS and WPA”, USENIX Security Symposium, 2013.
• [RFC2246] T. Dierks ,C. Allen: “The TLS Protocol Version 1.0”, RFC2246, 1998.
• [RFC4346] T. Dierks, E. Rescorla: “The Transport Layer Security (TLS) Protocol Version 1.1”, RFC4346, 2006.
• [RFC5246] T. Dierks, E. Rescorla: “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC5246, 2008.
• [RFC6101] A. Freier, P. Karlton,P. Kocher: “The Secure Sockets Layer (SSL) Protocol Version 3.0”, RFC6101, 1996(published as Historic RFC in 2011).
• [tlscbc] B. Möller: “Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures”, http://www.openssl.org/~bodo/tlscbc.txt, 2004.

TLS_FALLBACK_SCSV is a TLS Signaling Cipher Suite Value (SCSV) that can be used to guard against protocol downgrade attacks. The extension can be useful for clients like web browsers, which fall back to a lesser protocol version if attempts to use a higher protocol version fail.

In the attack, the adversary would force a negotiation failure of a higher protocol like TLS 1.2 or 1.1 in hopes the client will retry with TLS 1.0 or SSLv3. Then, the adversary will use defects in the down level protocols to carry out other attacks. Table 1 below lists some of the losses that could occur when traversing down protocol versions.

Protocols, Downgrades and Features

^[1] See Differences Between SSLv2, SSLv3, and TLS and This POODLE Bites: Exploiting The SSL 3.0 Fallback.

The SSL_MODE_SEND_FALLBACK_SCSV extension can be used to remediate the POODLE bug by ensuring clients don’t fall back to SSLv3 if the client performs fallbacks. However, the extension does not fix the underlying padding oracle. Rather, it just avoids the defective protocol version.

SCSV means TLS_FALLBACK_SCSV shows up as a cipher suite in the ClientHello. The spurious cipher is added to the cipher suites if the SSL_MODE_SEND_FALLBACK_SCSV option is present.

Note Well: if the client does not perform fallbacks, then the TLS_FALLBACK_SCSV extension is not needed.

Reason for the Extension[edit]

Browsers and other similar software attempt to support every server created on {God|Allah|Brahman|…}’s green earth. If the browser attempts to connect to 1990s era server and the connection fails, then the browser will fallback to a lesser protocol. It falls back to a lesser protocol by initiating a new connection with the down level protocol.

Its curious why the browsers chose to compromise the security of the dominant/standard use cases for a trivial minority. The W3C clearly states two design principals: Secure By Design and Priority of Constituencies. When a browser falls back to insecure protocols when the user asks for a secure scheme, they violate both principals.

The browsers could have provided modern TLS support with 15 or 20 reasonable ciphers (or let the users choose their vanity ciphers); and then require a plug-in to achieve the existing insecure behavior. Browsers seem more than happy to require plug-ins for the most basic functionality, like opening a homepage (try to get Chrome, Firefox or Opera to open your homepage on a new tab).

Even more befuddling, the SSL_MODE_SEND_FALLBACK_SCSV is not needed now that SSLv3 is insecure due to the padding oracle (as if Loern Weith was not clear that SSLv3 was insecure in 2006). In fact, the down level software that is part of the problem likely won’t be updated to understand the TLS extension anyway.

Avoiding the Extension[edit]

As stated earlier, SSL_MODE_SEND_FALLBACK_SCSV is not needed if the client does not perform fallbacks. The easiest way to avoid use of the SSL_MODE_SEND_FALLBACK_SCSV is to always specify the protocols you are willing to accept. The detail is you always send the highest protocol version with the ClientHello.

For example, suppose you want to accept TLS 1.0 through TLS 1.2. In this case, you send a ClientHello with that information, and you don’t include SSL_MODE_SEND_FALLBACK_SCSV. Below is a portion of the code to do so (its likely similar to the code you have been using for years):

const SSL_METHOD* method = SSLv23_method();
if(method == NULL)) handleFailure();

SSL_CTX* ctx = SSL_CTX_new(method);
if(ctx == NULL) handleFailure();

const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION;
SSL_CTX_set_options(ctx, flags);

In the code above, the SSLv23_method enables all protocol version — from SSLv2 through TLS 1.2. The method is then used to create a context object. After the context object is created, weak/wounded/broken protocols and options are removed by setting SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3 and SSL_OP_NO_COMPRESSION.

The ClientHello will set a minimum protocol version of TLS 1.0 and a maximum protocol version of TLS 1.2 in the ClientHello. The TLS protocol ensures TLS 1.2 is used if available; and TLS 1.1 is used is TLS 1.2 is not available; and TLS 1.0 is used if TLS 1.2 and 1.1 are not available. During key exchange, the ClientHello is MAC’d and used (in part) to derive the premaster_secret, so tampering with protocol versions will be detected.

When TLS 1.3 is added to OpenSSL, it will include TLS 1.3. You won’t have to change your code.

Using the Extension[edit]

If you need to use the extension, then the following is an example of how to use it:

const SSL_METHOD* method = TLSv1_2_method();
if(method == NULL)) handleFailure();

SSL_CTX* ctx = SSL_CTX_new(method);
if(ctx == NULL) handleFailure();

#ifdef SSL_MODE_SEND_FALLBACK_SCSV
    SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV)
#endif

Some folks on the OpenSSL mailing list recommend using TLS_FALLBACK_SCSV and SSL_MODE_SEND_FALLBACK_SCSV whenever available. See, for example, Use of TLS_FALLBACK_SCSV on the OpenSSL mailing list.

[edit]

Below are some discussions that occurred on the OpenSSL and IETF mailing lists and around the web.

• Context options and SSL_MODE_SEND_FALLBACK_SCSV
• Use of TLS_FALLBACK_SCSV
• Please document the new SSL_MODE_SEND_FALLBACK_SCSV
• Working Group Last Call for draft-ietf​-tls-downg​rade-scsv-​00
• The TLS_FALLBA​CK_SCSV time bomb
• SSL is dead, long live TLS

Stay tuned for
more insights