The OpenNET Project / Index page

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



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

Оглавление

В Chrome планируют помечать соединение как небезопасное при ..., opennews (??), 13-Дек-14, (0) [смотреть все] +1

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


57. "В Chrome планируют помечать соединение как небезопасное при ..."  +1 +/
Сообщение от Xaionaro (ok), 14-Дек-14, 11:22 
> Какого хрена! Они там обкурились чтоли?
> Теперь безграмотных пользователей будут отпугивать всякие ложные предупреждения, мол,
> этот сайт небезопасен, вали отсюда, и все шишки посыпятся на владельцев
> сайтов.

Нда, и более того, будет жаловаться несмотря на используемые IPSec и всякие шифрованные VPN. Работы в следующем году прибавится :(

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

170. "В Chrome планируют помечать соединение как небезопасное при ..."  +1 +/
Сообщение от Аноним (-), 14-Дек-14, 23:40 
> Нда, и более того, будет жаловаться несмотря на используемые IPSec

Это не зря. Еще один декоративный протокол по типу https. Примерно настолько же внушающий доверие.


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

189. "В Chrome планируют помечать соединение как небезопасное при ..."  +/
Сообщение от Xaionaroemail (ok), 15-Дек-14, 10:48 
>> Нда, и более того, будет жаловаться несмотря на используемые IPSec
> Это не зря. Еще один декоративный протокол по типу https. Примерно настолько
> же внушающий доверие.

Это почему ещё?

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

206. "В Chrome планируют помечать соединение как небезопасное при ..."  +/
Сообщение от Аноним (-), 15-Дек-14, 19:32 
> Это почему ещё?

Потому что очередной сложный в устройстве и конфигурации протокол с сомнительными моментами и кучей опций, не то чтобы удачной подборкой алгоритмов, рядом бестолковостей и так далее. Если поинтересоваться вопросом - можно заметить что большинство криптографов на такой протокол всерьез надеяться не собирается.

Вообще, так модно козырять тем фактом что нечто - стандарт. И все стандарты как на подбор то еще гэ с рядом проблем. Вон тот же повсеместно пхаемый AES например имеет время выполнения зависящее от ключа. Это позволяет туеву хучу атак косвенного восстановления ключей по анализу времени выполнения алгоритма. Всякие RSA и прочие - морально устарели. А получить представление о том как можно более-менее по людски делать шифрование сетевых пакетов можно на примере cjdns какого-нибудь. В десять раз проще, минимум имения мозга пользователю, шустрая подборка алгоритмв и все лучшие свойства которые можно ожидать от протокола с шифрованием. По дефолту. Без сотен рычагов и кнопочек.

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

220. "В Chrome планируют помечать соединение как небезопасное при ..."  +/
Сообщение от Xaionaroemail (ok), 16-Дек-14, 09:15 
>> Это почему ещё?
> Потому что очередной сложный в устройстве и конфигурации протокол

Что такое «сложный в конфигурации» протокол? И мне не кажется IPSec сложным в устройстве по той причине, что там нет ничего лишнего. Если в случае каких-то других решений всё пакуют в один хрен-разберёшь протокол, то тут всё разложили по полочкам.

> с сомнительными моментами

Например?

> и кучей опций

Например? Какие «опции» являются лишними?

> , не то чтобы удачной подборкой алгоритмов, рядом бестолковостей
> и так далее. Если поинтересоваться вопросом - можно заметить что большинство
> криптографов на такой протокол всерьез надеяться не собирается.

Ну, лично я вообще не доверяю шифрованию, упирающуюся в факторизацию или дискретное логарифмирование. А следовательно нужно использовать либо известные и проверенные реализации проверенных пост-квантовых асимметричных алгоритмов (много таких знаете с поддержкой в ядре?), либо заморачиваться с распространением ключей для симметричной криптографии другими путями (что для большинства моих use case-ов является явно избыточным). Второе делается, но только для систем, работающих с ПДн. А первого мы ещё не скоро дождёмся в юзабельном для меня виде. И если дождёмся, то возможно как раз в IPSec-е.

> Вообще, так модно козырять тем фактом что нечто - стандарт. И все
> стандарты как на подбор то еще гэ с рядом проблем.

Решение задачи напрямую исходит из формулировки самой задачи. Если стандартные средства более чем подходят, то зачем усложнять следующему сис. админу жизнь? По возможности, лучше использовать давно проверенные, хорошо изученные и всем известные средства. Естественно, существует тонна use case-ов, где приходится использовать всевозможные не-IPSec-и по объективным причинам, но есть всё-таки и тонна обратных use case-ов.

> Вон тот же повсеместно пхаемый AES например имеет время выполнения зависящее от
> ключа. Это позволяет туеву хучу атак косвенного восстановления ключей по анализу
> времени выполнения алгоритма.

Кто вас заставляет использовать AES в IPSec?

> Всякие RSA и прочие - морально устарели.

<sarcasm>Поэтому давайте считать RSA в HTTPS безопасным, а IPSec — нет.</sarcasm>

> А получить представление о том как можно более-менее по людски делать шифрование
> сетевых пакетов можно на примере cjdns какого-нибудь.

Вся нагрузка на CPU при передаче трафика делается на уровне ядра? Если нет, то для моих use case-ов сразу в пень.

> В десять раз проще,
> минимум имения мозга пользователю

«Программы могут работать в данной сети, при условии, что они поддерживают протокол IPv6.» , «Hyperboria является экспериментальной сетью, созданной тестерами и разработчиками cjdns для проверки протокола.» © https://ru.wikipedia.org/wiki/Cjdns

Что-то мне кажется, что если вводить это в production, то имения мозга от программы и от начальства мне надолго хватит.

Ещё люди бывает работают с филиалами, и лучше всего для объединения большого множества различных обособленных структур подходит что-то стандартизированное. Или, например, бывает L2TP over IPSec и т.п. Будете на android-ы ставить эти «cjdns»?

Вообще, чего я распинаюсь? Вы просто привели в пример утилиту, решающую совершенно другую задачу.

> , шустрая подборка алгоритмв и все лучшие свойства
> которые можно ожидать от протокола с шифрованием. По дефолту. Без сотен
> рычагов и кнопочек.

И асимметрия, и пост-квантовость, и высокая производительность, и безопасность, и достаточно хорошая проверенность алгоритмов и их реализации, и поддержка на большинстве платформ и всё остальное?

Не бывает универсального решения. Для каждой задачи своё решение (конечно, нередко эти решения пересекаются).

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

221. "В Chrome планируют помечать соединение как небезопасное при ..."  –1 +/
Сообщение от pavel_simple (ok), 16-Дек-14, 09:16 
>> Это почему ещё?
> Потому что очередной сложный в устройстве и конфигурации протокол с сомнительными моментами
> и кучей опций,

так и запишем -- неасилил.
> не то чтобы удачной подборкой алгоритмов,

про какие алгоритмы идёт речь, инкапсуляция/шифрование/удостоверения_подлинности -- какие конкретно из них не вызывают вашего доверия, чем?
> рядом бестолковостей

гласите весь список пожалуйста
> и так далее. Если поинтересоваться вопросом - можно заметить что большинство
> криптографов на такой протокол всерьез надеяться не собирается.

кто конкретно из криптологов, ссылки на публикации?
> Вообще, так модно козырять тем фактом что нечто - стандарт. И все
> стандарты как на подбор то еще гэ с рядом проблем. Вон
> тот же повсеместно пхаемый AES например имеет время выполнения зависящее от
> ключа. Это позволяет туеву хучу атак косвенного восстановления ключей по анализу
> времени выполнения алгоритма. Всякие RSA и прочие - морально устарели.

какие вероятности подбора ключа (уменьшение стойкости ключа) AES имеются при использовании контролируемого/неконтролируемого канала (входного)? Публикации криптологов имеются? Чем конкретно морально устарел RSA/DSA, при какой длине ключа вы делаете столь смелые утверждения?
> А
> получить представление о том как можно более-менее по людски делать шифрование
> сетевых пакетов можно на примере cjdns какого-нибудь. В десять раз проще,
> минимум имения мозга пользователю, шустрая подборка алгоритмв и все лучшие свойства
> которые можно ожидать от протокола с шифрованием. По дефолту. Без сотен
> рычагов и кнопочек.

почему не приведён в пример "правильности" openvpn? как вы сравниваете правильность на двух совершенно разных протоколах с различной применяемой топологией, критерии правильности прошу озвучить. Список лучших свойств так-же прошу привести.

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

222. "В Chrome планируют помечать соединение как небезопасное при ..."  +/
Сообщение от Xaionaroemail (ok), 16-Дек-14, 09:40 
Напишу несколько вещей в защиту данного анонима, а в остальном поддерживаю.

> какие вероятности подбора ключа (уменьшение стойкости ключа) AES имеются при использовании
> контролируемого/неконтролируемого канала (входного)?
> Публикации криптологов имеются?

Есть статья, рассказывающая, что AES by design сделан так, что позволяет timing attack-и.

http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

> Чем конкретно морально устарел RSA/DSA, при какой длине ключа вы делаете
> столь смелые утверждения?

IIRC, уже давно проскакивали публикации о возможности создания и поддержания кубитов при комнатной температуре на основе дефектов в кристаллах. Если действительно важно, могу поискать публикации. А далее встаёт проблема из-за алгоритма Шора, как подсказывает кэп :)

