Maybe the news server log doesn't even know what outgoing port I used? Maybe it does?

[Gunther F]

I'm a user. Not an admin. I care about privacy. This is about that.

I'm thinking about trying to randomize the outgoing port I use.
To minimize the chance of fingerprinting (perhaps even by the MITM).

But maybe the news server doesn't even know what outgoing port I used?
Maybe they do?

So here's my basic networking question related to news servers.

When I post to any given news server using news.server.net:port,
does the news server log know exactly what port I'm using each time?

[Adam W.]

Gunther F <grun...@nospam.edu> wrote:

> But maybe the news server doesn't even know what outgoing port I used?
> Maybe they do?

They do. They might log it or not. Assume they do log it.

[Gunther F]

"Adam W." <gof-cut-...@cut-this-chmurka.net.invalid> said:

>> But maybe the news server doesn't even know what outgoing port I used?
>> Maybe they do?
>
> They do. They might log it or not. Assume they do log it.

Thank you for that information as the outgoing port doesn't usually change
and worse, it's a specific large number (1024 to 65K I think), isn't it?

I think WireShark will get the outgoing port number but is there an
easier way to get that outgoing port number the newsreader chooses?

Do newsreaders normally choose random ports or the same port?
I appreciate your help so please don't feel required to answer that.

It's OK if you don't answer this as I already got the answer I asked
for, which means I need to delve further to find out what port is used.

And then how to change it to foil fingerprinting (perhaps by the MITM).

[Scott Dorsey]

Gunther F <grun...@nospam.edu> wrote:
>I'm a user. Not an admin. I care about privacy. This is about that.
>
>I'm thinking about trying to randomize the outgoing port I use.
>To minimize the chance of fingerprinting (perhaps even by the MITM).

The problem is that the server is listening on tcp/119. You can use any
port you want, but if you use a port other than tcp/119 the server will
not talk to you. Well, it won't talk nntp, that is. Maybe it will offer
something else with some other protocol.

>But maybe the news server doesn't even know what outgoing port I used?
>Maybe they do?
>
>So here's my basic networking question related to news servers.
>
>When I post to any given news server using news.server.net:port,
>does the news server log know exactly what port I'm using each time?

Yes, because it is always tcp/119 unless the server has specifically be
configured to use something else.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[immibis]

On 1/10/24 01:05, Gunther F wrote:
> "Adam W." <gof-cut-...@cut-this-chmurka.net.invalid> said:
>
>>> But maybe the news server doesn't even know what outgoing port I used?
>>> Maybe they do?
>>
>> They do. They might log it or not. Assume they do log it.
>
> Thank you for that information as the outgoing port doesn't usually change
> and worse, it's a specific large number (1024 to 65K I think), isn't it?

Outgoing ports are normally randomized for every connection.
Your news server can identify you better by IP address.
If you're *posting*, your news server certainly knows who you are, since
most of them don't provide fully anonymous accounts, since they would
quickly be saturated with spam.

[Grant Taylor]

On 1/9/24 18:05, Gunther F wrote:
> Thank you for that information as the outgoing port doesn't usually
> change and worse, it's a specific large number (1024 to 65K I think),
> isn't it?

The /destination/ IP and port almost certainly won't change when talking
to the same news server / configuration. (Different news servers may
use a different configuration.)

The /source/ IP /may/ change based on various criteria. The /source/
/port/ almost certainly will change.

Ports 1-1024 are considered reserved, and by extension a bit more
secure, in Unix (and others based therefrom) TCP/IP stack. Ports
1024-65535 are considered ephemeral.

N.B. the security aspect comes from needing root (or comparable)
privileges to bind to a port up to 1024. Hence if root was involved in
starting the daemon, chances are decent that the daemon is supposed to
be there. Ports 1025 and above are free game and can be bound to by
anyone as long as the port + IP pair aren't in use.

Since the /destination/ IP and port is fixed, and the /source/ IP is
largely fixed, the only thing that can easily change is the /source/ port.

Connections are defined by the source IP, source port, destination IP,
and destination port.

So in order to avoid -- what I'll simplify as -- race conditions with a
connection being re-used, it is convention to change the source port for
each connection.

How this change is done is per OS / per kernel / per TCP/IP stack
implementation.

> I think WireShark will get the outgoing port number but is there an
> easier way to get that outgoing port number the newsreader chooses?

netstat will likely provide the information on most operating systems.

> Do newsreaders normally choose random ports or the same port?

Most TCP/IP programs ask the TCP/IP stack (or kernel hosting it) to
establish the connection and don't really know (though they could find
out) or care what the source IP & port are as long as the TCP/IP stack
(kernel) establishes the connection on their behalf.

Think about sending a letter through the postal service. You probably
don't care about what outgoing mailbox you drop your letter into,
instead favoring the one that's the most convenient for you. You do
care that the postal service gets the letter to the destination that you
specify. What's more is that you likely don't care what route the
postal service takes to get your letter from source to destination as
long as it gets there in a timely manner.

> I appreciate your help so please don't feel required to answer that.

You are asking good questions. Though your questions should be covered
in any worthwhile introduction to TCP/IP. I've long suggested the old
Linux Documentation Project's NET-3 HowTo which I read ~25 years ago.
The basics haven't changed. Most things are built on top if them.

I suspect that any such introduction / tutorial will answer many
questions that I've seen you ask and likely some that I've not yet seen
you ask but are associated.

> It's OK if you don't answer this as I already got the answer I asked
> for, which means I need to delve further to find out what port is used.

I'm always happy to have polite discussions and try to answer questions
and / or learn from others.

However I will counter with a question:

Q: Why do you feel the desire to know what your source port is? --
What difference will it make? What, if anything, will you do differently?

> And then how to change it to foil fingerprinting (perhaps by the MITM).

The source port has little to do with fingerprinting. There are many
other things that can help fingerprint the OS. But fingerprinting the
OS is a far cry from fingerprinting your computer, much less you as a
person.

Remember, the more different you are from others, the more unique that
makes you. With this in mind, being as common as possible means that
you have more people that you can hide in.



--
Grant. . . .

[Marco Moock]

Am 10.01.2024 um 00:05:31 Uhr schrieb Gunther F:

> I think WireShark will get the outgoing port number but is there an
> easier way to get that outgoing port number the newsreader chooses?

It needs to be configures in the newsreader (I don't know one that
offers that) because it opens the socket.

> Do newsreaders normally choose random ports or the same port?

They choose random port between 49152 and 65535 that is free.

You can't obfuscate that port from the news server because it is
relevant for the communication.

[Richard Kettlewell]

Gunther F <grun...@nospam.edu> writes:
> I'm a user. Not an admin. I care about privacy. This is about that.
>
> I'm thinking about trying to randomize the outgoing port I use.
> To minimize the chance of fingerprinting (perhaps even by the MITM).

By fingerprintering I assume you mean the ability of someone monitoring
network traffic to distinguish your connections from anyone else’s.

Tinkering with source port choice is quite unlikely to reduce it. Indeed
it may _increase_ the possibility of fingerprinting: if you use
something other than your platform’s normal source port choice then you
are distinguishable from all other users of the same platform.

> But maybe the news server doesn't even know what outgoing port I used?
> Maybe they do?

It does know.

> So here's my basic networking question related to news servers.
>
> When I post to any given news server using news.server.net:port,
> does the news server log know exactly what port I'm using each time?

Depends on implementation.

--
https://www.greenend.org.uk/rjk/

[Gunther F]

Grant Taylor <gta...@tnetconsulting.net> said:

> Think about sending a letter through the postal service. You probably
> don't care about what outgoing mailbox you drop your letter into,
> instead favoring the one that's the most convenient for you. You do
> care that the postal service gets the letter to the destination that you
> specify. What's more is that you likely don't care what route the
> postal service takes to get your letter from source to destination as
> long as it gets there in a timely manner.

But what if you sent a letter from the same post office for years,
always with the same envelope & handwriting & other identifying bits?

If you're using an old newsreader (and many people are) then you're
probably required to add something like Stunnel to do the encryption.
https://www.stunnel.org/downloads.html

Therein lies the issue I'm trying to better understand, as a user.
When you're using Stunnel you have to set up a permanent outgoing port.

Isn't that static port (which can remain unchanged for years) something
that a MITM (or an audit of the server logs) can use to fingerprint you?

Of course, you could manually edit the outgoing port inside the old
newsreader and correspondingly edit the outgoing port inside of the
stunnel.conf file, but you aren't likely to do that since there's no easy
way to randomize the outgoing port in most newsreaders nor in Stunnel.

Hence you're likely to keep that outgoing port static, perhaps for years.

For example, assume in the old newsreader, you've set the server:port as
Newsreader server = 127.0.0.1
Newsreader port = 49152

Then, in the stunnel.conf file you must match to the same outgoing port.
[EternalSept]
client = yes
accept = 127.0.0.1:49152
connect = news.eternal-september.org:563
verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.eternal-september.org
OCSPaia = yes

My question is whether a MITM (or an audit of the server logs) will show
all your posts as having the same outgoing port, perhaps for years on end?

If so, to prevent fingerprinting, should we randomize the outgoing port?

[Gunther F]

Richard Kettlewell <inv...@invalid.invalid> said:

>> But maybe the news server doesn't even know what outgoing port I used?
>> Maybe they do?
>
> It does know.

Thank you for explaining that the outgoing port is known to the server.
Hence, it can be grep'd for in a future audit of that server's logs.

But is that outgoing port ALSO known to a MITM in real time?

Since your communication to the server is encrypted, I would expect that
outgoing port to ALSO be encrypted such that a MITM wouldn't see it.

But is that outgoing port encrypted such that only the server sees it?
Or is that outgoing port sent in the clear so that any MITM can see it?

[Gunther F]

Marco Moock <mm+use...@dorfdsl.de> said:

>> Do newsreaders normally choose random ports or the same port?
>
> They choose random port between 49152 and 65535 that is free.
>
> You can't obfuscate that port from the news server because it is
> relevant for the communication.

