Am 02.01.22 um 15:28 schrieb Matthias Andree: >>> 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...
It started with Internet browsers wanting confirmation every time an https certificate is not publicly verifiable. The key point of surveillance is to get people to disclose private communications and servers. For example, with Tor, all traffic goes through only one or a few outbound servers, so it's easy to see who is using such evil technology. Packets can be correlated over the time. >> 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. This point is not clear. When you have a copy of the downloaded public certificate you can check against it or not? So when somebody tries to fake the certificate without having the private certificate this should be conspicuous. In this case i understand the sense of this trust store. > > 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. This is definitely a coin with two sides. >> 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? When possible you should check the fingerprint of the used certificate. After checking this certificate and connection can be trusted. Right? > Company networks with malware-scanning outside proxies, free WiFi sites, > you name it. > > You don't verify, you don't know. Not for every website of course, but for a private account that is used daily. >> 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. Is there any documentation for DAU's (dumbest presumed user) out there? With examples how to use it? > 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. I agree (in the meantime) that this is a useful pedagogical method. :-) >> 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. That was good for users like me. > 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. Yes - this is a feature and not a bug. But it would be still wonderful if the lazy users have a chance to use encryption without studying documentation for weeks. Cheers karsten
