Доступен первый выпуск библиотеки BearSSL, предлагающей компактную реализацию протоколов SSL и TLS (RFC 5246). Автором разработки является канадский эксперт по криптографии (Thomas Pornin), автор RFC 6979, разработчик библиотеки sphlib, создатель функции хэширования паролей Makwa, соавтор хэша Shabal, блочного шифра DFC и потокового шифра SOSEMANUK. Код проекта написан на языке Си и распространяется под лицензией MIT. Выпуск 0.1 позиционируется как ознакомительный, а разработка пока находится в состоянии альфа-тестирования.

Ключевые цели проекта:

  • Надёжность и безопасность. Поддерживаются только проверенные версии протоколов и алгоритмы, в которых не зафиксировано уязвимостей. Реализации алгоритмов по умолчанию защищены от timing-атак;
  • Небольшое потребление ресурсов и небольшой размер кода. Минимальная сборка занимает всего 20 Кб и требует для своей работы 25 Кб ОЗУ;
  • Высокая переносимость, возможность сборки не только для стационарных систем, но и для контроллеров, загрузчиков и встраиваемых решений;
  • Поддержка различных расширений и наборов шифров для SSL/TLS. Расширяемость через систему дополнений, позволяющая сторонним разработчикам создавать собственные реализации алгоритмов для BearSSL.


Реализованные возможности:

  • Применение модели статической компоновки для включения в итоговые бинарные файлы только используемых алгоритмов без необходимости пересборки BearSSL со специальными опциями препроцессора;
  • Несколько вариантов API: основной state-machine API без callback-вызовов для ввода/вывода (удобен для обработки сообщений и программах с мультиплексированием на основе модели poll/select) и упрощённый потоковый API с callback-вызовами для низкоуровневой обработки ввода/вывода;
  • Полный отказ от динамического выделения памяти и предсказуемое потребление памяти, что обеспечивает неподверженность проблемам с утечками памяти и DoS-атаками, направленными на излишнее потребление ОЗУ. В библиотеке нет ни одного вызова malloc(), а из библиотечных функций используются только memcpy(), memmove(), memcmp() и strlen(), что упрощает перенос на различные специфичные системы и позволяет применять BearSSL в загрузочных окружениях без ОС. На стационарных системах для обращения к таймеру и генератору случайных чисел используются предоставляемые ОС системные вызовы;
  • Реализация клиентских и серверных компонентов;
  • Поддержка TLS 1.0, TLS 1.1 и TLS 1.2. SSL 2.0 и SSL 3.0 не поддерживаются из-за подверженности уязвимостям;
  • Поддержка алгоритмов обмена ключами RSA, ECDH и ECDHE. В ECDHE реализовано свойство "Forward Secrecy", не позволяющее расшифровать перехваченный сеанс при компрометации одного из долговременных ключей. DHE принципиально не поддерживается;
  • Реализованы минимально необходимые средства для проверки сертификатов X.509: сопоставление subject/issuer DN, оценка времени notBefore/notAfter, применение основных условий и расширения для обмена ключами. Код проверки выдаёт отрицательный результат при задействовании в сертификатах неподдерживаемых возможностей важных TLS-расширений. Существенным ограничением является отсутствие проверки отзыва сертификата;
  • Поддержка цифровых подписей RSA и ECDSA, а также всех классических хэш функций (SHA-1, SHA-2 от SHA-224 до SHA-512), кроме MD5;
  • Поддержка алгоритмов шифрования AES/GCM, AES/CBC и 3DES/CBC;
  • Поддержка эллиптических кривых secp256r1 (P-256), secp384r1 (P-384) и secp521r1 (P-521);
  • Обеспечена защита от проведения атак по сторонним каналам для AES/GCM, AES/CBC, 3DES/CBC, RSA и реализаций эллиптических кривых. BearSSL затрачивает постоянное время на обработку заполнения и зашифрованных данных, а также однородно обрабатывает некорректные входные данные;
  • Поддержка возобновления прерванных сеансов для клиента и сервера. Для обработки повторных запросов согласования соединений предоставляется простой кэш сеансов (при включении расход памяти около 100 байт на сеанс);
  • Поддержка безопасного метода повторного согласования соединения (Secure Renegotiation, RFC 5746), прерывающего операцию если другая сторона не поддерживает запрошенное расширение;
  • На стороне клиента для согласования меньшего максимального размера записей используется расширение для ограничения максимальной длины фрагмента (Maximum Fragment Length);

Из планов на будущее отмечается поддержка алгоритмов ChaCha20+Poly1305 (RFC 7905), задействование инструкций AES-NI для ускорения AES на современных x86 CPU, оптимизация для процессоров ARM, ускорение работы RSA, поддержка Curve25519 и EdDSA, расширенные средства для работы с клиентскими сертификатами, высокоуровневые функции (генерация пар ключей, самоподписанные сертификаты), поддержка DTLS, поддержка расширения ALPN (RFC 7301) для HTTP/2, поддержка TLS 1.3 после утверждения RFC.

Источник: http://www.opennet.ru/opennews/art.shtml?num=45438