On Tue, 11 Apr 2023 19:01:15 +0200, Ray Banana wrote:

> As Seamus has pointed out so eloquently many years ago, Steve and I are
> clandestinely conspiring and exchanging secret IP addresses in order to
> block access from certain users. In this case I made a bad mistake and gave him
> Kensi's instead of Nadegda's. Or was it the other way round? Anyway, my bad.

I'm sure you're joking Wolfgang, but I'm curious if you're even half
serious how you or Steve possibly could manage/block based on IP addresses
given VPNs are a dime a dozen nowadays.

I understand if you don't feel like responding as I think you were only
joking. But I can't see how it's possible, practically anyway - to do it.

Is it?

On 6/21/2023 10:53 PM, dan wrote:
> On Tue, 11 Apr 2023 19:01:15 +0200, Ray Banana wrote:
>
>
>> As Seamus has pointed out so eloquently many years ago, Steve and I are
>> clandestinely conspiring and exchanging secret IP addresses in order to
>> block access from certain users. In this case I made a bad mistake and gave him
>> Kensi's instead of Nadegda's. Or was it the other way round? Anyway, my bad.
>
> I'm sure you're joking Wolfgang

It's a perk (perquisite) that comes with the job.

*******

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

"During most of its existence, the cabal
(sometimes capitalized) steadfastly denied
its own existence"

They are shadowy figures, only coming out of
hiding long enough to reboot.

Paul

Paul <nospam@needed.invalid> wrote:

> On 6/21/2023 10:53 PM, dan wrote:
> > On Tue, 11 Apr 2023 19:01:15 +0200, Ray Banana wrote:
> >
> >
> >> As Seamus has pointed out so eloquently many years ago, Steve and I are
> >> clandestinely conspiring and exchanging secret IP addresses in order to
> >> block access from certain users. In this case I made a bad mistake and
> >> gave him Kensi's instead of Nadegda's. Or was it the other way round?
> >> Anyway, my bad.
> >
> > I'm sure you're joking Wolfgang
>
> It's a perk (perquisite) that comes with the job.
>
> *******
>
> https://en.wikipedia.org/wiki/Backbone_cabal
>
> "During most of its existence, the cabal
> (sometimes capitalized) steadfastly denied
> its own existence"
>
> They are shadowy figures, only coming out of
> hiding long enough to reboot.
>
> Paul
>

TINC, AAFK.

--
^Ï^. – Sn!pe – <https://youtu.be/_kqytf31a8E>

My pet rock Gordon just is.

On 22 Jun 2023, Paul <nospam@needed.invalid> posted some
news:u71vhh$3c4vn$1@dont-email.me:

> On 6/21/2023 10:53 PM, dan wrote:
>> On Tue, 11 Apr 2023 19:01:15 +0200, Ray Banana wrote:
>>
>>
>>> As Seamus has pointed out so eloquently many years ago, Steve and I
>>> are clandestinely conspiring and exchanging secret IP addresses in
>>> order to block access from certain users. In this case I made a bad
>>> mistake and gave him Kensi's instead of Nadegda's. Or was it the
>>> other way round? Anyway, my bad.
>>
>> I'm sure you're joking Wolfgang
>
> It's a perk (perquisite) that comes with the job.
>
> *******
>
> https://en.wikipedia.org/wiki/Backbone_cabal
>
> "During most of its existence, the cabal
> (sometimes capitalized) steadfastly denied
> its own existence"
>
> They are shadowy figures, only coming out of
> hiding long enough to reboot.

Binding decisions are made from the bottom at the top.

dan <nospam@nospam.com> wrote in news:u70d2s$snni$1@paganini.bofh.team:

> On Tue, 11 Apr 2023 19:01:15 +0200, Ray Banana wrote:
>
>
>> As Seamus has pointed out so eloquently many years ago, Steve and I
>> are clandestinely conspiring and exchanging secret IP addresses in
>> order to block access from certain users.

Just cancelling by sock alone would be good enough. You know, like the
good old days. Start with these two.

https://imgflip.com/i/6mamjy

sock#17F6 <sock#17f6@invalid.net> wrote:

> dan <nospam@nospam.com> wrote in news:u70d2s$snni$1@paganini.bofh.team:
>
> > On Tue, 11 Apr 2023 19:01:15 +0200, Ray Banana wrote:
> >
> >>
> >> As Seamus has pointed out so eloquently many years ago, Steve and I
> >> are clandestinely conspiring and exchanging secret IP addresses in
> >> order to block access from certain users.
> >>
>
> Just cancelling by sock alone would be good enough. You know, like the
> good old days. Start with these two.
>
> <https://imgflip.com/i/6mamjy>
>

Fake photo! This is the ~real~ Nadgeda and Kensi:

<https://imgur.com/a/FJXPuZm>

--
^Ï^. – Sn!pe – <https://youtu.be/_kqytf31a8E>

My pet rock Gordon just is.

On 25 Jun 2023, snipeco.2@gmail.com (Sn!pe) posted some
news:1qcwnut.o1hchsbpawdaN%snipeco.2@gmail.com:

