В выпущенных сегодня обновлениях библиотеки OpenSSL 1.0.1s (https://mta.openssl.org/pipermail/openssl-announce/2016-Marc... и 1.0.2g (https://mta.openssl.org/pipermail/openssl-announce/2016-Marc... устранена опасная уязвимость (https://mta.openssl.org/pipermail/openssl-announce/2016-Marc... (CVE-2016-0800), позволяющая совершить новый вид атаки на HTTPS - DROWN (https://drownattack.com/). Уязвимость не специфична для OpenSSL и затрагивает непосредственно протокол SSLv2, который в 2011 году переведён (https://tools.ietf.org/html/rfc6176) в разряд устаревших. Тем не менее проблема остаётся актуальной, применима к защищённым сеансам TLS и затрагивает приблизительно 33% всех сайтов, доступных по HTTPS, или 25% из миллиона крупнейших сайтов в Сети.Атака позволяет получить контроль над шифрованным каналом связи, если предварительно атакующим удалось получить контроль над промежуточным шлюзом или вынудить пользователя подключиться к подконтрольному атакующим серверу доступа. Вклинившись в канал связи (MITM) атакующий может притвориться HTTPS-сервером или почтовым сервером с TLS к которому обращается пользователь и получить полный контроль над трафиком, принимая запросы от клиента и транслируя их к реальному серверу, организовав скрытое прослушивание и при необходимости внося изменения в трафик. Пользователь при этом не заметит подвоха и будет уверен в успешности установки защищённого соединения.
Суть уязвимости сводится к возможности расшифровки шифротекста (https://ru.wikipedia.org/wiki/%D0%A8%D0%... RSA, без знания закрытого ключа RSA. Проблеме подвержены серверы, в которых присутствует поддержка SSLv2, а также серверы на которых применяются закрытые ключи RSA, используемые совместно с уязвимым сервером.
Проблема может применяться для организации кросс-протокольной атаки, нацеленной на расшифровку сеансов, в которых используются современные протоколы шифрования (TLSv 1.0 - 1.2), пользуясь тем, что обычно в TLS и в SSLv2 совместно используется один и тот же ключ RSA.
Атака достаточно сложна в реализации (https://drownattack.com/drown-attack-paper.pdf) и требует стечения определённых факторов. Для восстановления одного сеансового ключа атакующему необходимо выполнить примерно 2^50 вычислительных операций и инициировать тысячи соединений с целевым сервером. Подбор существенно упрощается в случае использования на сервере устаревших версий OpenSSL 1.0.2a, 1.0.1m, 1.0.0r и 0.9.8zf, для ускорения атаки на которые можно задействовать уязвимость CVE-2016-0703.GnuTLS и NSS атаке не подвержены, так как по умолчанию собираются без поддержки SSLv2. Для защиты серверов достаточно полностью отключить протокол SSLv2 или всех специфичных для SSLv2 наборов шифров, но только в версиях OpenSSL новее 1.0.1r и
1.0.2f (в более ранних выпусках отключения шифров недостаточно так как атакующий всё равно может воспользоваться ими в составе экспортного набора). В представленных сегодня релизах OpenSSL 1.0.2g и 1.0.1s поддержка SSLv2 полностью отключена на этапе сборки, а уязвимые наборы шифров удалены из поставки. GnuTLS и NSS атаке не подвержены, так как по умолчанию собираются без поддержки SSLv2. Проверить свой сервер на наличие уязвимости можно на сайте test.drownattack.com (https://test.drownattack.com/).
В новых выпусках OpenSSL 1 также устранена уязвимость (CVE-2016-0799) в реализации функций BIO_*printf, которая может привести к переполнению кучи. Уязвимость отнесена разработчиками OpenSSL к категории неопасных, но выявившие проблему исследователи не столь оптимистичны и не исключают (https://guidovranken.wordpress.com/2016/02/27/openssl-cve-20... теоретическую возможность инициирования выполнения кода атакующего при обработке в BIO_printf очень большого блока данных, полученного из не заслуживающего доверия источника (например, при выводе в BIO_printf данных, введённых пользователем). Функции BIO_*printf достаточно популярны и, например, используются в PHP и Apache httpd.URL: https://mta.openssl.org/pipermail/openssl-announce/2016-Marc...
Новость: http://www.opennet.dev/opennews/art.shtml?num=43971
https зло. рекламщики трут ручки в предвкушении, когда оно будет повсеместно
> https злоПочему это?
Потому что Тото прочитал только заголовок статьи...
А что добро? Открытое соединение где даже уязвимостей ну нужно чтобы слушать? Или ты свой протокол изобрёл?
а зачем тебе повсеместно в вэб "закрытое" соединение? на форумах секретную информацию прослушают? банкинг допустим вообще тунеллировать давно пора, единственное где секурность нужна, а повсеместное применение https только открывает дорогу рекламе
> А что добро? Открытое соединение где даже уязвимостей ну нужно чтобы слушать?
> Или ты свой протокол изобрёл?И не говорите!!!
Так многие лохи и на улицу до сих пор в XXI веке без черных очков выходят, что их и без специальных приборов узнать можно.
>https злоТоже так считал, ибо во многих случаях - напрасная трата электричества. Однако новость со вставкой билайном рекламных блоков в незащищённые страницы делает https оправданным.
Если уж тратить электричество, то уж лучше с пользой. Всё лучше, чем плэйном login:password передавать.
Ну, была же удаленная уязвимость, позволявшая незнакомцу почитать, что ты там за login:password передавал.
Так что, не всё так однозначно.
> Если уж тратить электричество, то уж лучше с пользой. Всё лучше, чем
> плэйном login:password передавать.Внезапно: пароли вообще передавать не обязательно.
Но вместо вменяемой поддержки такого стандарта, кое-кто (не будем показывать пальцем на наглую рыжую морду и цветной шарик) почему-то предпочел запихнуть в браузеры WebRTC, P2P и остальные свистелки и перделки.
>> Внезапно: пароли вообще передавать не обязательно.А что тогда передавать? Отпечатки пальцев или скан сетчатки глаз?
>>> Внезапно: пароли вообще передавать не обязательно.
> А что тогда передавать? Отпечатки пальцев или скан сетчатки глаз?Навскидку, примитивно-наивный, самопальный метод:
send(Vasyan:sha256(timestamp + sha256(password)) )
или
send(Vasyan:PBKDF2(timestamp + PBKDF2(password)) )А еще можно этим самым паролем шифровать.
send(Vasyan:encrypt("это я!" + timestamp, pbkdf2(password)))А так – много их, как устаревших, так и не очень и вместо глупой попытки съязвить, мусье мог бы и поинтересоваться и погуглить:
https://ru.wikipedia.org/wiki/Вызов-ответ_(аутентификация)
https://ru.wikipedia.org/wiki/SCRAM
https://ru.wikipedia.org/wiki/SRP
https://ru.wikipedia.org/wiki/OCRA
https://ru.wikipedia.org/wiki/CRAM-MD5
https://ru.wikipedia.org/wiki/CHAP
https://ru.wikipedia.org/wiki/Протокол_Диффи_—_Хеллмана
да ну нафиг - перейдут все на защищенное соединение - будет вставлять и в защищенные.
Просто заставит вас установить свой сертификат - а не установите, в пункте 16458.273574.c.LXXXVII оферты ясно же написано - мы вам на других условиях https предоставлять не обещали.
Поэтому нужен сетевой нейтралитет.
Только не забывай, что сегодня в http с рекламой можно бороться с помощью adblock, privoxy и тд, а вот когда тебе будут вкорячивать рекламу в https ничего уже не поделаешь
а какая разница? адлобку пофиг какую рекламу резать, терминирование-то на клиенте происходит, далее адблок работает уже с пейлоадом
адблок еще для openwrt бывает
> адблоку пофигну расскажите всем как софт для домохозяек режет рекламу в https-сессии, в таком случае. у вас есть возможность взорвать интернет
Поставь на всех концах uBlock. Обязательно на роутере рекламу резать?
TLS 1.3 на подходе, обратной совместимости и даунгрейда не будет.The best way to promote the use of secure connections, HTTPS is to improve the current protocols to be as fast and secure as possible. One of the protocols that are currently being revised is the protocol TLS, Transport Layer Security, successor of SSL protocol, in order to improve the security of this protocol at the same time that it considerably reduces the waiting time in the negotiations to reduce the maximum waiting times.
With the aim of improving the performance and security of all secure connections, so as to speed up the processes of TLS negotiation, is reviewing the protocol for the launch of a new version of the same which is intended to be the definitive reason for that all, or at least most of the website servers connected to the Internet to establish secure connections between client-server, ensuring the security and privacy of users.
The current version of TLS is 1.2, which, when complete, the corresponding revisions will be the TLSv1.3. Among the main differences between both versions are to be noted:
* It removes the support of the GMT time in favor of UTC.
* It has changed the name of the function KeyExchange to KeyShare.
* Added a new function "HelloRetryRequest" to refuse to unauthorized customers.
* It has been revised negotiation Handshake in order to provide mode 1-RTT.
* You have deleted the groups DUS custom.
* It eliminates the possibility of compression.
* It has eliminated the possibility of an exchange of RSA keys and DH static.
* Removed support for encryption systems that are not AEAD.
Of all of the above characteristics, the most important in terms of performance is the review of the negotiation 1-RTT. The new TLS 1.3 is going to streamline significantly the processes of negotiation to establish secure connections with you so that the process can work without problem on servers "little powerful", and reduce as well the waiting times and the appearance of "lag" that show some sites.
>It eliminates the possibility of compression.И зачем надо было это убирать.
>>It eliminates the possibility of compression.
> И зачем надо было это убирать.для устранения очевидной side-channel атаки
А зачем оно надо? Сжимать данные надо до этапа шифрования.
LibreSSL не подвержен. SSLv2 выкинули чуть ли не первым делом после форка. Из 8-ми уязвимостей в родительском проекте, OpenSSL, лишь две перекачевали в LibreSSL, которые нерелевантны для самой OpenBSD в виду других средств защиты применяемых в ОС. Насчёт других ОС не вкурсе, но обе уязвимости малозначительны.
Хм, это значит что с ним эти сайты вообще не откроются?
Не откроются скорее всего, если там нет параллельно поддержки более новых chipersuites.PS. В LibreSSL выпилен ГОСТ и FIPS так, что там в принципе не откроюся HTTPS сайты развернутые для гос органов причем как наших так и американских.
> В LibreSSL выпилен ГОСТ и FIPS так, что там в принципе не откроюся HTTPS сайты развернутые для гос органов причем как наших так и американских.В LibreSSL захакали новую реализацию ГОСТа:
http://undeadly.org/cgi?action=article&sid=20141209095711&mo...
$ uname -srv && openssl list-cipher-algorithms | grep -i gost
OpenBSD 5.8 GENERIC.MP#4
gost89
gost89
gost89-cnt
gost89-ecb
ЕМНИП недавно в Германии кто-то проводил аудит openssl и делал вывод, что проблем нет.
> кто-то проводил аудит openssl и делал вывод, что проблем нет.В библиотеке нет, а в протоколе есть.
Наивный мальчик, доверяет заявлениям спецслужб. Заявлениям спецслужб, Карл!
> ЕМНИП недавно в Германии кто-то проводил аудит openssl и делал вывод, что
> проблем нет.вы бредите. К тому же никакой аудит не позволяет делать таких выводов, если это профессионалы - они скажут "мы не смогли их обнаружить". Вывод "проблем нет" делается на основании доказательства правильности кода - которое практически нереально.
А тут и аудит просто невозможен разумными усилиями - именно по этой причине пришлось рожать форки. Закрасить проще, чем отмывать.Оно и в целом омерзительно написано (поскольку наколенный самодельный проект одного человека начали с дурной упертостью пихать в мэйнстрим), включая и его интерфейсы для программистов, и плюс сам набор протоколов чудовищно уродлив, то есть его при всем желании нельзя написать чисто, понятно и красиво.
Q3: Which processor versions are vulnerable?We performed our tests on an Intel Xeon E5-2430. We believe that all Sandy Bridge processors are vulnerable. Earlier microarchitectures, such as Nehalem and Core 2 may be vulnerable as well.
Our attack code does not work on Intel Haswell processors, where, apparently, cache-bank conflicts are no longer an issue.
о, как оно протухло
а этот сервак из-за кривизны рук сисадминов до сих пор не перешел на норламьные серты
Так ты не стесняйся, каждый раз когда что-то не нравится высылай деньги админам, на новые серты, на хостинг, на красивый дизайн. Контакты сам в состоянии найти?
чем бесплатные не устраивают? даже на халяву и то лень нормально настроить
> чем бесплатные не устраивают? даже на халяву и то лень нормально настроитьБесплатные вдмины-то? :-<
палемон ему не доверяет, а хромогиум — вполне, так что хз, что там протухло в цепочке из комодов и клаудфларе
>Для защиты серверов достаточно полностью отключитьих от интернета
> SSL2 ... yahoo.comСпасибо, не удивлён. Эта компостная яма воняет на весь топ100
Я бы обратил внимание на <<Атака позволяет вклиниться в шифрованный канал связи, если предварительно атакующим удалось получить контроль над промежуточным шлюзом или вынудить пользователя подключиться к подконтрольному атакующим серверу доступа>>, т.е. атака не напрямую на пользователя, а через шлюз...
> инициировать несколько десятков тысяч соединенийДушеспасителен fail2ban, всегда подозревал.
А вот и результат. Собираю git-2.7.2 в Gentoo:/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64/libcurl.so: undefined reference to `SSLv2_client_method'
Идти в багзиллу или подождать день-другой...
Полечилось пересборкой curl, вдруг кому пригодится.
Отлично, самый большой "дрруг" по-прежнему забоитится о нас. Эмблему, имя собственное, отдельный сайт, и отдельную новость на опенет!, на каждый чих ^W патч."И вот теперь, начиная с 2013-го года, у нас простые ошибки в СПО (неисправность в строке или двух) попадают в центр внимания и получают имена собственные, эмблемы и пр., при этом критические "zero-day" дефекты от самого Майкрософт-а едва ли попадают в заголовки."
http://www.opennet.dev/openforum/vsluhforumID3/105391.html#15
***Хорошо, что у нас тут не RSDN-какой, а то б каждый вторник по 150 эмблем-кликух-сайтов и отдельных новостей! Во ихние админы мучаются-то?!