и наоборот?
Очень сложный вопрос. С одной стороны, в 2019г была новость, что rustls обошел openssl по скорости, но rustls базируется на ринге, который наполовину написан на С и асме, его код не был проверен. Так же у тебя не получится использовать алгоритмы ECDSA_NISTP521_SHA512 и ED448 (они тупо не реализованы в ринге). С другой стороны, даже половина кода на расте - это большой сдвиг в сторону безопасности.
Есть ещё https://mitls.org/ которая по большей части даже верифицирована (и, по слухам, используется в недрах Chrome и Firefox).
То есть в плане скорости для TLSv1.2 rustls лучше нативных?
По новостям 2019 года - да)
Ну вроде как актуально +- 2 года, спасибо!)
Половина кода на расте из которого половина ансейф? Да, мощный сдвиг.
Зато правдиво)
А в чем теоретическая сложность реализовать все на чистом safe расте, если таковая имеется?
Убийство производительности.
На одном пики точёные...
Ну, вон ребята из Microsoft верифицируют код прямо на Ассемблере...
+иногда неудобно или даже невозможно.
Ну у меня на первой работе мужик мог программу в Hex кодах читать и ошибки искать. В принципе ничего тут такого нет сверх сложного. Насчет верификации ассамберного кода. Там просто некоторые последовательности команд могут быть так сказать наводящими на подозрение в их правильности.
Не похоже, чтобы Вы вообще занимались верификацией, уж простите что я озвучиваю такое наблюдение. 😉
В прошлом году вроде были новости о том что rustls прошёл верификацию
Ну да. Дело это сложное и долгое, если формальные методы верификации использовать. Но некоторые вещи могут сразу стать видны. В принципе статическийй анализатор можно для всего сделать. Тоже в какой-то мере верификация. Например тот же Sonar неплохо улучшает качество кода. Даже на Java.
Действительно: http://jbp.io/2020/06/14/rustls-audit.html
Nope. Верификация обязана быть sound, иначе это не верификация. Статический анализ — не обязан и не является. Это я Вам как бывший разработчик статического анализатора говорю. 😃
Аудит — это не верификация... 🧐
Обсуждают сегодня