Send inn-workers mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."


Today's Topics:

   1. Re: NNTPS pointers (Richard Kettlewell)
   2. Re: NNTPS pointers (Grant Taylor)
   3. Re: NNTPS pointers (Julien ?LIE)
   4. Re: NNTPS pointers (Julien ?LIE)
   5. Re: NNTPS pointers (Russ Allbery)
   6. Re: NNTPS pointers (Grant Taylor)


----------------------------------------------------------------------

Message: 1
Date: Tue, 19 Oct 2021 20:24:51 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

On 18/10/2021 20:44, Grant Taylor wrote:
> Does anyone have quick pointers how to get INN to support NNTPS for 
> server-to-server peering?
> 
> I've got NNTPS working for NNRP but now I'm trying to add it for NNTP.
> 
> I took a swing at it a couple of weeks ago but didn't make much 
> progress.? I'd like to avoid hacks like stunnel if at all possible as I 
> want INN to see the remote peer's real IP address.

AFAICS there's no support for this in innd as it stands today - only 
nnrpd knows about TLS.

ttfn/rjk


------------------------------

Message: 2
Date: Tue, 19 Oct 2021 15:11:20 -0600
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 10/19/21 1:24 PM, Richard Kettlewell wrote:
> AFAICS there's no support for this in innd as it stands today - only 
> nnrpd knows about TLS.

~grump~

Okay.  That would be why I couldn't find anything.  :-/

So ... how about STARTTLS support on port 119?

Thank you for the response Richard.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: 
<https://lists.isc.org/pipermail/inn-workers/attachments/20211019/4efaf7ad/attachment-0001.bin>

------------------------------

Message: 3
Date: Tue, 19 Oct 2021 23:36:39 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Grant,

>> AFAICS there's no support for this in innd as it stands today - only 
>> nnrpd knows about TLS.
> 
> ~grump~
> 
> Okay.? That would be why I couldn't find anything.? :-/

Yep!
Usually, either IPsec or stunnel with TCP wrappers is used for innd.


> So ... how about STARTTLS support on port 119?

Note that STARTTLS is now discouraged because of possible 
man-in-the-middle attacks.  Implementations SHOULD use implicit TLS on 
port 563 (see RFC 8143).

It is tricky to implement in innd, with its channels...
Same thing for COMPRESS, which would be useful to have in transit mode.

Patch welcome of course :-)

-- 
Julien ?LIE

??Il est difficile de discuter avec des gens qui ne peuvent pas entendre
   et qui ne veulent pas entendre.?? (Julius Welhausen)


------------------------------

Message: 4
Date: Tue, 19 Oct 2021 23:45:20 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Grant,

Do you know news servers implementing TLS for transit?

If that's the case, as nnrpd has TLS support and implements IHAVE, maybe 
you could try to start 2 instances of nnrpd (one listening to port 563 
for readers, and another to port 433 for instance).  Remote news servers 
may send you articles to port 433 using TLS and IHAVE.
I believe it would work.  Yet, not as fast as innd would, though.

And innfeed does not implement TLS either...

-- 
Julien ?LIE

??Il est difficile de discuter avec des gens qui ne peuvent pas entendre
   et qui ne veulent pas entendre.?? (Julius Welhausen)


------------------------------

Message: 5
Date: Tue, 19 Oct 2021 14:57:24 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8

Julien ?LIE <[email protected]> writes:

> It is tricky to implement in innd, with its channels...
> Same thing for COMPRESS, which would be useful to have in transit mode.

I've probably said this at some point before, but the core innd I/O loop
is basically a partial (but very battle-tested) implementation of
libevent built on the lowest-common-denominator system calls and therefore
slower and less efficient.

It's yet another huge project, but replacing the innd core I/O loop with
actual libevent would not only give us TLS for essentially free and
probably substantial performance improvements given that libevent would
use epoll/kqueue (and presumably io_ring at some point, although it
doesn't look like they've implemented that yet), it would also give us DNS
resolution in the event loop, which would eliminate the long-standing
"periodically reload incoming.conf because INN doesn't honor DNS TTLs"
problem.

I've used libevent for another project and it's really nice to work with.
It uses a similar callback model to how INN already works.

-- 
Russ Allbery ([email protected])             <https://www.eyrie.org/~eagle/>

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


------------------------------

Message: 6
Date: Tue, 19 Oct 2021 15:58:18 -0600
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 10/19/21 3:36 PM, Julien ?LIE wrote:
> Hi Grant,

Hi Julien,

> Yep!

;-)

> Usually, either IPsec or stunnel with TCP wrappers is used for innd.

ACK

Would you please elaborate on what you mean by "stunnel with TCP 
wrappers"?  As in what is TCP wrappers doing to modify stunnel?  Is it 
just allowing / blocking access?  If so, I'd think that a firewall could 
do the same thing.

> Note that STARTTLS is now discouraged because of possible 
> man-in-the-middle attacks.? Implementations SHOULD use implicit TLS on 
> port 563 (see RFC 8143).

Sure.  Implicit TLS would be nice for NNTP (server-to-server).  But, I 
think that STARTTLS is the lesser of the evils (sub-optimal security vs 
no security).

> It is tricky to implement in innd, with its channels...
> Same thing for COMPRESS, which would be useful to have in transit mode.

*nod*

> Patch welcome of course :-)

I'm not personally qualified to do write a patch.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: 
<https://lists.isc.org/pipermail/inn-workers/attachments/20211019/0b9341c8/attachment.bin>

------------------------------

Subject: Digest Footer

_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers


------------------------------

End of inn-workers Digest, Vol 134, Issue 8
*******************************************

Reply via email to