Dated February 7, 2023

https://www.openssl.org/news/secadv/20230207.txt

Is QSL vulnerable?

Would the libraries need to be updated?

On 09 Feb 2023, Nomen Nescio <nobody@dizum.com> posted some
news:4fa228e72e9bb6eee1694805c8321b11@dizum.com:

> Dated February 7, 2023
>
> https://www.openssl.org/news/secadv/20230207.txt
>
> Is QSL vulnerable?

Probably. Does it apply?
> Would the libraries need to be updated?

Think about it. Applying Occam's razor, the origin and destination are
essentially confined in interactive scope. Meaning if QSL is vulnerable,
so is the entire remailer network.

Ask yourself this question, "Does my QSL client send anything in an
unencrypted X.400 format during interaction with a mixmaster remailer
server"?

On 2/9/2023 10:35 AM, bitster wrote:

> On 09 Feb 2023, Nomen Nescio <nobody@dizum.com> posted some
> news:4fa228e72e9bb6eee1694805c8321b11@dizum.com:
>
>> Dated February 7, 2023
>>
>> https://www.openssl.org/news/secadv/20230207.txt
>>
>> Is QSL vulnerable?
>
> Probably. Does it apply?
>
>> Would the libraries need to be updated?
>
> Think about it. Applying Occam's razor, the origin and destination are
> essentially confined in interactive scope. Meaning if QSL is vulnerable,
> so is the entire remailer network.
>
> Ask yourself this question, "Does my QSL client send anything in an
> unencrypted X.400 format during interaction with a mixmaster remailer
> server"?
>

Absolutely. You're right.

I wasn't trying to inject FUD here.

I do specifically recall some years back, in response
to the SSL Heartbleed vulnerability, Richard updated
the SSL libraries and issued an update to the QSL program.

My concern is, Richard is no longer around to do an update
if it was required.

On 09 Feb 2023, Anonymous <nobody@remailer.paranoici.org> posted some
news:6aeeb96cb7b7ee7d7caf49e0fe174aa6@remailer.paranoici.org:

>
> On 2/9/2023 10:35 AM, bitster wrote:
>
>> On 09 Feb 2023, Nomen Nescio <nobody@dizum.com> posted some
>> news:4fa228e72e9bb6eee1694805c8321b11@dizum.com:
>>
>>> Dated February 7, 2023
>>>
>>> https://www.openssl.org/news/secadv/20230207.txt
>>>
>>> Is QSL vulnerable?
>>
>> Probably. Does it apply?
>>
>>> Would the libraries need to be updated?
>>
>> Think about it. Applying Occam's razor, the origin and destination
>> are essentially confined in interactive scope. Meaning if QSL is
>> vulnerable, so is the entire remailer network.
>>
>> Ask yourself this question, "Does my QSL client send anything in an
>> unencrypted X.400 format during interaction with a mixmaster remailer
>> server"?
>>
>
>
> Absolutely. You're right.
>
> I wasn't trying to inject FUD here.
>
> I do specifically recall some years back, in response
> to the SSL Heartbleed vulnerability, Richard updated
> the SSL libraries and issued an update to the QSL program.
>
> My concern is, Richard is no longer around to do an update
> if it was required.

This?

2014-11-20 v1.0.8
1) UPDATED MIXMASTER TO 3.0.3a
2) Updated openssl to 1.0.1i
3) Added mixmaster version to the QSL About Box.
4) Fix bug in selecting final remailer from remailer
group.
5) Fixed a bug in allpingers selection. The list of stats
sources was not being cleared before the new sources
are added. Fixed.
6) Set QSL's SSL component to use TLS only. No SSLv2 and
no SSlv3.

On 2023-02-09, Nomen Nescio <nobody@dizum.com> wrote:
> Dated February 7, 2023
>
> https://www.openssl.org/news/secadv/20230207.txt
>
> Is QSL vulnerable?
>
> Would the libraries need to be updated?

Most OpenSSL bugs involve checking of chains
of certificates and do not concern us here.

The advisory says "When CRL checking is enabled".
CRL = Certificate Revocation List

So it shouldn't affect programs only using crypto features.

On 09 Feb 2023, bitster <none@anon.com> posted some
news:619e8cc9f36c8bfa87b786bcb3890c9b@dizum.com:

> On 09 Feb 2023, Nomen Nescio <nobody@dizum.com> posted some
> news:4fa228e72e9bb6eee1694805c8321b11@dizum.com:
>
>> Dated February 7, 2023
>>
>> https://www.openssl.org/news/secadv/20230207.txt
>>
>> Is QSL vulnerable?
>
> Probably. Does it apply?
>
>> Would the libraries need to be updated?
>
> Think about it. Applying Occam's razor, the origin and destination
> are essentially confined in interactive scope. Meaning if QSL is
> vulnerable, so is the entire remailer network.
>
> Ask yourself this question, "Does my QSL client send anything in an
> unencrypted X.400 format during interaction with a mixmaster remailer
> server"?

