Анонсирован (http://marc.info/?l=openssh-unix-dev&m=123535620330726&w=2) выход релиза OpenSSH 5.2 (http://www.openssh.com), открытой реализации клиента и сервера для работы по протоколу SSH версии 1.3, 1.5 и 2.0.
Новшества, представленные в OpenSSH 5.2:- Изменен порядок применение методов шифрования, начиная с текущей версии по умолчанию приоритетными методами являются AES CTR и переработанный "arcfour256". Приоритет выбора CBC метода понижен до минимума, так как он подвержен уязвимости (http://www.opennet.me/opennews/art.shtml?num=18947), теоретически позволяющей перехватывать и изменять SSH трафик. Кроме того, в OpenSSH 5.2 изменено поведение сервера при обнаружении аномалий в CBC шифровании, что сводит на нет возможность проведения вышеупомянутых атак.
- В ssh клиент добавлена новая опция "-y", позволяющая выводить служебную информацию через syslog, а не stderr, что полезно при запуске ssh в режиме демона (ssh -f);
- В файле конфигурации sshd директива ForceC...
URL: http://marc.info/?l=openssh-unix-dev&m=123535620330726&w=2
Новость: http://www.opennet.me/opennews/art.shtml?num=20420
>Изменен порядок применение методов шифрования, начиная с текущей версии по умолчанию приоритетными методами являются AES CTR и переработанный "arcfour256". Приоритет выбора CBC метода понижен до минимума, так как он подвержен уязвимости, теоретически позволяющей перехватывать и изменять SSH трафик. Кроме того, в OpenSSH 5.2 изменено поведение сервера при обнаружении аномалий в CBC шифровании, что сводит на нет возможность проведения вышеупомянутых атак.Следует отметить, что результатом этого изменения является фактически отмена использования аппаратных ускорителей шифрования, т.к. они поддерживают в основном CBC. Впрочем, они и так редкость, во всяком случае, в России. Подробнее: http://www.nabble.com/SSH-cipher-preference-change-(was:-Re:...)-td21627217.html
ссылка в комменте выше побилась, вот более удобная, на которой OpenNet'овский движок не сбоит: http://archives.neohapsis.com/archives/openbsd/2009-02/0917....
С удовольствием почитал бы анализ, насколько эти «аппаратные ускорители шифрования» могут быть хоть сколько-то полезны в свете openssh на текущем железе (хоть в каких-то ситуациях, у меня это пока не bottleneck ни разу). Или в свете openvpn, это даже интереснее.
>С удовольствием почитал бы анализ, насколько эти «аппаратные ускорители шифрования» могут быть
>хоть сколько-то полезны в свете openssh на текущем железе (хоть в
>каких-то ситуациях, у меня это пока не bottleneck ни разу). Или
>в свете openvpn, это даже интереснее.Пример из гугля:
"Our evaluation shows that, despite its addition in the system as a device/service virtualization layer, the OCF is extremely efficient in utilizing cryptographic accelerator functionality, attaining 95% of the theoretical peak device performance. In another configuration, we were able to achieve a 3DES aggregate throughput of over 800 Mbps, by employing a multi-threaded application and load-balancing across multiple accelerators. Furthermore, use of hardware accelerators can remove contention for the CPU and thus improve overall system responsiveness and performance for unrelated tasks."
http://www.openbsd.org/papers/ocf.pdfА так — прогуляйтесь на http://www.hardware-ciphers.com/ , ознакомьтесь со спеками и посчитайте для себя. Это не x86-процессоры последних поколений, производительность просчитать несложно (главное, не забывать учитывать шину, на которой чип сидит, и накладные расходы в виде ОС).
а в реальной ситуации? вот есть у меня сервер с openvpn. я туда поставлю железку — и, что, responsiveness для клиентов увеличится?в теории список таких ситуаций крайне мал. а на практике ещё меньше.
подумайте об этом и у вас больше не будет вопросов по поводу непопулярности железных шифро-процессоров.
>а в реальной ситуации? вот есть у меня сервер с openvpn. я
>туда поставлю железку — и, что, responsiveness для клиентов увеличится?Может быть. А, может быть, и нет. Опять-таки, считать надо.
>в теории список таких ситуаций крайне мал. а на практике ещё меньше.
>
>
>подумайте об этом и у вас больше не будет вопросов по поводу
>непопулярности железных шифро-процессоров.А у меня как-то вопросов и не было, это вы спрашивали. ;)
> Может быть. А, может быть, и нет. Опять-таки, считать надо.вот я именно хоть сколько-то нормальных замеров и просил два сообщения назад. :-)
> А у меня как-то вопросов и не было, это вы спрашивали. ;)
нет, я благодарен за замечание про крипто-акселлераторы. но я как бы намекаю на то, что потеря невелика.
>> Может быть. А, может быть, и нет. Опять-таки, считать надо.
>
>вот я именно хоть сколько-то нормальных замеров и просил два сообщения назад.
>:-)Замер я привёл, ну а конкретно это всё равно надо считать. Вообще тенденция судить о чём-то по бенчмаркам, которые делаются в отличных от ваших условиях, ИМХО, череповато. Можно ту или иную степень достоверности им присваивать "для себя", но не более. Повторяю, посчитать несложно. От себя скажу, что если у вас криптотраффик составляет заметную часть загрузки системы, то результат будет заметен. Я встречал цифры порядка 6-8 кратного ускорения шифрования-дешифрования, но насколько это поможет в конкретной конфигурации — никто, кроме вас самого, не скажет. А так можно заявить, как некоторые фряшники, о десятикратном приросте обработки пакетов в 7.0, забывая о том, что это относится лишь к определённой части сетевого стека. :)
Я бы сказал так: если у вас машина занимается в основном OpenVPN (читай, OpenSSL) и SSH, то нагрузка снизится раза в два-три. Заметно дешевле нового сервера, ИМХО. А если эта прибавка идёт ещё и бесплатно, скажем, вместе с процессором (Via C3), то вообще жить хорошо и замечательно. Пока не утыкаемся в обсуждённые выше проблемы с CBC. :)
>> А у меня как-то вопросов и не было, это вы спрашивали. ;)
>
>нет, я благодарен за замечание про крипто-акселлераторы. но я как бы намекаю
>на то, что потеря невелика.В большинстве случаев — да.
>... Пока не утыкаемся в обсуждённые выше проблемы с CBC.В чем проблема? Включаем в настройках и радуемся... Разработчики ведь не закрыли поддержку, а лишь изменили приоритет!
>>... Пока не утыкаемся в обсуждённые выше проблемы с CBC.
>
>В чем проблема? Включаем в настройках и радуемся... Разработчики ведь не закрыли
>поддержку, а лишь изменили приоритет!Ну так включайте, пожалуйста. И не стесняйтесь на красный свет дорогу переходить, чего бояться.
Для Ыкстпертов: cbc не выкинули, просто при наличии лучших алгоритмов - заюзаются онЕ.
А по поводу того насколько это безопасно - дык! Классический трэйдофф - скорость вс секурность :)ПыСЫ: Кстате - санки вроде придлагали карты с аесом на борту.
>Для Ыкстпертов: cbc не выкинули, просто при наличии лучших алгоритмов - заюзаются
>онЕ.Вы будете смеяться, но до большинства это дошло раньше, чем до вас…
>А по поводу того насколько это безопасно - дык! Классический трэйдофф -
>скорость вс секурность :)
>
>ПыСЫ: Кстате - санки вроде придлагали карты с аесом на борту.Да их много, этих карт (точнее, чипов), сходите по одной из ссылок, приведённых выше: http://www.hardware-ciphers.com/ . Просто, как и, скажем, карты для кодирования видео, они нужны далеко не всем.
>>Для Ыкстпертов: cbc не выкинули, просто при наличии лучших алгоритмов - заюзаются онЕ.
>Вы будете смеяться, но до большинства это дошло раньше, чем до вас…Но вот до Вас конкретно - позже всех :) Не так ли ?
Или для чего весь этот стон про "кирдык хардовым чиперам"? :)
>>>Для Ыкстпертов: cbc не выкинули, просто при наличии лучших алгоритмов - заюзаются онЕ.
>>Вы будете смеяться, но до большинства это дошло раньше, чем до вас…
>
>Но вот до Вас конкретно - позже всех :) Не так ли
>?
>Или для чего весь этот стон про "кирдык хардовым чиперам"? :)Это были не стоны (не говоря о том, что терминов вроде «кирдык» вы в моих и других сообщениях не найдёте), а отражение объективной реальности:
Во-первых, бОльшая часть SSH-соединений устанавливается при помощи OpenSSH;
Во-вторых, бОльшая часть пользователей (или поставщиков решений, использующих) OpenSSH не настраивает приоритеты алгоритмов, полагаясь (и не без оснований) на выбор разработчиков.
Поэтому в более или менее скором времени, когда (заботливые) администраторы, а также люди, полагающиеся на автообновление, установят новую версию OpenSSH, то у них возможно падение производительности. И если отдельно установленные платы для аппаратного шифрования/дешифрования ещё редкость, то, скажем, Via C3 — уже не очень. Те, кто, скажем, купил barebone-систему с таким камнем и юзает её для переливания файлов (скажем, бэкапов) по SSH — могут заметить разницу.
И если до вас ещё не дошло: то, что _заметной_ проблемой это станет лишь для немногих остальные тоже уже в курсе.
>на то, что потеря невелика.А это смотря что делать.Представьте себе проксирование или vpn порядка гигабита по ssh например.Вы все еще уверены что это ерунда?А если гигабитных интерфейсов несколько а сервак, допустим, юзает орава народа (VDS там и так далее).Вообще, ssh особой скромностью в плане юзежа проца при большоем траффике не отличается.Подозреваю что за счет шифрования как раз.А случаи бывают разные.
P.S. arcfour'у довольно много досталось от криптографов и нафиг его (даже переработанный) делать приоритетным - не очень понятно.Или их переработка устраняет все известные проблемы и надежность оного проверена криптографами?
>непопулярности железных шифро-процессоров.Кстати, некоторые виды оборудования (например, репитеры для оптоволокна) трудно назвать шибко популярными, но тем не менее в определённых, пусть и узких сферах, они активно используются и вопросы их использования, соответственно, весьма актуальны. ;)
> репитеры для оптоволокнакстати, насколько для них актуален вопрос отмены ряда крипто-железок для openssh? правильно — нинасколько вообще.
>> репитеры для оптоволокна
>
>кстати, насколько для них актуален вопрос отмены ряда крипто-железок для openssh? правильно
>— нинасколько вообще.Угу. Это был абстрактный пример. Лопата ;)
>туда поставлю железку — и, что, responsiveness для клиентов увеличится?Больше ресурсов проца другим достанется.А вы думаете, шифровать, например, гигабит - это ерунда?Черта с два, проц пригрузится как делать нефиг.Если в него вообще не упрется все.
Нужны числа?
Начните качать с сайта большой файл на хорошей скорости (скажем, 100 мегабит) по https.
И смотрите загрузку проца в это время.
Если вам не нравится такая загрузка, то вам может помочь аппаратные решения.
Особенно, если скорость канала в интернет данного сервера куда больше скорости, на которой качался файл.Можно обосновать математически:
Имеем уравнение:
(ширина канала)/(скорость закачки) = 100%/(загрузка проца одной такой закачкой)Если правая и левая части уровнения равны, значит ваша система справится с шифрованием всего трафика.
Если правая часть меньше, значит не справится.Пример:
ширина канала = 1000Mb/s
скорость закачки = 100Mb/s
100% = 100%
загрузка одной закачкой = 10%1000/100 = 100%/10% - проц справляется (правда при 1Gbps будет загружен на 100%)
Другой пример:
загрузка одной закачкой = 201000/100 = 100/20 - проц сможет осилить только половину скорости канала (если весь трафик будет шифроваться)
Ну и т.д.
Вывод:
В каждом случае будет свой ответ на вопрос "а нужна ли железяка?".
>