6 ms·

Albeit unrelated, I wonder when Quakenet is going to realise that SSL for IRC, both server-to-server, but also client-to-server, is a must have in the year 2014

by ahf 13y ago

Albeit unrelated, I wonder when Quakenet is going to realise that SSL for IRC, both server-to-server, but also client-to-server, is a must have in the year 2014, if you are truly care about your users privacy.

csmithuk 13y ago
It's unfortunately also very CPU intensive which is a big problem for IRC networks which handle stupid numbers of connections at the same time.
- meebi 13y ago
  CPU load is not the primary issue. SSL on IRC networks for client connections cannot assert that the communication is secure (for example, that all clients in a channel actually bothered to verify the SSL certificate properly). This issue will remain until client verification techniques such as DANE and DNSSEC are widely adopted on for IRC usage.
  - ahf 13y ago
    It's not true that this is up to the clients authors alone to do this work, and it's not fair for the users to tell them that you are awaiting client adoption of various technology, when the current Quakenet ircd implementation is currently incapable of even accepting SSL connections. Or at least it was, last time I checked. Also, the DANE support in Irssi was announced in September last year and I have only heard of one network where some of its servers have adopted to this technology. Even though there is only one client that currently supports DANE+DNSSEC verification, we still need the (big) networks to start preparing for the support of it, and help us reaching the point where we can secure our user connections even better :-) Having SSL on IRC, even without DANE+DNSSEC, is still better than having no SSL at all.
    - pferde 13y ago
      This is why I am disappointed that SILC[1] never got off the ground in the mainstream. It could have been an elegant successor to IRC. 1. http://silcnet.org http://silcnet.org
      - welterde 13y ago
        I blame the reference (server) implementation leaving so much to be desired. Primarily stability. I tried running a silc server alongside my ircd for a while, but it never even reached a weeks worth of uptime without crashing (no matter if debian package, self compiled stable or devel, or some minor messing with the source). Perhaps if a non-C/C++ implementation comes along..
        pferde 13y ago
        No, it wasn't that. There used to be (maybe still is, I didn't check) a core group of reliable servers. I remember having a client idling on them for weeks without reconnections. What was missing, I think, was lack of client development and adoption. There was default CLI client which was a weird fork of Irssi, then there was plugin for Irssi, and not much else. There were of course few small client projects, but few of them got past early alpha stage.
  - jevinskie 13y ago
    It still helps in the "coffee shop wifi" scenario. I'll take my defense in depth, thank you. =)
- ahf 13y ago
  Other networks have adopted SSL much earlier and I simply refuse to believe that Quakenet's problem is CPU related. I'm not saying that a network should require all of its users to use SSL, but I do think that it's should be up to the user to decide whether or not her or they wants to encrypt the connection between themselves and the IRC server and let it be up to the channel operator to decide whether or not she's willing to accept clients, that connect over insecure connections, in her channel. It's purely because it hasn't been prioritised until recently, but it sounds like it's getting some attention now :-)
blibble 13y ago
we believe it's better to not have it than to do it badly. the other way to do it would be like freenode: do it quickly without understanding the risks... they used the same SSL cert for every ircd, then they got hacked, and with no PFS, all their past SSL'ed IRC is now effectively in the clear. we are now actively working on the problem for server links, but ultimately believe that having ssl for client connections at this moment in time adds little value: https://www.quakenet.org/articles/99-trust-is-not-transitive-or-why-irc-over-ssl-is-pointless https://www.quakenet.org/articles/99-trust-is-not-transitive...
- jlgaddis 13y ago
  Does QuakeNet runs services such as Freenode's ChanServ, NickServ, etc.? At the very least, SSL helps protects a user's credentials when using such services.
  - ahf 13y ago
    Not the same as Freenode does, but Quakenet does have services, yes.
- ahf 13y ago
  I'm sorry, but said article have already been brought up multiple times in #dev and people are starting to understand how it doesn't hold water anymore. I break into any discussion I see on IRC where someone posts a link to this article as an argument against SSL on IRC simply because it's not an argument against SSL. Of course, it takes two to tango. We, the client authors, have started enhancing our SSL support and so should the network operators that hosts the servers on the larger networks. Also, I think we agree on how Freenode stores the same certificate on every sever is... not ideal...
- SudoAlex 13y ago
  There's still some value. I'd love to be able to connect to a QuakeNet IRC server which is SSL/TLS protected to help guard against anyone sniffing on the local network, or along the route to the specific IRC server. Yes, there are problems to solve. Clients need to validate the servers certificate properly. Users need to understand that whatever they send may still be logged by the network, other users on the channel, etc. Saying that IRC doesn't need SSL is like saying that other IM applications such as Skype don't need it either. Anything which helps prevent eavesdropping should be done.

