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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx >>>>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> LARTC mailing list >>>>> LARTC@xxxxxxxxxxxxxxx >>>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >>>>> >>>>> >>>> _______________________________________________ >>>> LARTC mailing list >>>> LARTC@xxxxxxxxxxxxxxx >>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> LARTC mailing list >> LARTC@xxxxxxxxxxxxxxx >> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >> >> >> >> > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > > _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
