The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Язык программирования Go переходит с Mercurial на Git и GitHub, opennews (??), 14-Ноя-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


19. "Язык программирования Go переходит с Mercurial на Git и GitH..."  –1 +/
Сообщение от Аноним (-), 14-Ноя-14, 12:19 
интеллектуального оргазм от с/с++ достигается на таком коде:

#ifndef OPENSSL_NO_HEARTBEATS
int tls1_process_heartbeat(SSL *s){
         unsigned char *p = &s->s3->rrec.data[0], *pl;
         unsigned short hbtype;
         unsigned int payload;
         unsigned int padding = 16; /* Use minimum padding */

         /* Read type and payload length first */
         hbtype = *p++;
         n2s(p, payload);
         pl = p;

Ручное управление памятью, все дела. Зато быстро.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

69. "Язык программирования Go переходит с Mercurial на Git и GitH..."  +/
Сообщение от Аноним (-), 15-Ноя-14, 06:11 
> Ручное управление памятью, все дела. Зато быстро.

Сдуру можно и х... сломать. И root cause тут не сишечка, а
1) Переусложненный протокол с кучей легаси и костылей.
* Для начала, фича просить у ремоты энное количество байтов - не должна была существовать, даже в проекте. Ну и багов в ней - соответственно, быть не должно.
* А вон тут соседняя атака - с буферами ничего не делает вообще. MITM просто даунгрейдит протокол с TLS'а до SSLv3 и потом радостно вскрывает древний и слабый вариант протокола. И ничего вы с этим отказом от управления памятью не сделаете.
2) Как известно, сдуру можно и х... сломать и в криптографии автоматическое управление памятью - последнее что может помочь криптографу. Ключи должны изничтожаться предсказуемо, etc. Без этого будет много неочевидных ламоватым кидизам но от того не менее опасных в плане утечки ключей дыр. Ключ должен существовать ровно столько сколько он требуется и на этом пути GC с отложенной сборкой может очень сильно нагадить. И вообще, идея использовать криптографическую либу от тех кто не может даже памятью управлять - очень сомнительна. А сколько там тогда багов в алгоритмах криптографии и обвязке?
3) У OpenSSL дурное апи и дурной код. Ее авторы вообще не криптографы. Поэтому не так уж принципиально какой ЯП они возьмут. Сильно безопаснее не станет. Наворачивание хитрозадых конструкций на сях лишь немного дополняет эту картину. И не более того. А вовсе и не перекраивает весь ландшафт.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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