The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз библиотеки OpenSSL 1.0.1 с поддержкой TLS 1.2

16.03.2012 16:21

Спустя два года с момента выхода прошлого значительного релиза представлена новая версия OpenSSL 1.0.1, библиотеки с реализацией протоколов SSL/TLS и различных алгоритмов шифрования. Несмотря на незначительный на первый взгляд номер версии в OpenSSL 1.0.1 представлено несколько существенных новшеств.

Ключевые улучшения:

  • Поддержка протоколов TLS v1.2 и TLS v1.1;
  • Поддержка протокола SRP (Secure Remote Password) и пакетов шифрования (ciphersuites) TLS-SRP для создания безопасного канала связи с использованием обычных паролей, которые в состоянии запомнить человек. Пример создания SRP-сессии можно посмотреть здесь;
  • Поддержка в TLS/DTLS расширения heartbeat;
  • Поддержка протокола SCTP (Stream Control Transmission Protocol);
  • Возможность экспорта данных ключей TLS в соответствии с требованиями RFC 5705;
  • Поддержка DTLS-SRTP согласования в соответствии с RFC 5764;
  • Реализация TLS-расширения с поддержкой протокола согласования Next, предложенного компанией Google (Next Protocol Negotiation);
  • Возможность использования PSS-сигнатур (Probabilistic Signature Scheme) в сертификатах, запросах и CRL;
  • Поддержка в библиотеке CMS (Cryptographic Message Syntax) механизма шифрования с использованием заданных пользователями паролей, определённого в RFC 3211;
  • Предварительная поддержка FIPS для непроверенного OpenSSL FIPS-модуля 2.0.


  1. Главная ссылка к новости (http://marc.info/?l=openssl-an...)
  2. OpenNews: Релиз библиотеки OpenSSL 1.0.0 и обновление 0.9.8n с устранением уязвимости
Лицензия: CC-BY
Тип: Программы
Ключевые слова: openssl
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (63) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, iZEN (ok), 17:24, 16/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    В IPv6 интегрирован IPSec. Перспективы OpenSSL/TLS под вопросом.
     
     
  • 2.2, Аноним (-), 17:54, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И когда наступит этот ipv6? Внуки хоть застанут?
     
     
  • 3.11, Genry (?), 19:23, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    6 июня!
     
     
  • 4.12, Аноним (-), 19:26, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Какого года?
     
     
  • 5.13, Аноним (-), 19:31, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Каждого.
     
     
  • 6.14, pavlinux (ok), 19:49, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    опять?
     
  • 5.25, Genry (?), 09:15, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Когда умалчивается, значит текущий!
     
     
  • 6.36, Аноним (-), 15:10, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да? А день рождения у тебя какого числа?
     
  • 5.26, Genry (?), 09:19, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Какого года?

    http://www.opennet.ru/opennews/art.shtml?num=32840

     
  • 2.3, Stell (??), 17:56, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Почему-то миф об "интегрированном 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 выполняют несколько разные задачи.

     
     
  • 3.6, iZEN (ok), 18:48, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему-то миф об "интегрированном IPsec" очень популярен, только непонятно что под этим люди подразумевают.

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

    > И потом, SSL/TLS и IPsec выполняют несколько разные задачи.

    SSL/TLS это протоколы аутентификации, авторизации и шифрования.
    IPSec это протокол аутентификации, авторизации, шифрования и обеспечения конфиденциальности передаваемых по сети данных. Какие у них могут быть "разные задачи"? IPSec обрабатывает/фильтрует всё, что выше него, SSL/TLS только отдельные сессии TCP.

     
     
  • 4.9, ptr (??), 19:03, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +7 +/

    >> И потом, SSL/TLS и IPsec выполняют несколько разные задачи.
    > IPSec обрабатывает/фильтрует всё, что выше него, SSL/TLS только отдельные сессии TCP.

    Ну вот вы сами и подтвердили, что задачи разные.
    Если мне нужно, чтобы мой мобильный телефон находился в защищенной офисной сети - эту задачу лучше выполнит IPSec. Если при этом, я не хочу, чтобы обмен моего почтового клиента с почтовым сервером внутри этой защищенной сети кто-то мог дешифровать, то эту задачу лучше выполнит SSL/TLS.

     
     
  • 5.18, Аноним (-), 20:46, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Если мне нужно, чтобы мой мобильный телефон находился в защищенной офисной сети
    > - эту задачу лучше выполнит IPSec.

    И как, много мобильников с поддержкой ipsec вы уже видели? Хотя я допускаю возможность прикрутить это к девайсам с пингвином на борту, но подолбаться при настройке придется порядочно. А оно надо? OpenVPN на основе сабжа раз в 20 проще поднять будет при прочих равных и через офисные фаеры оно пролезает намного лучше, если уж мы хотим секурно зайти в офисную сеть сидя в какой-то кафешке с публичной точкой доступа например :)

     
     
  • 6.24, Пыщь (?), 09:08, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Во всех iPhone-ах IPSec есть из коробки.
     
     
  • 7.27, Stax (ok), 12:23, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это не телефон, а смартфон.. Спрашивали про ipsec в телефонах, между прочим! Так что пример не катит.
     
     
  • 8.63, XoRe (ok), 19:07, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А часто вы почту на простых телефонах проверяете Один фиг, к тому моменту, когд... текст свёрнут, показать
     
  • 7.28, Аноним (-), 12:32, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Во всех iPhone-ах IPSec есть из коробки.

    А скрин настроек? Впрочем на ифонах мир не заканчивается. Например вот под рукой симбиановский смарт. IPv6 - есть, а ipsec - что-то не вижу.

     
     
  • 8.32, ptr (??), 13:54, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вот в руке держу E72 IPv6 не вижу, зато IPSec есть и работает из коробки И воо... текст свёрнут, показать
     
     
  • 9.34, тень_pavel_simple (?), 13:58, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вы про ipsec вообще не в курсе или притворяетесь ... текст свёрнут, показать
     
  • 9.46, Аноним (-), 19:08, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А у меня наоборот В настройках соединения GPRS есть выбор ipv4 или ipv6 А ник... текст свёрнут, показать
     
     
  • 10.49, тень_pavel_simple (?), 19:43, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален кто сказал что для других отсутствие соединения чем не ... текст свёрнут, показать
     
  • 10.53, pavlinux (ok), 01:43, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    IPSec это туннель внутри IPv4 иль IPv6 ... текст свёрнут, показать
     
  • 6.41, Аноним (-), 17:11, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    все устройства выпущеные Apple - умеют ipsec и стопку других VPN конектов..
    В отличии от тех же телефонов c linux на борту..
     
     
  • 7.47, Аноним (-), 19:09, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В отличии от тех же телефонов c linux на борту..

    Ой, под линуксные телефоны навалом любых самых загогулистых VPN. Вплоть до cisco vpn и какой там еще нестандартной байды.

     
  • 5.33, тень_pavel_simple (?), 13:55, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >то эту задачу лучше выполнит SSL/TLS.

    нет!


     
     
  • 6.37, ptr (??), 15:17, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >>то эту задачу лучше выполнит SSL/TLS.
    > нет!

    Да!!!

    Так как мой аргумент на целых два восклицательных знака длинее, значит он весомей ;)
    Доходчиво объяснил, как нужно аргументировать свое мнение?

     
  • 4.35, stellgenossen.ru (?), 14:56, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Люди под интеграцией IPSec подразумевают защищённость соединений и возможность шифрования
    > трафика на сетевом уровне, на уровне более низком, чем уровни прикладных
    > и транспортных протоколов.

    Чем отличается IPsec в стэке IPv6, куда он якобы интегрирован, от IPv4, где этой интеграции якобы нет?
    Как это поможет IPsec в IPv6 заменить TLS/SSL, и почему в IPv4 это невозможно?

    > SSL/TLS это протоколы аутентификации, авторизации и шифрования.
    > IPSec это протокол аутентификации, авторизации, шифрования и обеспечения конфиденциальности
    > передаваемых по сети данных. Какие у них могут быть "разные задачи"?
    > IPSec обрабатывает/фильтрует всё, что выше него, SSL/TLS только отдельные сессии TCP.

    IPsec применяется при обмене трафиком между хостами, у которых есть об этом предварительная договоренность.
    SSL/TLS между хостами, у которых предварительной договоренности нет.

     
     
  • 5.38, тень_pavel_simple (?), 15:59, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > где этой интеграции якобы нет?
    > Как это поможет IPsec в IPv6 заменить TLS/SSL, и почему в IPv4
    > это невозможно?
    >> SSL/TLS это протоколы аутентификации, авторизации и шифрования.
    >> IPSec это протокол аутентификации, авторизации, шифрования и обеспечения конфиденциальности
    >> передаваемых по сети данных. Какие у них могут быть "разные задачи"?
    >> IPSec обрабатывает/фильтрует всё, что выше него, SSL/TLS только отдельные сессии TCP.
    > IPsec применяется при обмене трафиком между хостами, у которых есть об этом
    > предварительная договоренность.
    > SSL/TLS между хостами, у которых предварительной договоренности нет.

    да-да конечно, именно поэтому необходима инфраструктура сертификатов, а-то, я то и не знал.

    принципиальное оnличие протоколов только в njм, что они на разных уровyях OSI, и то что в случае использование ssl/tls вам помимо прjчего придётся писать кучу доп кода вместо простого и поyятного socket();

     
     
  • 6.39, MrStell (ok), 16:08, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > да-да конечно, именно поэтому необходима инфраструктура сертификатов, а-то, я то и не
    > знал.
    > принципиальное оnличие протоколов только в njм, что они на разных уровyях OSI,
    > и то что в случае использование ssl/tls вам помимо прjчего придётся
    > писать кучу доп кода вместо простого и поyятного socket();

    Вы сейчас на какой вопрос отвечали?
    Напомню: исходная посылка была о том, что в IPv6 интегрирован IPsec, и поэтому TLS/SSL станет не нужен.
    Мои вопросы были: В чем заключается интеграция IPsec в IPv6? в чем принципиальное отличие IPsec в IPv6 от IPsec в IPv4, и почему в IPv6 он заменит SSL/TLS, а в IPv4 не может?

     
  • 6.48, Аноним (-), 19:16, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    И это - хорошо и правильно Зато мы можем проверить что прицепившийся клиент - н... текст свёрнут, показать
     
  • 5.54, pavlinux (ok), 01:59, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > IPsec применяется при обмене трафиком между хостами, у которых есть об этом
    > предварительная договоренность.

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

     
     
  • 6.57, MrStell (ok), 02:42, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> IPsec применяется при обмене трафиком между хостами, у которых есть об этом
    >> предварительная договоренность.
    > Угу, щаз... попробуй установи и поддерживай соединение с "договорёнными" хостами из дома.
    > Только не говори, что у вас к удалённым хостам прямой оптокабель!

    Кабеля нет, зато есть PSK или сертификат, для обмена трафиком с этими хостами. В большинстве случаев SSL/TLS работает не требуя от клиента авторизации, в отличие от IPsec где обе стороны знают друг о друге.

     
     
  • 7.61, тень_pavel_simple (?), 16:12, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>> 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.

     
  • 2.5, ptr (??), 18:38, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Перспективы использования SSL/TSL для защищенного соединения хостов в инфраструктуре IPv6, может и под вопросом. Зато перспективы использования SSL/TLS для защищенного соединения сервисов вполне ясны и востребованность SSL/TLS очевидна.

    Иными словами:
    Да, существует ряд задач, с решением которых IPSec справляется, по ряду критериев, лучше, чем SSL/TLS. Однако верно и обратное утверждение: существует ряд задач (например, поддержка HTTPS), с решением которых SSL/TLS справляется, по ряду критериев, лучше, чем IPSec.

    Еще короче:
    Вертолет чем-то лучше автомобиля, но и автомобиль чем-то лучше вертолета.

    Совсем коротко: кесарю кесарево

     
  • 2.15, Аноним (-), 20:39, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > В IPv6 интегрирован IPSec. Перспективы OpenSSL/TLS под вопросом.

    Сравнил ж-у (к тому же грязную) с пальцем.

     
  • 2.19, Аноним (-), 21:26, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скажите мне, многоуважаемый, как вы с помощью IPSec зашифруете файл типа "openssl aes-128-cbc -salt -in file -out file.aes"
     
     
  • 3.20, iZEN (ok), 21:41, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Скажите мне, многоуважаемый, как вы с помощью IPSec зашифруете файл типа "openssl
    > aes-128-cbc -salt -in file -out file.aes"

    Какой файл, вы о чём? В IPSec всё автоматически происходит в зависимости от настроек протокола.
    Вот отсюда: http://ru.wikipedia.org/wiki/IPsec начинайте читать.


     
     
  • 4.21, Аноним (-), 22:58, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Какой протокол, во о чем? Человеку файл нужно зашифровать.
    Вот http://en.wikipedia.org/wiki/Encryption отсюда начинайте читать.
     
  • 4.29, Аноним (-), 12:33, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Какой файл, вы о чём?

    О том что он файл шифрует утилиткой из комплекта openssl, а что? :)

     
     
  • 5.58, iZEN (ok), 09:08, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Какой файл, вы о чём?
    > О том что он файл шифрует утилиткой из комплекта openssl, а что? :)

    Что что — побочное действие протокола прикладного уровня.

    Для IPSec на одном узле нужно будет заводить отдельный IP и организовывать передачу файла с одного IP на другой. Смотрится, как "бешеной собаке семь вёрст — не крюк". Правда, что там с конечным результатом — х.з., получим ли мы зашифрованный файл, какой надо, или будет довольствоваться обратной расшифровкой. Зато секурно. :))

    Предложение по шифрованию файла средствами SSL — пример того, как использовать то, что для этого не предназначено.


     
  • 2.45, Andrew Kolchoogin (?), 18:22, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Изя, сдай дилера.

    HTTPS, к примеру, умеет аутентифицировать удалённого пользователя по предъявленному им сертификату. Там, где логин и пароль -- слабоваты, это вполне себе катит.

    IPSec так умеет, да? Чоправдашоле? Ну-ка, настройки мне для Apache?

     
     
  • 3.50, iZEN (ok), 19:44, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Изя

    Мерзопакостный народец нынче пошёл. Чужие никнеймы корёжит.

    > HTTPS, к примеру, умеет аутентифицировать удалённого пользователя по предъявленному им
    > сертификату. Там, где логин и пароль -- слабоваты, это вполне себе
    > катит.
    > IPSec так умеет, да?

    Представь себе, да.

    > Чоправдашоле? Ну-ка, настройки мне для Apache?

    Apache, как и любые другие приложения, использующие стандартный транспортный протокол (TCP), не нуждается в СОБСТВЕННОЙ настройке для работы с IPSec. IPSec является отдельным настраиваемым слоем сетевого протокола (IP) и не имеет никакого отношения к протоколам прикладного уровня (HTTP), хотя может выступать их фильтром.

     
     
  • 4.51, MrStell (ok), 20:05, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> HTTPS, к примеру, умеет аутентифицировать удалённого пользователя по предъявленному им
    >> сертификату. Там, где логин и пароль -- слабоваты, это вполне себе
    >> катит.
    >> IPSec так умеет, да?
    > Представь себе, да.
    >> Чоправдашоле? Ну-ка, настройки мне для Apache?
    > Apache, как и любые другие приложения, использующие стандартный транспортный протокол
    > (TCP), не нуждается в СОБСТВЕННОЙ настройке для работы с IPSec. IPSec
    > является отдельным настраиваемым слоем сетевого протокола (IP) и не имеет никакого
    > отношения к протоколам прикладного уровня (HTTP), хотя может выступать их фильтром.

    Это все очевидные вещи.
    Неочевидно, как тот же Apache сможет узнать имя, указанное в сертификате. Именно про это и был вопрос. Тот факт, что сессия состоялась, свидетельствует только о том, что клиент имеет валидный сертификат, а кто конкретно этот клиент?

     
     
  • 5.59, iZEN (ok), 09:15, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Неочевидно, как тот же Apache сможет узнать имя, указанное в сертификате.

    А зачем Apache что-то знать кроме организации сессии HTTP вон с тем узлом?
    Не его собачье дело совать нос в защищённый сетевой уровень, который УЖЕ САМ аутентифицировал хост пользователя, организовал авторизованное соединение и гарантирует безопасную, конфиденциальную передачу данных.

    > Именно
    > про это и был вопрос. Тот факт, что сессия состоялась, свидетельствует
    > только о том, что клиент имеет валидный сертификат, а кто конкретно
    > этот клиент?

    Прочитайте про протокол аутентификации IPSec что ли.

     
     
  • 6.60, MrStell (ok), 13:35, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Неочевидно, как тот же Apache сможет узнать имя, указанное в сертификате.
    > А зачем Apache что-то знать кроме организации сессии HTTP вон с тем
    > узлом?
    > Не его собачье дело совать нос в защищённый сетевой уровень, который УЖЕ
    > САМ аутентифицировал хост пользователя, организовал авторизованное соединение и гарантирует безопасную, конфиденциальную передачу данных.

    Вы вопросы вообще читаете или комментируете от балды?

    При использовании SSL, сертификат клиента может быть использован для его авторизации на сервере (web, mail и т.п.). Я предъявляю сертификат, и мне дается доступ к моему почтовому ящику, к моему личному разделу сайта, не задавая других вопросов, потому что кто я - написано в сертификате.

    Как то же самое реализовать используя IPsec? Если никак - то это минус.

     
     
  • 7.67, Michael Shigorin (ok), 03:06, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы вопросы вообще читаете или комментируете от балды?

    Давно уж от балды. :(  Поправь его сейчас МакКузик, он и его бы загрызть попробовал, наверное.

     

  • 1.4, CSRedRat (ok), 18:03, 16/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень занимательно, что объявлена поддержка протокола SCTP. Интересно, как он там поживает? Мало где встретишь упоминания о нём, а софта, который его поддерживает я вообще в руках не держал, хотя протокол ну очень перспективный, обладает рядом интересных возможностей (по ссылке в статье на википедии описаны преимущества перед TCP и возможности протокола), причём реализация этого протокола есть в ядре Linux, в Unix-системах, CISCO IOS и прочих, что даёт его наличие в множестве сетевых устройств, но он не поддержан в Windows, хотя в .NET Framework 4 ввели поддержку протокола SCTP. Интересно, что препятствует энергичному развитию и продвижению протокола?
     
     
  • 2.7, Аноним (-), 18:50, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ознакомился с SCTP - смысл в нем есть.

    >Интересно, что препятствует энергичному развитию и продвижению протокола?

    А кому это надо? 95% населения работает только из-за бабла.

     
     
  • 3.22, Аноним (-), 22:59, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А кому это надо? 95% населения работает только из-за бабла.

    Что в этом плохово?

     
     
  • 4.23, Аноним (-), 04:01, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Что в этом плохово?

    s/плохово/плохого/

    Много чего. Если вам это не очевидно - то, вероятно, вам это знать и не нужно.

     
  • 4.31, СуперАноним (?), 13:26, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> А кому это надо? 95% населения работает только из-за бабла.
    >Что в этом плохово?

    То, что не выполняется вселенское предназначение существования существ, наделённых разумом и, вероятно, душой.

     
  • 4.68, Michael Shigorin (ok), 03:15, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> [...] работает только из-за бабла.
    > Что в этом плохово?

    Полная бессмысленность.  В клинических случаях даже кризисы-дефолты не доходят.

    Вот эссе, которое на днях подсунули почитать: http://flibusta.net/b/144270/read (краткий пересказ для некоторых: если ты ставишь программки "для ускорения интернета" или даже крутишь бездумно конфиги по чужому блогпосту, совершенно не вникая в суть делаемого и происходящего вследствие -- то ты не профи, ты не админ, ты не технарь, а просто чайник с большим или меньшим самомнением и идёшь ты дорогой в никуда)

    PS: возвращаясь к OpenSSL -- можно и не за бабло крупно ошибиться, а ишача на линтер.  Разница в том, чему придали неоправданую важность.

     
  • 2.8, Аноним (-), 18:52, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, что препятствует энергичному развитию и продвижению протокола?
    > он не поддержан в Windows

    Молодец. Сам спросил, сам ответил.

     
     
  • 3.10, CSRedRat (ok), 19:18, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Интересно, что препятствует энергичному развитию и продвижению протокола?
    >> он не поддержан в Windows
    > Молодец. Сам спросил, сам ответил.

    Это понятно, но в .NET он появился, значит уже особых преград нет. В приложениях, которые ориентированы только на *nix-среду тоже можно использовать, т.к. реализация протокола интегрирована уже давно. Но почему-то не видно приложений, которые его используют. Что мешает вместо TCP просто использовать SCTP в таких случаях? Сложнее?

     
     
  • 4.17, Аноним (-), 20:43, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Молодец. Сам спросил, сам ответил.
    > Это понятно, но в .NET он появился, значит уже особых преград нет.

    А зачем должны быть преграды? Вот вы можете взять пудовую гирю и с ней побегать с первого этажа на десятый и обратно, никаких преград к этому нет. Но врядли вы станете это делать.

     
  • 2.16, Аноним (-), 20:42, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > что препятствует энергичному развитию и продвижению протокола?

    Отсутствие в этом какого либо внятного смысла. TCP и UDP уже есть, покрывают 99.9% задач, пролезают везде и поддерживаются куда большим числом сетевого оборудования и сервисов типа натов, фаеров, прокси, ...

    А с SCTP есть риск застрять на первом же фаере/нате/... например.

     
     
  • 3.55, pavlinux (ok), 02:37, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    oops
     
  • 2.30, СуперАноним (?), 13:22, 17/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Очень занимательно, что объявлена поддержка протокола SCTP.

    Тоже считаю, что это самое существенное нововведение в этой версии OpenSSL.

    >но он не поддержан в Windows

    А почему нас должны волновать проблемы Windows?
    Может, это и хорошо, что он не поддержвает многие протоколы, есть причина использовать неWindowsы.

     
  • 2.56, pavlinux (ok), 02:40, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Интересно, что препятствует энергичному развитию и продвижению протокола?

    Фаерфокс на 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 стали ещё призрачней.  

     
     
  • 3.62, тень_pavel_simple (?), 16:21, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Интересно, что препятствует энергичному развитию и продвижению протокола?
    > Фаерфокс на 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;
    fi

    exec $*

     
     
  • 4.64, pavlinux (ok), 21:03, 18/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Начинайте продвигать!!! :)
    >> А вот Google предлагает SPDY, по смыслу очень похож на SCTP,
    >> так что, перспективы массового SCTP стали ещё призрачней.
    > cat /usr/bin/withsctp
    > #!/bin/sh

    #  withsctp
    checksctp: Protocol not supported

    :D

    Дырявый он в своё время был, вот наверно года с 2006 у меня все конфиги ядра без него.
    Кстати, он  до сих пор EXPEREMENTAL
    ---
    # git pull
    # make

    net/sctp/protocol.c: В функции «sctp_addr_wq_timeout_handler»:
    net/sctp/protocol.c:676:1: предупреждение: метка «free_next» определена, но не используется [-Wunused-label]


    ля-ля-ля...

    [code]
    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);
            }
    [/code]


     
     
  • 5.65, Sem (??), 23:55, 19/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Если в линуксе кривая реализация, это не значит, что протокол плохой.
     
     
  • 6.66, pavlinux (ok), 01:10, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Если в линуксе кривая реализация, это не значит, что протокол плохой.

    Где было про реализацию и кривизну? Просто баг - не используемая метка, которая
    компилятором тупа удаляется, так как ни одного перехода на неё всё равно не будет.

      

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру