(START)TLS between servers?

Russ Allbery rra at stanford.edu
Sun Apr 3 22:23:25 UTC 2011


Julien ÉLIE <julien at trigofacile.com> writes:

> Well, that is not straight-forward to implement.

> When you say that INN supports STARTTLS, it is in fact nnrpd that
> supports it (and acting as a "TLS server").

> At least two other programs need being modified:  innd (acting as a TLS
> server, like nnrpd) and innfeed (acting as a TLS client).  When I say
> "at least", it is because one may want to also use TLS with tinyleaf,
> pullnews, actsync, innxmit, inews, etc.

nnrpd was very easy to add TLS support to because every connection to
nnrpd has its own separate process.  Both innd and innfeed make heavy use
of non-blocking I/O.  The TLS libraries do have some support for that, but
my experience is that it's very difficult to get it to work properly.
(It's easier in GnuTLS than it is in OpenSSL, but currently the rest of
the TLS code in INN is all based on OpenSSL and OpenSSL is more widely
interoperable and more commonly used.)

IIRC, the NSS libraries also have better support for non-blocking I/O, but
that's yet another completely different API.

The basic problem is that innd and innfeed both are calling select
directly and expect to have a lot of knowledge of whether there's network
data pending in either direction, exactly how much data was sent, and
similar things.  The additional layer of TLS has a tendency to obscure
some of that and require careful handling to not block or lose data.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.



More information about the inn-workers mailing list