Пожалуйста, помогите сравнить безопасность последних версий SSH и TLS

TLS растёт из веба и это сразу подрывает его репутацию + все библиотеки для работы с ним почему-то систематически похожи на помойку. История богата багами и уязвимостями как его быдлокодерских реализаций, так и, что ещё хуже, самого протокола. На текущий момент наверно известных уязвимостей нет, но обязательно ещё найдутся и не раз. К mitm, в традиционном исполнении (с кучей доверенных центров сертификации), крайне уязвим по причине коррумпированности и дырявости этих самых центров, но это уже организационная а не техническая проблема.

OpenSSH (ты наверно его имел ввиду когда v9.0 писал) хорошая штука, его разрабатывают в рамках уважаемой системы OpenBSD. Уязвимости не помню, но если и были то очень мало (речь именно про OpenSSH, потому что у протокола SSH2 есть и другие реализации, например libssh - та плохая и одно время позволяла залогиниться не вводя пароля).

TLS растёт из веба и это сразу подрывает его репутацию

Почему веб - это плохо?

Ведь TLS используется и в других софтинах типа stunnel?

+ все библиотеки для работы с ним почему-то систематически похожи на помойку.

Даже LibreSSL?

https://en.wikipedia.org/wiki/LibreSSL

История богата багами и уязвимостями как его быдлокодерских реализаций, так и, что ещё хуже, самого протокола. На текущий момент наверно известных уязвимостей нет, но обязательно ещё найдутся и не раз.

https://en.wikipedia.org/wiki/Transport_Layer_Security

Вроде бы сейчас все чики-пуки?

К mitm, в традиционном исполнении (с кучей доверенных центров сертификации), крайне уязвим по причине коррумпированности и дырявости этих самых центров, но это уже организационная а не техническая проблема.

Читал, что норм пацаны для приватных браузерных решений вычищают нафик все доверенные CA из списка браузера.

Но меня интересуют другие приложения типа stunnel и т.п.

OpenSSH (ты наверно его имел ввиду когда v9.0 писал)

Да.

https://www.openssh.com/txt/release-9.0

хорошая штука, его разрабатывают в рамках уважаемой системы OpenBSD. Уязвимости не помню, но если и были то очень мало (речь именно про OpenSSH, потому что у протокола SSH2 есть и другие реализации, например libssh - та плохая и одно время позволяла залогиниться не вводя пароля).

А dropbear для initrd?

Почему веб - это плохо?

Там принято накрывать гору костылей вперемежку с просто мусором красивой обёрткой и делать вид что всё хорошо. Это касается как серверной стороны (всякие сайты на php/python/go итд), так и клиентской (все популярные браузеры).

Ведь TLS используется и в других софтинах типа stunnel?

А зря. Лично я его нигде не использую кроме веба, где других вариантов нет.

Даже LibreSSL?

Это форк OpenSSL, они конечно старались навести там порядок, но историю сложно выкинуть. Возможно он лучше остальных, но с другой стороны он не особо популярный.

Вроде бы сейчас все чики-пуки?

Я ж писал: прямо сейчас известных уязвимостей нет. Но у них такая культура разработки что ничего хорошего от них ждать не стоит.

А dropbear для initrd?

Не знаю, не сталкивался.

А зря. Лично я его нигде не использую кроме веба, где других вариантов нет.

А чем заменить stunnel кроме OpenSSH ?

Я ж писал: прямо сейчас известных уязвимостей нет. Но у них такая культура разработки что ничего хорошего от них ждать не стоит.

Какие есть еще варианты без TLS для удобного шифрования трафика любых приложений кроме VPN типа Wireguard, IPSec, SoftEther, etc. ?

Хотелось хотя бы аутентификацию с обоих сторон линии по аппаратным криптоключам. Такое есть в OpenSSH и в TLS, а где еще ?

А чем заменить stunnel кроме OpenSSH ?

Почему «кроме»? OpenSSH всем хорош, просто используй его. Ключи -R, -L.

Какие есть еще варианты без TLS для удобного шифрования трафика любых приложений

И это он тоже умеет, ключ -w создаёт виртуальный зашифрованный интерфейс, почти то же самое что vpn.

эскобар.жпг

noise!

Это форк OpenSSL, они конечно старались навести там порядок, но историю сложно выкинуть. Возможно он лучше остальных, но с другой стороны он не особо популярный.

Был не особо, а теперь и вовсе: более года назад прокатилась волна отказа от LibreSSL: Gentoo прекращает поддержку LibreSSL в пользу OpenSSL и LibreTLS (06.01.2021), https://bugs.python.org/issue43669, https://peps.python.org/pep-0644/#libressl,…

