LINUX.ORG.RU

Amazon представил свою собственную реализацию TLS

 , ,


3

5

Amazon анонсировал выход своей собственной реализации TLS — библиотеки s2n. Основная причина разработки своей библиотеки — гиганский объем кода OpenSSL и сложность его аудита, а также целая серия уязвимостей, найденных в ней за последние два года.

Библиотека представляет свою собственную реализацию TLS поверх низкоуровневой криптографии из OpenSSL. Исходные тексты (на языке Си) в настоящий момент состоят из 6000 строк кода, тогда как в OpenSSL около 70000 строк так или иначе связаны с поддержкой TLS. Лицензия новой библиотеки — Apache, исходные тексты доступны в репозитории на github.

>>> Подробности

★★★★★

В целых 11 раз хуже написали :<

melkor217 ★★★★★ ()

Со временем растолстеет круче OpenSSL. Зонды работают «из коробки»?

Klymedy ★★★★★ ()

Аудит проведут — свистите.

Deleted ()

Больше вилосипедов, хороших и разных! А по существу, они сами-то её хоть где-то использовать будут?

WARNING ★★★★ ()
Ответ на: комментарий от WARNING

+1

Но такое ощущение, что у OpenSSL хотя и подмоченная репутация, все-таки, это что-то известное и относительно проверенное. Но надо глянуть на код от Amazon, если он просто и понятно написан, в отличие от.

praseodim ★★★★★ ()

А чем libreSSL не устроил?

drfaust ★★★★★ ()
Ответ на: комментарий от drfaust

тем, что его разработчики некомпетентны.

anonymous ()
Ответ на: комментарий от reprimand

Гы. Гугло-синдром (язык Go) оказывается имеет своё имя...

drfaust ★★★★★ ()

А как же GnuTLS?

anonymous ()

гигантский объем кода

70000 строк

buddhist ★★★★★ ()

Одобрено АНБ?

anonymous ()

Не знаю насчет уязвимостей, но взять например этот кусок кода https://github.com/awslabs/s2n/blob/748ed608f68f6a184a062986d32d64c10dbe0df2/...

int s2n_stuffer_read_uint32(struct s2n_stuffer *stuffer, uint32_t *u)
{
    uint8_t data[4];
    struct s2n_blob b = {.data = data,.size = sizeof(data) };

    GUARD(s2n_stuffer_read(stuffer, &b));

    *u = data[0] << 24;
    *u |= data[1] << 16;
    *u |= data[2] << 8;
    *u |= data[3];

    return 0;
}

Они этот код на big-endian архитектурах тестировали? Зачем так делать?

SZT ★★★★ ()
Ответ на: комментарий от anonymous

+1, чем GnuTLS не устроил? Зачем было изобретать велосипед?

asaw ★★★★★ ()
Ответ на: комментарий от SZT

big-endian

серьёзные компании используют процессоры вместо заглушек, зачем им это

anonymous ()
Ответ на: комментарий от anonymous

Ну может быть серьезные компании захотят использовать эту библиотеку в каком-нибудь серьезном маршрутизаторе

SZT ★★★★ ()
Ответ на: комментарий от asaw