Кроме того, RSA жрёт немало CPU при ключах более 2048-бит, что уже много раз использовалось для различных DoS-атак. Но это отдельная тема. Лично я использую RSA с большими ключами и пока ни разу никто мне DoS за счёт этого не устраивал.

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

223. "В Chrome планируют помечать соединение как небезопасное при ..."  –1 +/
Сообщение от pavel_simple (ok), 16-Дек-14, 10:22 
> Напишу несколько вещей в защиту данного анонима, а в остальном поддерживаю.
>> какие вероятности подбора ключа (уменьшение стойкости ключа) AES имеются при использовании
>> контролируемого/неконтролируемого канала (входного)?
>> Публикации криптологов имеются?
> Есть статья, рассказывающая, что AES by design сделан так, что позволяет timing
> attack-и.
> http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

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

>> Чем конкретно морально устарел RSA/DSA, при какой длине ключа вы делаете
>> столь смелые утверждения?
> IIRC, уже давно проскакивали публикации о возможности создания и поддержания кубитов при
> комнатной температуре на основе дефектов в кристаллах. Если действительно важно, могу
> поискать публикации. А далее встаёт проблема из-за алгоритма Шора, как подсказывает
> кэп :)

к сожалению это не имеет отношения к непосредственной теме беседы -- т.е. IPSec.

