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: NNPS / TCP port 433 (Russ Allbery)
2. Re: NNPS / TCP port 433 (Julien ?LIE)
3. Re: NNTPS pointers / NNSP (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Oct 2021 20:08:50 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: NNPS / TCP port 433
Message-ID: <[email protected]>
Content-Type: text/plain
Grant Taylor <[email protected]> writes:
> Can anyone say with any authority if the NNPS / TCP port 433 is clear
> text like the NNTP / TCP port 119 or implicitly encrypted like the NNTPS
> / TCP port 563?
433 is generally not encrypted. The S in NNPS is for "server" not
"security." 433 is the port generally used by servers that want to
separate server-to-server connections on a separate port from
reader-to-server connections (because, among other reasons, spawning the
reader server from the transit server is unnecessary overhead).
> This second statement makes me think that the only difference between
> TCP ports 119 and 433 is their intended purpose.
Correct.
> This seems reminiscent of SMTP's MTA port 25 and MSA port 587, both of
> which are unencrypted / explicit encryption via STARTTLS.
Correct.
--
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: 2
Date: Thu, 28 Oct 2021 09:24:37 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: NNPS / TCP port 433
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Grant,
> IANA has the following three ports registered for NNTP:
>
> NNTP? - 119 - RFC 3977 - unencrypted & explicit encryption via STARTTLS
> NNSP? - 433 - RFC 3977 - unspecified
> NNTPS - 563 - RFC 4642 - implicit encryption via TLS
And also a less known 532 port:
netnews - 532 - readnews
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=10
Still reserved for Netnews, but no longer used nowadays (it used to by a
Microsoft reader client decades ago, but I have no more information).
> RFC 3977 has "STARTTLS" but discusses it on TCP port 119.
Because it is more detailed in RFC 4642 (defining STARTTLS) which was
updated by RFC 8143 (discouraging STARTTLS, in benefit to implicit TLS
connections, amongst other things).
> RFC 3977 also states:??? The official TCP port for the NNTP service is
> 119.? However, if a host wishes to offer separate servers for transit
> and reading clients, port 433 SHOULD be used for the transit server and
> 119 for the reading server.
>
> This second statement makes me think that the only difference between
> TCP ports 119 and 433 is their intended purpose.? This seems reminiscent
> of SMTP's MTA port 25 and MSA port 587, both of which are unencrypted /
> explicit encryption via STARTTLS.
>
> So ... what should the NNSP / TCP port 433 be?? My inclination is that
> NNSP / TCP port 433 is identical to NNTP / TCP port 119.
>
> What say you?
That's right, as Russ answered earlier.
Nonetheless, I have another question, now that implicit TLS is the
preferred way to use TLS.
- For news servers with both transit and reader facilities on the same
daemon, port 119 can be used unencrypted, and port 563 with TLS (even
for the transit facility by the way).
Port 433 remains unencrypted for the transit facility, if a separate
port is needed.
- For mode-switching news servers like INN, port 119 can be used
unencrypted for transit and reader facilities, and port 563 with TLS for
reader.
Port 433 remains unencrypted for the transit facility. And then the
question is: what should be done for transit with implicit TLS? We
cannot run 2 innd instances (one for unencrypted connections, another
one for implicit TLS). Wouldn't we need a 4th port for that?
Or say port 433 is for implicit TLS for mode-switching servers? (But
then, separating unencrypted transit and reader cannot be done.)
--
Julien ?LIE
??Ta remise sur pied lui a fait perdre la t?te?!?? (Ast?rix)
------------------------------
Message: 3
Date: Thu, 28 Oct 2021 12:34:42 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers / NNSP
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Grant,
>> It's worth adding that information in our FAQ if you're OK with that.
>
> Agreed.? Yes, I'm okay with it.
>
> Though I might suggest holding off for a little while longer.? I have
> managed to use iproute2 policy based routing and stunnel (no iptables
> required) to get INN to act as a client to a TLS enabled NNSP (NNTPS)
> server.
Oh, that's great.
With that setup, is it possible to run only 1 instance of innd,
accepting both unencrypted connections on port 119 and implicit TLS
connections on port 433?
Do you disallow readers? (I am unsure an nnrpd spawned by innd behind
iproute2/stunnel will see that the connection is already encrypted; it
may advertise STARTTLS whereas I think it should not.)
> I'd like to spend some more time working on things, or discuss what I've
> done with someone else interested in reproducing what I've done.? Use
> that effort to make the directions consistent.
You could also discuss that in news.software.nntp; maybe other people
are willing to experiment too.
> E.g. is iptables connection marking required or not?? --? iptables or
> fancier iproute2 PBR rules achieve the same goal.? Also, compare and
> contrast stunnel with socat.? The latter of the two sets are how I did
> the client portion.
Well, I'm not a network expert but I am interested in making TLS work
too for article feeding.
>> I can reference the iptables commands you found out.? Any other
>> configuration to mention?
>
> Ya.? More details on the client and unifying of the server (previous
> message) and client (yet to be fully described) methods.
Also, do you have a working TLS configuration for outgoing feeds
(innfeed, innxmit)?
Can TLS support be similarly added to programs like rnews, inews,
pullnews, nntpsend, etc. with iproute2/stunnel or like?
> But, yes, the spirit is sharing this so that others can utilize it if
> they so choose.
Greatly appreciated!
--
Julien ?LIE
??Il y a deux sortes de justice?: vous avez l'avocat qui conna?t bien la
loi, et l'avocat qui conna?t bien le juge?!?? (Coluche)
------------------------------
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 15
********************************************
