174087 - [RFE] Support IRC over SSL/TLS

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, enhancement)

Description

[Ben Bucksch (:BenB)]

Feature to communicate with IRC servers over SSL/TLS-encrypted connections.

On the server side, use sslwrap or something similar to create an SSL-enabled
IRC server. On the client side (which this bug is about), we can probably use
Mozilla SSL functions very much like Mailnews does.

Comment 1

[Chris P. Ross]

I agree.  I think there are a number of people working on openssl based irc
servers and clients already.  So, the server side may even be easy, soon.  It
would be nice to use chatzilla at that time.
Is the SSL code in mozilla available to chatzilla's code?  (ie, not compiled code)

Comment 2

[Carlo von Loesch]

xchat, irssi and mIRC have the ability to do SSL/IRC on port 9999.

for a server feel free to try things out on ours:
  ircs://irc.symlynX.de:9999

or install one yourself, it's open source
  http://muve.pages.de

maybe it proves useful that the same server is also accessible
via https://ve.symlynX.de:34443/PSYC/ using the same cert,
lets you compare HTTP and IRC over SSL within mozilla.

good luck! :)

Comment 3

[Carlo von Loesch]

Oops.. the cert is issued to the name ve.symlynX.com so all other
names are inherently suboptimal. I guess these URLs are more useful:

ircs://ve.symlynX.com:9999

https://ve.symlynX.com:34443/PSYC/

Thanks Ben.

Comment 4

[James Ross]

Hmm, I have no idea where this port 9999 lark came from. The registered port is
994. The server I'm on uses 6669 for it. I think we'd have to use 994 for ircs:
URLs, though.

Comment 5

[Justin Turner Arthur]

In my opinion, defaulting to port 994 for the ircs scheme would be advisable for
standards compliance. One reason why you hardly see any IRC networks utilizing
port 994 is because implementors typically shy away from running their IRC
daemons as a super user, which is necessary to listen on port 994 on most BSD
and Unix-like operating systems. Most IRC networks I am on offer SSL on port
9999 primarily because of X-Chat and IRSSI.

Comment 6

[James Ross]

(In reply to comment #5)
> In my opinion, defaulting to port 994 for the ircs scheme would be advisable for
> standards compliance.

Be careful using that as a reason. Did you know the standard irc: port is 194?
I've yet to see *anyone* use anything other than 6667. :)

Comment 7

[Justin Turner Arthur]

(In reply to comment #6)
> Did you know the standard irc: port is 194?
> I've yet to see *anyone* use anything other than 6667. :)

Most interesting, had not caught that. I'm writing up a patch for SSL support
right now; it defaults to port 9999 for the /sslserver command, as that is how
the command works in irssi and x-chat. Should I go ahead and default to that
port for connection initiated by "ircs" URL as well?

Comment 8

[Justin Turner Arthur]

Attachment: Elementary SSL support.

This patch adds elementary SSL support to ChatZilla by making the following
enhancements:
- connection_xpcom.js now has SSL support. An SSL socket is initiated by
passing a special argument to a CBSConnection object's "connect" method. My
implementation for the current Necko library has been tested succesfully, my
implementation for the old Necko library was based on what I could learn from
older .idl's and is untested.
- ChatZilla now responds to "ircs://" URL requests and implements SSL for the
session.
- New "sslserver" command; same syntax as "server" command but forces an SSL
connection.
- "attach" command tolerates ircs:// URLs, but will still assume the irc://
scheme if the scheme is unspecified.
- IRCs URL's and the sslserver command will assume a destination port of 9999
unless otherwise arbitrated by the user.
- SSL support is denoted per CIRCServer object. Note that CIRCNetwork objects
do not have any SSL indicators, hence why known networks that have secure
servers will still read "irc://networkname/" instead of "ircs://networkname/".
- A new network, Serenia, has been added to the initially known networks list
to test SSL support.

The patch is a diff on the 0.9.64e release, but with the files arranged as they
are in the mozilla source under "extensions/irc".

Comment 9

[Chris P. Ross]

Rock on!  Glad to see this...  And, what would be the way to fix your noted:
- SSL support is denoted per CIRCServer object. Note that CIRCNetwork objects
do not have any SSL indicators, hence why known networks that have secure
servers will still read "irc://networkname/" instead of "ircs://networkname/".
?  I consider it suboptimal, at least, for something using SSL to ever represent
itself as "irc://".  But, at least SSL is an option.  :-)
(lol.  And Bugzilla will have to be taught to link-ize "ircs://" links. ;-))

Comment 10

[Justin Turner Arthur]

Attachment: Elementary SSL support (updated)

This patch carries the same effect as the previously submitted with the
following differences:
- Fixed a silly logic bug in my previous patch for the "attach" command.
- Known network objects that contain only SSL-supporting servers now get the
ircs:// scheme when displayed via the "networks" command and when their URL is
retrieved via the "getURL(target)" method of a CIRCNetwork object.

Comment 11

[Justin Turner Arthur]

Attachment: Elementary SSL support (updated again)