> sock#17F6 <sock#17f6@invalid.net> wrote:
>
>> dan <nospam@nospam.com> wrote in news:u70d2s$snni$1@paganini.bofh.team:
>>
>> > On Tue, 11 Apr 2023 19:01:15 +0200, Ray Banana wrote:
>> >
>> >>
>> >> As Seamus has pointed out so eloquently many years ago, Steve and I
>> >> are clandestinely conspiring and exchanging secret IP addresses in
>> >> order to block access from certain users.
>> >>
>>
>> Just cancelling by sock alone would be good enough. You know, like the
>> good old days. Start with these two.
>>
>> <https://imgflip.com/i/6mamjy>
>>
>
> Fake photo! This is the ~real~ Nadgeda and Kensi:
>
><https://imgur.com/a/FJXPuZm>

That's incredible. I can see the resemblance immediately.

According to kensi, someone has apparently reconfigured mixmin to block
either posting in general, or posting by her specifically, and she's
been locked out for 24 hours now. She tried switching back to AIOE, only
to discover it's not been functioning for weeks (which is, quite frankly,
ridiculous and unconscionable when it wouldn't take half a week to stand
up a completely new NNTP server and point the domain name at that; the
time being wasted trying to fix the RAID problem instead of just starting
over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
EXPIRED BY NOW ANYWAY).

Anyway, kensi asked me to relay the following demand here in AFN:

----------
Either restore mixmin to normal immediately, or restore AIOE to normal
immediately. And stop monkeying with the free servers! Some people do not
have any alternatives, for any of a variety of reasons.
----------

That will be all for now.

Be it known, though, that any hacker exposed as the culprit behind this
latest problem will have me to answer to. Worse for them, at some point
they will likely have kensi to answer to, as well, and believe me when I
say that I've seen what happens to those kensi decides to utterly destroy,
and it is NOT pretty. You could fill a whole wing of Parkview Hospital
with them ...

--
FNVWe Nadegda

"By all means, compare these shitheads to Nazis. Again and again. I'm with
you." -- Mike Godwin, Aug 13, 2017, 8:03 PM
Checkmate admits that, for all intents and purposes, he carries a teddy
bear in public: <d6cnes.ket.17.19@news.alt.net>

Nadegda wrote:
>
> According to kensi, someone has apparently reconfigured mixmin to block
> either posting in general, or posting by her specifically, and she's
> been locked out for 24 hours now. She tried switching back to AIOE, only
> to discover it's not been functioning for weeks (which is, quite frankly,
> ridiculous and unconscionable when it wouldn't take half a week to stand
> up a completely new NNTP server and point the domain name at that; the
> time being wasted trying to fix the RAID problem instead of just starting
> over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
> EXPIRED BY NOW ANYWAY).
>
> Anyway, kensi asked me to relay the following demand here in AFN:
>
> ----------
> Either restore mixmin to normal immediately, or restore AIOE to normal
> immediately. And stop monkeying with the free servers! Some people do not
> have any alternatives, for any of a variety of reasons.
> ----------
>
> That will be all for now.
>
> Be it known, though, that any hacker exposed as the culprit behind this
> latest problem will have me to answer to. Worse for them, at some point
> they will likely have kensi to answer to, as well, and believe me when I
> say that I've seen what happens to those kensi decides to utterly destroy,
> and it is NOT pretty. You could fill a whole wing of Parkview Hospital
> with them ...

You tell them, Paul.
The bastards are all out to get you.

William Stickers <bill.stickers@innocent.com> wrote:

> Nadegda wrote:
> >
> > According to kensi, someone has apparently reconfigured mixmin to block
> > either posting in general, or posting by her specifically, and she's
> > been locked out for 24 hours now. She tried switching back to AIOE, only
> > to discover it's not been functioning for weeks (which is, quite frankly,
> > ridiculous and unconscionable when it wouldn't take half a week to stand
> > up a completely new NNTP server and point the domain name at that; the
> > time being wasted trying to fix the RAID problem instead of just starting
> > over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
> > EXPIRED BY NOW ANYWAY).
> >
> > Anyway, kensi asked me to relay the following demand here in AFN:
> >
> > ----------
> > Either restore mixmin to normal immediately, or restore AIOE to normal
> > immediately. And stop monkeying with the free servers! Some people do not
> > have any alternatives, for any of a variety of reasons.
> > ----------
> >
> > That will be all for now.
> >
> > Be it known, though, that any hacker exposed as the culprit behind this
> > latest problem will have me to answer to. Worse for them, at some point
> > they will likely have kensi to answer to, as well, and believe me when I
> > say that I've seen what happens to those kensi decides to utterly destroy,
> > and it is NOT pretty. You could fill a whole wing of Parkview Hospital
> > with them ...
> >

<https://www.dropbox.com/s/6zvnhu3amwqkped/abe0d25c5d9a8bf5a86587bb10180df3.jpg>

>
> You tell them, Paul.
> The bastards are all out to get you.
>

Shh! Don't clue him in, let it be a wonderful surprise when he
finds out for himself; then his <snicker> will be <snookered>.

