* STARTTLS for erc
@ 2011-06-22 23:55 Lars Magne Ingebrigtsen
2011-06-23 0:54 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 10+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-06-22 23:55 UTC (permalink / raw
To: emacs-devel
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/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: STARTTLS for erc
2011-06-22 23:55 STARTTLS for erc Lars Magne Ingebrigtsen
@ 2011-06-23 0:54 ` Lars Magne Ingebrigtsen
2011-06-23 12:24 ` Ted Zlatanov
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-06-23 0:54 UTC (permalink / raw
To: emacs-devel; +Cc: erc-discuss
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/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: STARTTLS for erc
2011-06-23 0:54 ` Lars Magne Ingebrigtsen
@ 2011-06-23 12:24 ` Ted Zlatanov
2011-06-23 13:44 ` Antoine Levitt
2011-06-23 13:49 ` Julien Danjou
2011-06-25 13:10 ` Stefan Monnier
2 siblings, 1 reply; 10+ messages in thread
From: Ted Zlatanov @ 2011-06-23 12:24 UTC (permalink / raw
To: erc-discuss; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: STARTTLS for erc
2011-06-23 12:24 ` Ted Zlatanov
@ 2011-06-23 13:44 ` Antoine Levitt
2011-06-24 14:20 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 10+ messages in thread
From: Antoine Levitt @ 2011-06-23 13:44 UTC (permalink / raw
To: erc-discuss; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: STARTTLS for erc
2011-06-23 0:54 ` Lars Magne Ingebrigtsen
2011-06-23 12:24 ` Ted Zlatanov
@ 2011-06-23 13:49 ` Julien Danjou
2011-06-25 13:10 ` Stefan Monnier
2 siblings, 0 replies; 10+ messages in thread
From: Julien Danjou @ 2011-06-23 13:49 UTC (permalink / raw
To: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: STARTTLS for erc
2011-06-23 0:54 ` Lars Magne Ingebrigtsen
2011-06-23 12:24 ` Ted Zlatanov
2011-06-23 13:49 ` Julien Danjou
@ 2011-06-25 13:10 ` Stefan Monnier
2011-06-25 17:04 ` Lars Magne Ingebrigtsen
2 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2011-06-25 13:10 UTC (permalink / raw
To: emacs-devel
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: STARTTLS for erc
2011-06-25 13:10 ` Stefan Monnier
@ 2011-06-25 17:04 ` Lars Magne Ingebrigtsen
2011-06-27 1:07 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-06-25 17:04 UTC (permalink / raw
To: emacs-devel
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/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: STARTTLS for erc
2011-06-25 17:04 ` Lars Magne Ingebrigtsen
@ 2011-06-27 1:07 ` Stefan Monnier
2011-06-27 10:25 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2011-06-27 1:07 UTC (permalink / raw
To: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-06-27 10:25 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-22 23:55 STARTTLS for erc Lars Magne Ingebrigtsen
2011-06-23 0:54 ` Lars Magne Ingebrigtsen
2011-06-23 12:24 ` Ted Zlatanov
2011-06-23 13:44 ` Antoine Levitt
2011-06-24 14:20 ` Lars Magne Ingebrigtsen
2011-06-23 13:49 ` Julien Danjou
2011-06-25 13:10 ` Stefan Monnier
2011-06-25 17:04 ` Lars Magne Ingebrigtsen
2011-06-27 1:07 ` Stefan Monnier
2011-06-27 10:25 ` Lars Magne Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.