This patch addresses review, concerns, and suggestions from rginda and silver
in irc://irc.mozilla.org/chatzilla . Enhancements include the following:
- The getURL method for network objects now returns a scheme based on whether
the currently connected server supports SSL or not. If there is no currently
connected server on the network, then ChatZilla will look to see if all servers
on the Network support SSL, and if they do the method will return the ircs://
scheme.
- Going to an ircs://knownnetworkname/ URL will only attempt to make
connections to the network's servers known to support SSL. This is a slightly
dirty hack as any non-SSL server that ChatZilla ignores during this process
increments the attempted connections count.
- Many schematics including important fixups for prototypes in
chatzilla-service.
- Now includes the necessary locale information for the sslserver command. I
had accidentally left this out of the previous patches. :o
- The sslserver command now appends the port to the stored hostname even if the
port is 9999, but will not store the port if it is 6667. This is to avoid key
confusion in client.networks.

Comment 12

[Chris P. Ross]

Hey there.  Any furthur progress/testing on this code happened lately?  Robert,
does this seem like something you might be able to integrate sometime soon?
Is there a way to build an xpi so I can install this version?  If I check it
out, and apply this patch, what would I have to do to build an XPI that I could
install?
Thanks...

Comment 13

[James Ross]

(In reply to comment #12)
> Hey there.  Any furthur progress/testing on this code happened lately?  Robert,
> does this seem like something you might be able to integrate sometime soon?
> Is there a way to build an xpi so I can install this version?  If I check it
> out, and apply this patch, what would I have to do to build an XPI that I could
> install?

ChatZilla 0.9.64f from http://www.hacksrus.com/~ginda/chatzilla/ has this patch
in it.

Comment 14

[Chris P. Ross]

Changes made in the last version of this patch confuse things.  For example, the
/sslserver command now doesn't retain :6667, but the URI for the channel is
still kept as "ircs://servername/channel".  When you try to open that URL, it
goes to 9999, as that's the default for ircs://.
Similarly, saving the channel as "Open at startup" saves that URL, which then
won't work for the above reason.

Comment 15

[James Ross]

(In reply to comment #14)
> Changes made in the last version of this patch confuse things.  For example, the
> /sslserver command now doesn't retain :6667, but the URI for the channel is
> still kept as "ircs://servername/channel".  When you try to open that URL, it
> goes to 9999, as that's the default for ircs://.
> Similarly, saving the channel as "Open at startup" saves that URL, which then
> won't work for the above reason.

The sslserver command needs to not name secure networks the same as insecure
networks, or there will be problems - that's hwy it was changed. I suspect the
URLs generated by getURL need some tweaking, but I'm not quite sure what the
best solution is currently, as I want the following setup to work with no
visible ports:

Network "foo" defined with 9 servers, 3 secure (port 6669, insecure ones 6667).
irc://foo/* needs to go to any server of the 9.
ircs://foo/* needs to go to any of the 3 secure servers.

Comment 16

[Chris P. Ross]

Well, silver, there are two problems with your comment.  One, ircs:// defaults
to 9999, not 6669.  So, it won't work quite as you describe anyway.
Two, the complaint is not that ircs:// *doesn't* default to 6667, but more that
whatever generates the URL after it's connected doesn't know that.  It trims off
the :6667 as the default, despite still having whatever knowledge it needs to
know that the "protocol" is ircs.  
I've had to manually edit my prefs.js (to add back in the :6667) so that it will
work for me.
you may be right that it's getURL that needs to be tweaked, but I don't know.
Justin?  You following this?

Comment 17

[James Ross]

(In reply to comment #16)
> Well, silver, there are two problems with your comment.  One, ircs:// defaults
> to 9999, not 6669.  So, it won't work quite as you describe anyway.

Wrong. It does work, and should continue too.

> Two, the complaint is not that ircs:// *doesn't* default to 6667, but more that
> whatever generates the URL after it's connected doesn't know that.  It trims off
> the :6667 as the default, despite still having whatever knowledge it needs to
> know that the "protocol" is ircs.  

Yes and no, see my remark about getURL needing fixing.

The problem is that for a properly defined network, the port is useless when
using the network name - the network server list knows the ports that get used.
One way or another, the network's getURL needs to know it's only being a wrapper
for a server, and act differently (i.e. always include the port if it != the
protocol's default). I think the fix needs to basically change
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/irc/js/lib/irc.js&mark=119-121#116
so it either doesn't care about the port at all, then make sure
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/irc/js/lib/irc.js&mark=357#350
does check against the correct (i.e. protocol dependant) port.

Comment 18

[James Ross]

ChatZilla 0.9.65 has landed. I believe this bug is fixed now; if it is not
fixed, please re-open the bug stating why you don't believe it's fixed.

Until an XPI is made of 0.9.65, 0.9.64g will do as for testing as it is
basically the same codebase.

Comment 19

[Chris P. Ross]

The bug I commented on in 0.9.64f still exists in 0.9.64g.  Should I open a new
bug for tracking that, as this one clearly doesn't apply?

Comment 20

[Samuel Sieb]

Comment on attachment 154675 [details] [diff] [review]
Elementary SSL support (updated again)

Checked in with bug 255081.

Comment 21

[Samuel Sieb]

Yes, please file a new bug.