Comments 25
Может, дело в том, что они так решили позаботиться о производительности на мобильных-то устройствах?
А до версии 2.3 они об этом значит не заботились?
В любом случае, пост не об этом, а о самом протоколе SSL и одной из его множества уязвимостей.
В любом случае, пост не об этом, а о самом протоколе SSL и одной из его множества уязвимостей.
Или PRISM решил позаботиться о производительности своих вычислительных центров и приложил лапу.
Это первый комент на HN кстати!
There's interesting technical content here, but it suffers from its alarmist tone.
The MD5 hash function is broken, that is true. However, TLS doesn't use MD5 in its raw form; it uses variants of HMAC-MD5, which applies the hash function twice, with two different padding constants with high Hamming distances (put differently, it tries to synthesize two distinct hash functions, MD5-IPAD and MD5-OPAD, and apply them both). Nobody would recommend HMAC-MD5 for use in a new system, but it has not been broken.
RC4 is horribly broken, and is horribly broken in ways that are meaningful to TLS. But the magnitude of RC4's brokenness wasn't appreciated until last year, and up until then, RC4 was a common recommendation for resolving both the SSL3/TLS1.0 BEAST attack and the TLS «Lucky 13» M-t-E attack. That's because RC4 is the only widely-supported stream cipher in TLS. Moreover, RC4 was considered the most computationally efficient way to get TLS deployed, which 5-6 years ago might have been make-or-break for some TLS deployments.
You should worry about RC4 in TLS — but not that much: the attack is noisy and extremely time consuming. You should not be alarmed by MD5 in TLS, although getting rid of it is one of many good reasons to drive adoption of TLS 1.2.
И ответ:
There is another technical angle; RC4 is usually quite a lot less CPU intensive than the alternatives available. Not using RC4 can easily mean stuttering video playback, greatly diminished battery life, and even lock ups. Very few users are open to accepting that issues like that are «better» for them.
Many RC4 deprecation efforts have faced rollback in the face of issues like this; especially on hard to fix embedded devices (think TVs, Cars and phones) with comparatively weak CPUs.
There's interesting technical content here, but it suffers from its alarmist tone.
The MD5 hash function is broken, that is true. However, TLS doesn't use MD5 in its raw form; it uses variants of HMAC-MD5, which applies the hash function twice, with two different padding constants with high Hamming distances (put differently, it tries to synthesize two distinct hash functions, MD5-IPAD and MD5-OPAD, and apply them both). Nobody would recommend HMAC-MD5 for use in a new system, but it has not been broken.
RC4 is horribly broken, and is horribly broken in ways that are meaningful to TLS. But the magnitude of RC4's brokenness wasn't appreciated until last year, and up until then, RC4 was a common recommendation for resolving both the SSL3/TLS1.0 BEAST attack and the TLS «Lucky 13» M-t-E attack. That's because RC4 is the only widely-supported stream cipher in TLS. Moreover, RC4 was considered the most computationally efficient way to get TLS deployed, which 5-6 years ago might have been make-or-break for some TLS deployments.
You should worry about RC4 in TLS — but not that much: the attack is noisy and extremely time consuming. You should not be alarmed by MD5 in TLS, although getting rid of it is one of many good reasons to drive adoption of TLS 1.2.
И ответ:
There is another technical angle; RC4 is usually quite a lot less CPU intensive than the alternatives available. Not using RC4 can easily mean stuttering video playback, greatly diminished battery life, and even lock ups. Very few users are open to accepting that issues like that are «better» for them.
Many RC4 deprecation efforts have faced rollback in the face of issues like this; especially on hard to fix embedded devices (think TVs, Cars and phones) with comparatively weak CPUs.
Речь не о производительности, а о совместимости, о чём, о боги, собственно и повествует статья по ссылке.
Что как бы и отвечает на вопрос: почему при всем при этом мы до сих пор пользуемся протоколом 14 летней давности — потому, что софт обновляется небыстро!
Более осмысленный список cipher'ов появился в Java7 совсем «недавно» (всего-то пару лет назад), так что Android его её не подхватил. Я думаю ещё несколько лет пройдёт и список обновится (ну там ещё пара лет уйдёт на то, чтобы все телефоны перешли на эту новую версию), так что без паники.
Что как бы и отвечает на вопрос: почему при всем при этом мы до сих пор пользуемся протоколом 14 летней давности — потому, что софт обновляется небыстро!
Более осмысленный список cipher'ов появился в Java7 совсем «недавно» (всего-то пару лет назад), так что Android его её не подхватил. Я думаю ещё несколько лет пройдёт и список обновится (ну там ещё пара лет уйдёт на то, чтобы все телефоны перешли на эту новую версию), так что без паники.
По ссылке и по ссылке по ссылке:
1) Проблема касается не «самых новых андроидов», а практически всех андроидов, т.к. в статье идёт речь про android > 2.3, то есть, читай, всех современных.
2) Багофича была добавлена во имя совместимости с оракловской реализацией в яве.
1) Проблема касается не «самых новых андроидов», а практически всех андроидов, т.к. в статье идёт речь про android > 2.3, то есть, читай, всех современных.
2) Багофича была добавлена во имя совместимости с оракловской реализацией в яве.
Про «новые» погорячился я конечно.
Про смысл фичи тут много вариантов. Вот vittore а своем комментарии приводит достаточно правдоподобное объяснение.
Про смысл фичи тут много вариантов. Вот vittore а своем комментарии приводит достаточно правдоподобное объяснение.
Вообще-то как указывает статья, которую вы, вроде как, обсуждаете, сами разработчики Android'а пишут ясно и недвусмысленно:
Так что рассказы про какой-то «особенно ослабленный SSL в Android'е» выглядят дико на фоне того, что ровно этот список использовался (и используется!) тучей серверного софта (далеко не все ещё перешли на Java7 на серверах, поверьте).
— We now have a well defined list of the supported cipher suites which are sorted in priority order as specified in JSSE documentation so that callers doing: s.setEnabledCipherSuites(s.getSupportedCipherSuites()) will get something reasonable.
— We now have a default cipher suite list that is chose to match RI behavior and priority, not based on OpenSSLs default and priorities.
Так что рассказы про какой-то «особенно ослабленный SSL в Android'е» выглядят дико на фоне того, что ровно этот список использовался (и используется!) тучей серверного софта (далеко не все ещё перешли на Java7 на серверах, поверьте).
Слово «новых» наверно нужно либо убрать либо взять в кавычки, ибо если я правильно понял то коммиту уже три года :)
Что показательно, не смотря на open source, это вскрылось так же как вскрылось бы и в закрытом софте — через анализ трафика, что на мой взгляд достаточно забавно
Что показательно, не смотря на open source, это вскрылось так же как вскрылось бы и в закрытом софте — через анализ трафика, что на мой взгляд достаточно забавно
Серверный список шифров имеет приоритет над клиентскими, разве нет? По крайней мере в каждом первом гайде по настройке ssl советуется выставлять prefer server ciphers.
У меня debug логи ssl в nginx включены, поискал android клиентов, видны строки типа «ECDHE-RSA-AES256-SHA returns» и значение хэш функций, явно длиннее MD5 (что именно точно значит написанное в логах — не берусь утверждать).
MD5, RC4 вообще нет. AES, SHA — есть. Так же все запросы TLS 1.2 или 1.1, в статье же идёт речь про 1.0,
Есть так же коммент к статье «RC4 is the recommended cipher for TLS 1.0»
MD5, RC4 вообще нет. AES, SHA — есть. Так же все запросы TLS 1.2 или 1.1, в статье же идёт речь про 1.0,
Есть так же коммент к статье «RC4 is the recommended cipher for TLS 1.0»
Не совсем.
Клиент присылает список (более предпочтительные идут первыми), сервер выбирает. Я навскидку не нашел в стандарте рекомендаций для сервера, как, собственно, выбирать.
Клиент присылает список (более предпочтительные идут первыми), сервер выбирает. Я навскидку не нашел в стандарте рекомендаций для сервера, как, собственно, выбирать.
Возможно эта статья поможет community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
Примеры конфигов
Думаю TLSv1 TLSv1.1 тоже надо выключать.
Примеры конфигов
Apache
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite «EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS»
Nginx
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers «EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS»;
Думаю TLSv1 TLSv1.1 тоже надо выключать.
Думаю TLSv1 TLSv1.1 тоже надо выключать.
Угу, и заблокировать большинство браузеров:
en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers
TLS 1.0/1.1 уязвим к BEAST, а использование RC4 рекомендовалось как решение.
Не совсем верное утверждение, что «Новый стандарт SHA-3 неотличим от случайного оракула». это Sponge схема неотличима при идеальной F, а вот про саму F у них никто такого не доказал )
А что там на цианогене? И можно ли закрыть багофичу патчем?
Sign up to leave a comment.
Ослабленный SSL в android устройствах?