Изпечатай

[VladSun]

Значи, ако филтрирам 0х17030100 пакетът, Скайп отваря нова сесия към друго(!) ИП, с което си "говори" без тази байтова последователност. Все още не съм установил някакъв благонадежден pattern в новата сесия.

[gat3way]

Зла програма е skype. Преди време им се радвах как успяват да дупчат NAT-ове, за да си прекарват трафика, обаче явно и нови забавни хрумвания са им хрумвали

[ntrance]

Зла програма е skype. Преди време им се радвах как успяват да дупчат NAT-ове, за да си прекарват трафика, обаче явно и нови забавни хрумвания са им хрумвали

Тъй като разполагам с  domаin controler (server 2003)  и на него има една сложена програма kerio route , и с него не съм успявал    Единствения начин когато съм успявал и под wina i  linux да спра skypa  това беше когато   , влезна с админ права  от юсерския комп  и му махна скайпа , понеже ония от горе така наречените менежари  винаги им хрумва по някоя гениална идея сутринта когато не са се наспали добре. Аз след 1 седмица ровене и тестване   еми  казвам си го НЕУСПЯХ. След като се отвори тази тема и тук , с радост следях какво ще стане , но за сетен път се обеждавам че май няма как да го спрем скайпа. Предполагам си има начин , но изглежда все още не  е известен за нас или поне за мен

[seadog]

Може ли да провериш  другото IP към което се прехвърля login process-a  дали е от skype мрежата или не ( в ripe.net). Ако НЕ е от техните мрежи то най-вероятно всеки online skype клиент в един момент може да се явява, като междинен gateway/node/server/proxy (или както искате да го наречем )  през който "орязани" клиенти да стигат до skype node и login server-a.  Принципно този pattern 0х170.....,  който се връща от login server-a е трудно да го махнат ( от гледна точка на съвместимост и др.), но могат да заобикалят това филтриране на пакети по друг начин ползвайки P2P механизми. Мисля , че това правят в новите версии.

[gat3way]

Може би ако няма никакво рутиране между вътрешната мрежа и интернет - всичко да минава през прокси, тогава VoIP трафика на скайпа няма как да мине. Но контролния трафик и чатовете предполагам ще продължат да могат да се прекарват през проксито, освен ако някой не измисли някакви много хитри правила, които да го блокират.

[seadog]

На който му се чете може да разгледа този линк и коментарите:

 http://share.skype.com/sites/en/2009/04/is_deutsche_telekom_playing_an.html

Това е от коментарите:

"It is our understanding that first applications to be blocked or at least heavily deprioritized will be protocols for p2p (e.g. BitTorrent) and Skype, in order to promote custom's telcos/providers VoIP solutions."

Щом телекоми, като DT,  а доколкото знам и China телеком са правили опити да блокират skype - Китай  - нали са народна република   .... НО - едно голямо НО, skype явно не са съгласни и са прави от тяхна гледна точка и имат $$$ интерес skype P2P протокола да е unbreakable! Това и правят и както по-горе казах,  а и в началото ,че блокирането на skype e трудно, а явно с новите версии е невъзможно. След всеки трик за блокиране на тарфика им - те пускат patch

[gat3way]

Я, в уикипедията имало интересни неща по въпроса и референция към един pdf (обаче е стар и не знам дали е в сила това което пише там):

http://en.wikipedia.org/wiki/Skype_protocol

Това, което ми направи впечатление (не знам дали е валидно още де):

The RC4 encryption algorithm is used to obfuscate the payload of datagrams.

   1. The CRC32 of public source and destination IP, Skype's packet ID are taken
   2. Skype obfuscation layer's initialization vector (IV).

The XOR of these two 32 bit values is transformed to a 80-byte RC4 key using an unknown key engine.

A notable misuse of RC4 in skype can be found on TCP streams (UDP is unaffected). The first 14 bytes (10 of which are known) are xored with the RC4 stream. Then, the cipher is reinitialized to encrypt the rest of the TCP stream

След като знаеш първите 10 байта е елементарно да намериш първите 10 байта от RC4 keystream-a - просто ще XOR-неш две известни 10-байтови стойности. Тъй като след 14-тия байт, RC4 се реинициализира (под което предполагам се разбира reseed-ване на KSA и нулиране на PRGA броячите), могат да се декриптират 10 байта от съобщението - от 14-тия до 24-тия, без да знаеш ключа. Ако в тях се съдържа нещо, което да е характерен pattern за skype трафик, то тогава може да се направи някакъв много зъл филтър за скайп трафик.. Но това само при положение че между 14-тия и 24-тия байт от криптирания трафик има последователност, която да може със сигурност да докаже, че това е скайп комуникация.


П.П. ако на някой му е хрумнало че след като имаме 10-те първи байта от RC4 keystream-а можем да декриптираме целия трафик....така като гледам много трудно ще стане това. KSA се seed-ва с 80-байтов (640-битов) ключ, който както пише горе е уникален за всеки изпратен skype пакет, т.е включва някакъв skype packed ID и следователно не се преизползва. Можем да тръгнем да bruteforce-ваме RC4 алгоритъма, seed-вайки KSA с различни стойности, докато получим същите 10 байта keystream, до максимум 2^640 опита трябва да стане. Не че това не е изчислително невъзможно сложна задача де, ама все пак има и друг проблем - 10 байта keystream просто няма да са достатъчни. Ще има (2^640/2^80)-1 = (2^560)-1 ключа, които ще генерират същите 10 начални байта keystream, но няма да са правилния ключ. Така че този пропуск реално погледнато трудно ще доведе до компрометиране на криптираните съобщения.

[VladSun]

Явно трябва да се пише connection tracking модул за Скай пакети (т.е. да се следят няколко последователни пакета от TCP сесията) и да се използва играта им с RC4 кодирането. Не мога да се сетя някакъв друг протокол, който да ползва подобно нещо.