Does that mean if you've used the same port for years, a MITM snooping on
the lines (or even an audit of the server logs) can fingerprint you.

Take the worst case scenario, for example, where I explained moments ago to
Grant Taylor that old news servers don't have modern encryption so people
obtain modern encryption with software such as Stunnel to get that done.

But Stunnel requires a static outgoing port, where the example I gave Grant
used a single server with a single static outgoing port for years.

Let's provide another scenario, which is probably a worst case situation.
Let's say, for arguments sake, you have two accounts on the same server.

But, let's assume, you did that to keep those two accounts separate.
That is, you don't want either the MITM or the server to know both are you.

If we concentrate only on ports for this question (as I'm well aware other
things will be similar such as the IP address and/or the system time zone,
and quite a few other bits of non-entropy) would it make sense to protect
the desired dissimilar nature of the two accounts by using DIFFERENT ports?

For example, assuming this is for account one of two accounts:

Newsreader server = 127.0.0.1
Newsreader port = 49152
Then, in the stunnel.conf file you must match to the same outgoing port.
[EternalSept]
client = yes
accept = 127.0.0.1:49152
connect = news.eternal-september.org:563
verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.eternal-september.org
OCSPaia = yes

This alone easily works for both accounts, but should you set up the second
account to use a DIFFERENT outgoing port to prevent easy fingerprinting?

For account two of two accounts:
Newsreader server = 127.0.0.1
Newsreader port = 49153

Then, in the stunnel.conf file you must match to the same outgoing port.

[EternalSept2]
client = yes
accept = 127.0.0.1:49153

connect = news.eternal-september.org:563
verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.eternal-september.org
OCSPaia = yes

Of course, if the fingerprinting concern is valid, then a better solution
might be to change newsreaders, but what if you are happy with the reader?

If what I'm asking is true (that a MITM or the server logs fingerprint both
accounts as possibly the same based on the same outgoing port for years),
then there must be a reasonable way to randomize the outgoing port used.

[Marco Moock]

Am 10.01.2024 um 09:38:13 Uhr schrieb Gunther F:

> Marco Moock <mm+use...@dorfdsl.de> said:
>
> >> Do newsreaders normally choose random ports or the same port?
> >
> > They choose random port between 49152 and 65535 that is free.
> >
> > You can't obfuscate that port from the news server because it is
> > relevant for the communication.
>
> Does that mean if you've used the same port for years, a MITM
> snooping on the lines (or even an audit of the server logs) can
> fingerprint you.

Yes, but applications won't use the same source port for years. They
choose one each time a connection is being established.

> Take the worst case scenario, for example, where I explained moments
> ago to Grant Taylor that old news servers don't have modern
> encryption so people obtain modern encryption with software such as
> Stunnel to get that done.
>
> But Stunnel requires a static outgoing port, where the example I gave
> Grant used a single server with a single static outgoing port for
> years.

IIRC stunnel has 2 connections.
1) stunnel <--> server
2) Client <--> stunnel

Relevant here is the source port at stunnel at 1.

> Let's provide another scenario, which is probably a worst case
> situation. Let's say, for arguments sake, you have two accounts on
> the same server.
>
> But, let's assume, you did that to keep those two accounts separate.
> That is, you don't want either the MITM or the server to know both
> are you.
>
> If we concentrate only on ports for this question (as I'm well aware
> other things will be similar such as the IP address and/or the system
> time zone, and quite a few other bits of non-entropy) would it make
> sense to protect the desired dissimilar nature of the two accounts by
> using DIFFERENT ports?

As long as you use the same machine, the IP address can be used to
track.
And using the same source port works only if only one connection is
being established.

> If what I'm asking is true (that a MITM or the server logs
> fingerprint both accounts as possibly the same based on the same
> outgoing port for years), then there must be a reasonable way to
> randomize the outgoing port used.

Randomizing the outgoing port is default.

[Adam W.]

Gunther F <grun...@nospam.edu> wrote:

> Thank you for explaining that the outgoing port is known to the server.
> Hence, it can be grep'd for in a future audit of that server's logs.
>
> But is that outgoing port ALSO known to a MITM in real time?

It would be better if you stuck to "source port" (the port allocated each
time you make a connection) and "destination port" (119, 563, or whatever
port news server wants you to connect to).

When you connect to the news server (destination IP and port), you send
your source IP and port in the initial packet. News server responds to
your source IP and source port.

Source ports on most implementations are dynamic, they change with each
connection (I saw them being static only on some proprietary embedded
platforms).

What *exactly* are you trying to mitigate here?

> But is that outgoing port encrypted such that only the server sees it?

No.

> Or is that outgoing port sent in the clear so that any MITM can see it?

Yes, both source and destination ports are sent in the clear.

[Gunther F]

"Adam W." <gof-cut-...@cut-this-chmurka.net.invalid> said:

> It would be better if you stuck to "source port" (the port allocated each
> time you make a connection) and "destination port" (119, 563, or whatever
> port news server wants you to connect to).

Thank you for suggesting "source port" for the port that Stunnel requires
match that of the older newsreader "source port", and destination port.

The destination port isn't what is of concern here since everyone pretty
much uses 563 or 119 as the destination port (as far as I am aware).

In the example given to Grant Taylor earlier, I'll list them specifically.
Newsreader:
Server = 127.0.0.1
Port = 49152 <<<<< you refer to this as the "source port"
Stunnel.conf
[EternalSept]
client = yes
accept = 127.0.0.1:49152 <<<<< this must be the same "source port"
connect = news.eternal-september.org:563 <<<<< you refer to this as the destination port

verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.eternal-september.org
OCSPaia = yes

> When you connect to the news server (destination IP and port), you send
> your source IP and port in the initial packet.

The "source IP" is not what is being asked here, but it's good to know.
The "source IP" can easily be randomized using a VPN so that's no issue.

The ONLY thing being asked here is what you called the "source port".

> News server responds to your source IP and source port.

Are you sure of that? Doesn't the news server ALSO respond to what you
refer to as the "destination port" (ie 119 or 563 most of the time)?

Does the news server obtain your "source port" (which is the port that is
assigned in the old newsreader to correspond to that of stunnel.conf)?

Newsreader:
Port = 49152 <<<<< you called this the "source port"
Stunnel.conf
accept = 127.0.0.1:49152 <<<<< you called this the "source port"]

The question is only asking if that "source port" is sent in the clear?

> Source ports on most implementations are dynamic, they change with each
> connection (I saw them being static only on some proprietary embedded
> platforms).
>
> What *exactly* are you trying to mitigate here?

Is what you called the "source port" sent in the clear over the net?

>> But is that outgoing port encrypted such that only the server sees it?
>
> No.

Then that's a problem if what you called the "source port" is sent in the
clear because a MITM can take advantage of fingerprinting you that way.

Right?

>> Or is that outgoing port sent in the clear so that any MITM can see it?
>
> Yes, both source and destination ports are sent in the clear.

I'm confused because you mixed IP addresses (which have nothing to do with
the question) and then you re-defined source & destination ports mixed up.

May I ask you to try again where BOTH OF US will use consistent terms?
Using the simple example I gave Grant Taylor, let's use these terms.

Newsreader:
Server = 127.0.0.1
Port = 49152 <<<<< "source port"
Stunnel.conf
[EternalSept]
client = yes
accept = 127.0.0.1:49152 <<<<< "source port"
connect = news.eternal-september.org:563 <<<<< "destination port"

verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.eternal-september.org
OCSPaia = yes

I'm not asking about anything other than what you called the "source port".

I'm well aware "other things" (like IP addresses & system time zones) are
sent over the net - but this question is only asking about "source ports".

May we start again with a response - where both of us use the same terms.

My basic question is:
Is that "source port" (as described above) sent in the clear over the net?
Or not?

[Gunther F]

Marco Moock <mm+use...@dorfdsl.de> said:

>> Does that mean if you've used the same port for years, a MITM
>> snooping on the lines (or even an audit of the server logs) can
>> fingerprint you.
>
> Yes, but applications won't use the same source port for years.

I think I confused everyone by not knowing the terms YOU use for the port
that I'm speaking about, which is definitely STATIC for years and years.

> They choose one each time a connection is being established.

Again, I think I confused everyone because the stunnel.conf file has a
static port that must be assigned, and which typically remains static.

In confusing everyone, I confused myself to the point that I don't know
what you're answering because I don't know the proper terms for ports.

In a previous message, if I understood Adam W correctly (and I may very
well NOT have understood him), this is what he termed the ports used.

Old newsreader server setting = 127.0.0.1
Old newsreader port setting = 49152 <<<<< Is this the "source port"?

Then, in the stunnel.conf file you must match to the same outgoing port.
[EternalSept]
client = yes

accept = 127.0.0.1:49152 <<<<< Is this the "source port" you refer to?
connect = news.eternal-september.org:563 <<<<< Is this the destination port?

verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.eternal-september.org
OCSPaia = yes

>> Take the worst case scenario, for example, where I explained moments
>> ago to Grant Taylor that old news servers don't have modern
>> encryption so people obtain modern encryption with software such as
>> Stunnel to get that done.
>>
>> But Stunnel requires a static outgoing port, where the example I gave
>> Grant used a single server with a single static outgoing port for
>> years.
>
> IIRC stunnel has 2 connections.
> 1) stunnel <--> server
> 2) Client <--> stunnel
>
> Relevant here is the source port at stunnel at 1.

Thank you for describing that connective process where it's confusing the
way you outlined it, as it's likely the opposite of what you showed.

Let's remove the double arrows to assume (for now) only a posting process.
1) Client sends the composed article to Stunnel
2) Stunnel sends the composed article to the newsserver
3) The newsserver adds a few headers and posts the article to Usenet

The question is asking whether maybe the news server knows what Adam
referred to as the "source port", or maybe not. I don't know.

Maybe it does. Maybe it doesn't.
That's why I asked.