--
^Ï^. – Sn!pe – My pet rock Gordon just is.

<https://youtu.be/_kqytf31a8E>

On Sun, 26 Mar 2023 07:41:40 -0000 (UTC), Nadegda <nad318b404@gmail.invalid> spurted out the following:
> According to kensi, someone has apparently reconfigured mixmin to block
> either posting in general, or posting by her specifically, and she's
> been locked out for 24 hours now. She tried switching back to AIOE, only
> to discover it's not been functioning for weeks (which is, quite frankly,
> ridiculous and unconscionable when it wouldn't take half a week to stand
> up a completely new NNTP server and point the domain name at that; the
> time being wasted trying to fix the RAID problem instead of just starting
> over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
> EXPIRED BY NOW ANYWAY).
>
> Anyway, kensi asked me to relay the following demand here in AFN:
>
> ----------
> Either restore mixmin to normal immediately, or restore AIOE to normal
> immediately. And stop monkeying with the free servers! Some people do not
> have any alternatives, for any of a variety of reasons.
> ----------
>
> That will be all for now.
>
> Be it known, though, that any hacker exposed as the culprit behind this
> latest problem will have me to answer to. Worse for them, at some point
> they will likely have kensi to answer to, as well, and believe me when I
> say that I've seen what happens to those kensi decides to utterly destroy,
> and it is NOT pretty. You could fill a whole wing of Parkview Hospital
> with them ...
>

That was me, I did it. I AM RESPONSIBLE. No, really, I am serious. It
was ME!!!

So fucking do something, bitch!

LOL

--
The Real Snoopy

On Sun, 26 Mar 2023 10:09:01 +0100, William Stickers <bill.stickers@innocent.com> spurted out the following:
> Nadegda wrote:
>>
>> According to kensi, someone has apparently reconfigured mixmin to block
>> either posting in general, or posting by her specifically, and she's
>> been locked out for 24 hours now. She tried switching back to AIOE, only
>> to discover it's not been functioning for weeks (which is, quite frankly,
>> ridiculous and unconscionable when it wouldn't take half a week to stand
>> up a completely new NNTP server and point the domain name at that; the
>> time being wasted trying to fix the RAID problem instead of just starting
>> over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
>> EXPIRED BY NOW ANYWAY).
>>
>> Anyway, kensi asked me to relay the following demand here in AFN:
>>
>> ----------
>> Either restore mixmin to normal immediately, or restore AIOE to normal
>> immediately. And stop monkeying with the free servers! Some people do not
>> have any alternatives, for any of a variety of reasons.
>> ----------
>>
>> That will be all for now.
>>
>> Be it known, though, that any hacker exposed as the culprit behind this
>> latest problem will have me to answer to. Worse for them, at some point
>> they will likely have kensi to answer to, as well, and believe me when I
>> say that I've seen what happens to those kensi decides to utterly destroy,
>> and it is NOT pretty. You could fill a whole wing of Parkview Hospital
>> with them ...
>
> You tell them, Paul.
> The bastards are all out to get you.

He can blame me for it.
--
The Real Snoopy

In article <tvosvk$2ddr3$2@dont-email.me>, nad318b404@gmail.invalid
says...
>
> According to kensi, someone has apparently reconfigured mixmin to block
> either posting in general, or posting by her specifically, and she's
> been locked out for 24 hours now. She tried switching back to AIOE, only
> to discover it's not been functioning for weeks (which is, quite frankly,
> ridiculous and unconscionable when it wouldn't take half a week to stand
> up a completely new NNTP server and point the domain name at that; the
> time being wasted trying to fix the RAID problem instead of just starting
> over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
> EXPIRED BY NOW ANYWAY).
>
> Anyway, kensi asked me to relay the following demand here in AFN:
>
> ----------
> Either restore mixmin to normal immediately, or restore AIOE to normal
> immediately. And stop monkeying with the free servers! Some people do not
> have any alternatives, for any of a variety of reasons.

You mean you can't afford a couple bucks a month?
> ----------
>
> That will be all for now.
>
> Be it known, though, that any hacker exposed as the culprit behind this
> latest problem will have me to answer to. Worse for them, at some point
> they will likely have kensi to answer to, as well, and believe me when I
> say that I've seen what happens to those kensi decides to utterly destroy,
> and it is NOT pretty. You could fill a whole wing of Parkview Hospital
> with them ...

It was me. Bring it bitch.

Time to trigger the right-wing snowflakes again. Melt, snowflakes, melt!
On Sun, 26 Mar 2023 07:41:40 +0000, Nadegda wrote:

> According to kensi, someone has apparently reconfigured mixmin to block
> either posting in general, or posting by her specifically

I now have more information from kensi. It seems mixmin keeps fumbling
network connections, sometimes only a second or two after connecting:

----------
200 news.mixmin.net InterNetNews NNRP server INN 2.7.0 (20211218 prerelease) ready (posting ok)

Connection to host lost.
----------

Does anyone know what would cause this? Perhaps a certificate issue?
She seems to recall discussions here in the past regarding mixmin switching
from CACert to LetsEncrypt. Has that recently been done? What would likely
need to be done in the way of client-side reconfiguration afterward?