by ahf 13y ago

csmithuk 13y ago

It's unfortunately also very CPU intensive which is a big problem for IRC networks which handle stupid numbers of connections at the same time.

meebi 13y ago
CPU load is not the primary issue. SSL on IRC networks for client connections cannot assert that the communication is secure (for example, that all clients in a channel actually bothered to verify the SSL certificate properly). This issue will remain until client verification techniques such as DANE and DNSSEC are widely adopted on for IRC usage.
- ahf 13y ago
  It's not true that this is up to the clients authors alone to do this work, and it's not fair for the users to tell them that you are awaiting client adoption of various technology, when the current Quakenet ircd implementation is currently incapable of even accepting SSL connections. Or at least it was, last time I checked. Also, the DANE support in Irssi was announced in September last year and I have only heard of one network where some of its servers have adopted to this technology. Even though there is only one client that currently supports DANE+DNSSEC verification, we still need the (big) networks to start preparing for the support of it, and help us reaching the point where we can secure our user connections even better :-) Having SSL on IRC, even without DANE+DNSSEC, is still better than having no SSL at all.
  - pferde 13y ago
    This is why I am disappointed that SILC[1] never got off the ground in the mainstream. It could have been an elegant successor to IRC. 1. http://silcnet.org http://silcnet.org
    - welterde 13y ago
      I blame the reference (server) implementation leaving so much to be desired. Primarily stability. I tried running a silc server alongside my ircd for a while, but it never even reached a weeks worth of uptime without crashing (no matter if debian package, self compiled stable or devel, or some minor messing with the source). Perhaps if a non-C/C++ implementation comes along..
      - pferde 13y ago
        No, it wasn't that. There used to be (maybe still is, I didn't check) a core group of reliable servers. I remember having a client idling on them for weeks without reconnections. What was missing, I think, was lack of client development and adoption. There was default CLI client which was a weird fork of Irssi, then there was plugin for Irssi, and not much else. There were of course few small client projects, but few of them got past early alpha stage.
- jevinskie 13y ago
  It still helps in the "coffee shop wifi" scenario. I'll take my defense in depth, thank you. =)
ahf 13y ago
Other networks have adopted SSL much earlier and I simply refuse to believe that Quakenet's problem is CPU related. I'm not saying that a network should require all of its users to use SSL, but I do think that it's should be up to the user to decide whether or not her or they wants to encrypt the connection between themselves and the IRC server and let it be up to the channel operator to decide whether or not she's willing to accept clients, that connect over insecure connections, in her channel. It's purely because it hasn't been prioritised until recently, but it sounds like it's getting some attention now :-)

blibble 13y ago

we believe it's better to not have it than to do it badly. the other way to do it would be like freenode: do it quickly without understanding the risks... they used the same SSL cert for every ircd, then they got hacked, and with no PFS, all their past SSL'ed IRC is now effectively in the clear. we are now actively working on the problem for server links, but ultimately believe that having ssl for client connections at this moment in time adds little value: https://www.quakenet.org/articles/99-trust-is-not-transitive-or-why-irc-over-ssl-is-pointless https://www.quakenet.org/articles/99-trust-is-not-transitive...

jlgaddis 13y ago
Does QuakeNet runs services such as Freenode's ChanServ, NickServ, etc.? At the very least, SSL helps protects a user's credentials when using such services.
- ahf 13y ago
  Not the same as Freenode does, but Quakenet does have services, yes.
ahf 13y ago
I'm sorry, but said article have already been brought up multiple times in #dev and people are starting to understand how it doesn't hold water anymore. I break into any discussion I see on IRC where someone posts a link to this article as an argument against SSL on IRC simply because it's not an argument against SSL. Of course, it takes two to tango. We, the client authors, have started enhancing our SSL support and so should the network operators that hosts the servers on the larger networks. Also, I think we agree on how Freenode stores the same certificate on every sever is... not ideal...
SudoAlex 13y ago
There's still some value. I'd love to be able to connect to a QuakeNet IRC server which is SSL/TLS protected to help guard against anyone sniffing on the local network, or along the route to the specific IRC server. Yes, there are problems to solve. Clients need to validate the servers certificate properly. Users need to understand that whatever they send may still be logged by the network, other users on the channel, etc. Saying that IRC doesn't need SSL is like saying that other IM applications such as Skype don't need it either. Anything which helps prevent eavesdropping should be done.