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?

Gunther F <grunther@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.

"Adam W." <gof-cut-this-news@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).

Gunther F <grunther@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."

On 1/10/24 01:05, Gunther F wrote:
> "Adam W." <gof-cut-this-news@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.

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. . . .

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.

Gunther F <grunther@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/

Grant Taylor <gtaylor@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?

Richard Kettlewell <invalid@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?

Marco Moock <mm+usenet-es@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.

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

> Marco Moock <mm+usenet-es@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.

Gunther F <grunther@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.

"Adam W." <gof-cut-this-news@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?

Marco Moock <mm+usenet-es@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.

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.

Gunther F <grunther@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.

Gunther F <grunther@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.

Gunther F <grunther@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).

Gunther F <grunther@nospam.edu> writes:
> Richard Kettlewell <invalid@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?

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/

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. . . .

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. . . .

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. . . .

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. . . .

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. . . .