Though my own thinking is that she wouldn't even be able to see the server's
greeting message if TLS was failing to handshake ...

--
FNVWe Nadegda

"By all means, compare these shitheads to Nazis. Again and again. I'm with
you." -- Mike Godwin, Aug 13, 2017, 8:03 PM
Checkmate admits that, for all intents and purposes, he carries a teddy
bear in public: <d6cnes.ket.17.19@news.alt.net>

On 3/26/23 9:31 AM, Nadegda wrote:
> Does anyone know what would cause this? Perhaps a certificate issue?
> She seems to recall discussions here in the past regarding mixmin
> switching from CACert to LetsEncrypt. Has that recently been done? What
> would likely need to be done in the way of client-side reconfiguration
> afterward?

How a certificate is acquired is completely independent of the
certificate and what it does.

Just like how you power your computer is completely independent of what
you use your computer for.

Similarly, clients wouldn't need to change anything when servers change
how the server acquires it's certificate.

> Though my own thinking is that she wouldn't even be able to see the
> server's greeting message if TLS was failing to handshake ...

It depends what port is being used.

I can see a hypothetical scenario where someone is connecting to port
119 and /explicitly/ requesting encryption via the `STARTTLS` verb.
They could see the initial hello banner before the connection failed in
some way while trying to use encryption.

I can think of a few different things that might cause encryption
negotiation to fail. Internet connection problems related to MTU, old
root certificates on the client, changes in cipher suite configuration
on the server (possibly via system updates), etc.

A network sniffer; e.g. tcpdump, tshark, Wireshark, is your friend when
trying to diagnose these types of connection issues.

--
Grant. . . .
unix || die

On 3/26/2023 12:01 PM, Grant Taylor wrote:
> On 3/26/23 9:31 AM, Nadegda wrote:
>> Does anyone know what would cause this? Perhaps a certificate issue? She seems to recall discussions here in the past regarding mixmin switching from CACert to LetsEncrypt. Has that recently been done? What would likely need to be done in the way of client-side reconfiguration afterward?
>
> How a certificate is acquired is completely independent of the certificate and what it does.
>
> Just like how you power your computer is completely independent of what you use your computer for.
>
> Similarly, clients wouldn't need to change anything when servers change how the server acquires it's certificate.
>
>> Though my own thinking is that she wouldn't even be able to see the server's greeting message if TLS was failing to handshake ...
>
> It depends what port is being used.
>
> I can see a hypothetical scenario where someone is connecting to port 119 and /explicitly/ requesting encryption via the `STARTTLS` verb. They could see the initial hello banner before the connection failed in some way while trying to use encryption.
>
> I can think of a few different things that might cause encryption negotiation to fail.  Internet connection problems related to MTU, old root certificates on the client, changes in cipher suite configuration on the server (possibly via system updates), etc.
>
> A network sniffer; e.g. tcpdump, tshark, Wireshark, is your friend when trying to diagnose these types of connection issues.
>

When I use Wireshark here, I'm getting a steady stream of this from news.mixmin.net:563

[RST,ACK] 144.76.182.167 ==> 192.168.0.2

so basically the server is telling everyone to "piss off".

No certificates are involved at that level :-/ It is not
an exchange of packets followed by a "kaboom". It's dead,
out of the gate.

The web server still works, so it is not a "general machine" problem
by the looks of it. Just related to a service that
"does not want to talk to anyone today".

Shades of the previous problem, or a new problem ?

It's perfectly normal for a server to issue a [RST], like
for a temporary resource shortage. But this is every packet
sent on that port number, is getting nacked. It is also possible
for DPI boxes, to shut off comms to a particular machine, using
[RST]. (The DPI box sends an [RST] in both directions.) So that
is a second failure mechanism (my old ISP had that
problem, a mis-programmed DPI box). If you were concerned about
which mechanism was at work, you could study the timestamps on
the responses.

But I'm pretty sure, based on statistics and occurrence frequency
of problems, this is a Mixmin-local problem.

Paul

On 3/26/23 11:12 AM, Paul wrote:
> When I use Wireshark here, I'm getting a steady stream of this from
> news.mixmin.net:563
>
> [RST,ACK] 144.76.182.167 ==> 192.168.0.2
>
> so basically the server is telling everyone to "piss off".

I suspect it's more "no service at this port" than it is "piss off".

Have you tried TCP port 119 w/ STARTTLS? I'm able to get connection and
what looks to be a valid TLS certificate that way.