novell...????

On 09 Feb 2023, invisible <invisible@none.com> posted some
news:ts4am1$1bv5f$1@paganini.bofh.team:

> On 09 Feb 2023, bitster <none@anon.com> posted some
> news:619e8cc9f36c8bfa87b786bcb3890c9b@dizum.com:
>
>> On 09 Feb 2023, Nomen Nescio <nobody@dizum.com> posted some
>> news:4fa228e72e9bb6eee1694805c8321b11@dizum.com:
>>
>>> Dated February 7, 2023
>>>
>>> https://www.openssl.org/news/secadv/20230207.txt
>>>
>>> Is QSL vulnerable?
>>
>> Probably. Does it apply?
>>
>>> Would the libraries need to be updated?
>>
>> Think about it. Applying Occam's razor, the origin and destination
>> are essentially confined in interactive scope. Meaning if QSL is
>> vulnerable, so is the entire remailer network.
>>
>> Ask yourself this question, "Does my QSL client send anything in an
>> unencrypted X.400 format during interaction with a mixmaster remailer
>> server"?
>
> novell...????

Certainly! All remailer servers run off a specially modified Novell
Netware X.400 NDS using hybrid IPX/SPX bridging and Gropewise Massaging.

On Fri, 10 Feb 2023 11:02:27 +0100 (CET), anon <anon@anon.not> wrote:

>On 09 Feb 2023, invisible <invisible@none.com> posted some
>news:ts4am1$1bv5f$1@paganini.bofh.team:
>
>> On 09 Feb 2023, bitster <none@anon.com> posted some

>>>
>>> Ask yourself this question, "Does my QSL client send anything in an
>>> unencrypted X.400 format during interaction with a mixmaster remailer
>>> server"?
>>
>> novell...????
>
>Certainly! All remailer servers run off a specially modified Novell
>Netware X.400 NDS using hybrid IPX/SPX bridging and Gropewise Massaging.

Finally someone gets it right!

On 2/10/2023 9:33 AM, geo@wxyz.com wrote:

> On Fri, 10 Feb 2023 11:02:27 +0100 (CET), anon <anon@anon.not> wrote:
>
>> On 09 Feb 2023, invisible <invisible@none.com> posted some
>> news:ts4am1$1bv5f$1@paganini.bofh.team:
>>
>>> On 09 Feb 2023, bitster <none@anon.com> posted some
>
>>>>
>>>> Ask yourself this question, "Does my QSL client send anything in an
>>>> unencrypted X.400 format during interaction with a mixmaster
remailer
>>>> server"?
>>>
>>> novell...????
>>
>> Certainly! All remailer servers run off a specially modified Novell
>> Netware X.400 NDS using hybrid IPX/SPX bridging and Gropewise
Massaging.
>
> Finally someone gets it right!

+1 !!!

>>> https://www.openssl.org/news/secadv/20230207.txt
>>>
>>> Is QSL vulnerable?

Timing Oracle in RSA Decryption (CVE-2022-4304)

That bit possibly.

That kind of thing is why it's better for a crypto program
to receive traffic and write it to disk with no decryption yet.
Then decrypt it in a process that does no networking and
runs no other programs that do networking. Then send it in a
process that hasn't read any private key.

On 12 Feb 2023, elvis-85792@notatla.org.uk posted some
news:slrntuhtc6.e3c.elvis-85792@notatla.org.uk:

>>>> https://www.openssl.org/news/secadv/20230207.txt
>>>>
>>>> Is QSL vulnerable?
>
> Timing Oracle in RSA Decryption (CVE-2022-4304)
>
> That bit possibly.
>
> That kind of thing is why it's better for a crypto program
> to receive traffic and write it to disk with no decryption yet.
> Then decrypt it in a process that does no networking and
> runs no other programs that do networking. Then send it in a
> process that hasn't read any private key.

QSL has the occasional TLS interaction which I believe might be
exploitable if you wanted to put the time and effort into it. That is not
a dig at Richard. He was wrestling with universally flawed
implementations of SSL at the time and took what he felt was the safest
route. Time proved him correct.

Everything has vulnerabilities, some less concerning than others. As you
noted, it depends when certain elements of processing occur. Others
become apparent over time, in some cases mind-numbing development or
manufacturing mistakes that nobody considers looking for. Dell's defunct
DSS product line comes to mind.