Re: [LARTC] How to fight with encrypted p2p

["Sébastien CRAMATTE" <s.cramatte@wanadoo.fr>]

Sorry ... I'm little bite tired ...
I mean  that we might sponsor  Klauss and L7 team to develop this ...

Regards

Sébastien CRAMATTE escribió:
> Klauss,
>
> Could you
> Might be you can sponsor the development ...
>
> Regards
>
> Sébastien
>
>
> Klaus escribió:
>   
>> About ipp2p,
>>
>> Right now, the battle against p2p is lost with l7 detection from ipp2p,
>> l7 filter and others.
>>
>> Why ?? It is a known fact that pattern matching does not work with full
>> encrypted P2P handshakes based on DHT key exchange algorithms with byte
>> padding. You have absolutely no byte pattern and no fixed packet lengths
>> in the stream. So something like a flow history will fail or might have
>> a very high false +ve rate.
>>
>> The thing is that there are proprietary solutions which can detect fully
>> encrypted p2p streams based on a heuristic approach. (AFAIK ipoque is
>> selling a proprietary library for this which is integrated in some
>> firewall vendors). I have not seen any open source development into this
>> direction.
>>
>> Klaus, (former) maintainer of ipp2p
>>
>>
>> Marco Aurelio wrote:
>>   
>>     
>>> As you might have seen, these are words from ipp2p author:
>>>
>>> """
>>>
>>> I have seen some pieces of code from ipoque which can detect encypted bittorrent
>>> and edonkey traffic. Unforunately, this code will not work with
>>> iptables, because it needs
>>> more information about the flow history and the history of an ip address.
>>>
>>> Right now, I do not have the time and the money to develop a filter
>>> like this, but
>>> if you are interested in a developement in this direction, please contact me.
>>>
>>> """
>>>
>>> I *think* that we need something like a "bittorrent helper" in the
>>> kernel to keep this extra information about the flow history and then
>>> an iptables plugin to match. What do you think? Maybe we could contact
>>> him to know what kind of information is it?
>>>
>>>
>>> On Nov 12, 2007 9:17 AM, sawar <sawar@interia.pl> wrote:
>>>     
>>>       
>>>> Rtorrent which I use sometimes have ability to completely disable plain text
>>>> communication :
>>>>
>>>> man rtorrent
>>>>               allow_incoming  (allow incoming encrypted connections),
>>>> try_outgoing (use encryption for outgoing connections), require (disable
>>>> unencrypted  handshakes),  require_RC4  (also  disable  plaintext
>>>> transmission  after  the initial encrypted handshake), enable_retry (if the
>>>> initial outgoing connection fails, retry with encryption turned on if it was
>>>> off or off if it was on),  prefer_plain text  (choose  plaintext when peer
>>>> offers a choice between plaintext transmission and RC4 encryption, otherwise
>>>> RC4 will be used).
>>>>
>>>> and many other clients have similar abilities.
>>>> I'm afraid that full encrypted and enabled by default communication is only a
>>>> matter of time and we will lose this "fight" very soon.
>>>>
>>>>
>>>>       
>>>>         
>>>>> Some clients P2P clients are nice about there encryption and negotiate
>>>>> encryption ahead of time using plain communication. I.E. Limewire,
>>>>> Azureus.  However, some just start TLS and that is all you can see.
>>>>>
>>>>> Looking at ipp2ps signatures, I don't see anything that leads me to
>>>>> believe they track that kind of info.
>>>>>
>>>>>
>>>>>
>>>>> David Bierce
>>>>>
>>>>> On Nov 11, 2007, at 9:48 PM, Mohan Sundaram wrote:
>>>>>         
>>>>>           
>>>>>> sAwAr wrote:
>>>>>>           
>>>>>>             
>>>>>>> Hi
>>>>>>> I believe that whole question is in topic. Is there any way to
>>>>>>> recognize ( and then shape ) p2p traffic which is encrypted?
>>>>>>> Modern p2p clients have this ability moreover some of them have
>>>>>>> this enabled by default. Now I'm using ipp2p for iptables but as I
>>>>>>> know this doesn't recognize encrypted traffic.
>>>>>>> Thanks in advance.
>>>>>>> Pozdrawiam
>>>>>>> Szymon Turkiewicz
>>>>>>>             
>>>>>>>               
>>>>>> Have not tried this. An idea. P2P initiations are not encrypted
>>>>>> AFAIK. Thus connections can be marked and related traffic shaped. If
>>>>>> initiation is also encrypted, then I think we have a serious problem.
>>>>>>
>>>>>> Mohan
>>>>>> _______________________________________________
>>>>>> LARTC mailing list
>>>>>> LARTC@mailman.ds9a.nl
>>>>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>>>>>>           
>>>>>>             
>>>>> _______________________________________________
>>>>> LARTC mailing list
>>>>> LARTC@mailman.ds9a.nl
>>>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>>>>>         
>>>>>           
>>>> _______________________________________________
>>>> LARTC mailing list
>>>> LARTC@mailman.ds9a.nl
>>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>>>>
>>>>       
>>>>         
>>>     
>>>       
>> _______________________________________________
>> LARTC mailing list
>> LARTC@mailman.ds9a.nl
>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>>
>>
>>   
>>     
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
>
>   

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc