STARTTLS for erc

STARTTLS for erc

[Lars Magne Ingebrigtsen]

I thought I had finished my TLS work for Emacs 24, but then I remembered
erc.  :-)

Apparently the IRC protocol now supports STARTTLS, but I can't seem to
find a reachable IRC server that supports it?  But I may be
misunderstanding the IRC protocol, which I know nothing about.

Anybody know of a public one that has STARTTLS that I can test with?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: STARTTLS for erc

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Anybody know of a public one that has STARTTLS that I can test with?

I googled a bit, and I found a few public ones.

However, none of the ones I found seemed to support "CAP LS", as
documented here:

http://wiki.inspircd.org/STARTTLS_Documentation

So you have to know in advance that the server supports STARTTLS or not,
which is kinda, er, stupid.

However.  After logging in, the servers seem to output a capability list
of sort during the login greeting.  But at that point it's too late to
get STARTTLS support going.  *sigh*

So erc could close the connection, and then restart it, now with
STARTTLS.  But ircd logins are notoriously slow, so that's totally
icky.

So perhaps something like the following would work?  If erc sees that
the server supports STARTTLS, then it will store this data for future
reference.  The next login will look up this data, and if the server
supports STARTTLS, it'll do STARTTLS.

But where would this per-server data be stored?

And this would be somewhat brittle.  If a server goes from one type
(supporting STARTTLS) to another (not supporting STARTTLS), it might
mean that the next login might fail.

However however, the IRC servers just seem to output no data whatsoever
on unknown commands, so perhaps a timeout on the STARTTLS for two
seconds (or something) would be sufficient to handle that case...

In any case, it all feels somewhat tacky and hacky.

Anybody have better ideas?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: STARTTLS for erc

[Ted Zlatanov]

On Thu, 23 Jun 2011 02:54:52 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> So you have to know in advance that the server supports STARTTLS or not,
LMI> which is kinda, er, stupid.

LMI> However.  After logging in, the servers seem to output a capability list
LMI> of sort during the login greeting.  But at that point it's too late to
LMI> get STARTTLS support going.  *sigh*

LMI> So erc could close the connection, and then restart it, now with
LMI> STARTTLS.  But ircd logins are notoriously slow, so that's totally
LMI> icky.

I'd make "no" the default because that STARTTLS support is rare.

LMI> So perhaps something like the following would work?  If erc sees that
LMI> the server supports STARTTLS, then it will store this data for future
LMI> reference.  The next login will look up this data, and if the server
LMI> supports STARTTLS, it'll do STARTTLS.

LMI> But where would this per-server data be stored?

It could be in auth-source, together with the user name and password
which I am supposed to add eventually (I posted a patch on the
emacs-bugs list a month or two ago and haven't had the time to apply it
and test it).  If you want, go ahead and use that patch.  I would make
the STARTTLS preference a "tls" key with a "yes/no/opportunistic" value,
with "no" or missing meaning no STARTTLS should be done.

Otherwise you could store the STARTTLS preference in the server
definition of ERC itself.

LMI> And this would be somewhat brittle.  If a server goes from one type
LMI> (supporting STARTTLS) to another (not supporting STARTTLS), it might
LMI> mean that the next login might fail.

I think that's really rare, unless you're hitting a DNS round-robin.

Ted

Re: STARTTLS for erc

[Antoine Levitt]

23/06/11 14:24, Ted Zlatanov
> LMI> And this would be somewhat brittle.  If a server goes from one type
> LMI> (supporting STARTTLS) to another (not supporting STARTTLS), it might
> LMI> mean that the next login might fail.
>
> I think that's really rare, unless you're hitting a DNS round-robin.

That's not so rare, the big IRC servers (for instance, irc.freenode.org)
redirect to subservers (like hitchcock.freenode.net) which might or
might not support TLS. Unless I'm misunderstanding what you're talking
about?

If it's not possible to have a clean opportunistic STARTTLS for ERC,
it's probably best to just leave it alone IMHO. Storing a flag to
connect via TLS next time just seems too hackish, and the benefits are
minimal. Also, TLS connections to IRC servers take ages, so it's
probably not a good idea to turn this on by default, which means users
would have to turn it on manually, and they can just as well call
erc-tls if they know the server supports it.

Re: STARTTLS for erc

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

On Thu, Jun 23 2011, Lars Magne Ingebrigtsen wrote:

> So you have to know in advance that the server supports STARTTLS or not,
> which is kinda, er, stupid.

Yes, but since TLS in IRC servers is just not wide spread, I think I
would not spend too much time thinking about it for now. But I'm glad
you did! :-)
You should let it be a server "parameter", like SSL. It'd be enough
IMHO, until IRC over TLS spreads. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: STARTTLS for erc

[Lars Magne Ingebrigtsen]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> If it's not possible to have a clean opportunistic STARTTLS for ERC,
> it's probably best to just leave it alone IMHO.

Yeah, I'm going to skip any further work on this for the time being...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: STARTTLS for erc

[Stefan Monnier]

> So erc could close the connection, and then restart it, now with
> STARTTLS.  But ircd logins are notoriously slow, so that's
> totally icky.

A protocol where sending a password is "necessary" is basically
incompatible with STARTTLS anyway (otherwise, it's trivial to force the
password to be sent in the clear).  So TLS support (which I added to
rcirc recently) seems quite sufficient for ERC.


        Stefan

Re: STARTTLS for erc

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> A protocol where sending a password is "necessary" is basically
> incompatible with STARTTLS anyway (otherwise, it's trivial to force the
> password to be sent in the clear).

I don't quite follow you.  With pop3, for instance, a password is
necessary, and STARTTLS works perfectly fine for pop3...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: STARTTLS for erc

[Stefan Monnier]

>> A protocol where sending a password is "necessary" is basically
>> incompatible with STARTTLS anyway (otherwise, it's trivial to force the
>> password to be sent in the clear).
> I don't quite follow you.  With pop3, for instance, a password is
> necessary, and STARTTLS works perfectly fine for pop3...

IIUC STARTTLS refers to "opportunistic encryption", which I find
incompatible with passwords since the opportunistic part means that if
the opportunity is absent, you end up sending passwords in the clear.
But maybe you had something else in mind for STARTTLS.


        Stefan

Re: STARTTLS for erc

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> IIUC STARTTLS refers to "opportunistic encryption", which I find
> incompatible with passwords since the opportunistic part means that if
> the opportunity is absent, you end up sending passwords in the clear.
> But maybe you had something else in mind for STARTTLS.

You can require that STARTTLS is used, and fail if it's not offered.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/