% openssl s_client -connect news.mixmin.net:119 -starttls nntp 2>/dev/null
CONNECTED(00000003)
---
Certificate chain
0 s:CN = news.mixmin.net
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
3 s:O = Digital Signature Trust Co., CN = DST Root CA X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFJTCCBA2gAwIBAgISBDpyiO1qxqG2ljev7V1z9PaiMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzAzMjExODUyMzRaFw0yMzA2MTkxODUyMzNaMBoxGDAWBgNVBAMT
D25ld3MubWl4bWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ALrWi9I41vIbZTeElRdRbIPHG6dQnZRM0HmYEH7rTbxQOWKmTSR55Y2K0rsl3g8y
UK7TjNFsQ44br0ZyNEZi9jfvaCnqxRJLt2Gp4fK8mB/CoymgU4/Ou2UjZJ8YqAH8
aSJjVkcmo97AWRbYzTn40WQH19tyw4HPcRy0dGqlieAM55fcMbqc6e6eo5EK69N6
Qr7mfkZZxrBOuwUkp9bEiFHjYoFXZItX0SELpAPyq83uJgCyEW3pcPeEaXgrvOwh
MV416hKFdvreJnnAxwtgZeSgKwGEfPeu391BHqbsV5pp01seKhrIY0/lK60/g7H1
hfO9Vwyhj5BOUXpf8X976A8CAwEAAaOCAkswggJHMA4GA1UdDwEB/wQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNV
HQ4EFgQULsumFpNR/713W+y0LIlUpX6ywUkwHwYDVR0jBBgwFoAUFC6zF7dYVsuu
UAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8v
cjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9y
Zy8wGgYDVR0RBBMwEYIPbmV3cy5taXhtaW4ubmV0MEwGA1UdIARFMEMwCAYGZ4EM
AQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0
c2VuY3J5cHQub3JnMIIBBQYKKwYBBAHWeQIEAgSB9gSB8wDxAHcAtz77JN+cTbp1
8jnFulj0bF38Qs96nzXEnh0JgSXttJkAAAGHBbsEAwAABAMASDBGAiEAt/oToBl4
3qnZUmgma1dGxfe5FgwELiEegtxkClenfEkCIQD4oFmVfA7WxZ3MP3tBKePY4nbM
pTrCfinGXKMrRVDzfwB2AHoyjFTYty22IOo44FIe6YQWcDIThU070ivBOlejUutS
AAABhwW7BCQAAAQDAEcwRQIgNpBHCd8agfRSDMjSLWTEG8DENbVBtCU728GPxyjJ
VZcCIQCz8LnziFF05vof4uXay8/vj95ORQIcpoTK9LmazJlfnTANBgkqhkiG9w0B
AQsFAAOCAQEAsIs6Nn2u7iaObgrs6/gkozyvQtWDZ8GAeRGrXFJfPb49O1nP1Ytj
7UZdftCBrq3zJTwS4x6HzYHn5MQKq30V7RzdQWrg7+uWlYR96J8NlEqvH7+aeZqj
/baB4mXPOd0h3lF2Asmdef2ashZr2faMmhVhWY4p2teYINXP++eyjkmyKhZ1yL6W
qCXZbZi/8Sy6KctMAB1bhyxQbRyCIdroOa8DI46Kr3Q+tXbc2bTVW7MWeIz/XEfo
fFGWIUpQ47ubYwdp2GDkIrVi7sz2g3UxxIHDYaWyECPi3P4aRIkHp197qfjIR/VC
ay9FEG+vmCm6YuMwLaOtbRdRbzYHlsKNnQ==
-----END CERTIFICATE-----

> Shades of the previous problem, or a new problem ?

Is there a problem?

> It's perfectly normal for a server to issue a [RST], like for a
> temporary resource shortage. But this is every packet sent on that
> port number, is getting nacked.

There are a number of things that could explain why /explicit/ TLS works
on port 119 via the `STARTTLS` verb and why /implicit/ TLS doesn't work
on port 563.

> It is also possible for DPI boxes, to shut off comms to a
> particular machine, using [RST]. (The DPI box sends an [RST] in both
> directions.)

Don't forget that the RST packets need to have source IP (and other
details) pretending to be the other system.

However I doubt that's the case. Especially with /explicit/ TLS working
when using the `STARTTLS` verb on TCP port 119.

> So that is a second failure mechanism (my old ISP had that problem,
> a mis-programmed DPI box). If you were concerned about which mechanism
> was at work, you could study the timestamps on the responses.

Hanlon's razor comes to mind.

> But I'm pretty sure, based on statistics and occurrence frequency of
> problems, this is a Mixmin-local problem.

It may be something as simple as the daemon that provides /implicit/ TLS
connectivity on TCP port 563 isn't running.

--
Grant. . . .
unix || die

In article <tvpogo$2og4s$1@dont-email.me>, nad318b404@gmail.invalid
says...
>
> Time to trigger the right-wing snowflakes again. Melt, snowflakes, melt!
> On Sun, 26 Mar 2023 07:41:40 +0000, Nadegda wrote:
>
> > According to kensi, someone has apparently reconfigured mixmin to block
> > either posting in general, or posting by her specifically
>
> I now have more information from kensi. It seems mixmin keeps fumbling
> network connections, sometimes only a second or two after connecting:
>
> ----------
> 200 news.mixmin.net InterNetNews NNRP server INN 2.7.0 (20211218 prerelease) ready (posting ok)
>
>
> Connection to host lost.
> ----------
>
> Does anyone know what would cause this? Perhaps a certificate issue?
> She seems to recall discussions here in the past regarding mixmin switching
> from CACert to LetsEncrypt. Has that recently been done? What would likely
> need to be done in the way of client-side reconfiguration afterward?
>
> Though my own thinking is that she wouldn't even be able to see the server's
> greeting message if TLS was failing to handshake ...