>> Let's provide another scenario, which is probably a worst case
>> situation. Let's say, for arguments sake, you have two accounts on
>> the same server.
>>
>> But, let's assume, you did that to keep those two accounts separate.
>> That is, you don't want either the MITM or the server to know both
>> are you.
>>
>> If we concentrate only on ports for this question (as I'm well aware
>> other things will be similar such as the IP address and/or the system
>> time zone, and quite a few other bits of non-entropy) would it make
>> sense to protect the desired dissimilar nature of the two accounts by
>> using DIFFERENT ports?
>
> As long as you use the same machine, the IP address can be used to
> track.

Adam discussed the IP address also, where I need to make it clear that I am
only asking about what Adam referred to as the "source port".

I am well aware that a ton of information also needs to be randomized, from
the IP address that is sending the article to the time zone of the system
to the newsreader being used to a slew of identifying bits of entropy.

This is not about that.

This is only asking whether what I think Adam meant by the "source port" is
being sent to the news server and whether that is being sent in the clear.

Old newsreader port setting = 49152 <<<<< Is this the "source port"?
accept = 127.0.0.1:49152 <<<<< Is this the "source port" you refer to?
connect = news.eternal-september.org:563 <<<<< Is this the destination port?

> And using the same source port works only if only one connection is
> being established.

Stunnel ALWAYS uses the same "source port" for years on end unless you
specifically spend the time and effort to manually type in another one.

>> If what I'm asking is true (that a MITM or the server logs
>> fingerprint both accounts as possibly the same based on the same
>> outgoing port for years), then there must be a reasonable way to
>> randomize the outgoing port used.
>
> Randomizing the outgoing port is default.

Using "outgoing port" is probably a bad mistake on my part as there are
going to be two ports in every transaction the way I describe them.

There is always going to be what I think Adam referred to as the
"destination port" which is usually (for nntp) either 563 or 119.

That's NOT what I'm asking about.

Then there is the static port that you pick out of a range of unused ports
on your own machine between 49152 & 65535 that are the "source ports" Adam
referred to (if I understood what he was trying to help me understand).

Until I use the terminology that YOU use, I'll just confuse you and your
answers will be confusing to me no matter how hard I try to understand.

We need a common name for these two ports that we all can agree on.

This question is only asking whether what Adam called the "source port" is
sent (in the clear or not) to the server over the Internet.

Maybe it is. Maybe it's not.
That's the question.

[Marco Moock]

Am 10.01.2024 um 11:20:51 Uhr schrieb Gunther F:

> In a previous message, if I understood Adam W correctly (and I may
> very well NOT have understood him), this is what he termed the ports
> used.
>
> Old newsreader server setting = 127.0.0.1
> Old newsreader port setting = 49152 <<<<< Is this the "source
> port"?
>
> Then, in the stunnel.conf file you must match to the same outgoing
> port. [EternalSept]
> client = yes
> accept = 127.0.0.1:49152 <<<<< Is this the "source port" you
> refer to? connect = news.eternal-september.org:563 <<<<< Is this the
> destination port?

You have to understand stunnel properly.

stunnel provides 2 connections, BOT of them have a source and
destination port.

Relevant for your privacy is the src port of the
"stunnel <--> NNTP server" connection.

This should be assigned randomly by stunnel.
You can verify that with
ss -tn

There stunnel should appear connected to your NNTP server.
You can see the outgoing port.

[Adam W.]

Gunther F <grun...@nospam.edu> wrote:

>> It would be better if you stuck to "source port" (the port allocated each
>> time you make a connection) and "destination port" (119, 563, or whatever
>> port news server wants you to connect to).
>
> Thank you for suggesting "source port" for the port that Stunnel requires
> match that of the older newsreader "source port", and destination port.

Ok, now everything's confused.

With stunnel, there are two connections, each of them having IP and port
pairs.

stunnel acts both as a server (for your newsreader) and as a client (for
the newsserver). When you connect to stunnel, stunnel creates its own
connection to the newsserver.

If stunnel runs on the same machine as a newsreader, then you'll probably
use a local IP (127.0.0.1). You have to configure a listening port in
stunnel, and if you connect from your newsreader to stunnel, this
listening port will be the destination port of that connection, and source
port (allocated on behalf of your newsreader) will be different each time
you connect.

Then, stunnel makes a separate connection to the newsserver. This will be
done to the server IP, to its destination port, from a source port.

> Newsreader:
> Server = 127.0.0.1
> Port = 49152 <<<<< you refer to this as the "source port"

No, it's the listening port in stunnel. It doesn't leak anywhere outside
of your machine. There's no trace of this port anywhere on the newsserver.
So to answer the question again: no, newsserver doesn't know the port you
use to connect your newsreader to your stunnel.

>> News server responds to your source IP and source port.
>
> Are you sure of that?

Yes, but to the source port, not to the port you configured between your
newsreader and your stunnel.

> Doesn't the news server ALSO respond to what you refer to as the
> "destination port" (ie 119 or 563 most of the time)?

Ok, let's use an example.

I set up a packet sniffer on my laptop and on my newsserver and made a
connection. I'm not using stunnel.

Here's what happens.

- seen on laptop: request packet
- from 192.168.2.50 port 50174
- to 176.56.237.216 port 119

- seen on server: request packet
- from <redacted> port 17595
- to 176.56.237.216 port 119

- seen on server: response packet
- from 176.56.237.216 port 119
- to <redacted> port 17595

- seen on laptop: response packet
- from 176.56.237.216 port 119
- to 192.168.2.50 port 50174

Addresses and ports used:

- 192.168.2.50 is my laptop's IP in my local network

- <redacted> is the public IP of my home connection

- 176.56.237.216 is the newsserver's IP address

- 50174 is the source port assigned by my laptop for this connection

- 17595 is the source port assigned by my router for this connection

- 119 is the listening port of my newsserver, which became a destination
port for this connection

A router changed ports, because it did the NAT (network address
translation). It's because I have many devices in my home network, but all
appear on the outside from the same public IP.

> Does the news server obtain your "source port" (which is the port that is
> assigned in the old newsreader to correspond to that of stunnel.conf)?

No, not this port.

>> Yes, both source and destination ports are sent in the clear.
>
> I'm confused because you mixed IP addresses (which have nothing to do with
> the question) and then you re-defined source & destination ports mixed up.
>
> May I ask you to try again where BOTH OF US will use consistent terms?
> Using the simple example I gave Grant Taylor, let's use these terms.

It's complicated, because there are many layers that make the connection
possible. IP layer that uses IP addresses, TCP layer that uses ports on
these addresses, and then you add stunnel on top of that, which makes the
connection be split into two separate, distinct ones. And then there's
probably NAT, which rewrites ports.

> I'm not asking about anything other than what you called the "source port".

Ok, this is not a source port. This is the listening port of stunnel. When
newsreader connects to stunnel, this port is used as a destination port,
but it's not seen outside of your PC.

> Is that "source port" (as described above) sent in the clear over the net?
> Or not?

No.

[Adam W.]

Gunther F <grun...@nospam.edu> wrote:

> This alone easily works for both accounts, but should you set up the second
> account to use a DIFFERENT outgoing port to prevent easy fingerprinting?

No. The server doesn't know what's between your newsreader and your
stunnel.

[Adam W.]

Gunther F <grun...@nospam.edu> wrote:

> In a previous message, if I understood Adam W correctly (and I may very
> well NOT have understood him), this is what he termed the ports used.
>
> Old newsreader server setting = 127.0.0.1
> Old newsreader port setting = 49152 <<<<< Is this the "source port"?

No.

With stunnel you have two connections, and for each connection you have
two ports (source and destination). So there are four ports in total.

Let's call the first connection (between newsreader and stunnel) A, and
second connection (between stunnel and newsserver) B.

Ports that are used:

- A, source port: randomized, not seen by the server
- A, destination port: fixed (49152 in your case), not seen by the server
- B, source port: randomized, seen by the server
- B, destination port: fixed (563 in your case), needed by the server

> Adam discussed the IP address also, where I need to make it clear that I am
> only asking about what Adam referred to as the "source port".

Ports are closely tied to IPs, that's why I also discussed them. You can't
just use a port without an IP address. A port can be seen, in very simple
(oversimplified) terms, as an extension to the IP address that allows
having multiple connections to (and from) each IP address.

> Old newsreader port setting = 49152 <<<<< Is this the "source port"?

In this example "A, destination port".

> accept = 127.0.0.1:49152 <<<<< Is this the "source port" you refer to?

In this example, the same as above, "A, destination port".

> connect = news.eternal-september.org:563 <<<<< Is this the destination port?

In this example "B, destination port".

And source ports are hidden (not configured, because they're assigned
automatically each time a connection is established).

[Richard Kettlewell]

With a direct connection to a news server it is not encrypted; anyone
who can read data off the intermediate network can see source and
destination address, and source and destination port. That’s just how
TCP/IP works.

The source address is the part most likely to be of interest to someone
trying to distinguish one user from another.

--
https://www.greenend.org.uk/rjk/

[Grant Taylor]

On 1/10/24 03:03, Gunther F wrote:
> But what if you sent a letter from the same post office for years,
> always with the same envelope & handwriting & other identifying bits?

Traffic / pattern analysis is a real issue. You have to decide if it's
an issue that you care about. Doing something about it can become very
difficult.

> Therein lies the issue I'm trying to better understand, as a user.
> When you're using Stunnel you have to set up a permanent outgoing port.

Not quite.

stunnel is functioning as a server (of sorts) for your news client while
also being a client (of sorts) in and of itself. Part of it being a
client means that it will rely on the OS / TCP/IP stack to choose the
source port for /stunnel's/ outgoing encrypted connection.

> Isn't that static port (which can remain unchanged for years)
> something that a MITM (or an audit of the server logs) can use to
> fingerprint you?

If you've got something doing traffic analysis on your computer, you've
got much bigger problems.

