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.

--
Grant. . . .

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

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

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

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

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

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

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?

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

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

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

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.

--
Grant. . . .

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

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

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

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

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.

--
Grant. . . .

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