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 (Grant Taylor)
2. Re: NNTPS pointers / NNSP (Grant Taylor)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Oct 2021 12:04:35 -0600
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: NNPS / TCP port 433
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 10/28/21 1:24 AM, Julien ?LIE wrote:
> Hi Grant,
Hi Julien,
> 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).
O.o???
I searched IANA's DB for "NNTP" and came up with the three ports. I'm
sort of glad that netnews / readnews didn't come up because it sounds
like more of a Microsoft proprietary thing than it does an open standard
used by anything outside of the Microsoft ecosystem. So, baring any
encouragement to mess with it, I'm going to ignore as opposed to being
ignorant of it.
But thank you for the pointer to it. #TIL....
> 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).
ACK
The powers that be ~> industry seems to keep waffling back and forth on
explicit vs implicit port encryption. As I understand it, it started
with separate implicit ports (a port was either encrypted exclusive or
not) because STARTTLS was not yet a thing. Then it went to combined
explicit ports (because you explicitly stated if you wanted encryption).
And now we seem to be going back to separate implicit ports in an
attempt to avoid downgrade attacks on explicit ports.
I'll have to check out RFC 8143 to see what I'm missing. Thank you for
the pointer.
> That's right, as Russ answered earlier.
ACK
> 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).
ACK
> Port 433 remains unencrypted for the transit facility, if a separate
> port is needed.
I would expect that the NNSP port 433 could be explicit encrypted via
STARTTLS much like NNTP port 119.
> - 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.
ACK
> Port 433 remains unencrypted for the transit facility.
I'm not sure. (See above comment.)
> And then the question is: what should be done for transit with implicit
> TLS?
I'm of the mind that we as the NNTP using community make a server rule
-- a la. "house rule" -- that the NNSP port 433 be implicitly TLS
protected much like NNTPS port 563 is. -- I say this because the
current industry best practices are to use implicit encryption. So if
the NNSP port 433 is largely unused and we want to start making use of
it, why not impose implicit encryption.
Have NNTP port 119 be legacy mixed use, NNSP port 433 be implicit
encryption for server-to-server, and NNTPS port 563 be implicit
encryption for client-to-server?
For the rest of this message, I'm assuming the following:
NNTP - 119 - c2s / s2s - unencrypted or explicit encryption
NNSP - 433 - s2s - implicit encryption
NNTPS - 563 - c2s - implicit encryption
Consider this a request for comments on the above proposal.
> We cannot run 2 innd instances (one for unencrypted connections,
> another one for implicit TLS).
I'm not yet convinced that we need a 2nd instance of INN(d) running.
Instead, I think that what I'm experimenting with in the NNTPS pointers
thread could be used to provide the three ports listed above via one
instance of INN(d).
> Wouldn't we need a 4th port for that?
I'm not convinced that we do need a 4th port. Sure, one could be
defined for uniformity. But I think doing so would be questionable in
these days of opportunistic encryption ~> encrypt everything possible.
> Or say port 433 is for implicit TLS for mode-switching servers?
As indicated above, I'm inclined to say that NNSP/433 uses implicit TLS
protection.
> (But then, separating unencrypted transit and reader cannot be done.)
I'm content separating transit and reader at the client side; NNSP/433
and NNTPS/563 respectively. I don't see an actual /need/ to be able to
have encrypted transport and reader on the same port.
On the off hand chance that I wanted encrypted transport & reader on the
same port, I could leverage a different aspect of the NNTPS pointers
thread to differentiate known transport peers from readers via remote IP
addresses connecting to the local server. Or said another way, assume
that $PORT is mode reader by default and only transport for known remote
IPs.
P.S. Russ, thank you for your reply. I rolled my responses to your
message into this longer message.
--
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/20211028/a61e969a/attachment-0001.bin>
------------------------------
Message: 2
Date: Thu, 28 Oct 2021 12:14:28 -0600
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers / NNSP
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 10/28/21 4:34 AM, Julien ?LIE wrote:
> Hi Grant,
Hi Julien,
> 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?
Yes, I do believe so. I alluded to doing exactly that in my recent
reply to the NNPS / TCP port 433 thread.
> Do you disallow readers?
Much of my testing has been on HTTP/80 vs HTTPS/443 as that's what I
spend more time speaking. But I have every single expectation that the
same methodology can be directly applied to NNTP/119, NNPS/433, and
NNTPS/563.
> (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.)
Yes, that is a legitimate concern. Though I don't see any actual harm
in advertising STARTTLS to a well behaved client that's communicating
via an encrypted channel. Admittedly this may tickle some bugs in less
well behaved clients. However, I'm going after least effort to allow
implicit TLS encryption with INN(d) as it exists today. So some
compromises like this may sneak through.
> You could also discuss that in news.software.nntp; maybe other people
> are willing to experiment too.
Good idea.
> Well, I'm not a network expert but I am interested in making TLS work
> too for article feeding.
:-)
> Also, do you have a working TLS configuration for outgoing feeds
> (innfeed, innxmit)?
One of my goals has been to make this encryption / decryption as
transparent as possible to INN(d) et al. Meaning that it is done
completely outside of them. Thus hopefully they will inherit the
external assistance.
If you're familiar with the concept, think mid-span PoE injectors
connected to a non-PoE switch. ;-)
Admittedly, the motivation for this comes from knowledge of traditional
stunnel use and AT-TLS on IBM z/OS mainframes where TLS encryption can
be added / removed outside / independently of the actual running service
and the desire to have similar functionality on Linux.
> Can TLS support be similarly added to programs like rnews, inews,
> pullnews, nntpsend, etc. with iproute2/stunnel or like?
I expect so. I'm ultimately keying off of remote IP and remote port
pairs. As such, I expect that INN(d) et al. will remain configured just
like they are today and will simply have something outside of them do
the TLS helper function, mid-span. }:-)
> Greatly appreciated!
I appreciate the interactive feedback. :-D
--
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/20211028/9af6f55b/attachment-0001.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 16
********************************************