> Hence you're likely to keep that outgoing port static, perhaps
> for years.

Nope.

> For example, assume in the old newsreader, you've set the server:port
> as
> Newsreader server = 127.0.0.1
> Newsreader port = 49152

That's the server that your news reader connects to. Your news reader
is still going to use a dynamic / ephemeral port as the source when
connecting to stunnel.

> Then, in the stunnel.conf file you must match to the same outgoing port.
> [EternalSept]
> client = yes
> accept = 127.0.0.1:49152

That's where you define the 127.0.0.1 / 49152 you point your news reader to.

> connect = news.eternal-september.org:563

That's where you point stunnel to connect to.

> verifyChain = yes
> CAfile = ca-certs.pem
> checkHost = news.eternal-september.org
> OCSPaia = yes

Nothing else in the config that you shared, nor what I'm aware of, has
anything to do with the source port that stunnel will send the encrypted
traffic from.

unencrypted client to stunnel - 127.0.0.1:*:127.0.0.1:49152
encrypted stunnel to server - 192.168.1.1:*:135.181.20.170

These are two completely independent connections.

> My question is whether a MITM (or an audit of the server logs) will
> show all your posts as having the same outgoing port, perhaps for
> years on end?

It depends what logging the server does. Most servers that I'm aware of
don't log the source port. Explicitly because it's an ephemeral thing
and by itself means next to nothing.

netstat et al. will show the remote client's source port, but it is
almost certainly ephemeral.

Network sniffers will see the source port and may capture to a file.

> If so, to prevent fingerprinting, should we randomize the outgoing
> port?

The OS / kernel / TCP/IP tack /does/ generate random source ports /by/
/default/ on every OS that I've ever used.

Depending on the configuration of the OS / kernel / TCP/IP stack, there
may be some bounds to which range of source ports is used. <= 1024
tends to be avoided. Some stacks use a range of 30k ports as possible
source /by/ /default/. Other stacks will use a range from 1025-65535.
You can usually tweak setting somewhere to alter this.

That's all on system. You can get into firewalls doing things to alter
this too.

[Grant Taylor]

On 1/10/24 03:38, Gunther F wrote:
> Does that mean if you've used the same port for years, a MITM snooping
> on the lines (or even an audit of the server logs) can fingerprint you.

Snooping on (sniffing) the lines is considerably different than reading
logs on the server.

sniffing is inherently real-time but may be recorded.

reading logs is after the fact. Maybe very soon after the fact. Logs
may be retained for an indeterminate amount of time.

Logs probably don't include ephemeral details from the connection.

sniffing inherently sees the ephemeral details for the connection.

> Take the worst case scenario, for example, where I explained moments
> ago to Grant Taylor that old news servers don't have modern encryption
> so people obtain modern encryption with software such as Stunnel to
> get that done.

Think about what you just typed; "old news server doesn't have modern
encryption". So what goes over the wire to the news server is old (and
busted) encryption.

It doesn't matter what the encryption is between the news client and
stunnel if the encryption between stunnel and the old news server is
unencrypted or uses busted encryption. Your traffic is still traversing
the Internet using no or busted encryption in this scenario.

> Let's provide another scenario, which is probably a worst case
> situation. Let's say, for arguments sake, you have two accounts on
> the same server.
>
> But, let's assume, you did that to keep those two accounts separate.
> That is, you don't want either the MITM or the server to know both
> are you.

Traffic analysis is going to give you away.

Are you using both accounts at the same time? If not, then timing --
hence traffic analysis -- is going to give you away.

If someone sniffs your Internet connection and sees that you send
traffic at time A and an article from identity A shows up on Usenet
shortly there after and then some time later at time B an article from
identity B shows up on Usenet there is a correlation to be had.

Do this enough times and with enough granularity and the gig is up.

This is the crux of traffic analysis.

It doesn't matter is time A / identity A uses news provider A via VPN A
and time B / identity B uses news provider B via VPN B. Patterns will
develop and can be used to correlate things to ultimately identify more
than you are comfortable with.

> would it make sense to protect the desired dissimilar nature of the
> two accounts by using DIFFERENT ports?

No.

The source port is ephemeral and changes with each connection by default
on all worthwhile OS / kernel / TCP/IP stacks.

> Of course, if the fingerprinting concern is valid, then a better
> solution might be to change newsreaders, but what if you are happy
> with the reader?

Network analysis can correlate across different news readers.

> If what I'm asking is true (that a MITM or the server logs fingerprint
> both accounts as possibly the same based on the same outgoing port
> for years), then there must be a reasonable way to randomize the
> outgoing port used.

Traffic analysis will get you despite the ephemeral / dynamic / changing
source ports from stunnel.

[Grant Taylor]

On 1/10/24 05:20, Gunther F wrote:
> I think I confused everyone by not knowing the terms YOU use for the
> port that I'm speaking about, which is definitely STATIC for years
> and years.

It is /you/ Gunther, who is using non-standard naming for things.

Source ports are ephemeral / dynamic / ideally unpredictable by design
for the last 25+ years. 25+ years ago there may have been some
predictability in the pattern of the ephemeral / dynamic port. But
we've moved past that.

> Again, I think I confused everyone because the stunnel.conf file has a
> static port that must be assigned, and which typically remains static.

Yes. But the static / unchanging ports are the /destination/ ports, not
the source ports.

> In confusing everyone, I confused myself to the point that I don't know
> what you're answering because I don't know the proper terms for ports.

Which is why I suggested that you read a tutorial.

> In a previous message, if I understood Adam W correctly (and I may very
> well NOT have understood him), this is what he termed the ports used.
>
> Old newsreader server setting = 127.0.0.1
> Old newsreader port setting = 49152 <<<<< Is this the "source port"?

Nope. That's the /destination/ port you are pointing your news reader to.

> Then, in the stunnel.conf file you must match to the same outgoing port.
> [EternalSept]
> client = yes
> accept = 127.0.0.1:49152 <<<<< Is this the "source port" you refer to?

Nope. That's the /destination/ port that stunnel is listening for
connections from your news reader.

> connect = news.eternal-september.org:563 <<<<< Is this the destination port?

That's the /destination/ port that stunnel is connecting to.

> verifyChain = yes
> CAfile = ca-certs.pem
> checkHost = news.eternal-september.org
> OCSPaia = yes

N.B. that none of that is the /source/ port for either connection; news
reader to stunnel nor stunnel to the news server.

> Thank you for describing that connective process where it's confusing
> the way you outlined it, as it's likely the opposite of what you
> showed.

Nope. You have it backwards in your head.

What Marco wrote is correct. Maybe not worded the best possible, but
it's accurate.

The server sees the ephemeral / dynamic port that stunnel uses as a client.

> Let's remove the double arrows to assume (for now) only a posting process.
> 1) Client sends the composed article to Stunnel

A) news reader sends a connection from a dynamic port on 127.0.0.1 to
stunnel at port 49152 on 127.0.0.1.

> 2) Stunnel sends the composed article to the newsserver

B) stunnel sends a connection from a dynamic port on ${LAN_IP} to port
563 on news.eternal-september.org(135.181.20.170).

> 3) The newsserver adds a few headers and posts the article to Usenet
>
> The question is asking whether maybe the news server knows what Adam
> referred to as the "source port", or maybe not. I don't know.

The news server will see the ephemeral / dynamic source port that the OS
/ kernel / TCP/IP stack provided to stunnel in the 2nd connection; B.

The news server has no knowledge of anything from the 1st connection; A.

> Maybe it does. Maybe it doesn't. That's why I asked.

Yes, the news server has knowledge of the source port that stunnel used.
The news server /absolutely/ *MUST* know what that ephemeral / dynamic
source port is.

The ephemeral / dynamic source (and destination) port(s) is as much part
of the connection that data goes through as the IP addresses are. It's
impossible to establish a TCP connection without ports.

> I am well aware that a ton of information also needs to be randomized,
> from the IP address that is sending the article to the time zone of
> the system to the newsreader being used to a slew of identifying bits
> of entropy.

Be aware that the more that you change from the default the more that
you stand out and identify yourself.

You really want to be as common as possible.

> This is only asking whether what I think Adam meant by the "source
> port" is being sent to the news server and whether that is being sent
> in the clear.

Effective, yes, the source IP, source port, destination IP, and
destination port are sent in the clear.

I say effectively because there are ways to hide it, but they require
things like a VPN /and/ support by the news server. As such, they
effectively don't happen.

> Stunnel ALWAYS uses the same "source port" for years on end

You're wrong. Read more replies, or better, a tutorial on how TCP/IP
works to understand why.

> That's NOT what I'm asking about.

It is one of the things that you have asked about.

> Until I use the terminology that YOU use, I'll just confuse you
> and your answers will be confusing to me no matter how hard I try
> to understand.

N.B. that it is /you/, Gunther, that are using terminology incorrectly.

> We need a common name for these two ports that we all can agree on.

The entire networking industry has agreed upon the terms that Adam,
Marco, and myself have used.

Each end has an IP address and a TCP port. There is the source end and
the destination end. Do some basic extrapolation and you will get to:

- source IP
- source port
- destination IP
- destination port

Those /are/ the /common/ /names/ for the ports.

*You* /Gunther, are the one that is not using what the rest of the
industry is using.

> This question is only asking whether what Adam called the "source port"
> is sent (in the clear or not) to the server over the Internet.

This is a new question; compared to other questions you've asked in this
thread; and I've spoken to it above.

> Maybe it is. Maybe it's not.

As stated above, TCP/IP *REQUIRES* ports on the source and destination
end. We call those the "source port" and "destination port".

Similarly, since TCP/IP *REQUIRES* IP on the source and destination end.
We call those the "source IP" and "destination IP".

TCP connections consist of the following four things:

<source IP>:<source port>:<destination IP>:<destination port>

How those four things are represented and in what order and how they are
encoded can vary depending on context, but EVERY SINGLE TCP/IP
connection /will/ /have/ /and/ /know/ these four things.