Maybe mixmin is sick of your lies.

Time to trigger the right-wing snowflakes again. Melt, snowflakes, melt!
On Sun, 26 Mar 2023 13:12:54 -0400, Paul wrote:

> On 3/26/2023 12:01 PM, Grant Taylor wrote:
>> On 3/26/23 9:31 AM, Nadegda wrote:
>>> Does anyone know what would cause this? Perhaps a certificate issue? She seems to recall discussions here in the past regarding mixmin switching from CACert to LetsEncrypt. Has that recently been done? What would likely need to be done in the way of client-side reconfiguration afterward?
>>
>> How a certificate is acquired is completely independent of the certificate and what it does.
>>
>> Just like how you power your computer is completely independent of what you use your computer for.
>>
>> Similarly, clients wouldn't need to change anything when servers change how the server acquires it's certificate.
>>
>>> Though my own thinking is that she wouldn't even be able to see the server's greeting message if TLS was failing to handshake ...
>>
>> It depends what port is being used.
>>
>> I can see a hypothetical scenario where someone is connecting to port 119 and /explicitly/ requesting encryption via the `STARTTLS` verb. They could see the initial hello banner before the connection failed in some way while trying to use encryption.
>>
>> I can think of a few different things that might cause encryption negotiation to fail.  Internet connection problems related to MTU, old root certificates on the client, changes in cipher suite configuration on the server (possibly via system updates), etc.
>>
>> A network sniffer; e.g. tcpdump, tshark, Wireshark, is your friend when trying to diagnose these types of connection issues.
>>
>
> When I use Wireshark here, I'm getting a steady stream of this from news.mixmin.net:563
>
> [RST,ACK] 144.76.182.167 ==> 192.168.0.2
>
> so basically the server is telling everyone to "piss off".
>
> No certificates are involved at that level :-/ It is not
> an exchange of packets followed by a "kaboom". It's dead,
> out of the gate.
>
> The web server still works, so it is not a "general machine" problem
> by the looks of it. Just related to a service that
> "does not want to talk to anyone today".
>
> Shades of the previous problem, or a new problem ?
>
> It's perfectly normal for a server to issue a [RST], like
> for a temporary resource shortage. But this is every packet
> sent on that port number, is getting nacked. It is also possible
> for DPI boxes, to shut off comms to a particular machine, using
> [RST]. (The DPI box sends an [RST] in both directions.) So that
> is a second failure mechanism (my old ISP had that
> problem, a mis-programmed DPI box). If you were concerned about
> which mechanism was at work, you could study the timestamps on
> the responses.
>
> But I'm pretty sure, based on statistics and occurrence frequency
> of problems, this is a Mixmin-local problem.
>
> Paul

That's bizarre, since kensi was able to get the server greeting
message.

As for DPI boxes, nobody should use them. They violate the end-to-end
principle. And the main uses I've heard of for them are all evil:
censorious regimes (think "China"); injecting ads and other unwanted
garbage for commercial gain (aka spamming); and malicious interference
with apps the superrich don't like people using (think Bittorrent). The
only legitimate use-case I can think of for them off-hand is antimalware,
and that use-case is defeated by the widespread use of TLS on both web and
email connections.

Basically, in the presence of pervasive end-to-end encryption the only
thing a DPI box can do that an ordinary perimeter firewall or local antivirus
can't is obstruct two third parties from talking to each other even if they
themselves both want to communicate (so, censorship) and compile a list of
who's talking to who (so, espionage).

Hence, evil.

And breaks the end-to-end principle and therefore breaks the internet.

Hence, stupid *and* evil.

--
FNVWe Nadegda

"By all means, compare these shitheads to Nazis. Again and again. I'm with
you." -- Mike Godwin, Aug 13, 2017, 8:03 PM
Checkmate admits that, for all intents and purposes, he carries a teddy
bear in public: <d6cnes.ket.17.19@news.alt.net>

On 3/26/23 11:44 AM, Nadegda wrote:
> As for DPI boxes, nobody should use them.

Deep Packet Inspection is a tool / technique. And like all tools /
techniques, it can be used for both good and / or bad.

I have a firewall rule that looks for a specific string in queries to my
DNS servers. Said string is for a zone that I don't host and I don't
provide recursive services. It's a string that a bot uses for an
amplification attack.

I'm using -- what is arguably -- DPI to identify and block those DNS
queries from ever hitting my DNS server. -- The last time I looked I
had over a million requests for that query filtered.

> They violate the end-to-end principle.

No, Deep Packet Inspection does not violate the end-to-end principle.
Anybody can filter anything they want to anywhere on their network. How
they do it is up to them.

NAT violates the end-to-end principle in that there is no possible way
for each end to communicate directly without the assistance of something
else translating traffic.

> And the main uses I've heard of for them are all evil:

By your own words; "the main uses", implies that there are other uses.

As stated above, not all uses for DPI are evil.