Хотя LibreSSL не так удалась, как планировалось, зато благодаря ней у нас теперь есть LibreTLS - упрощённый интерфейс к OpenSSL.

Почему «кроме»? OpenSSH всем хорош, просто используй его. Ключи -R, -L.

Всетаки хотелось бы знать достойные аналоги.

И это он тоже умеет, ключ -w создаёт виртуальный зашифрованный интерфейс, почти то же самое что vpn.

VPN через TCP - это IMHO только когда больше ничего другое не работает, либо очень нужна безопасность на уровне OpenSSH.

С 2019 пошёл массовый дроп либры, openssl подправился где-то с версий 1.02

Всетаки хотелось бы знать достойные аналоги.

Их нет. Да и не нужны.

Там принято накрывать гору костылей вперемежку с просто мусором красивой обёрткой и делать вид что всё хорошо. Это касается как серверной стороны (всякие сайты на php/python/go итд), так и клиентской (все популярные браузеры).

Мсье прямо образчик конструктива. Может быть посоветуете, на чем именно должны быть «сайты»? А то вот перечисле стандартный набор языков для бэкеда, а что-то смысл комментария не понятен…

Кстати, это что такое вообще, «сайты»?

Ну и до кучи, какими браузерами надо, по мнению мсье, пользоваться?

P.S. Извините за наброс, но такого рода комментарии - это прямо в духе старого доброго лора: «ты дурак - сам дурак» :) :) :)

Кроме веба существует большое количество различных так называемых SSL-VPN, использующих TLS для шифрования (например OpenConnect) или хотя бы аутентификации (например OpenVPN):

https://en.wikipedia.org/wiki/OpenConnect#DTLS

http://www.infradead.org/openconnect/features.html

Мне TLS 1.3 был интересен как раз в области его применения в VPN, а не классическом веб браузере с сотней заранее прописанных CA.

Так я ж написал - дело не в конкретных проявлениях, современный массовый веб весь такой, за редкими исключениями. В частности, хороших браузеров не существует. Да, тут нет конструктива, я не собирался рассказывать как сделать хороший веб, тема вообще не про него.

В частности, хороших браузеров не существует.

А чем плох Firefox?

И это он тоже умеет, ключ -w

Очень хорошо для tcp и ужасно для udp, всякая телефония и видео будет работать нестабильно, плюсом достаточно серьезная нагрузка на ЦП. У того же openvpn нагрузка сильно меньше и нет проблем с udp.

В свете их последней выходки - отличная шутка

Что именно такого ужасного они сотворили?

Разве https://librewolf.net это не пофиксит?

openvpn нагрузка сильно меньше

У WireGuard ведь еще меньше ? но в нем нет TLS.

Как такое можно было пропустить. На счет форков не известно, надеюсь они на подобное не способны.

Это что.

У меня через пару часов после установки Skype в виртуалке Brave забыл все свои сохраненные пароли, хотя до этого пару лет работал исправно. Но конечно есть ZFS снэпшот до запуска Skype :)

Ну после покупки их майкрософтом можно было ожидать чего угодно.

Я про то, что openssh великолепный инструмент, но в качестве vpn слишком неудобный.

Я про то, что openssh великолепный инструмент, но в качестве vpn слишком неудобный.

Не столько неудобный (в настройке как раз удобный?), сколько тормозной в использовании?

Яннп, ты счас на полном серьезе сравниваешь алгоритм и протокол? Сравни https и tlsv3. Хуже того, куча школоты поддерживает обсуждение идиотизма? Ау, сознание-то включи.

Яннп,

Очень заметно, вероятно еще на стадии своего (твоего) обучения.

ты счас на полном серьезе сравниваешь алгоритм и протокол?

Позвольте узнать, что из TLS и SSH является алгоритмом, а не протоколом?

Сравни https и tlsv3.

HTTPS (как и SMTPS, IMAPS) можно построить на базе TLS v1.3 (а НЕ V3), даже через внешнюю утилиту типа stunnel.

Хуже того, куча школоты поддерживает обсуждение идиотизма?

Школоты типа тебя?

Ау, сознание-то включи.

Не выключалось вообще-то ... :)

Ты сам в своем посте себя опроверг, как так? О_о

stunnel - это тоже протокол как и https и ssh. tls - алгоритм шифрования.

1)

Ты сам в своем посте себя опроверг, как так? О_о

В чем это проявляется?

2)

stunnel - это тоже протокол как и https и ssh.

https://www.stunnel.org/

Читаем вниматИльнА на сайте разработчика:

Stunnel is a free software authored by Michał Trojnara.