[Grant Taylor]

On 1/10/24 03:01, Richard Kettlewell wrote:
> By fingerprintering I assume you mean the ability of someone monitoring
> network traffic to distinguish your connections from anyone else’s.

Agreed.

> Tinkering with source port choice is quite unlikely to reduce
> it. Indeed it may _increase_ the possibility of fingerprinting: if you
> use something other than your platform’s normal source port choice
> then you are distinguishable from all other users of the same platform.

Exactly!

If there are 100 people in the room and only one speaks language A, then
when you hear language A, you know who said it.

Conversely if 51 people speak language A, then when you hear language A,
you know that one of the 51 people said it.

> It does know.

Yep. It MUST know. It can't function without knowing.

> Depends on implementation.

And depending on configuration.

[Grant Taylor]

On 1/10/24 03:25, Gunther F wrote:
> Thank you for explaining that the outgoing port is known to the server.
> Hence, it can be grep'd for in a future audit of that server's logs.

Maybe it can be. Maybe it can't be. It depends on how the server is
configured (does it log the client source IP or port) and how long it's
been (are the logs still there).

> But is that outgoing port ALSO known to a MITM in real time?

In short, yes.

Based on your use of stunnel and TCP port 563 on the news server, we are
discussing TLS encryption.

TLS rides on top of the TCP connection.

As previously stated, the source IP, *source* *port*, destination IP,
and destination port are integral parts of the TCP connection.

Thus the source port is below / outside of the TLS encryption.

There are other ways to encrypt the traffic that does hide at least the
ports, if not the IPs as well. But that's not what is being used here.
What's more is that these methods require explicit support from the news
server.

> Since your communication to the server is encrypted, I would expect
> that outgoing port to ALSO be encrypted such that a MITM wouldn't
> see it.

You'd be wrong.

I understand why you make the assumption that you did, but it's still wrong.

> But is that outgoing port encrypted such that only the server sees it?

Nope.

> Or is that outgoing port sent in the clear so that any MITM can see it?

Yep.

[Grant Taylor]

On 1/10/24 04:59, Gunther F wrote:
> Are you sure of that? Doesn't the news server ALSO respond to what you
> refer to as the "destination port" (ie 119 or 563 most of the time)?

The news server uses a TCP connection.

The TCP connection is defined as four things:

- source IP
- source port
- destination IP
- destination port

You don't have a TCP connection without all four.

> Does the news server obtain your "source port"

Yes, the news server *MUST* have a source port as it's an integral part
of the TCP connection. The TCP connection can't exist without the four
things listed above.

> (which is the port that is assigned in the old newsreader to correspond
> to that of stunnel.conf)?

The source port as far as the news server is concerned is the source
port in the TCP connection.

Eliding NAT, this will be the source port that the OS / kernel / TCP/IP
stack provided to stunnel for establishing the connection to the news
server.

NAT can change, er /translate/ ;-), things.

Network Address Translation may change the source port that the
destination system sees. But there is still a source port. -- Again,
TCP/IP can't function without the four things listed above.

> Then that's a problem if what you called the "source port" is sent in the
> clear because a MITM can take advantage of fingerprinting you that way.

That's like saying that water is wet or that it's nominally between 32
and 212 degrees Fahrenheit is a problem.

> Right?

No, not really.

The source port is only 16 bits (if that many do to various things) out
of thousands of other bits that do far more to identify you.

> May I ask you to try again where BOTH OF US will use consistent terms?

Why don't you try understanding the terms that the rest of us are using
consistently:

- source IP
- source port
- destination IP
- destination port

If you need clarification of what those phrases mean, ask. That way you
can start using the same dictionary that the entire networking industry
uses to describe the topic at hand.

> Using the simple example I gave Grant Taylor, let's use these terms.

I've responded elsewhere, but I'll respond here again.

> Newsreader:
> Server = 127.0.0.1
> Port = 49152 <<<<< "source port"

Hope. That's the destination port that the news reader will connect to
stunnel.

> Stunnel.conf
> [EternalSept]
> client = yes
> accept = 127.0.0.1:49152 <<<<< "source port"

Nope. That's the destination port that stunnel listens for connections on.

N.B. how the news reader connects the same port that stunnel listens on.

> connect = news.eternal-september.org:563 <<<<< "destination port"

That's the destination port that stunnel will connect to the news server.

> verifyChain = yes
> CAfile = ca-certs.pem
> checkHost = news.eternal-september.org
> OCSPaia = yes
>
> I'm not asking about anything other than what you called the "source port".

You keep asking multiple questions and then saying that you're not
asking about them.

> May we start again with a response - where both of us use the same terms.

Just as soon as you understand and use the terms that the rest of the
networking industry uses.

> My basic question is:
> Is that "source port" (as described above) sent in the clear over the net?
> Or not?

We have answered that question, "is the source port clear over the net",
many times.

We've answered the question, "does the server know the source port",
many times.

We've answered at least one other question many times too.

We've tried to help you with terms many times.

[Gunther F]

Grant Taylor <gta...@tnetconsulting.net> said:

>> I think I confused everyone by not knowing the terms YOU use for the
>> port that I'm speaking about, which is definitely STATIC for years
>> and years.
>
> It is /you/ Gunther, who is using non-standard naming for things.

I agree with you so I will clear it all up below by calling it "49152".

We're all frustrated but the question is really this simple as I see it.
Q: Is "49152" being sent to the news server or not?

I'm so confused by all the helpful answers that I'm about to give up.
It's really a simpler question than it's being made out to be.

There are two huge basic problems I see which makes this confusing.

The first is I don't know what YOU want me to call the specific port.
And the other is that this port question is really a very simple one.

It's not supposed to be a complicated question.
Maybe the server sees port "49152"; maybe it doesn't.

It's really that simple of a question of maybe that unique specific "49152"
port is sent over to the server in the clear or maybe it's never even sent.

I still don't know the answer to that (which is the original) question.
If I use the example already given, I can refer to that port as "49152".

The newsreader actually isn't involved as far as I can tell, so I'm going
to _remove_ teh newsreader from this since sTunnel is doing all the work.

[EternalSept]
client = yes
accept = 127.0.0.1:49152

connect = news.eternal-september.org:563

verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.eternal-september.org
OCSPaia = yes

I realize you're trying to help, but I confused all of you with too much
information so the question is re-stated boiled to the basic essentials.

The question is (and always was) really this super simple as I see it.
Q: Is "49152" being sent to the news server or not?

[Adam W.]

Grant Taylor <gta...@tnetconsulting.net> wrote:

> Explicitly because it's an ephemeral thing and by itself means next to
> nothing.

It might mean something when correlated with NAT logs.

One time police contacted me asking for logs about one of my users (IRC
server, not NNTP), they wanted his IP(s) as well as source port(s). Not
saying they know what they're doing, but that's what they asked for.

I just modified my nnrpd to log the port, BTW. It doesn't cost anything,
and might be needed some time later.

#v+
--- nnrpd/nnrpd.c~ 2024-01-11 01:48:58.248000000 +0100
+++ nnrpd/nnrpd.c 2024-01-11 01:49:43.612000000 +0100
@@ -661,7 +661,7 @@
sizeof(nodelay));
#endif

- notice("%s (%s) connect - port %u", Client.host, Client.ip, port);
+ notice("%s (%s:%u) connect - port %u", Client.host, Client.ip, Client.port, port);
}
#v-

Of course this port has nothing to do with the port Gunther is asking
about (he's probably unaware that such thing as source port in TCP even
exists, or was unaware until now).

> The OS / kernel / TCP/IP tack /does/ generate random source ports /by/
> /default/ on every OS that I've ever used.

I saw two exotic embedded implementations in which it didn't. One simply
incremented the port number and other used the same number every time. But
I paid attention in the first place, because I had to diagnose and
document other weird problems these implementations had. They were poorly
written and has problems with IP fragmentation, for example.

BTW, I also once saw zero as a port number, but oddly the machine on the
other end (a normal Linux) had no problem with that, and communication
worked. I still don't know if zero as a source port number is allowed or
not. Common sense tells me it shouldn't be, but well... it worked.

[Adam W.]

Gunther F <grun...@nospam.edu> wrote:

> We're all frustrated but the question is really this simple as I see it.
> Q: Is "49152" being sent to the news server or not?

The equally simple answer to that question is "no".

> I'm so confused by all the helpful answers that I'm about to give up.

TCP/IP can be quite complicated when you get into details, but basic,
high-level functionality is actually very simple and it has already been
explained.

> The first is I don't know what YOU want me to call the specific port.

Let's stick to calling it 49152. At this point we all know what we're
talking about.

Proper name for it would be "stunnel's listening port". Stunnel listens on
this port and when a connection from a newsreader to stunnel is made, this
port is the destination port your newsreader connects to.

> The newsreader actually isn't involved as far as I can tell, so I'm going
> to _remove_ teh newsreader from this since sTunnel is doing all the work.

It is, because 49152 is used *only* to talk between your newsreader and
stunnel.

> [EternalSept]
> client = yes
> accept = 127.0.0.1:49152
> connect = news.eternal-september.org:563
> verifyChain = yes
> CAfile = ca-certs.pem
> checkHost = news.eternal-september.org
> OCSPaia = yes

This configuration means: Listen on port 49152 for connections
originating from a local machine (so another machine in your local network
won't be able to connect to your stunnel, only programs running on your
own computer, like your newsreader, will be able to do it). When a
connection to this port is made, create a *new* connection to
news.eternal-september.org on port 563.

This setup makes stunnel handle the TLS handshake and encryption on behalf
of the newsreader by providing the newsreader with a port (49152) that
expects an unencrypted traffic.

news.eternal-september.org doesn't know (or care) if TLS encryption is
done by stunnel or by implementation in a modern newsreader.

If your newsreader allowed you to make encrypted connections without
stunnel, then you wouldn't have 49152 anywhere in the picture, as the
communication between the part handling the news protocol and part
handling the TLS encryption (both being parts of a newsreader) would be
handled completely internally in the newsreader (and most probably not
involving TCP/IP at all, however different implementations are possible).