> censorious regimes (think "China"); injecting ads and other
> unwanted garbage for commercial gain (aka spamming); and malicious
> interference with apps the superrich don't like people using (think
> Bittorrent).

Altering the stream without terminating it is considerably more than
/just/ DPI. It's also more evil than /just/ DPI.

> The only legitimate use-case I can think of for them off-hand is
> antimalware,

So you agree that there are acceptable uses for DPI.

> and that use-case is defeated by the widespread use of TLS on both
> web and email connections.

I'm trying to decide if TLS monkey-in-the-middle counts as DPI or not.
I think it's more active proxying than it is DPI.

I also think that DPI conceptually could happen even with TLS if the DPI
system has access to the keys and no PFS / ephemeral keys are used.
E.g. a company puts the web server's TLS keys on a DPI box so that they
can inspect traffic at the edge for compliance reasons.

> Basically, in the presence of pervasive end-to-end encryption the
> only thing a DPI box can do that an ordinary perimeter firewall or
> local antivirus can't is obstruct two third parties from talking
> to each other even if they themselves both want to communicate (so,
> censorship) and compile a list of who's talking to who (so, espionage).

A perimeter firewall / router can easily obstruct two parties from
talking to each other. You don't need DPI for that.

A perimeter firewall / router can easily compile a list of who's
talking. NetFlow and the likes are specifically meant for things like
this. You don't need DPI for that either.

> Hence, evil.

DPI is a tool. A tool by itself is not inherently evil.

How the tool is most commonly used may be evil.

> And breaks the end-to-end principle and therefore breaks the internet.

DPI doesn't break the end-to-end principle.

> Hence, stupid *and* evil.

Nope.

--
Grant. . . .
unix || die

In article <tvq09p$2og4s$2@dont-email.me>, nad318b404@gmail.invalid
says...
>
> Time to trigger the right-wing snowflakes again. Melt, snowflakes, melt!
> On Sun, 26 Mar 2023 13:12:54 -0400, Paul wrote:
>
> > On 3/26/2023 12:01 PM, Grant Taylor wrote:
> >> On 3/26/23 9:31 AM, Nadegda wrote:
> >>> Does anyone know what would cause this? Perhaps a certificate issue? She seems to recall discussions here in the past regarding mixmin switching from CACert to LetsEncrypt. Has that recently been done? What would likely need to be done in the way of client-side reconfiguration afterward?
> >>
> >> How a certificate is acquired is completely independent of the certificate and what it does.
> >>
> >> Just like how you power your computer is completely independent of what you use your computer for.
> >>
> >> Similarly, clients wouldn't need to change anything when servers change how the server acquires it's certificate.
> >>
> >>> Though my own thinking is that she wouldn't even be able to see the server's greeting message if TLS was failing to handshake ...
> >>
> >> It depends what port is being used.
> >>
> >> I can see a hypothetical scenario where someone is connecting to port 119 and /explicitly/ requesting encryption via the `STARTTLS` verb. They could see the initial hello banner before the connection failed in some way while trying to use encryption.
> >>
> >> I can think of a few different things that might cause encryption negotiation to fail.  Internet connection problems related to MTU, old root certificates on the client, changes in cipher suite configuration on the server (possibly via system updates), etc.
> >>
> >> A network sniffer; e.g. tcpdump, tshark, Wireshark, is your friend when trying to diagnose these types of connection issues.
> >>
> >
> > When I use Wireshark here, I'm getting a steady stream of this from news.mixmin.net:563
> >
> > [RST,ACK] 144.76.182.167 ==> 192.168.0.2
> >
> > so basically the server is telling everyone to "piss off".
> >
> > No certificates are involved at that level :-/ It is not
> > an exchange of packets followed by a "kaboom". It's dead,
> > out of the gate.
> >
> > The web server still works, so it is not a "general machine" problem
> > by the looks of it. Just related to a service that
> > "does not want to talk to anyone today".
> >
> > Shades of the previous problem, or a new problem ?
> >
> > It's perfectly normal for a server to issue a [RST], like
> > for a temporary resource shortage. But this is every packet
> > sent on that port number, is getting nacked. It is also possible
> > for DPI boxes, to shut off comms to a particular machine, using
> > [RST]. (The DPI box sends an [RST] in both directions.) So that
> > is a second failure mechanism (my old ISP had that
> > problem, a mis-programmed DPI box). If you were concerned about
> > which mechanism was at work, you could study the timestamps on
> > the responses.
> >
> > But I'm pretty sure, based on statistics and occurrence frequency
> > of problems, this is a Mixmin-local problem.
> >
> > Paul
>
> That's bizarre, since kensi was able to get the server greeting
> message.
>
> As for DPI boxes, nobody should use them. They violate the end-to-end
> principle. And the main uses I've heard of for them are all evil:
> censorious regimes (think "China"); injecting ads and other unwanted
> garbage for commercial gain (aka spamming); and malicious interference
> with apps the superrich don't like people using (think Bittorrent). The
> only legitimate use-case I can think of for them off-hand is antimalware,
> and that use-case is defeated by the widespread use of TLS on both web and
> email connections.
>
> Basically, in the presence of pervasive end-to-end encryption the only
> thing a DPI box can do that an ordinary perimeter firewall or local antivirus
> can't is obstruct two third parties from talking to each other even if they
> themselves both want to communicate (so, censorship) and compile a list of
> who's talking to who (so, espionage).
>
> Hence, evil.
>
> And breaks the end-to-end principle and therefore breaks the internet.
>
> Hence, stupid *and* evil.

