Комментарии 25
Решение проблемы прайвэси простое — добавив в VOIP-клиенте некоторую (небольшую, конечно) задержку, буферизовать данные. Тогда объём пересылаемой информации будет (неприемлимо) меньше (для хакеров) соотноситься с динамикой речи.
а у некоторых ip-телефонов есть опция - "комфортный шум"
Буферизация там есть и так в любом случае. Мне кажется что более надежный способ это тоннелирование такого трафика и скремблирование данных перед инкапсуляцией в тоннель. Слабое место такого способа это необходимость дополнительных аппаратных рессурсов на серверной стороне voip-оператора для одновременного кодирования/декодирования на лету тысяч одновременных разговоров.
При чём здесь ресурсы оператора? В SIP, например, оператор "сводит" абонентов, а дальше - p2p. Можно даже просто "позвонить на ip-шник", безо всякого оператора.
SIP это всего лиш один из способов реализации VoIP. Причем далеко не самый качественный и не самый распространенный.
SIP - это всего лишь сигнализация
Хорошо, приведите пример широко распространённой VoIP-технологии, которая была бы не p2p.
Skype тот же. Или вы считаете что VoIP это только когда с компа на комп?
Skype - p2p-протокол
Ага. И когда я звоню со Skype на городской или мобильный телефон это тоже по вашему P2P? Т.е. VOiP трафик не терминируется нигде в момент приземления в обычные телефонные сети? Интересно.
Да, это p2p. pstn- или gsm-гейт также, как и ваш клиент, авторизуется сервере, для чего у него есть специальный логин. Для соединения он практически ничем не отличается от вашего skype-клиента, оно происходит так же, как и между двумя клиентами.
Это p2p в котором в качестве второго узла выступает voip-pstn шлюз. Насколько помню VoIP (неважно с какой сигнализацией,SIP,H323...) по определению выгоднее строить по p2p технологии.
Криптография и криптоанализ это сила!
Помню ещё такой интересный метод сужения множества, как анализ интервалов между нажатиями клавишь с целью уточнения вероятности следования того или иного символа.
http://en.wikipedia.org/wiki/Steganograp…
«A new steganographic technique involves injecting imperceptible delays to packets sent over the network from the keyboard. Delays in keypresses in some applications (telnet or remote desktop software) can mean a delay in packets, and the delays in the packets can be used to encode data.»
Помню ещё такой интересный метод сужения множества, как анализ интервалов между нажатиями клавишь с целью уточнения вероятности следования того или иного символа.
http://en.wikipedia.org/wiki/Steganograp…
«A new steganographic technique involves injecting imperceptible delays to packets sent over the network from the keyboard. Delays in keypresses in some applications (telnet or remote desktop software) can mean a delay in packets, and the delays in the packets can be used to encode data.»
Во-первых это можно сравнить с разгабыванием японского кроссворда в ситуации, между ним и глазами находится трехметровый аквариум не кристально чистой воды.
Во-вторых в шифрованном тунеле неразглядеть какого размера пакеты по нему бегают
В-третьих, кодеков для voip с переменным VBR крайне мало, навскидку тока speex вспомню, а посмеместно распространенные g729 g723 g711 gsm таким образом не скомпрометируются.
Подозвреваю пиар zfone - ссылка на который есть в исходной статье.
Короче безопасность это хорошо, но еще лучше когда без паранои, иначе можно впустую слить массу денег :)
Во-вторых в шифрованном тунеле неразглядеть какого размера пакеты по нему бегают
В-третьих, кодеков для voip с переменным VBR крайне мало, навскидку тока speex вспомню, а посмеместно распространенные g729 g723 g711 gsm таким образом не скомпрометируются.
Подозвреваю пиар zfone - ссылка на который есть в исходной статье.
Короче безопасность это хорошо, но еще лучше когда без паранои, иначе можно впустую слить массу денег :)
а что мешает сделать битрейт постоянной величиной?
по поводу "оу" - представил перехват разговора реперов - "йоу,братан, йоу как дела", лингвисты повесятся)
по поводу "оу" - представил перехват разговора реперов - "йоу,братан, йоу как дела", лингвисты повесятся)
Решения, использующиеся в промышленности, не очень страдают от этого. Там есть два режима (g711, g726, например): режим постоянного "высокого" битрейта - от протокола зависит, если не ошибаюсь - 64kbps для первого, 40, 32, 16 kbps - для второго; и режим "низкого" битрейта, который имеется если используется VAD (Voice Activity Detection) и включается, когда голос не обнаруживается, при этом передаются результаты замеров характеристик шума, по этим замерам на том конце генерируется комфортный шум (CNG - comfortable noise generating).
Вот такой там "VBR".
Собственно, по размерам пакетов можно определить только, говорит сейчас человек, или нет.
Вот такой там "VBR".
Собственно, по размерам пакетов можно определить только, говорит сейчас человек, или нет.
IMHO буря в стакане воды. Фрагментировать передаваемые данные на стороне кодера иначе чем по словам/фразам проще простого.
Надежным решением в данном случае (ИМХО) будет нормализация трафика. Кстати, если кто-то считает, что потоковый звук и видео плохо нормализуются, то это заблуждение. Есть нормализаторы, которые справляются с этой задачей просто "на ура" (сам видел!). Правда, есть другой аспект... это дорого. И это не единственная проблема: все пакеты придется инкапсулировать; если применяется шифрование с инкапсуляцией, то исходный пакет будет обернут 2 раза.
И тут уже не понятно где мы больше сэкономим. Либо это переменный битрейт, который дает ощутимый результат при компресии, плюс двойная обертка пакетов и выравнивающий трафик, сгенерированный нормализатором. Либо постоянный битрейт, как следствие, больший объем трафика, но отсутствие необходимости нормализации.
Это все опять же здорово в теории. А на практике как оператор решит, так и будет :)
И тут уже не понятно где мы больше сэкономим. Либо это переменный битрейт, который дает ощутимый результат при компресии, плюс двойная обертка пакетов и выравнивающий трафик, сгенерированный нормализатором. Либо постоянный битрейт, как следствие, больший объем трафика, но отсутствие необходимости нормализации.
Это все опять же здорово в теории. А на практике как оператор решит, так и будет :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анализ зашифрованного VoIP-трафика по размеру пакетов