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. The people that can make MITM/eavesdropping attacks can fake an CA-authority too. Do you think it is possible to make thousands of MITM/eavesdropping attacks parallel for every private server? Can you please recommend *other* options to ensure more security with self signed certificates? >> >> 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. >>> In this case the original private certificate from the server is needed? >>> >>> Why a client must have additional files now to access an server > > No. That's the wrong question to ask. Do not ask "why they are needed > now", but "why have older fetchmail versions made proper trust > verification optional" for so many years. Why have older fetchmail versions made proper trust verification optional? :-) > And another question to ask is "why do users ignore manuals and NEWS > files of the applications they use" That's a really good question. When I think about it, the honest answer is probably laziness and to some extent disinterest. You set up a server at a certain point in time and as soon as it is running smoothly, you don't change anything about it - true to the motto "don't touch a running system". To the best of the knowledge and understanding, you have installed encrypted communication and hope that this is both sufficient and maintained through security updates. > And a third one, to third parties and outside of this bug's context "how > do we get proper yet concise certificate trust management documentation > in prominent places?". This is a very good question too! The most important problem is that this encryption stuff is very complicate to avoid to say "to complicate". You have to have the affinity to want to understand it, to really see through the details. > > One half is really OpenSSL basic usage and how to maintain its trust > store, and one half is, sorry to be so blunt, a half-baked approach at > trying to be your own CA without knowing what you are doing. That's correct. It is an unsuccessful attempt to bridge the gap between encryption in use and complete understanding of it. > Fetchmail's expectation is that the server-presented single self-signed > certificate, or normally certificate chain, traces back to a root > signing certificate that is "trusted" and is installed in your local > computer's OpenSSL trust store (the one running fetchmail), and trusted > in a way that it properly verifies the sub-CAs it authenticates with > respect to the policies and practices they implement. But this is all > OpenSSL trust handling and, again, not specific to fetchmail. Thank you for this explanation - that helps me to follow you. Cheers karsten