Т.е. это, как я и говорил, утилита (программа, software).

3)

tls - алгоритм шифрования.

https://en.wikipedia.org/wiki/Transport_Layer_Security

Transport Layer Security (TLS), the successor of the now-deprecated Secure Sockets Layer (SSL), is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

Таки TLS - протокол шифрования, а не алгоритм.

Алгоритмы, используемые протоколом TLS:

https://en.wikipedia.org/wiki/Transport_Layer_Security#Algorithms

4) Дружище, ты перед кем тут выпендриваешься своим невежеством, неграмотностью и некомпетентностью?

Или просто троллируешь меня и тестируешь мою стрессоустойчивость и альтруизм?

16-19 ? угадал?

stunnel - утилита, использующая stunnel протокол с применением алгоритма шифрования tls (и не только:-)

ssh - утилита, исполтзующая ssh протокол с применением алгоритма шифрования tls (и не только:-)

https - алгоритм, использующий протокол http с применением алгоритма шифрования tls (и не только:-)

удачи в освоении, чо

ssh - утилита, исполтзующая ssh протокол с применением алгоритма шифрования tls (и не только:-)

https://crypto.stackexchange.com/questions/60255/why-doesnt-ssh-use-tls

Фто ище придумает детский садик Anoxemian?

Anoxemian - это бот, который использует алгоритм Anoxemian для закакивания форумов всякими глупостями?

Не столько неудобный

Ну, работает с -w только от рута. Необходим перезапуск если соединение повисло. В итоге все обрастает некрасивым скриптом на баше. А вот тормозов нет, ну подумаешь сервер загружен на 60% только из-за ssh.

Ну, работает с -w только от рута.

Можно в виртуалке, например KVM.

А вот тормозов нет, ну подумаешь сервер загружен на 60% только из-за ssh.

VPN по TCP - это в любом случае тормоза по сравнению с UDP (например WireGuard) или IP протоколами (например IPSec).

VPN по TCP - это в любом случае тормоза по сравнению с UDP

Не силён я в сетевых вещах, а узнать почему так интересно - не подскажете ?

https://www.quora.com/Is-using-a-VPN-over-UDP-faster-than-TCP

Потому что udp чуть быстрее при передачи данных даже без шифрации, но требует белых адресов.

У WireGuard ведь еще меньше ? но в нем нет TLS.

sanyo1234 Ммусье вы сделали мой вечер !! надо бы еще раз перечитать тему

Потому что udp чуть быстрее при передачи данных даже без шифрации, но требует белых адресов.

UDP сам по себе не требует белых адресов более чем, например, TCP. Проблема может быть только в незнакомых для некоторых реализаций NAT протоколах, которые, хотят создавать дополнительные соединения на других и особенно на рандомных портах, как например, протокол FTP:

https://www.jscape.com/blog/active-v-s-passive-ftp-simplified

Лично у меня никогда не было никаких проблем при натировании UDP соединений между постоянными одиночными UDP портами на роутерах на базе обычного Linux, настроенного с помощью скриптов Firehol:

https://firehol.org/firehol-manual.html

Вообще он прав в том смысле, что в стартовом посте речь о сравнении openssh v9.0, т.е. конкретной реализации конкретного алгоритма с TLS v1.3 т.е. протокола. Это уж в данном комменте ты вильнул филейной частью подменив openssh v9.0 на просто абстрактный ssh

подменив openssh v9.0 на просто абстрактный ssh

Пожалуйста, объясни, почему OpenSSH какой-либо версии - это только алгоритм, а не комплекс программ, алгоритмов, протоколов и документации?

Это уж в данном комменте ты вильнул филейной частью

А я думал, это ты вильнул.

Смотрим сообщение Anoxemian:

Пожалуйста, помогите сравнить безопасность последних версий SSH и TLS (комментарий)

И видим, что он называет в нем TLS алгоритмом:

tls - алгоритм шифрования

И ты тут же пишешь, что TLS - таки протокол:

TLS v1.3 т.е. протокола

и про какое-то виляние, вероятно у тебя с Anoxemian богатый опыт в этой сфере, но нет, опять мимо, попробуйте что-нибудь еще, например такое:

http://www.bolshoyvopros.ru/questions/292352-kak-nauchitsja-perestat-viljat-p...

Кстати, а с каких это пор «конкретная реализация конкретного алгоритма» стала протоколом? Решил вступить в клуб нубов Anoxemian? У вас там что, конкурс на лучшего клоуна - ганстолкера?

http://www.freezepage.com/1651067971MRNFQYEGLI

