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

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

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

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

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

+1

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

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

NIH-синдромом же

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

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

А как же GnuTLS?

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

70000 строк

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

Не знаю насчет уязвимостей, но взять например этот кусок кода 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 архитектурах тестировали? Зачем так делать?

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

big-endian

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

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

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

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

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

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

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

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

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

т.е. по вашему это мало?!

Я вообще всегда делаю

*u = *((uint32_t*)data);

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

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

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

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

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

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

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

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

А ты тестировал? В чём проблема?

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

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

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

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

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

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

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

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

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

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

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

Так не должно быть, надо обновляться.

Во-первых нет, во всяких роутерах этот 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];

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];  
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Amazon

Не нужно

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

Не нужно²

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

Значит будем считать, что претензий нет.

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

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