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