Am 02.01.22 um 14:24 schrieb Karsten:
Am 02.01.22 um 12:28 schrieb Matthias Andree:
But it would be helpful for others what must be done to create and install this new
"client side certificate" that
appears about 2018?
I think the certificate issue was there right from the beginning.
Definitely no. Mails where fetched for about 5 years without any problem.
Untrue. Messages were fetched without proper protection from
MITM/eavesdropping attacks, unless you were using *other* options to
ensure authenticity of the server. Which I doubt, else you would have
asked specific questions about fetchmail options.
That's true - but you change the privacy with an voluntary registration at an
CA-authority.
I don't see anyone suggested that, but tell me how...
The people that can make MITM/eavesdropping attacks can fake an CA-authority
too.
...that CA certificate would make it into your trust store. There used
to be ill-advised instructions by fourth parties that gave the wrong
advise to download and storing the server's certificate into the trust
store. If the faked CA authority certificate is not in your trust store,
certificate validation will flag the missing trust anchor or issue
"self-signed certificate" errors.
In practice, Linux and BSD distros usually deploy the CAs from Mozilla's
CA Program https://blog.mozilla.org/security/category/ca-program/ and
Mozilla have banned CAs that were abusive.
Do you think it is possible to make thousands of MITM/eavesdropping attacks
parallel for every private server?
You can safely bet it happens at scale, and million-fold each and every
day. The question is who will make the faked CA authority trustworthy?
Company networks with malware-scanning outside proxies, free WiFi sites,
you name it.
You don't verify, you don't know.
Can you please recommend *other* options to ensure more security with self
signed certificates?
See my previous messages, put the CA certificate (not private key) that
signed your server's certificate into the OpenSSL trust store of the
computer running fetchmail, or into a local place that you point
fetchmail to. That won't work without reading documentation on how
certification chains and trust delegation work. In the Debian world,
things revolve around update-ca-certificates from the ca-certificates
package.
I'm caring about safety and privacy, that's the reason encryption with private
certificates are used.
Nonsense. That's the reason why fetchmail 6.4.0 finally broke
compatibility with broken sites and finally (far too late) enforces
proper X.509 certificate chains to so-called trust anchors.
Can you explain this a little bit more please?
Using encryption with an self-signed certificate cannot be more nonsense then
to use no encryption at all.
This makes no sense for me from a logic point.
That's not what I wrote, but the logic you refer to is why fetchmail 6.4
- finally - forbids unverified certificates by default.
Meaning: No more connection to sites with incomplete certification
chains or where the certification chain cannot be anchored to a trusted CA.
Why have older fetchmail versions made proper trust verification optional? :-)
6.3 appeared in 2005, before E. Snowden hat blown the whistle and before
web browsers started to flag sites with unverified certification chains
as insecure - and 6.3.X has kept compatibility and defaults.
Before this turns into more gossip, I propose to close the bug report
now. Do that by replying to 1002910-cl...@bugs.debian.org instead of the
1002910@ address.
