If Client1 -> ServerA is encrypted, ServerA <-> ServerB is encrypted, ServerB <- Client2 is encrypted, Then that particular conversation (query) would be encrypted end to end, yes?
For as long as the server accepts non-encrypted client connections, then yes there's the obvious aspect of all things passed securely, also being passed insecurely. (Ordinarily I would not suggest this be supported, as disclosing both the plaintext and cyphertext content of a packet would give you a lead into finding the encryption key or algorithm? I'm a very amateur crypto-nerd.) But given that only server-to-server links will carry 'everything' maybe that risk is mitigated. There's some intermediary logic I could see; a flag that allowed you to see whether a user is connected via IRC or IRCS; a channel mode to only allow IRCS clients to connect. The user has to take _some_ responsibility for not assuming end-to-end secure comms? I use one IRCS server now - it's a single server, so doesn't have the issues you highlight - but one assumes that ultimately the goal would be to have the entire network encrypted-only (if not now, then 10 years from now?) and you have to start somewhere. So perhaps some clever decisions about network architecture and some useful UI tools to show whether end-to-end integrity is reasonable to assume (or not), could provide stepping stones. Interesting to see this discussed after so long. Cheers Mark/BlakJak On 30/10/12 17:06, Empus wrote: > I think you're missing my point. > > Let's say you're ClientA, connected over SSL to ServerA. > > I'm ClientB, connected insecurely (ie. no SSL) to ServerB. > > ServerA is connected to ServerB, unencrypted. > > You established a connection with your server over SSL, so you think > your session is secure, and that chat conversations will be protected > from man in the middle attacks because of encryption. > > However, if you chat with me, the ServerA<->ServerB connection, and > also the ServerB<->ClientB side of the connection, is all insecure. > You think your SSL provides security on our conversation, but in > reality, it wouldn't. It only protects the ClientA<->ServerA side of > things. One could argue that some security is better than none, but I > think it's a dangerous illusion of sorts. > > Again, these are just my thoughts but it's something I've considered > before and I think it's a valid reason to be wary of IRC over SSL. > > - Empus > > On Tue, Oct 30, 2012 at 1:35 PM, Noel Butler <noel.but...@ausics.net > <mailto:noel.but...@ausics.net>> wrote: > > On Tue, 2012-10-30 at 12:36 +1000, Empus wrote: >> I've a huge fan of all things electronic security (working in >> this space for a living).... but personally, I see little benefit >> in SSL for IRC, because of the very architecture model. >> >> >> Unless you're speaking with another client on the same server, or >> all people in a channel you're on is on the same server, you'd >> end up with a false sense of security. >> >> >> Without guaranteeing that ALL client<->server connections are >> encrypted, and any server<->server connections in between are as >> well, you could never be sure that the end to end path is >> encrypted and thus MIM attacks are mitigated. >> >> >> So without that scenario, wouldn't the client be fooled into a >> false sense of security? >> > > I'd say yes, to large networked servers like Undernet ;) but SSL > would be a great advantage, in particular for stand alone's or > small networks where agreements mandate ssl only. > > Think.. > > Port { server = yes; port = 4400; }; > ... > Port { port = 6667; }; > Port { port = 8888; ssl = yes; }; > > anyone connects to 6667, only ssl are accepted on 8888, > commenting out the port 6667 Port entry, would mean server only > accepts connections on port 8888, that are SSL, plain connections > on 8888 should be rejected. > > Cheers > > > > _______________________________________________ > Coder-com mailing list > Coder-com@undernet.org <mailto:Coder-com@undernet.org> > http://undernet.sbg.org/mailman/listinfo/coder-com > > > > > _______________________________________________ > Coder-com mailing list > Coder-com@undernet.org > http://undernet.sbg.org/mailman/listinfo/coder-com
_______________________________________________ Coder-com mailing list Coder-com@undernet.org http://undernet.sbg.org/mailman/listinfo/coder-com
