Richmond <dnomhcir@gmx.com> wrote:

> Nadegda <nad318b404@gmail.invalid> writes:
>
> > Time to trigger the right-wing snowflakes again. Melt, snowflakes, melt!
> > On Tue, 28 Mar 2023 10:39:51 +0100, Richmond wrote:
> >
> >> Nadegda <nad318b404@gmail.invalid> writes:
> >>
> >>> 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.
> >>
> >> I was able to connect to fleegle.mixmin.net using gnus. It complained
> >> that the certificate name did not match but I was able to accept it and
> >> post.
> >
> > kensi reports no joy trying with "fleegle.mixmin.net" in place of
> > "news.mixmin.net".
> >
> >> news.mixmin.net doesn't resolve anymore.
> >
> > Well, *that* is a *very* bad sign. Letting domain names lapse is generally
> > a sign of complete abandonment, at least when accompanied by other things
> > being broken rather than happening in isolation.
> >
> > I think we have a serious problem here, and it's much larger than just
> > some glitch at one single news server. It looks like someone is killing
> > off free newsservers one by one. The lack of meaningful communication
> > from their (former?) admins is suggestive of their arms being twisted.
> > It looks like they're being forced to sabotage, or at least cease
> > maintaining, their servers, and also ordered not to say anything about
> > this in public. Whoever's doing this is able to make credible threats
> > with international reach, so either we're dealing with a serious hacker
> > who has the skillz to dig up dirt on pretty much anyone they want to
> > and then threaten to expose it, or we're dealing with someone capable
> > of putting boots on the ground pretty much anywhere on the planet, so
> > likely either one of the larger mafias or a nation-state actor. The
> > most aggressive in recent years have been Russia and the United States
> > and the most censorious has tended to be China, so it's a three-way
> > toss-up who's responsible, if it *is* a nation-state actor. Though I'd
> > have expected China *and* Russia to settle for Great Firewalling all
> > Usenet servers within their respective territories, so I'm leaning
> > toward the good ol' US of A as the likely culprit here.
> >
> > The question then becomes: Why? And why *now*?
> >
> > But more likely it's the hacker scenario, in which case given their
> > known proclivities for doxxing and their hatred for kensi it's a fair
> > bet that it's one of the old-guard AUKers who's behind this. The idiot
> > took down AIOE first, and when I taunted that that isn't even the server
> > kensi uses these days, mixmin is, a few days later, bam! There goes
> > mixmin.
> >
> > So I suppose I bear some small portion of culpability. But the bulk of
> > your ire should be reserved for whichever asshole is willing to wreck
> > things for thousands of people and blackmail at least two of them just
> > to harass one ...
> >
> > As for who that might be, I've no idea. Most of kensi's opponents who
> > had any sort of technical know-how (K-man in particular) melted down
> > years ago and vanished off the face of the 'net. And none of them
> > seemed to have *enough* technical know-how to pull off something of
> > this magnitude. The closest any of them ever came was murphy, perhaps;
> > he attempted to dox *me* roughly a decade ago, even going so far as
> > to post a photo online of "my" house (needless to say he was off by
> > several thousand miles, and we all had a good laugh before nominating
> > him for a Pickett's Charge for going RL on one of his opponents, an
> > award he subsequently won by a landslide). With "competence" of this
> > magnitude it seems doubtful he could have successfully doxxed both
> > Paolo Amoroso *and* Steve Crook sufficiently to have blackmail material
> > on them both.
> >
> > If I *had* to hazard a guess as to the identity of the guilty party,
> > I'd say Sn!pe.
> >

OMG! Busted!! I should have known you'd work it out in the end.

Am I a shame-faced wading bird. ≈:o(

> >
> > He's made his antipathy for no-registration news servers
> > plain on multiple occasion, and it is exceeded only by his antipathy
> > for kensi. And although he's quiet about it it's clear he has more than
> > the average amount of technical knowledge, though it's less clear how
> > *much* more. He might have been hiding the full magnitude of his
> > capabilities, not least because he was planning to use them for criminal
> > purposes and preferred *not* to be at the top of Scotland Yard's suspect
> > list when that time came. (Unfortunately for him, that didn't pan out.
> > Worse still, he's at the top of *my* suspect list, and even more
> > frightening for him, he will likely soon be at the top of *kensi*'s. He'd
> > better start running *now*, if he is in fact the guilty party!)
> >
> > One more thing to note in all of this: the perpetrator would simply have
> > blackmailed kensi herself, if he could, before resorting to this Rube
> > Goldbergian scheme to destroy *every single news server* kensi has ever
> > posted through. He was subsequently able to easily amass blackmail
> > material against 2 generally well-regarded server admins. Make of that
> > what you will.
> >
> > (The correct answer, obviously, is "kensi is squeaky clean". <snicker>)
> >
>
> It could be just the price of electricity.
>

Nah, it was me all along. [twirls moustache, leers]

Oh well, that's me <snookered>...

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

<https://youtu.be/_kqytf31a8E>