In short: everything involving port 49152 is only between newsreader and
stunnel. Information that the port used was 49152 (and even that any port
was used at all) never reaches the server.

[Adam W.]

Grant Taylor <gta...@tnetconsulting.net> wrote:

>> Take the worst case scenario, for example, where I explained moments
>> ago to Grant Taylor that old news servers don't have modern encryption
>> so people obtain modern encryption with software such as Stunnel to
>> get that done.
>
> Think about what you just typed; "old news server doesn't have modern
> encryption". So what goes over the wire to the news server is old (and
> busted) encryption.

I think Gunther wanted to write "old news readers", because only then it
would make sense. But only he knows for sure...

[Gunther F]

Yes. The reason for sTunnel is to give old news READERS modern encryption.

BTW, I think I made two big mistakes in this thread, for which I apologize.

One was to confuse everyone with more details than necessary, and the other
was to use all the wrong terminology (which just made that mistake worse).

I've been digging into this where I realized only belatedly that the old
news reader really plays no role whatsoever in communicating with a server.

To be clear, I'm now (belatedly) aware there are actually four pairs of
IP-addresses and ports involved (I think they're each called sockets).

[EternalSept]
client = yes
accept = 127.0.0.1:49152
connect = news.eternal-september.org:563
verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.eternal-september.org
OCSPaia = yes

Service [EternalSept] accepted connection from 127.0.0.1:54321
s_connect: connected 135.181.20.170:563
Service [EternalSept] connected remote server from 183.17.22.24:49153
Connection closed: 3981 byte(s) sent to TLS, 246 byte(s) sent to socket

127.0.0.1:54321 <-> The old newsreader randomly chooses any available
local port for its connection to & from sTunnel

127.0.0.1:49152 <-> However, I have pre-defined both sTunnel
and the old newsreader to use this exact
specific static local port for sTunnel's
connections to & from the old newsreader

183.17.22.24:49153 <-> This seems to be the 49152 above plus one
(at least based on my peek at sTunnel logs)
for the local sTunnel port for connections
to and from the news server (the IP address
is that of my Internet connection, usually VPN)

135.181.20.170:563 <-> This seems to be the remote news server port
the connection to & from sTunnel (the IP address
is that of the news server, usually fixed) and
the port is also of the news server, usually fixed.

What I'm stating above can be wrong (and probably is wrong).
But it's my take of what the sTunnel logs are trying to explain to me.

I think I have the answer now - which isn't the answer anyone gave me.
So it could be wrong - since nobody said what I'm going to assume.

I'm sorry for all the confusion I caused - as I don't know enough yet
but I saw the answer already which was the 49152 isn't sent, which at first
I thought was a "good thing" but then I found out that "49153" is what's
sent (as it's the first open port above 49152 that is actually sent).

So sending 49152 is not happening.
49152 is what's sent instead (I think) as it's the next unused port.

That's just as bad isn't it?
I mean, what's the difference between always sending 49152 (which it is not
doing) but, instead, almost always sending 49153.

Is my assessment above (which nobody said yet) right?
Or wrong?

The news server knows the port it received, which is (usually) one more
than the port I set, which, as I see it, is practically the same thing.

Is it?

[Grant Taylor]

On 1/10/24 19:04, Adam W. wrote:
> It might mean something when correlated with NAT logs.

Maybe. Probably. ;-)

> One time police contacted me asking for logs about one of my users (IRC
> server, not NNTP), they wanted his IP(s) as well as source port(s). Not
> saying they know what they're doing, but that's what they asked for.

I would have asked to see a court warrant before I would say anything
beyond if I had information that I could provide upon receipt of a court
warrant.

> I just modified my nnrpd to log the port, BTW. It doesn't cost
> anything, and might be needed some time later.

I've never gone out of my way to add /additional/ logging save for when
debugging something. Then I usually disable said additional logging
after finishing what I was working on.

> Of course this port has nothing to do with the port Gunther is asking
> about (he's probably unaware that such thing as source port in TCP
> even exists, or was unaware until now).

I think that Gunther is asking from a place of good intention but not
yet understanding how things fit together. But Gunther's questions seem
to be moving forward.

After all, we all started at zero at some point. I try to help bring
people along the way that I would want people to help bring me along.

> I saw two exotic embedded implementations in which it didn't.

I suspect you've run into something older and / or less mainstream than
I. ;-)

> One simply incremented the port number and other used the same number
> every time.

Ya, incrementing the port number monotonically was common in very early
TCP/IP stacks. Using an initial random port and monotonically
incrementing it therefrom was done for a while. Then it was the output
of a one way hash with the counter as an input. I think there is now
some randomness used per connection on some TCP/IP stacks.

It turns out that the port number being unpredictable is a good thing
like passwords being unpredictable is a good thing.

> But I paid attention in the first place, because I had to diagnose
> and document other weird problems these implementations had. They were
> poorly written and has problems with IP fragmentation, for example.

*nod*

Thankfully I've not run into those -- what I'll call -- extreme types of
problems.

> BTW, I also once saw zero as a port number, but oddly the machine
> on the other end (a normal Linux) had no problem with that, and
> communication worked.

*shudder*

/Technically/ 0 is a valid binary value. Linux has a habit of working
well with things that people question.

> I still don't know if zero as a source port number is allowed or
> not. Common sense tells me it shouldn't be, but well... it worked.

I think using port 0 is a "technically you can but please don't"
combined with "not every TCP/IP stack supports it and you may tickle
unwanted bugs".

IANA shows that port 0 is reserved. But that doesn't speak to if it's
okay to use it or not.

I qualify using port 0 as yes you can, but you shouldn't. More
convention than technical limitation.

[Grant Taylor]

On 1/10/24 18:01, Gunther F wrote:
> I agree with you so I will clear it all up below by calling it "49152".

Referring to something by it's value doesn't really help.

> We're all frustrated but the question is really this simple as I
> see it.
> Q: Is "49152" being sent to the news server or not?

Assuming that 49152 is the port that stunnel is listening on and that
the news reader is connecting to:

No, the /news/ server does not see the port 49152. (Unless fate is
being cruel to you and happens to pick 49152 out of the 65535 possible
ports to stunnel uses as it's source port when talking to the news server.

Yes, the /stunnel/ server does see the port 49152.

> I'm so confused by all the helpful answers that I'm about to give up.

Please don't give up.

I get the impression that you are close to understanding.

> It's really a simpler question than it's being made out to be.

It both is and is not.

> There are two huge basic problems I see which makes this confusing.
>
> The first is I don't know what YOU want me to call the specific port.

I'll try explaining something another way.

The news reader has an IP (192.0.2.1) and a port (11111) that it uses to
talk to the stunnel server.
A
stunnel /server/ has an IP (192.0.2.22) and a port (22222) that it uses
to talk to the news reader.

stunnel /client/ has an IP (198.51.100.33) and a port (33333) that it
uses to talk to the news server.
B
The news server has an IP (203.0.113.44) and a port (44444) thatit uses
to talk to the stunnel client.

Below are the IPs and ports for each of the connections.

A) news reader sends to the stunnel server / stunnel server receives
from the news reader:
- source IP 192.0.2.1
- source port 11111
- destination IP 192.0.2.22
- destination port 22222

B) stunnel client sends to the news server / news server receives from
the stunnel client:
- source IP 198.51.100.33
- source port 33333
- destination IP 203.0.113.44
- destination port 44444

C) news server sends to the stunnel client / stunnel client receives
from the news server:
- source IP 203.0.133.44
- source port 44444
- destination IP 198.51.100.33
- destination port 33333

D) stunnel server sends to news reader / news reader receives from
stunnel server:
- source IP 192.0.2.22
- source port 22222
- destination IP 192.0.2.1
- destination port 11111

A, B, C, and D are all disparate and independent packets each with their
own source IP, source port, destination IP and destination port.

A and D are effectively mirrors of each other as A is the request and D
is the reply for the same singular connection between the news reader
and the stunnel server.

B and C are effectively mirrors of each other as B is the request and C
is the reply for the same singular connection between the stunnel client
and the news server.

With this in mind, 49152 is the port that stunnel is listening on. So
when talking about the traffic between the news reader and the stunnel
server, it depends on which direction the traffic is going. If the
traffic is going from the news reader to the stunnel server, then 49152
is the destination port. If the traffic is going from the stunnel
server to the news reader, then 49152 is the source port.

> And the other is that this port question is really a very simple one.

No, the question really isn't as simple as you want it to be. "It
depends." is the simple answer.

> It's not supposed to be a complicated question.

Does the news server (which talks to the stunnel client) see any details
about the connection between the news reader and stunnel server, no, it
should not.

The news server MUST see all of the details to be able to talk to the
stunnel client.

> Maybe the server sees port "49152"; maybe it doesn't.

Which server? ;-)

I'll answer as if you are referring to the news server.

The news server sees the port that the stunnel client is using. There
is (less than) a 1 in 65535 chance that the stunnel client will use
49152 as it's port.

- source port when the stunnel client sends to the news server
- destination port when the news server sends to the stunnel client.

> It's really that simple of a question of maybe that unique specific
> "49152" port is sent over to the server in the clear or maybe it's
> never even sent.

As I tried to indicate in a reply, the very nature of TCP absolutely
*REQUIRES* that the IPs /and/ port be sent. What's more is that when
using TLS, the encryption does not protect the port, so the ports are in
the clear.

> I still don't know the answer to that (which is the original) question.
> If I use the example already given, I can refer to that port as
> "49152".

No, you can't just refer to something as port 49152 and have it mean
anything to people. Especially people that don't have the context of
this thread.

There are some ports that are well known; e.g. 80, 443, 22, 25, etc.
These ports are common ports that web, ssh, and smtp /servers/ use.
Since they are well known, that common knowledge brings some context
along with them and you may get away with being less precise.