в комментариях к аналогичной новости когда-то на лоре мне сказали, что он ещё хуже openssl :( правда или нет — хз.

anonymous ()
Ответ на: комментарий от anonymous

Он может быть «хуже» по религиозным соображениям, тогда это не страшно. Страшно если по техническим.

asaw ★★★★★ ()
Ответ на: комментарий от SZT

Во-первых, big-endian издохли, во-вторых, не могу понять что не так с этим кодом.

Reset ★★★★★ ()
Ответ на: комментарий от asaw

К моменту когда GnuTLS начал пиарится во всю в нем нашли несколько серьезных уязвимостей. Даже пострашней, чем в openssl. Было это года 2-3 назад. С тех пор, интерес к gnutls у тех же гентушников приутих.

gh0stwizard ★★★★★ ()
Ответ на: комментарий от SZT

в серьёзном маршрутизаторе такое не будет обрабатываться софтварно, you dummy

anonymous ()
Ответ на: комментарий от SZT

И в чём проблема? Порядок байт в сериализованном представлении — big-endian. Чтение выполняется в целочисленную переменную. А как она внутри устроена на данной архитектуре — абсолютно пофиг.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от SZT

Хехе, раскинул понты без предварительной рекогносцировки. Это вполне православный endian-aware C-style.

anonymous ()
Ответ на: комментарий от FIL

Ни много, ни мало, вполне ожидаемо. Я-то думал, что под «гигантским объемом» они имеют в виду хотя бы тысяч 500 строк, а то и миллион.

buddhist ★★★★★ ()
Последнее исправление: buddhist (всего исправлений: 1)

Amazon представил свою собственную реализацию TLS...

...С бэкдором и уязвимостями!!!

// Как это еще никто не написал?!

segfault ★★★★★ ()
Ответ на: комментарий от segfault

реализацию TLS...

...С бэкдором и уязвимостями!!!

// Как это еще никто не написал?!

Это в порядке вещей.

suuaq ()
Ответ на: комментарий от SZT

Надо на s2n_stuffer_read смотреть, в этой функции все нормально.

anonymous ()

По моему, вся эта игра в безопасность уже изжила себя, и надо перестать мучить программистов и железо и передавать данные в plaintext. Кому надо, всё равно взломает и прочтет что нужно.

zenden ()
Ответ на: комментарий от Reset

Что б это им издыхать? Ну да, little endian добавили тоже, если кому захочется.

spqr ★★ ()

амазон не нужен

anonymous ()
Ответ на: комментарий от Reset

MIPS, почти в каждом роутере. PowerPC тоже вполне себе живы.

anonymous ()

Народ подскажите сайт по https выдает сообщение

SSL получило слабый эфемерный ключ Диффи-Хеллмана в сообщении рукопожатия «Обмен ключами сервера». (Код ошибки: ssl_error_weak_server_ephemeral_dh_key)

У меня работает tomcat на centos сертификат comodo за 700 рур в год.

У меня сервак взломали или так и должно быть?

sanets ()
Ответ на: комментарий от Reset

Во-первых, big-endian издохли

Во-первых, man IBM POWER

anonymous ()
Ответ на: комментарий от Reset

Во-первых нет, во всяких роутерах этот big endian вполне используется. Пруф вот http://wiki.openwrt.org/start?do=search&id=cpu big endian

Во-вторых с кодом не так то, что порядок записанных по адресу *u байт будут зависеть от того, какой используется порядок байт в процессоре. Оно или развернет порядок, или не развернет. По сути этот код

    *u = data[0] << 24;
    *u |= data[1] << 16;
    *u |= data[2] << 8;
    *u |= data[3];
будет делать то же, что и функция ntohl. Если именно этого поведения они хотят(скорее всего именно этого), то зачем такой код писать, если есть ntohl? Код со сдвигами может быть медленней. В частности, компилятор clang для этих двух функции
void test1(uint8_t *a, uint32_t *b)
{
  uint32_t tmp;
  memcpy(&tmp,a,sizeof(tmp));
  *b = ntohl(tmp);
}

void test2(uint8_t *a, uint32_t *b)
{
  uint8_t c[4] = {a[0], a[1], a[2], a[3]};
  *b  = c[0] << 24;
  *b |= c[1] << 16;
  *b |= c[2] << 8;
  *b |= c[3];  
}
генерирует под x86-64 сильно различающийся код на асме, в то время как у свежего gcc код получился полностью одинаковым, и там и там используется специальная инструкция bswap(к несвежему gcc это не относится). Посмотреть можно тут http://goo.gl/q1MLVk

Если тут имелось ввиду не ntohl, а просто хотелось таким способом поменять порядок байт независимо от порядка байт в процессоре и записать результат по другому адресу, то это баг

SZT ★★★★ ()
Ответ на: комментарий от SZT

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

Конечно, мы же в int пишем.

будет делать то же, что и функция ntohl.

Ты просто капитан очевидность! Видимо были какие-то причины не использовать ntohl.

генерирует под x86-64 сильно различающийся код на асме

И что? У тебя какие-то реальные претензии к коду есть? Например, пример где он сломается?

Reset ★★★★★ ()
Ответ на: комментарий от anonymous

Экзотика. Да, про мипсы тоже в курсе, но думаю, что они скоро и как армы на le съедут.

Reset ★★★★★ ()
Ответ на: комментарий от anonymous

Это вполне православный endian-aware C-style.

Для этого специальные функции ntohl/htonl придумали. Нафиг не нужно велосипеды со сдвигами писать, особенно учитывая что они могут плохо оптимизироваться компилятором

SZT ★★★★ ()
Ответ на: комментарий от Reset

И что? У тебя какие-то реальные претензии к коду есть? Например, пример где он сломается?

Чтобы найти пример где он сломается, мне нужно найти места, в которых эта самая функция s2n_stuffer_read_uint32 реально используется, но она там вызывается только в тестах. https://github.com/awslabs/s2n/search?utf8=✓&q=s2n_stuffer_read_uint32

SZT ★★★★ ()
Ответ на: комментарий от buddhist

Если каждая из-них - это макросная магия или невнятное непрокомментированное числодрочерство - то это вполне себе жопа. А с криптобиблиотеками числодрочерства как такового не избежать. А вот как его реализовать - вот тут вопрос...

Pinkbyte ★★★★★ ()
Ответ на: комментарий от anonymous

серьёзные компании используют процессоры вместо заглушек

48 ядерные MIPS-ы(Octeon) с криптообвязкой ржут в голос

Pinkbyte ★★★★★ ()
Ответ на: комментарий от SZT

В десериализации из data в u ошибок, вроде, нет. Но я бы использовал ntohl(), да. Странно, что многие этими функциями пренебрегают

Deleted ()

Amazon

Не нужно

Основная причина разработки своей библиотеки — гиганский объем кода OpenSSL
поверх низкоуровневой криптографии из OpenSSL

Не нужно²

Unicode4all ★★★★★ ()
Ответ на: комментарий от Deleted

Причин много. Заголовок для этих функций не определен. Например, на винде надо подключать монструозный winsock2.h. С 64х битными версиями беда. А еще сериализация может быть изначально в формате le. У всех свои причины, уверен, что и у разрабов сабжа они были.

Reset ★★★★★ ()
Ответ на: комментарий от Deleted

Странно что некоторые эксперты не знают про о проблемах с unaligned memory access.

anonymous ()
Ответ на: комментарий от anonymous

Я на роль эксперта не претендую. А свое анонимное высокомерие оставь при себе, оно не красит, даже несмотря на правоту.

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.