В библиотеке GnuTLS, которая применяется по умолчанию во многих пакетах из состава Debian, включая пакетный менеджер APT и многие утилиты, выявлена уязвимость (CVE-2020-13777), позволяющая возобновить ранее остановленный сеанс TLS без знания сессионного ключа. С практической стороны уязвимость может применяться для осуществления MITM-атак...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53120
Минуттачку, мы с вами ещё не закончили! ;)
...Будьте добры, помедленнее! Я записываю...
"может применяться"
Только опять таки надо знать атакующего
> TLS-сервер не осуществлял привязку сессионного ключа шифрования со значением, переданным приложениемШикарно...
> GnuTLS, которая применяется по умолчанию во многих пакетах ..., включая пакетный менеджерВсе загрузочные ISO образы, стайджи и пакеты программ должны обязательно проверяться OpenPGP. Не зависимо от того, что скачали их по https.
>> GnuTLS, которая применяется по умолчанию во многих пакетах ..., включая пакетный менеджер
> Все загрузочные ISO образы, стайджи и пакеты программ должны обязательно проверяться OpenPGP.
> Не зависимо от того, что скачали их по https.Зря стараетесь.
Когда пытаешься донести до местных Свидетелей HTTPS-ца, что шифрование канала никак не заменяет подписей, шифрования самих данных или использования нормальных алгоритмов аутентификации (особенно учитывая весьма идиотскую привычку "вебдевов" пересылать логины и пароли плейнтекстом "ну а чо, это же в https, а значит сикурно!", где они в обычно в таком виде и хранятся) -- начинается кидание <этим самым, коричневым>, истерика и причитания про луддитов ;)
Самое удивительное, что в это кто-то верил. Мозилла с этими радужными значками так особенно отличилась, вся такая безопасная, угу. А хром вообще сканирует систему. Всё для пущей безопасности, ага.А как ещё пересылать, если не плейнтекстом? Передаётся плейн (желательно не через GET, но GET это очень удобно пользователю) и сравнивается с хэшем. Md5 в лучшем случае, хаха. Но с плейн текст паролями должно быть проще вернуть аккаунт законному владельцу в случае чего.
https://wiki.debian.org/SecureAptНо вы продолжайте, продолжайте, за вашим сеансом взаимной мастурбации интересно наблюдать.
> https://wiki.debian.org/SecureApt
> Но вы продолжайте, продолжайте, за вашим сеансом взаимной мастурбации интересно наблюдать.Не понял, при чём тут дебилиан, извините. Но я застал время, когда пакеты в арче и генте никак не верифицировались.
> А как ещё пересылать, если не плейнтекстом?А зачем? См. хотя бы ту же авторизацию в WPA-PSK (никто не гоняет пароль). Ну или PAKE/SRP (Secure Remote Password).
>> А как ещё пересылать, если не плейнтекстом?
> А зачем? См. хотя бы ту же авторизацию в WPA-PSK (никто не
> гоняет пароль). Ну или PAKE/SRP (Secure Remote Password).А это где-то используется в интернете? На каких сайтах?
>>> А как ещё пересылать, если не плейнтекстом?
>> А зачем? См. хотя бы ту же авторизацию в WPA-PSK (никто не
>> гоняет пароль). Ну или PAKE/SRP (Secure Remote Password).
> А это где-то используется в интернете? На каких сайтах?А нигде (хотя конечно может где-то и есть, благо либ с реализацией куча https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...) -- ведь "испокон веков" принято гонять пароли в плейнтексте. Зачем что-то менять, "ведь есть HTTPS и поэтому оно секурно!"(с).
Поэтому в браузеры и стандарты попала вагон и маленькая тележка хлама, но никак не реализация нормальной аутетнификации.
Как минимум, при использовании AWS Amplify для AWS Cognito. Там из коробки SRP.
> идиотскую привычку "вебдевов" пересылать логины и пароли плейнтекстом "Как сделать логин-форму без скриптов и паролей плейнтекстом?
>> идиотскую привычку "вебдевов" пересылать логины и пароли плейнтекстом "
> Как сделать логин-форму без скриптов и паролей плейнтекстом?
> без скриптовИ в вакууме. Сферическом.
В 2020м только рассказывать о восьмом чуде света -- современном, интерактивном сайте, работающем без JS 🙄Но так и быть:
https://tools.ietf.org/html/rfc2069
> January 1997
> An Extension to HTTP : Digest Access AuthenticationОно было еще в IE 5. Но проще ж было просто пересылать формочку (в то время даже без обертки https) и не заморачиваться 🙄
Ну и зачастую логин c (любым) паролем -- на самом деле не нужен:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256Это _мое_ сообщение!
Отправленно плейнтекстом.
-----BEGIN PGP SIGNATURE-----iHUEARYIAB0WIQSqzOsxglhneE9AoANPeamwXnt+nQUCXuIAPwAKCRBPeamwXnt+
nYEdAQC1A9l0HEIXvx9y3x6t6mtpshg/e7aGa4tEIZ/bdzdxRwD+JrNojtRlHM/7
H2DBCNQPhtVtZ6vgEo07MarPvVbHoQk=
=89pk
-----END PGP SIGNATURE-----
> И в вакууме. Сферическом.В 2020м только рассказывать о восьмом чуде света -- современном, интерактивном сайте, работающем без JS 🙄
Опеннет удивительный сайт. Здесь собираются анти-https и любители модных уеб-технологий (bloatware) в одном лице.
> January 1997
> An Extension to HTTP : Digest Access Authentication
> ObsoleteНу такое.
> Ну и зачастую логин c (любым) паролем -- на самом деле не нужен:
-----BEGIN PGP SIGNED MESSAGE-----
Теперь для каждого сайта надо новый ключ создавать и хранить?
>> И в вакууме. Сферическом.
> В 2020м только рассказывать о восьмом чуде света -- современном, интерактивном сайте,
> работающем без JS 🙄
> Опеннет удивительный сайт. Здесь собираются анти-https и любители модных уеб-технологий (bloatware) в одном лице.А еще любители читать, хм, не совсем глазами, между строк -- и додумывать все остальное. Или аноним может процитировать мое "анти-https" высказывание?
>> January 1997
>> An Extension to HTTP : Digest Access Authentication
>> Obsolete
> Ну такое.Ну, можно сделать вид, что там нет ссылки на следующий RFC https://tools.ietf.org/html/rfc2617
1999 года (и оттуда - на версию 2014).
И что технология заглохла из-за злобного сговора веббраузероклепальщиков, а не потому что "вебдевы" предпочитали не заморачиваться - "и так сойдет!" (с)>> Ну и зачастую логин c (любым) паролем -- на самом деле не нужен:
> -----BEGIN PGP SIGNED MESSAGE-----
> Теперь для каждого сайта надо новый ключ создавать и хранить?1) не на каждый сайт, а лишь на каждый ID.
2) какая принципиальная разница-то?
> Или аноним может процитировать мое "анти-https" высказывание?Оно где-то здесь: "Свидетелей HTTPS-ца"
> И что технология заглохла из-за злобного сговора веббраузероклепальщиков, а не потому что "вебдевы" предпочитали не заморачиваться - "и так сойдет!" (с)
RFC это очень хорошо, но на практике то можно?
> 1) не на каждый сайт, а лишь на каждый ID.
2) какая принципиальная разница-то?
Очень неудобно. Софта то для этого нет.
>> Или аноним может процитировать мое "анти-https" высказывание?
> Оно где-то здесь: "Свидетелей HTTPS-ца""Кто не с нами, тот против нас!"?
И энта самое, что там с современными интерактивными сайтами без JS?
>> И что технология заглохла из-за злобного сговора веббраузероклепальщиков, а не потому что "вебдевы" предпочитали не заморачиваться - "и так сойдет!" (с)
> RFC это очень хорошо, но на практике то можно?Можно. Этот RFC поддерживался еще IE5(.x)
> И энта самое, что там с современными интерактивными сайтами без JS?Это какие?
> Можно. Этот RFC поддерживался еще IE5(.x)
Ну ладно.
>> И энта самое, что там с современными интерактивными сайтами без JS?
> Это какие?Это вам лучше знать, раз уж задавали такие странные вопросы:
>>>> Как сделать логин-форму без скриптов и паролей плейнтекстом?Я, несмотря на вкушание какту^W^W NoJS по умолчанию в основном браузере -- ничем не могу вам помочь.
> Уязвимость в GnuTLS, позволяющая возобновить сеанс TLS 1.3Хорошо, что у Микрософт и Эппл библиотеки TLS 1.3 без дыр!
У нас вообще все библиотеки без дыр.
(Но код мы вам не покажем, вы должны верить нам, потому что у нас серьезные корпорации).
Всё без дыр. В них нет нужды. У нас нормальные инженерные входы.
Если честно, поверить вам проще чем анонимным волосатым мамкиным хацкерам.
Всё так.
Не «дыры», а «технологические отверстия» :)
Речь идёт про "безопасный Линукс", а не Винду и Мак. Не отвлекайся.
>Уязвимость устранена в выпуске 3.6.14
>В дистрибутивах уязвимость устранена в Debian, SUSE, FreeBSD, Fedora, Ubuntu, EPEL, RHEL 8Слоупоки.
pacman -Qi gnutls | grep -e Version -e 'Install Date'
Version : 3.6.14-1
Install Date : Fri 05 Jun 2020 01:18:03 PM MSK
В генту ещё 4 обновили, но glsa только сегодня выпустили https://security.gentoo.org/glsa/202006-01
интересно все же, как вявили этот уязвимость?o_0 почему именно сейчас, а не тогда когда создавали-тестировали ОС!!!
если б вы хоть краешком были знакомы с концепцией и методологией практического тестирования вопрос отпал бы сам собой.