Спустя два года с момента выхода прошлого значительного релиза представлена (http://marc.info/?l=openssl-announce&m=133174050203217&w=2) новая версия OpenSSL 1.0.1 (http://openssl.org/), библиотеки с реализацией протоколов SSL/TLS и различных алгоритмов шифрования. Несмотря на незначительный на первый взгляд номер версии в OpenSSL 1.0.1 представлено несколько существенных новшеств.
Ключевые улучшения:
- Поддержка протоколов TLS v1.2 (http://tools.ietf.org/html/rfc5246) и TLS v1.1 (http://www.ietf.org/rfc/rfc4346.txt);
- Поддержка протокола SRP (http://srp.stanford.edu/) (Secure Remote Password) и пакетов шифрования (ciphersuites) TLS-SRP для создания безопасного канала связи с использованием обычных паролей, которые в состоянии запомнить человек. Пример создания SRP-сессии можно посмотреть здесь (http://www.opennet.me/tips/2676_openssl_srp_tls_crypt.shtml);
- Поддержка в TLS/DTLS расширения heartbeat (http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04);
- Поддержка протокола SCTP (http://ru.wikipedia.org/wiki/SCTP) (Stream Control Transmission Protocol);
- Возможность экспорта данных ключей TLS в соответствии с требованиями RFC 5705 (http://tools.ietf.org/html/rfc5705);
- Поддержка DTLS-SRTP согласования в соответствии с RFC 5764 (http://tools.ietf.org/html/rfc5764);
- Реализация TLS-расширения с поддержкой протокола согласования Next, предложенного компанией Google (Next Protocol Negotiation (http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00));
- Возможность использования PSS-сигнатур (Probabilistic Signature Scheme) в сертификатах, запросах и CRL;
- Поддержка в библиотеке CMS (Cryptographic Message Syntax) механизма шифрования с использованием заданных пользователями паролей, определённого в RFC 3211 (http://tools.ietf.org/html/rfc3211);
- Предварительная поддержка (http://old.nabble.com/OpenSSL-FIPS-Module-2.0-status-update-... FIPS для непроверенного OpenSSL FIPS-модуля 2.0 (http://opensslfoundation.com/testing/validation-2.0/source/).URL: http://marc.info/?l=openssl-announce&m=133174050203217&w=2
Новость: http://www.opennet.me/opennews/art.shtml?num=33372
В IPv6 интегрирован IPSec. Перспективы OpenSSL/TLS под вопросом.
И когда наступит этот ipv6? Внуки хоть застанут?
6 июня!
Какого года?
Каждого.
опять?
Когда умалчивается, значит текущий!
Да? А день рождения у тебя какого числа?
> Какого года?http://www.opennet.me/opennews/art.shtml?num=32840
Почему-то миф об "интегрированном IPsec" очень популярен, только непонятно что под этим люди подразумевают.
Действительно, изначально IPsec придуман как часть стэка IPv6, и являлся обязательной частью стандарта. Поскольку миграция на IPv6 изрядно затянулась, IPsec был оттуда переложен на IPv4, где ему нашлось применение.В настоящее время требования к IPv6 узлам описываются документом:
http://tools.ietf.org/html/rfc6434"Previously, IPv6 mandated implementation of IPsec and recommended the
key management approach of IKE. This document updates that
recommendation by making support of the IPsec Architecture [RFC4301]
a SHOULD for all IPv6 nodes."И потом, SSL/TLS и IPsec выполняют несколько разные задачи.
> Почему-то миф об "интегрированном IPsec" очень популярен, только непонятно что под этим люди подразумевают.Люди под интеграцией IPSec подразумевают защищённость соединений и возможность шифрования трафика на сетевом уровне, на уровне более низком, чем уровни прикладных и транспортных протоколов.
> И потом, SSL/TLS и IPsec выполняют несколько разные задачи.
SSL/TLS это протоколы аутентификации, авторизации и шифрования.
IPSec это протокол аутентификации, авторизации, шифрования и обеспечения конфиденциальности передаваемых по сети данных. Какие у них могут быть "разные задачи"? IPSec обрабатывает/фильтрует всё, что выше него, SSL/TLS только отдельные сессии TCP.
>> И потом, SSL/TLS и IPsec выполняют несколько разные задачи.
> IPSec обрабатывает/фильтрует всё, что выше него, SSL/TLS только отдельные сессии TCP.Ну вот вы сами и подтвердили, что задачи разные.
Если мне нужно, чтобы мой мобильный телефон находился в защищенной офисной сети - эту задачу лучше выполнит IPSec. Если при этом, я не хочу, чтобы обмен моего почтового клиента с почтовым сервером внутри этой защищенной сети кто-то мог дешифровать, то эту задачу лучше выполнит SSL/TLS.
> Если мне нужно, чтобы мой мобильный телефон находился в защищенной офисной сети
> - эту задачу лучше выполнит IPSec.И как, много мобильников с поддержкой ipsec вы уже видели? Хотя я допускаю возможность прикрутить это к девайсам с пингвином на борту, но подолбаться при настройке придется порядочно. А оно надо? OpenVPN на основе сабжа раз в 20 проще поднять будет при прочих равных и через офисные фаеры оно пролезает намного лучше, если уж мы хотим секурно зайти в офисную сеть сидя в какой-то кафешке с публичной точкой доступа например :)
Во всех iPhone-ах IPSec есть из коробки.
Это не телефон, а смартфон.. Спрашивали про ipsec в телефонах, между прочим! Так что пример не катит.
> Это не телефон, а смартфон.. Спрашивали про ipsec в телефонах, между прочим!
> Так что пример не катит.А часто вы почту на простых телефонах проверяете?
Один фиг, к тому моменту, когда ваша компания внедрит ipv6+ipsec в _локальной_ сети, ваш телефон уже будет это поддерживать.
> Во всех iPhone-ах IPSec есть из коробки.А скрин настроек? Впрочем на ифонах мир не заканчивается. Например вот под рукой симбиановский смарт. IPv6 - есть, а ipsec - что-то не вижу.
>> Во всех iPhone-ах IPSec есть из коробки.
> А скрин настроек? Впрочем на ифонах мир не заканчивается. Например вот под
> рукой симбиановский смарт. IPv6 - есть, а ipsec - что-то не
> вижу.Вот в руке держу E72. IPv6 не вижу, зато IPSec есть и работает из коробки.
И вообще, вы как то сильно отклонились от темы - нить перечитайте.
Началось с того, что iZEN сказал:
> В IPv6 интегрирован IPSec. Перспективы OpenSSL/TLS под вопросом.Так что речь шла о тех грядущих временах, когда мобильный телефон при подключении по 99g (3g тогда, видимо, уже давно устареет) будет получать IPv6 адрес, а про IPv4 будут помнить только седые аксакалы.
И вот в те утопичные времена, я осмелился предположить, что SSL/TLS тоже для чего-то сгодится, потому как непонятно, зачем создавать через IPSec новое соединение с новой парой IP адресов, если достаточно зашифровать TCP соединение.
> И вот в те утопичные времена, я осмелился предположить, что SSL/TLS тоже
> для чего-то сгодится, потому как непонятно, зачем создавать через IPSec новое
> соединение с новой парой IP адресов, если достаточно зашифровать TCP соединение.вы про ipsec вообще не в курсе или притворяетесь?
> Вот в руке держу E72. IPv6 не вижу, зато IPSec есть и работает из коробки.А у меня наоборот. В настройках соединения GPRS есть выбор: ipv4 или ipv6. А никакого ipsec я не вижу.
> будет получать IPv6 адрес, а про IPv4 будут помнить только седые аксакалы.
И что?
Во первых, IPSec вообще опциональная часть стандарта. Был по изначальной задумке обязательным но на это все дружно забили и пришлось признать очевидное.
Во вторых, SSL решает иные задачи. Он обеспечивает явную защиту канала до ремоты с возможностью авторизации сертификатом и прочая и приложения явно в курсе успеха/неуспеха авторизации, параметров шифрования и прочая. А ipsec вообще так, "защита локалки". Ну или кто гарантирует что "вот отсюда до вон того сервера" ipsec пролезет и будет использовать стойкое шифрование? И как приложению проверить что оно натурально есть и стойкое? Ну мало ли, не хотим мы допустим в банке процессить транзакцию например если клиент не смог доказать сертификатом что он - именно он, а не некто левый. SSL это обеспечивает. IPSec ... а он для совсем других целей. Он по идее прозрачен для приложений, но нам в данном случае надо наоборот явно знать успех авторизации, что клиент и сервер - именно те за кого себя выдают, шифрование - надежное, сертификат клиента - правильный. И вот тогда...
То что там натупили с механикой подписывания сертификатов - отдельный вопрос, однако SSL можно использовать и например когда всего 1 CA которой мы натурально доверяем. В таком виде это даже вполне секурно, если что.
>[оверквотинг удален]
> Во вторых, SSL решает иные задачи. Он обеспечивает явную защиту канала до
> ремоты с возможностью авторизации сертификатом и прочая и приложения явно в
> курсе успеха/неуспеха авторизации, параметров шифрования и прочая. А ipsec вообще так,
> "защита локалки". Ну или кто гарантирует что "вот отсюда до вон
> того сервера" ipsec пролезет и будет использовать стойкое шифрование? И как
> приложению проверить что оно натурально есть и стойкое? Ну мало ли,
> не хотим мы допустим в банке процессить транзакцию например если клиент
> не смог доказать сертификатом что он - именно он, а не
> некто левый. SSL это обеспечивает. IPSec ... а он для совсем
> других целей.кто сказал что для других?
> Он по идее прозрачен для приложений, но нам в
> данном случае надо наоборот явно знать успех авторизации, что клиент и
> сервер - именно те за кого себя выдают, шифрование - надежное,
> сертификат клиента - правильный. И вот тогда...отсутствие соединения чем не показатель того что _защищенное_ соединение не установлено?
> То что там натупили с механикой подписывания сертификатов - отдельный вопрос, однако
> SSL можно использовать и например когда всего 1 CA которой мы
> натурально доверяем. В таком виде это даже вполне секурно, если что.не нужно вообще использовать сертификаты, это порочная практика удостоверяющих центhов во всей красе показала свою несостоятельность, сертификаты зло -> на свалку. уже давно есть протjколы защищающие установку соединения обеспечивающие не тjлько защиту от MITM но и других векторов атак -> внимательно см. SRP или PAKE2
> есть выбор: ipv4 или ipv6. А никакого ipsec я не вижу.IPSec это туннель внутри IPv4 иль IPv6.
все устройства выпущеные Apple - умеют ipsec и стопку других VPN конектов..
В отличии от тех же телефонов c linux на борту..
> В отличии от тех же телефонов c linux на борту..Ой, под линуксные телефоны навалом любых самых загогулистых VPN. Вплоть до cisco vpn и какой там еще нестандартной байды.
>то эту задачу лучше выполнит SSL/TLS.нет!
>>то эту задачу лучше выполнит SSL/TLS.
> нет!Да!!!
Так как мой аргумент на целых два восклицательных знака длинее, значит он весомей ;)
Доходчиво объяснил, как нужно аргументировать свое мнение?
> Люди под интеграцией IPSec подразумевают защищённость соединений и возможность шифрования
> трафика на сетевом уровне, на уровне более низком, чем уровни прикладных
> и транспортных протоколов.Чем отличается IPsec в стэке IPv6, куда он якобы интегрирован, от IPv4, где этой интеграции якобы нет?
Как это поможет IPsec в IPv6 заменить TLS/SSL, и почему в IPv4 это невозможно?> SSL/TLS это протоколы аутентификации, авторизации и шифрования.
> IPSec это протокол аутентификации, авторизации, шифрования и обеспечения конфиденциальности
> передаваемых по сети данных. Какие у них могут быть "разные задачи"?
> IPSec обрабатывает/фильтрует всё, что выше него, SSL/TLS только отдельные сессии TCP.IPsec применяется при обмене трафиком между хостами, у которых есть об этом предварительная договоренность.
SSL/TLS между хостами, у которых предварительной договоренности нет.
>[оверквотинг удален]
> где этой интеграции якобы нет?
> Как это поможет IPsec в IPv6 заменить TLS/SSL, и почему в IPv4
> это невозможно?
>> SSL/TLS это протоколы аутентификации, авторизации и шифрования.
>> IPSec это протокол аутентификации, авторизации, шифрования и обеспечения конфиденциальности
>> передаваемых по сети данных. Какие у них могут быть "разные задачи"?
>> IPSec обрабатывает/фильтрует всё, что выше него, SSL/TLS только отдельные сессии TCP.
> IPsec применяется при обмене трафиком между хостами, у которых есть об этом
> предварительная договоренность.
> SSL/TLS между хостами, у которых предварительной договоренности нет.да-да конечно, именно поэтому необходима инфраструктура сертификатов, а-то, я то и не знал.
принципиальное оnличие протоколов только в njм, что они на разных уровyях OSI, и то что в случае использование ssl/tls вам помимо прjчего придётся писать кучу доп кода вместо простого и поyятного socket();
> да-да конечно, именно поэтому необходима инфраструктура сертификатов, а-то, я то и не
> знал.
> принципиальное оnличие протоколов только в njм, что они на разных уровyях OSI,
> и то что в случае использование ssl/tls вам помимо прjчего придётся
> писать кучу доп кода вместо простого и поyятного socket();Вы сейчас на какой вопрос отвечали?
Напомню: исходная посылка была о том, что в IPv6 интегрирован IPsec, и поэтому TLS/SSL станет не нужен.
Мои вопросы были: В чем заключается интеграция IPsec в IPv6? в чем принципиальное отличие IPsec в IPv6 от IPsec в IPv4, и почему в IPv6 он заменит SSL/TLS, а в IPv4 не может?
> писать кучу доп кода вместо простого и поyятного socket();И это - хорошо и правильно. Зато мы можем проверить что прицепившийся клиент - натурально Вася, а не посторонний претендент. Чего одним только socket() не обеспечивается: для нас все клиенты как бы ничем не отличаются. А тут Вася может сертификат предъявить, заверенный нами, что мы натурально раньше выдали это Васе, а не кому-то там еще. И или либа нам валидирует это как сертификат Васи, или мы шлем его в пень и нифига не процессим его транзакции, например. А с ipsec это как сделать?
В общем то к SSL есть ровно 1 крупная предъява, касающаяся в основном браузеров: по дефолту забито дофига удостоверяющих центров которые типа доверяемые. При том что они доверяемые - за вас заранее решили другие. Но это не единственный вариант использования SSL. Например можно использовать только 1 СА (свой) а остальным не доверять. Тогда даже будет вполне нормально.
> IPsec применяется при обмене трафиком между хостами, у которых есть об этом
> предварительная договоренность.Угу, щаз... попробуй установи и поддерживай соединение с "договорёнными" хостами из дома.
Только не говори, что у вас к удалённым хостам прямой оптокабель!
>> IPsec применяется при обмене трафиком между хостами, у которых есть об этом
>> предварительная договоренность.
> Угу, щаз... попробуй установи и поддерживай соединение с "договорёнными" хостами из дома.
> Только не говори, что у вас к удалённым хостам прямой оптокабель!Кабеля нет, зато есть PSK или сертификат, для обмена трафиком с этими хостами. В большинстве случаев SSL/TLS работает не требуя от клиента авторизации, в отличие от IPsec где обе стороны знают друг о друге.
>>> IPsec применяется при обмене трафиком между хостами, у которых есть об этом
>>> предварительная договоренность.
>> Угу, щаз... попробуй установи и поддерживай соединение с "договорёнными" хостами из дома.
>> Только не говори, что у вас к удалённым хостам прямой оптокабель!
> Кабеля нет, зато есть PSK или сертификат, для обмена трафиком с этими
> хостами. В большинстве случаев SSL/TLS работает не требуя от клиента авторизации,
> в отличие от IPsec где обе стороны знают друг о друге.повторяем для невнимательных
для работы ssl/tls в том виде в которjм вы её здесь описываете необходима инфраструктура сертификатов (т.е. хосты напрямую себя не знают, но чтобы работать безопасно клиент должнен знать публичный ключ сервера, который он собственно получает на этапе согласования) -- подобная схема реализуется в том-же racoon'е с помощью схемы rsasig
P.S.
опять-же процедура проверки валидности предоставленного сертификата во всей красе показала себя в этом году -- т.к. сильно желающие смогли получbть сертификаты многих разных уважаемых контор -- отсюда следует что раз схема не гарантирует безопасных транзакций то эта схема не гарантирует ничего -> на свалкуP.P.S.
тот-же racoon написан кросплатформенно поэтjму для уровня приложений получить информацию об аутентифицироваyном пользователе он не позволяет, но никто не мешает в том-же linux'е запросить параметры установленного соединения через netlink, более того в рамках selinux/netlabel/LSM соединение может быть отправленно в необходимый домен selinux.
Перспективы использования SSL/TSL для защищенного соединения хостов в инфраструктуре IPv6, может и под вопросом. Зато перспективы использования SSL/TLS для защищенного соединения сервисов вполне ясны и востребованность SSL/TLS очевидна.Иными словами:
Да, существует ряд задач, с решением которых IPSec справляется, по ряду критериев, лучше, чем SSL/TLS. Однако верно и обратное утверждение: существует ряд задач (например, поддержка HTTPS), с решением которых SSL/TLS справляется, по ряду критериев, лучше, чем IPSec.Еще короче:
Вертолет чем-то лучше автомобиля, но и автомобиль чем-то лучше вертолета.Совсем коротко: кесарю кесарево
> В IPv6 интегрирован IPSec. Перспективы OpenSSL/TLS под вопросом.Сравнил ж-у (к тому же грязную) с пальцем.
Скажите мне, многоуважаемый, как вы с помощью IPSec зашифруете файл типа "openssl aes-128-cbc -salt -in file -out file.aes"
> Скажите мне, многоуважаемый, как вы с помощью IPSec зашифруете файл типа "openssl
> aes-128-cbc -salt -in file -out file.aes"Какой файл, вы о чём? В IPSec всё автоматически происходит в зависимости от настроек протокола.
Вот отсюда: http://ru.wikipedia.org/wiki/IPsec начинайте читать.
Какой протокол, во о чем? Человеку файл нужно зашифровать.
Вот http://en.wikipedia.org/wiki/Encryption отсюда начинайте читать.
> Какой файл, вы о чём?О том что он файл шифрует утилиткой из комплекта openssl, а что? :)
>> Какой файл, вы о чём?
> О том что он файл шифрует утилиткой из комплекта openssl, а что? :)Что что — побочное действие протокола прикладного уровня.
Для IPSec на одном узле нужно будет заводить отдельный IP и организовывать передачу файла с одного IP на другой. Смотрится, как "бешеной собаке семь вёрст — не крюк". Правда, что там с конечным результатом — х.з., получим ли мы зашифрованный файл, какой надо, или будет довольствоваться обратной расшифровкой. Зато секурно. :))
Предложение по шифрованию файла средствами SSL — пример того, как использовать то, что для этого не предназначено.
Изя, сдай дилера.HTTPS, к примеру, умеет аутентифицировать удалённого пользователя по предъявленному им сертификату. Там, где логин и пароль -- слабоваты, это вполне себе катит.
IPSec так умеет, да? Чоправдашоле? Ну-ка, настройки мне для Apache?
> ИзяМерзопакостный народец нынче пошёл. Чужие никнеймы корёжит.
> HTTPS, к примеру, умеет аутентифицировать удалённого пользователя по предъявленному им
> сертификату. Там, где логин и пароль -- слабоваты, это вполне себе
> катит.
> IPSec так умеет, да?Представь себе, да.
> Чоправдашоле? Ну-ка, настройки мне для Apache?
Apache, как и любые другие приложения, использующие стандартный транспортный протокол (TCP), не нуждается в СОБСТВЕННОЙ настройке для работы с IPSec. IPSec является отдельным настраиваемым слоем сетевого протокола (IP) и не имеет никакого отношения к протоколам прикладного уровня (HTTP), хотя может выступать их фильтром.
>> HTTPS, к примеру, умеет аутентифицировать удалённого пользователя по предъявленному им
>> сертификату. Там, где логин и пароль -- слабоваты, это вполне себе
>> катит.
>> IPSec так умеет, да?
> Представь себе, да.
>> Чоправдашоле? Ну-ка, настройки мне для Apache?
> Apache, как и любые другие приложения, использующие стандартный транспортный протокол
> (TCP), не нуждается в СОБСТВЕННОЙ настройке для работы с IPSec. IPSec
> является отдельным настраиваемым слоем сетевого протокола (IP) и не имеет никакого
> отношения к протоколам прикладного уровня (HTTP), хотя может выступать их фильтром.Это все очевидные вещи.
Неочевидно, как тот же Apache сможет узнать имя, указанное в сертификате. Именно про это и был вопрос. Тот факт, что сессия состоялась, свидетельствует только о том, что клиент имеет валидный сертификат, а кто конкретно этот клиент?
> Неочевидно, как тот же Apache сможет узнать имя, указанное в сертификате.А зачем Apache что-то знать кроме организации сессии HTTP вон с тем узлом?
Не его собачье дело совать нос в защищённый сетевой уровень, который УЖЕ САМ аутентифицировал хост пользователя, организовал авторизованное соединение и гарантирует безопасную, конфиденциальную передачу данных.> Именно
> про это и был вопрос. Тот факт, что сессия состоялась, свидетельствует
> только о том, что клиент имеет валидный сертификат, а кто конкретно
> этот клиент?Прочитайте про протокол аутентификации IPSec что ли.
>> Неочевидно, как тот же Apache сможет узнать имя, указанное в сертификате.
> А зачем Apache что-то знать кроме организации сессии HTTP вон с тем
> узлом?
> Не его собачье дело совать нос в защищённый сетевой уровень, который УЖЕ
> САМ аутентифицировал хост пользователя, организовал авторизованное соединение и гарантирует безопасную, конфиденциальную передачу данных.Вы вопросы вообще читаете или комментируете от балды?
При использовании SSL, сертификат клиента может быть использован для его авторизации на сервере (web, mail и т.п.). Я предъявляю сертификат, и мне дается доступ к моему почтовому ящику, к моему личному разделу сайта, не задавая других вопросов, потому что кто я - написано в сертификате.
Как то же самое реализовать используя IPsec? Если никак - то это минус.
> Вы вопросы вообще читаете или комментируете от балды?Давно уж от балды. :( Поправь его сейчас МакКузик, он и его бы загрызть попробовал, наверное.
Очень занимательно, что объявлена поддержка протокола SCTP. Интересно, как он там поживает? Мало где встретишь упоминания о нём, а софта, который его поддерживает я вообще в руках не держал, хотя протокол ну очень перспективный, обладает рядом интересных возможностей (по ссылке в статье на википедии описаны преимущества перед TCP и возможности протокола), причём реализация этого протокола есть в ядре Linux, в Unix-системах, CISCO IOS и прочих, что даёт его наличие в множестве сетевых устройств, но он не поддержан в Windows, хотя в .NET Framework 4 ввели поддержку протокола SCTP. Интересно, что препятствует энергичному развитию и продвижению протокола?
Ознакомился с SCTP - смысл в нем есть.>Интересно, что препятствует энергичному развитию и продвижению протокола?
А кому это надо? 95% населения работает только из-за бабла.
> А кому это надо? 95% населения работает только из-за бабла.Что в этом плохово?
>Что в этом плохово?s/плохово/плохого/
Много чего. Если вам это не очевидно - то, вероятно, вам это знать и не нужно.
>> А кому это надо? 95% населения работает только из-за бабла.
>Что в этом плохово?То, что не выполняется вселенское предназначение существования существ, наделённых разумом и, вероятно, душой.
>> [...] работает только из-за бабла.
> Что в этом плохово?Полная бессмысленность. В клинических случаях даже кризисы-дефолты не доходят.
Вот эссе, которое на днях подсунули почитать: http://flibusta.net/b/144270/read (краткий пересказ для некоторых: если ты ставишь программки "для ускорения интернета" или даже крутишь бездумно конфиги по чужому блогпосту, совершенно не вникая в суть делаемого и происходящего вследствие -- то ты не профи, ты не админ, ты не технарь, а просто чайник с большим или меньшим самомнением и идёшь ты дорогой в никуда)
PS: возвращаясь к OpenSSL -- можно и не за бабло крупно ошибиться, а ишача на линтер. Разница в том, чему придали неоправданую важность.
> Интересно, что препятствует энергичному развитию и продвижению протокола?
> он не поддержан в WindowsМолодец. Сам спросил, сам ответил.
>> Интересно, что препятствует энергичному развитию и продвижению протокола?
>> он не поддержан в Windows
> Молодец. Сам спросил, сам ответил.Это понятно, но в .NET он появился, значит уже особых преград нет. В приложениях, которые ориентированы только на *nix-среду тоже можно использовать, т.к. реализация протокола интегрирована уже давно. Но почему-то не видно приложений, которые его используют. Что мешает вместо TCP просто использовать SCTP в таких случаях? Сложнее?
>> Молодец. Сам спросил, сам ответил.
> Это понятно, но в .NET он появился, значит уже особых преград нет.А зачем должны быть преграды? Вот вы можете взять пудовую гирю и с ней побегать с первого этажа на десятый и обратно, никаких преград к этому нет. Но врядли вы станете это делать.
> что препятствует энергичному развитию и продвижению протокола?Отсутствие в этом какого либо внятного смысла. TCP и UDP уже есть, покрывают 99.9% задач, пролезают везде и поддерживаются куда большим числом сетевого оборудования и сервисов типа натов, фаеров, прокси, ...
А с SCTP есть риск застрять на первом же фаере/нате/... например.
oops
>Очень занимательно, что объявлена поддержка протокола SCTP.Тоже считаю, что это самое существенное нововведение в этой версии OpenSSL.
>но он не поддержан в Windows
А почему нас должны волновать проблемы Windows?
Может, это и хорошо, что он не поддержвает многие протоколы, есть причина использовать неWindowsы.
> Интересно, что препятствует энергичному развитию и продвижению протокола?Фаерфокс на SCTP - http://www.eecis.udel.edu/~amer/PEL/Firefox/sctp_firefox_3.0...
Апач over SCTP - http://www.eecis.udel.edu/~nataraja/research.htmlНачинайте продвигать!!! :)
А вот Google предлагает SPDY, по смыслу очень похож на SCTP,
так что, перспективы массового SCTP стали ещё призрачней.
>> Интересно, что препятствует энергичному развитию и продвижению протокола?
> Фаерфокс на SCTP - http://www.eecis.udel.edu/~amer/PEL/Firefox/sctp_firefox_3.0...
> Апач over SCTP - http://www.eecis.udel.edu/~nataraja/research.html
> Начинайте продвигать!!! :)
> А вот Google предлагает SPDY, по смыслу очень похож на SCTP,
> так что, перспективы массового SCTP стали ещё призрачней.cat /usr/bin/withsctp
#!/bin/sh
# -*- sh -*-
LIBDIR=/usr/lib/lksctp-tools
BINDIR=/usr/bin
export LD_PRELOAD=${LIBDIR}/libwithsctp.so.1.0.11
if ! ${BINDIR}/checksctp 2> /dev/null
then
${BINDIR}/checksctp;
exit 1;
fiexec $*
>> Начинайте продвигать!!! :)
>> А вот Google предлагает SPDY, по смыслу очень похож на SCTP,
>> так что, перспективы массового SCTP стали ещё призрачней.
> cat /usr/bin/withsctp
> #!/bin/sh# withsctp
checksctp: Protocol not supported:D
Дырявый он в своё время был, вот наверно года с 2006 у меня все конфиги ядра без него.
Кстати, он до сих пор EXPEREMENTAL
---
# git pull
# makenet/sctp/protocol.c: В функции «sctp_addr_wq_timeout_handler»:
net/sctp/protocol.c:676:1: предупреждение: метка «free_next» определена, но не используется [-Wunused-label]
ля-ля-ля...
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 5942d27..9c90811 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -673,7 +673,9 @@ void sctp_addr_wq_timeout_handler(unsigned long arg)
SCTP_DEBUG_PRINTK("sctp_addrwq_timo_handler: sctp_asconf_mgmt failed\n");
sctp_bh_unlock_sock(sk);
}
+#if IS_ENABLED(CONFIG_IPV6)
free_next:
+#endif
list_del(&addrw->list);
kfree(addrw);
}
Если в линуксе кривая реализация, это не значит, что протокол плохой.
> Если в линуксе кривая реализация, это не значит, что протокол плохой.Где было про реализацию и кривизну? Просто баг - не используемая метка, которая
компилятором тупа удаляется, так как ни одного перехода на неё всё равно не будет.