In your example, your question is involving four different IP+port
pairs, all of which can be source and destination (different things
depending on the direction of traffic flow).

As such, you need to be more specific and better describe what you are
asking about.

> The newsreader actually isn't involved as far as I can tell, so I'm
> going to _remove_ teh newsreader from this since sTunnel is doing
> all the work.

If you're removing the newsreader, then you are also effectively
removing port 49152 from the discussion. Which means that you are
/only/ talking about the traffic between stunnel client and the news
server. So traffic B and C above.

> I realize you're trying to help, but I confused all of you with too
> much information so the question is re-stated boiled to the basic
> essentials.

But you can't just boil things down.

> The question is (and always was) really this super simple as I see it.

You have blinders on and are missing lots of other things in play that
are quite germane.

> Q: Is "49152" being sent to the news server or not?

As you have used it, 49152 is a port between the news reader and the
stunnel server. It has nothing to do with the connection between the
stunnel client and the news server.

I believe that you have all the information that you need, and direct
answers to this question multiple places in this thread.

You need to spend a little bit of time to understand the information
that people have provided to you.

[Grant Taylor]

On 1/10/24 19:27, Adam W. wrote:
> I think Gunther wanted to write "old news readers",

Agreed.

> because only then it would make sense. But only he knows for sure...

I've seen people use stunnel on the server to provide a TLS interface to
a server that doesn't support TLS.

The only differences between what we think Gunther asked and the
scenario I just described are 1) where stunnel is running and 2) the IP
addresses used to communicate with stunnel.

TCP/IP is EXTREMELY flexible in what it can do, especially when
augmented with things like stunnel.

One needs to have a modicum of understanding of the subject to be able
to ask easily answerable questions.

[Grant Taylor]

On 1/10/24 21:11, Gunther F wrote:
> Yes. The reason for sTunnel is to give old news READERS modern
> encryption.

;-)

> BTW, I think I made two big mistakes in this thread, for which
> I apologize.

It happens.

#beenThereDoneThat

> One was to confuse everyone with more details than necessary,

I don't think the details were unnecessary. If anything the details
were necessary.

> the other was to use all the wrong terminology (which just made that
> mistake worse).

I think what details you used when and what you used to refer to the
details were you primary mistakes.

I maintain skimming a basic TCP/IP tutorial would have given you more /
better information with fewer bytes to read / type.

> I've been digging into this where I realized only belatedly that the
> old news reader really plays no role whatsoever in communicating with
> a server.

The old news reader doesn't communicate with the news server.

The old news reader does communicate with the stunnel server.

Simply saying "server" does not clarify which server you're talking to;
news server vs stunnel server.

> To be clear, I'm now (belatedly) aware there are actually four pairs of
> IP-addresses and ports involved (I think they're each called sockets).
>
> [EternalSept]
> client = yes
> accept = 127.0.0.1:49152
> connect = news.eternal-september.org:563
> verifyChain = yes
> CAfile = ca-certs.pem
> checkHost = news.eternal-september.org
> OCSPaia = yes
>
> Service [EternalSept] accepted connection from 127.0.0.1:54321
> s_connect: connected 135.181.20.170:563

The two lines above make sense to me.

> Service [EternalSept] connected remote server from 183.17.22.24:49153

The line above doesn't make any sense to me.

135.181.20.170 and 183.17.22.24 are two completely different IPs. The
first IP is what news.eternal-september.org resolves to for me.

> Connection closed: 3981 byte(s) sent to TLS, 246 byte(s) sent to socket

Meh.

> 127.0.0.1:54321 <-> The old newsreader randomly chooses any available
> local port for its connection to & from sTunnel

Close enough.

Minor nit pick in that it should be the TCP/IP stack picking the port
and providing it to the old news reader and not the old news reader
picking the port.

> 127.0.0.1:49152 <-> However, I have pre-defined both sTunnel
> and the old newsreader to use this exact
> specific static local port for sTunnel's
> connections to & from the old newsreader

Correct.

> 183.17.22.24:49153 <-> This seems to be the 49152 above plus one
> (at least based on my peek at sTunnel logs)
> for the local sTunnel port for connections
> to and from the news server (the IP address
> is that of my Internet connection, usually VPN)

Okay.

I have strong objections to stunnel using port one number higher than
the incoming connection for many reasons. One of which is the same
reason you are concerned by it.

> 135.181.20.170:563 <-> This seems to be the remote news server port
> the connection to & from sTunnel (the IP address
> is that of the news server, usually fixed) and
> the port is also of the news server, usually fixed.

Correct.

> What I'm stating above can be wrong (and probably is wrong). But it's
> my take of what the sTunnel logs are trying to explain to me.

I believe this is the closest you've been all thread.

> I think I have the answer now - which isn't the answer anyone gave me.

You have been given information to know that port 49152 and been told
that the port stunnel listens on is not used / exposed to the news server.

> So it could be wrong - since nobody said what I'm going to assume.
>
> I'm sorry for all the confusion I caused - as I don't know enough
> yet but I saw the answer already which was the 49152 isn't sent,
> which at first I thought was a "good thing"

I must break this statement into two parts because the first part is a
very good thing.

> but then I found out that "49153" is what's sent (as it's the first
> open port above 49152 that is actually sent).

While this second part is a very bad thing. If stunnel is always using
one port higher, I would consider that to be a SEVERE SECURITY BUG!
<full stop>

Having a predictable client port is a BAD THING.

So, if stunnel is always using one port higher, I would report that as a
bug and clamor for it to be fixed.

IMHO stunnel should be asking the OS / kernel / TCP/IP stack for a port
to send the traffic from / receive replies to.

> So sending 49152 is not happening. 49152 is what's sent instead
> (I think) as it's the next unused port.

I would suggest that you try to reproduce this. There is a 1 in 65535
chance that you rolled a critical fail in D&D and got a bad port.

If you re-run the test multiple times and stunnel still uses 49153 as
it's source port, that is a BIG PROBLEM.

> That's just as bad isn't it?

Effectively, yes.

> I mean, what's the difference between always sending 49152 (which it
> is not doing) but, instead, almost always sending 49153.

Please elaborate on the "almost always". Either it always is, or it's
not always doing it.

/always/ using 49153 is BAD. Randomly landing on 49153 1 in 100 / 1000
times, that's just the (BAD) luck of the draw.

> Is my assessment above (which nobody said yet) right? Or wrong?

At a high level, what you described, the connection between the news
reader and the stunnel server and the separate connection between the
stunnel client and the news server have been described multiple times by
multiple people.

At a low level, stunnel should not be using a predictable port for it's
client connection to the news server.

> The news server knows the port it received, which is (usually) one more
> than the port I set, which, as I see it, is practically the same thing.

If stunnel truly is using the next port, that is what I would consider
to be a SEVERE and SECURITY impacting bug in stunnel.

> Is it?

If stunnel truly is using the next port, then, yes, that is effectively
the same thing.

[Adam W.]

Gunther F <grun...@nospam.edu> wrote:

> (I think they're each called sockets).

No, but let's not complicate it even more.

> 183.17.22.24:49153 <-> This seems to be the 49152 above plus one
> (at least based on my peek at sTunnel logs)

Can you check it after making a few connections? Is it always 49153, or
was it 49153 only once?

[Adam W.]

Grant Taylor <gta...@tnetconsulting.net> wrote:

>> One time police contacted me asking for logs about one of my users (IRC
>> server, not NNTP), they wanted his IP(s) as well as source port(s). Not
>> saying they know what they're doing, but that's what they asked for.
>
> I would have asked to see a court warrant before I would say anything
> beyond if I had information that I could provide upon receipt of a court
> warrant.

I didn't want to bother. I don't feel obliged to protect users that break
the law, and it's also written in rules.

On the other hand, this case was mild, I doubt it was pursued further (but
I don't know, I didn't receive any update, nor did I expect it). There was
a schizophrenic guy convinced that that someone hacked into his computer
and removed some files, and the user in question admitted to have done it
(as a joke), but the schizophrenic guy filed a report with the police in
response and they investigated.

>> I just modified my nnrpd to log the port, BTW. It doesn't cost
>> anything, and might be needed some time later.
>
> I've never gone out of my way to add /additional/ logging save for when
> debugging something. Then I usually disable said additional logging
> after finishing what I was working on.

Maybe you live in a country where the law is is obeyed by the authorities.
I like many things about Poland, but how things work here when it comes to
the abuse of power by the authorities is not one of them. I'd prefer to
have the source port, it costs me nothing and could save me from potential
trouble. Especially as I don't feel obliged to protect anyone who breaks
the law using my server (and they would be instantly booted out if I
learned that the did it).

> I think that Gunther is asking from a place of good intention but not
> yet understanding how things fit together.

Yes, it definitely seems so. You make a connection and it happens, but how
it all works under the hood... you have to be interested in it (or work in
that field) to actually learn about it.

> After all, we all started at zero at some point. I try to help bring
> people along the way that I would want people to help bring me along.

Me too.

>> I saw two exotic embedded implementations in which it didn't.
>
> I suspect you've run into something older and / or less mainstream than
> I. ;-)

It was modern, it's just how things are done in certain proprietary
devices. Let's call the company A. They hire people to reinvent the wheel,
maybe due to NIH syndrome, maybe due to other reasons, but they don't want
to pay too much, so people who agree to work for that wage don't have much
experience, and they do the best they can.

Then there's a need from the customer to make these devices communicate
with devices made by company B (the one I work for), and of course the
communication isn't reliable, but company A claims it's the fault of our
devices, and I'm asked to check what's really going on and make it work.

