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