> Кроме того, RSA жрёт немало CPU при ключах более 2048-бит, что уже
> много раз использовалось для различных DoS-атак. Но это отдельная тема. Лично
> я использую RSA с большими ключами и пока ни разу никто
> мне DoS за счёт этого не устраивал.

dos делать тем более затруднительно если используешь ipsec в режиме точка-точка, в режиме точка-многоточка методы предотващиния подобных атак элементарны и просты в реализации.

да, IPSec как протокол вовсе не мешает использовать постквантовые методы (алгоритмы) обмена ключами как и использовать любые другие блочные шифры.

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

227. "В Chrome планируют помечать соединение как небезопасное при ..."  +/
Сообщение от Xaionaroemail (ok), 16-Дек-14, 10:56 
> т.е. сеть сама даёт такие джиттеры что об угадывании ключа говорить сложно.

Чисто теоретически это можно обойти собрав большую статистику (большую коллекцию событий). Космофизики выделяют сигнал за шумом, превышающий этот сигнал на несколько порядков.

> к сожалению это не имеет отношения к непосредственной теме беседы -- т.е. IPSec.

Да, это было лишь про RSA.

> dos делать тем более затруднительно если используешь ipsec в режиме точка-точка, в режиме точка-многоточка методы предотващиния подобных атак элементарны и просты в реализации.

Согласен.

> да, IPSec как протокол вовсе не мешает использовать постквантовые методы (алгоритмы) обмена ключами как и использовать любые другие блочные шифры.

Согласен. Я даже об этом упомянул в другом своём комментарии выше. :)

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

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

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




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

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