А по поводу OpenSSH 9.0 можешь при желании читать, как протокол SSH v2, используемый в OpenSSH v9, сравнивается с протоколом TLS v1.3 с точки зрения безопасности, если тебе от этого полегчает.

А у меня нет задачи доказывать, что Anoxemian прав во всем. Я показал в чем неправ ты

А у меня нет задачи доказывать, что Anoxemian прав во всем.

Так он по сути почти во всем неправ в этой ветке :)

Я показал в чем неправ ты

И в чем же, принимая во внимание заговолок темы:

Пожалуйста, помогите сравнить безопасность последних версий SSH и TLS

Оба блеснули своим менталитетом придраться хоть к чему-нибудь, пофик что совсем мимо, и при этом ничем не помочь. Впрочем что еще можно было ожидать от таких забияк как вы?

Такая формулировка так же не однозначна. Непонятно предлагается ли сравнивать чисто протоколы или конкретную реализацию протокола, в которой могут быть свои ошибки, с протоколом. Протоколы можно сравнивать с протоколами, а реализации с реализациями. Протокол с реализацией сравнивать некорректно

Такая формулировка так же не однозначна.

Так наверно несложно догадаться, что предлагается сравнивать протокол с протоколом и реализации с реализациями.

Почему у вас проявляется какое-то маникальное стремление приписать мне желание сравнивать яблоки с апельсинами?

Еще бы чеснок с долькой апельсина предложил сравнить, LOL :)))

1. И в SSH, и в TLS у сервера есть ключевая пара. Она используется клиентом для аутентификации сервера. В расширениях OpenSSH есть механизм, позволяющий ротировать ключи - пока клиент доверяет старому ключу, сервер может сообщить ему о новом, а потом перестать использовать старый.

2. Обычно TLS используют с (системным) хранилищем CA, против которых проверяются ключи сторон. В SSH обычно используется TOFU - клиент при первом подключении показывает отпечаток ключа сервера и интерактивно запрашивает у пользователя подтверждение на добавления его в known_hosts. Для TLS такое тоже возможно - www.tofuproxy.stargrave.org

3. TLS использует сертификаты. Их можно связывать в цепочки, делегируя выпуск сертификатов промежуточным CA и устанавливать ограничения (например по цели использования, сроку действия или возможным именам субъектов) для них. В SSH тоже есть сертификаты, но нет возможности сделать автономный промежуточный CA - для реализации TLS-подобных схем придётся out-of-band ходить с запросом подписи, что на практике ограничивает применение сертификатов одной организацией. И TLS, и SSH позволяют использовать сертификаты как на клиенте, так и на сервере.

4. Серверная реализация TLS может менять свою конфигурацию (например, предоставлять различные сертификаты) в зависимости от того, какое имя сервера указано на клиенте - SNI. Это позволяет переиспользовать одну пару IP:port для различных целей. В SSH такого механизма нет.

Устойчивость к MitM зависит от надёжности CA, достоверности и заполненности баз отпечатков. Аппаратные ключи тут не сильно помогут, важнее наличие хорошей процедуры развёртывания.

Устойчивость к MitM зависит от надёжности CA, достоверности и заполненности баз отпечатков. Аппаратные ключи тут не сильно помогут, важнее наличие хорошей процедуры развёртывания.

Что толку от отпечатков ключей, закрытые части которых утекли без аппаратного крипто к атакующей стороне, т.е. по сути перестали быть закрытыми?

Под MitM обычно понимают атаки на сеть, когда атакующий влияет на маршрутизацию таким образом, чтобы гонять трафик через себя.

Если отпечатков ключей нет на стороне клиента, то злоумышленник может заставить доверенный CA выпустить новый сертификат. А в случае полного отсутствия PKI - просто сгенерировать новую ключевую пару.

Если атакующий смог считать приватные ключи с файловой системы, то обычно это означает, что он получил root. В таком случае ему и аппаратный ключ не будет помехой - к нему у него тоже будет доступ, и он просто будет его использовать так же, как это бы делал ssh-сервер.

Предлагаю для начала договориться, какую модель угроз мы рассматриваем. Какие возможности есть у злоумышленника, и что нужно защитить?

Если отпечатков ключей нет на стороне клиента,

Важно не просто наличие отпечатка на клиенте, но и:

1) Нескомпрометированность закрытого ключа (в т.ч. сервера). Иначе неизвестно чей отпечаток вы проверяете, аутентичного хоста или таки как раз MITM хоста.

2) Биндинг отпечатка к хосту, а не просто чтобы отпечаток был в наличии.

то злоумышленник может заставить доверенный CA выпустить новый сертификат.

Предположим, нет такого CA, или вообще нет никакого CA.

