Proposed functionaility for $ConnectToMe Secure.

[GoogleCodeExporter]

On newer DC clients, an undocumented advancement to the Hub-Client protocol
is "$ConnectToMe <remote_nick> <myip>:<myport>S|" to signal that the two
clients should use self-signed TLS encrypted transmissions.

Dtella successfully passes the flags correctly, signifying that a client is
TLS capable.  However, the current implementation flags "<port>S" as a
malformed address.

I present herewith a patch that was made against current head revision
(556) that successfully transmits a CS packet.  It has been tested and
shown to work with the StrongDC 2.21 client.

Are there any issues with the patch?

~Andyhhp

Original issue reported on code.google.com by andy...@gmail.com on 22 Jan 2009 at 4:30

Attachments:

• ConnectToMeSecure-patch.patch

[GoogleCodeExporter]

What happens if you just drop the 'S'?  Can a non-SSL connection still be 
negotiated?

If so, then I could make Dtella check the version of the target host, and 
insert a
1-byte 'flags' field into the CA packet if it's new enough.  (bit 0 would 
indicate
secure mode.)

Also, do you know if the 'S' has any relevance in passive mode connection 
requests?

Original comment by sparkm...@gmail.com on 27 Jan 2009 at 5:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

As i said, i cant find this in the official protocol. i believe it was 
introduced by
1 client and adopted by popular concent.

As for how it happens:  if a user enables 'tls encryption for complient 
clients',
that client advertised the fact by means of the flags in $MyINFO ALL.  If two 
clients
who are tls capable want to connect, they send a $ConnectToMe S command.

As for passive commands, i was under the impression that that was simply a
$RevConnectToMe followed by a $ConnectToMe.  There was nothing in the 
documentation
about this that suggested anything other than the flags and $ConnectToMe 
commands are
altered (as far as the hub is concerned - there may be altered client-client 
commands
but those are irrelevent to this topic)

I can see that conditionally altering the CA flags might be backward compatible 
as
far as dtella is concerned.  However, i doubt the clients will get along if 
they are
both tls capable, one sends a secure $ConnectToMe, its node ignores the S and 
sends a
regular message.  At this point, the first client is expecting a secure 
incomming
connection when in reality it will be getting an insecure one, probably using a
different clent-client command.

~Andyhhp

Original comment by andy...@gmail.com on 27 Jan 2009 at 2:22

[GoogleCodeExporter]

I still think it's worth it to see what happens when you drop the 'S'.  It 
would be
reasonable for it to fail, but you'll never know until you try.

I don't really feel like rebooting to Windows and setting up my own test network
right now, though.

Original comment by sparkm...@gmail.com on 28 Jan 2009 at 6:45

[GoogleCodeExporter]

Just did some tests involving dropping the 'S'

It doesnt work - the $ConnectToMe request times out and is resent.

I cant see any way of adding this support and still being completely backward
compatable.  It wont affect a network of old nodes.  However, the new 
alterations
will only work between 2 nodes that do not have a single old node on their 
message
paths which drop the CS packet.

What do you think is the best course of action, seeing as we certainly require 
this
as a proper form of protocol hiding?

~Andyhhp

Original comment by andy...@gmail.com on 31 Jan 2009 at 4:29

[GoogleCodeExporter]

Here's the documentation I was able to find on the protocol change:

# Supports a modified version of $ConnectToMe and $MyINFO. (Special thanks to 
PPK who
came up with the idea from the begining)

    * $ConnectToMe <RemoteNick> <SenderIp>:<SenderTLSPort>[S]| S indicate secure
connection and should only be sent from user a if user b also supports TLS, 
this is
indicated in $MyINFO.
    * $MyINFO $ALL <nick> <description>$ $<connection><flag>$<e-mail>$<sharesize>$|
flag value of: 0x10 = TLS (0x10 hex == 16 dec) indicates support for tls 

So, here's what I'm gonna do to Dtella:

When parsing incoming INFO messages, examine the flag byte.  If the remote 
Dtella
version (as indicated by the dttag) is below 1.2.4, then always clear the 0x10 
flag
bit.  This should make the DC client never attempt an 'S' connection to nodes 
whose
Dtella version won't be able to understand it.

The rest will be as I described before.  When making an 'S' connection, add the 
extra
flags byte to the CA packet, with bit 0 set.  When receiving CA packets, try to
decode both formats (with and without the flags byte).

Original comment by sparkm...@gmail.com on 31 Jan 2009 at 4:52

• Changed state: Accepted

[GoogleCodeExporter]

Fixed in r559-560.

Original comment by sparkm...@gmail.com on 14 Feb 2009 at 10:38

• Changed state: Fixed