You cry about free stuff. Typical woke broke liberal.

In article <tvq13a$pij$1@tncsrv09.home.tnetconsulting.net>,
gtaylor@tnetconsulting.net says...
>
> On 3/26/23 11:44 AM, Nadegda wrote:
> > As for DPI boxes, nobody should use them.
>
> Deep Packet Inspection is a tool / technique. And like all tools /
> techniques, it can be used for both good and / or bad.
>
> I have a firewall rule that looks for a specific string in queries to my
> DNS servers. Said string is for a zone that I don't host and I don't
> provide recursive services. It's a string that a bot uses for an
> amplification attack.
>
> I'm using -- what is arguably -- DPI to identify and block those DNS
> queries from ever hitting my DNS server. -- The last time I looked I
> had over a million requests for that query filtered.
>
> > They violate the end-to-end principle.
>
> No, Deep Packet Inspection does not violate the end-to-end principle.
> Anybody can filter anything they want to anywhere on their network. How
> they do it is up to them.
>
> NAT violates the end-to-end principle in that there is no possible way
> for each end to communicate directly without the assistance of something
> else translating traffic.
>
> > And the main uses I've heard of for them are all evil:
>
> By your own words; "the main uses", implies that there are other uses.
>
> As stated above, not all uses for DPI are evil.
>
> > censorious regimes (think "China"); injecting ads and other
> > unwanted garbage for commercial gain (aka spamming); and malicious
> > interference with apps the superrich don't like people using (think
> > Bittorrent).
>
> Altering the stream without terminating it is considerably more than
> /just/ DPI. It's also more evil than /just/ DPI.
>
> > The only legitimate use-case I can think of for them off-hand is
> > antimalware,
>
> So you agree that there are acceptable uses for DPI.
>
> > and that use-case is defeated by the widespread use of TLS on both
> > web and email connections.
>
> I'm trying to decide if TLS monkey-in-the-middle counts as DPI or not.
> I think it's more active proxying than it is DPI.
>
> I also think that DPI conceptually could happen even with TLS if the DPI
> system has access to the keys and no PFS / ephemeral keys are used.
> E.g. a company puts the web server's TLS keys on a DPI box so that they
> can inspect traffic at the edge for compliance reasons.
>
> > Basically, in the presence of pervasive end-to-end encryption the
> > only thing a DPI box can do that an ordinary perimeter firewall or
> > local antivirus can't is obstruct two third parties from talking
> > to each other even if they themselves both want to communicate (so,
> > censorship) and compile a list of who's talking to who (so, espionage).
>
> A perimeter firewall / router can easily obstruct two parties from
> talking to each other. You don't need DPI for that.
>
> A perimeter firewall / router can easily compile a list of who's
> talking. NetFlow and the likes are specifically meant for things like
> this. You don't need DPI for that either.
>
> > Hence, evil.
>
> DPI is a tool. A tool by itself is not inherently evil.
>
> How the tool is most commonly used may be evil.
>
> > And breaks the end-to-end principle and therefore breaks the internet.
>
> DPI doesn't break the end-to-end principle.
>
> > Hence, stupid *and* evil.
>
> Nope.

Nads is a liberal crybaby.

On 3/26/23 12:03 PM, Skeeter wrote:
> Nads is a liberal crybaby.

That may, or may not, be the case.

I don't particularly care.

If someone wants to have a polite and civil discussion about a topic
that I'm interested in, then I'll do so. At least until I get tired of
the discussion.

--
Grant. . . .
unix || die

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 3/26/23 12:03 PM, Skeeter wrote:

>>Nads is a liberal crybaby.

>That may, or may not, be the case.

>I don't particularly care.

>If someone wants to have a polite and civil discussion about a topic
>that I'm interested in, then I'll do so. At least until I get tired of
>the discussion.

Isn't it less difficult to see that the other person has a point if the
other person doesn't repeatedly change socks to fake the existence of a
disinterested third party supporting his position?

"Nadegda" isn't pretending to be human except in Paul's own mind. (Paul
has a mind? Yes yes, I know. Post proof, ko0ky.)

There are still enough people on Usenet to speak to who don't morph
continuously.

I'm suggesting a fairly low bar here.

In article <tvq563$40n$1@tncsrv09.home.tnetconsulting.net>,
gtaylor@tnetconsulting.net says...
>
> On 3/26/23 12:03 PM, Skeeter wrote:
> > Nads is a liberal crybaby.
>
> That may, or may not, be the case.
>
> I don't particularly care.
>
> If someone wants to have a polite and civil discussion about a topic
> that I'm interested in, then I'll do so. At least until I get tired of
> the discussion.

Then Kensi/Nads won't work for you.