А в случае полного отсутствия PKI - просто сгенерировать новую ключевую пару.

Очень любопытно, и как же закрытый ключ клиента подойдет к открытой части пользовательского authorized_keys на левом хосте? Это фантастика? Или как пройдет проверка забинденного на клиенте (к старому ключу оригинального сервера) отпечатка открытого вновь сгенерированного серверного ключа MITM хоста?

Вообще по этому вопросу я не уверен, нужно еще почитать про SSH MITM.

Если атакующий смог считать приватные ключи с файловой системы, то обычно это означает, что он получил root. В таком случае ему и аппаратный ключ не будет помехой - к нему у него тоже будет доступ, и он просто будет его использовать так же, как это бы делал ssh-сервер.

Да фто ви говогите? Это такой новомодний троллинг? А как же многофакторность аппаратных неизвлекаемых ключей?

Предлагаю для начала договориться, какую модель угроз мы рассматриваем. Какие возможности есть у злоумышленника, и что нужно защитить?

Боюсь, что мы с вами замучаемся перечислять эти вектора в 2022 году. Проще пытаться защищаться от всего, так называемый «Zero Trust» ;)

Очень любопытно, и как же закрытый ключ клиента подойдет к открытой части пользовательского authorized_keys на левом хосте?

Зависит от настроек клиента. Если включен ForwardAgent, а ключи в агента загружены без -c, то злоумышленник может пускать всех (без паролей и ключей), а дальше использовать ключ из агента для похода на целевой сервер. Но это не самый типичный сценарий настройки клиента, хотя и встречается на админских рабочих станциях.

Более типичный и банальный сценарий - пользователь авторизуется паролем, тогда MITM выполнить совсем легко.

Хотя тут можно и без полноценного MITM сделать что-нибудь плохое - создать иллюзию входа на целевой сервер и ждать, пока клиент попытается передать туда какой-нибудь секрет. Например, запустит mysql -p, введёт пароль, а потом злоумышленник просто сэмулирует сетевую проблему.

А как же многофакторность аппаратных неизвлекаемых ключей?

У sshd есть все необходимые доступы для использования этих ключей, злоумышленнику необязательно извлекать их.

Сервер же не будет требовать от человека у консоли использовать фактор каждый раз, когда потребуется взаимодействие с ключом.

Более типичный и банальный сценарий - пользователь авторизуется паролем, тогда MITM выполнить совсем легко.

Ну это уж совсем детский сад, мы же с вами понимаем, что пароли в 2022 году можно использовать только там, где приемлема записка, что «ключ под ковриком», т.е. только в окружении приличных людей, где вместо дверей можно использовать зановесочку.

Хотя тут можно и без полноценного MITM сделать что-нибудь плохое - создать иллюзию входа на целевой сервер и ждать, пока клиент попытается передать туда какой-нибудь секрет. Например, запустит mysql -p, введёт пароль, а потом злоумышленник просто сэмулирует сетевую проблему.

В смысле троян на рабочей станции админа воспользуется уже открытой аутентифицированной удаленной консолью?

А как же многофакторность аппаратных неизвлекаемых ключей?

У sshd есть все необходимые доступы для использования этих ключей, злоумышленнику необязательно извлекать их.

Откуда у ssh(d) необходимые доступы, если к примеру используется ключ U2F, которому нужно нажатие пальцем в момент подтверждения транзакции аутентификации? Речь в первую очередь о SSH клиенте, хотя и на SSH сервере тоже можно использовать подобные ключи, но тогда нужна помощь удаленных сотрудников для нажатия кнопки подтверждения:

https://support.nitrokey.com/t/nitrokey-pro2-and-openssh-sshd-server-side-pri...

Сервер же не будет требовать от человека у консоли использовать фактор каждый раз, когда потребуется взаимодействие с ключом.

Как настроите :)

В смысле троян на рабочей станции админа воспользуется уже открытой аутентифицированной удаленной консолью?

Нет. Пусть, например, злоумышленник захватил контроль над маршрутизатором. Админ с пустым known_hosts делает ssh -i .ssh/id_rsa remoteserver, злоумышленник заворачивает трафик к себе, злодейский сервер пускает к себе, а потом рисует шелл, который на первый взгляд выглядит так же, как на настоящем remoteserver.

Даже если используется ключ U2F, админу с пустым known_hosts это не поможет - он не заметит разницы между реальным remoteserver и сервером злоумышленника.

Речь в первую очередь о SSH клиенте

При наличии отпечатков ключей в known_hosts или при развёрнутом SSH PKI, аппаратные ключи на клиенте становятся гораздо более полезными.