To make it even worse, device from company A has been tested (by company
A) and got approved by the government, so they're not allowed to modify it
(because they would have to apply for approval once again, and it's a cost
they don't want to cover) and we're the ones supposed to make it work
together, because it's our customer who wants our devices communicating
with these from company A. Only then they'll buy our devices, so there's
pressure from the sales team.

In the end I made it work somehow, but it will never be stable. And guess
who will be blamed for that.

On the other hand, if I was asked to write a TCP/IP stack and I wasn't
able to talk sense to the manager, I would do it to the best of my
knowledge, but these things are so complicated and there are so many edge
cases when communicating with various other implementations (each behaving
in a subtly different way in some cases) that I think it would be full of
bugs almost by design.

Such things have to mature, be actually used by many people in many
environments, before they're stable enough to be used in production. But
engineers can talk, and sales and management knows better...

Fortunately many things improved after I switched teams, my current
manager is a programmer himself, so he knows very well which expectations
are sane and which aren't.

> Ya, incrementing the port number monotonically was common in very early
> TCP/IP stacks. Using an initial random port and monotonically
> incrementing it therefrom was done for a while. Then it was the output
> of a one way hash with the counter as an input. I think there is now
> some randomness used per connection on some TCP/IP stacks.

Something possibly interesting to read about it (I didn't read it yet):

https://lwn.net/Articles/910435/

> I qualify using port 0 as yes you can, but you shouldn't. More
> convention than technical limitation.

Probably yes. I'd have to dig into RFCs to satisfy this curiosity...

[Adam W.]

Grant Taylor <gta...@tnetconsulting.net> wrote:

>> because only then it would make sense. But only he knows for sure...
>
> I've seen people use stunnel on the server to provide a TLS interface to
> a server that doesn't support TLS.

Yes, I did it too. But in this case encrypting the connection from the
newsreader to stunnel only for it to be decrypted outside localhost
doesn't make any sense.

> The only differences between what we think Gunther asked and the
> scenario I just described are 1) where stunnel is running and 2) the IP
> addresses used to communicate with stunnel.

From the config snippets he provided I think the answer to both of these
questions is localhost.

[Grant Taylor]

On 1/12/24 10:15, Adam W. wrote:
> I didn't want to bother. I don't feel obliged to protect users that
> break the law, and it's also written in rules.

The few interactions with police have made me question if the law was
actually broken and I definitely wouldn't take a police officers word
for it.

I would also ask for the warrant as a matter of principle.

I've dealt with too many things where people ask for things they know
that they have no business having and that others would disapprove of,
but they ask for it anyway. -- I've even done this myself. It's
surprising how effective it is. "Social engineering" comes to mind.

> On the other hand, this case was mild, I doubt it was pursued further
> (but I don't know, I didn't receive any update, nor did I expect
> it). There was a schizophrenic guy convinced that that someone hacked
> into his computer and removed some files, and the user in question
> admitted to have done it (as a joke), but the schizophrenic guy filed
> a report with the police in response and they investigated.

Keep in mind that police reports are simply recording of events as told
at the time by a supposedly unbiased and trusted source. Nothing more,
nothing less.

Much like a notary.

> Maybe you live in a country where the law is is obeyed by the
> authorities.

Hardly. But that doesn't mean that I won't ask for a warrant. It means
that they have to want to subvert things /enough/ to either get the
warrant, thus conspiracy, or find another way to get it.

Either way, I have done what I consider to be due diligence. I can
freely answer "because I was given a court order / warrant to do so"
when asked "why did you turn information over to people?".

> I like many things about Poland, but how things work here when it
> comes to the abuse of power by the authorities is not one of them. I'd
> prefer to have the source port, it costs me nothing and could save me
> from potential trouble. Especially as I don't feel obliged to protect
> anyone who breaks the law using my server (and they would be instantly
> booted out if I learned that the did it).

Three things come to mind:

1) how do you know that the request is legitimate without the
documentation substantiating that it's legitimate.

2) How do you know that the accused did anything illegal without
substantiating evidence?

3) What reputation do you want with your other users when it comes to
protecting their information / privacy?

> Yes, it definitely seems so. You make a connection and it happens,
> but how it all works under the hood... you have to be interested in it
> (or work in that field) to actually learn about it.

Yep.

> Me too.

:-)

> It was modern, it's just how things are done in certain proprietary
> devices. Let's call the company A. They hire people to reinvent
> the wheel, maybe due to NIH syndrome, maybe due to other reasons,
> but they don't want to pay too much, so people who agree to work for
> that wage don't have much experience, and they do the best they can.

*sigh* I'm picking up what you're putting down. /But/ /that/ /doesn't/
/mean/ /I'm/ /happy/ /about/ /it/!

> Then there's a need from the customer to make these devices communicate
> with devices made by company B (the one I work for), and of course the
> communication isn't reliable, but company A claims it's the fault of
> our devices, and I'm asked to check what's really going on and make
> it work.

*sigh* ...

Is company A bigger than company B?

> To make it even worse, device from company A has been tested (by
> company A) and got approved by the government, so they're not allowed
> to modify it (because they would have to apply for approval once again,
> and it's a cost they don't want to cover) and we're the ones supposed
> to make it work together, because it's our customer who wants our
> devices communicating with these from company A. Only then they'll
> buy our devices, so there's pressure from the sales team.

Ya....

> In the end I made it work somehow, but it will never be stable. And
> guess who will be blamed for that.

....

> On the other hand, if I was asked to write a TCP/IP stack and I
> wasn't able to talk sense to the manager, I would do it to the best
> of my knowledge, but these things are so complicated and there are so
> many edge cases when communicating with various other implementations
> (each behaving in a subtly different way in some cases) that I think
> it would be full of bugs almost by design.

Probably not /by/ /design/ per se. More likely lack of complete design.

> Such things have to mature, be actually used by many people in
> many environments, before they're stable enough to be used in
> production. But engineers can talk, and sales and management knows
> better...

Yep.

> Fortunately many things improved after I switched teams, my current
> manager is a programmer himself, so he knows very well which
> expectations are sane and which aren't.

:-)

> Something possibly interesting to read about it (I didn't read it yet):
>
> https://lwn.net/Articles/910435/

Yup.

> Probably yes. I'd have to dig into RFCs to satisfy this curiosity...

I don't need to dig. I've seen mainstream firewalls filter port 0 and
the likes. Enough things to know that I can't rely on it. So I won't
rely on it. ;-)

[Grant Taylor]

On 1/12/24 10:18, Adam W. wrote:
> Yes, I did it too. But in this case encrypting the connection from the
> newsreader to stunnel only for it to be decrypted outside localhost
> doesn't make any sense.

I mostly agree.

However, consider an embedded system that can't be easily replaced
(building control, large press printer, some other industrial system).

Put something like a Raspberry Pi in front of it and connected to it by
a 2' cross over cable. Use TLS protection to stunnel running on the 'Pi
that sends unencrypted traffic to the embedded system.

There are very definite use cases for this, but they are far and few in
between.

> From the config snippets he provided I think the answer to both of
> these questions is localhost.

Agreed.

[Adam W.]

Grant Taylor <gta...@tnetconsulting.net> wrote:

>> Maybe you live in a country where the law is is obeyed by the
>> authorities.
>
> Hardly. But that doesn't mean that I won't ask for a warrant. It means
> that they have to want to subvert things /enough/ to either get the
> warrant, thus conspiracy, or find another way to get it.

Hard to disagree with all you wrote (and I didn't quote). The thing is
that I don't want to risk having it done "another way". I don't want to
have my devices seized, service interrupted, me being put into custody and
beaten (which is a standard here) / killed (when beating turns out to be
to severe) just because someone else didn't know how to behave.

It's all a matter of how much do we want to invest into keeping the (free)
service. I'm willing to invest some money, my time spent in front of a
computer, and technical knowledge, but if it starts interfering with my
freedom (which in this country can happen, innocent people are kept in
custody for years, and sometimes are killed by the police, and nobody
faces any consequences), I feel no obligation to make my life harder just
for the sake of it.

We're talking about a country in which the chief of the police blew the
police headquarters with a grenade launcher that he smuggled from Ukraine,
and he was never punished for it.

https://www.bbc.com/news/world-europe-63993385

Law often just doesn't apply here.

https://en.wikipedia.org/wiki/Death_of_Igor_Stachowiak

https://worldnewsday.org/behind-the-headlines-investigating-death-sobering-station-wroclaw-poland/

https://notesfrompoland.com/2021/02/09/man-wrongly-imprisoned-for-18-years-wins-polands-highest-ever-compensation-payout/

> 1) how do you know that the request is legitimate without the
> documentation substantiating that it's legitimate.

It came from account in an official police domain, through a police mail
server, and I checked the logs to confirm that things they wrote about
really happened.

> 2) How do you know that the accused did anything illegal without
> substantiating evidence?

I don't know if it was legal or not. I'm not a lawyer. It's for the court
to decide. At this time they're just investigating.

> 3) What reputation do you want with your other users when it comes to
> protecting their information / privacy?

This is actually the most interesting question. When I interact with any
service, I feel that I'm responsible for protecting my data, if I want it
protected. I wouldn't assume or expect that anyone will go to legal
trouble to protect my data for me.

My users know (because it's written in the rules they, at least in theory,
should have read before using the service) that I comply with orders from
the police.

If everything I can produce after receiving such order is a temporary
email created via Tor and some useless IPs of open proxies, then well, I
did my part.

>> Then there's a need from the customer to make these devices communicate
>> with devices made by company B (the one I work for), and of course the
>> communication isn't reliable, but company A claims it's the fault of
>> our devices, and I'm asked to check what's really going on and make
>> it work.
>
> *sigh* ...
>
> Is company A bigger than company B?

That's the most interesting part. Company A is much smaller. It creates
devices for the Polish market. Company B is an international corporation
and it's almost certain that you interacted with our devices at some
point.

The problem is that the company is big, but the Polish team isn't. They
got the order for devices and we had to make it work.

>> (each behaving in a subtly different way in some cases) that I think
>> it would be full of bugs almost by design.
>
> Probably not /by/ /design/ per se. More likely lack of complete design.

With "by design" I mean that it's probably not possible to create a TCP/IP
implementation from scratch and expect it to work reasonably well with
variety of devices out there.