Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 17:11 schrieb Karsten: Basically you can install the self-signed certificate (if you or a trusted party signed it, and you have transmitted it over a secure channel, for instance, via SFTP or SCP) into the trust store (assuming it suits both the TLS server and the signing CA roles - which was set when you created it). Just for understanding - the installation is the public certificate of the server, or must be a special file derived from the private certificate? "It depends" - on how you exactly you generated it - even if you only created it with "openssl req -x509 ...", the openssl configuration files matter. Normally, 1. the client's trust store (OpenSSL on the fetchmail computer) needs the CA certificate, i. e. one with the CA flag set to true in the basicConstraints, or basicContraints missing, see the x509(1ssl) manual page under CERTIFICATE EXTENSIONS. 2. Then, the server needs to present a certificate that is suitable as "SSL Server" (extendedKeyUsage = serverAuth) role. See the x509v3_config(5ssl) manual page for details. If your server's certificate does not fulfill both criteria, you better start over and set up a ca (and store its private key password-protected in a safe place, as you seldomly need it), and a separate server cert signed by your own ca. easy-rsa may help with that. Check /usr/share/doc/easy-rsa, easy-rsa has README files, but no manual page. To check: openssl x509 -noout -text -in whatever.crt # or whatever.pem shows you that, here for a CA certificate: X509v3 Basic Constraints: CA:TRUE ... X509v3 Key Usage: Certificate Sign, CRL Sign The TLS server has X509v3 Basic Constraints: CA:FALSE ... X509v3 Extended Key Usage: TLS Web Server Authentication Some of this may not be enforced in currently shipping fetchmail versions, but since a lot of public foot-shooting was involved in third-party documentation that advised trust-on-first-use schemes without warning people of the dangers involved, future versions might actually tighten things even more, so, f.i. validate CA flags of all but the server certificate. I don't currently use Debian or derivatives as so you need to check [update-]ca-certificates documentation and configuration to be sure that your certificate is (a) put in the right place where update-ca-certificate finds it, (b) "enabled" in configuration and processed into the output trust store, and (c) not in a place where it will be removed on system upgrades. dpkg-reconfigure ca-certificates - possibly with some modified priority option - might be required. That stackexchange link in the earlier message hints that there were changes somewhen in the past, and also be sure to re-check documentation since the answer there is older than Debian 11. No, where does that access happen? The trust store is local to your computer and fetchmail might use your system's DNS resolver (which can have privacy implications) and will connect to the servers you point it to. First you send your certificate to the public CA to sign it. Then an client must connect the CA to proove that the public certificate is correct signed. Correct or wrong? If I am my own CA, I am not sending something anywhere. I install the ca certificate on my clients' trust stores, put its (the CA) private keys on a CD or USB key so it's not left on my computer (let alone on my server), and that's it. I've been doing that for more than a dozen years; for public services however Let's Encrypt is a viable alternative.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 16:07 schrieb Matthias Andree: > Am 02.01.22 um 14:03 schrieb Karsten: >> Am 02.01.22 um 12:15 schrieb Matthias Andree: I am the owner of the domain so nobody is hijacked! >>> Are you the owner of "mydomain.de" or of the unnamed domain you intended >>> not to show to the public? >> Do you want to help with this new certificate issue or discuss the ownership >> of domains? > > In this case, the latter. There are dedicated domain names for everyone > to use for documentation and test purposes, > https://datatracker.ietf.org/doc/html/rfc6761#section-6.5 Aha - O.K. >> With the search "install OpenSSL trust store" i could find this article: >> https://support.code42.com/CP/Admin/On-premises/6/Configuring/Use_OpenSSL_to_install_a_keystore >> that explains much of the stuff, but not how to use an self-signed >> certificate. > > https://unix.stackexchange.com/questions/90450/adding-a-self-signed-certificate-to-the-trusted-list/ > but check the fine print and lower rated comments, too -- for recent > ca-certificates packages. Thank you - that is very helpful. > Basically you can install the self-signed certificate (if you or a > trusted party signed it, and you have transmitted it over a secure > channel, for instance, via SFTP or SCP) into the trust store (assuming > it suits both the TLS server and the signing CA roles - which was set > when you created it). Just for understanding - the installation is the public certificate of the server, or must be a special file derived from the private certificate? >> >> This worked for more then 5 years with TLS1.2 without any problem. >> Why this must be a problem now? > > Because "working" does not imply "working safely and securely". Yes - but the connection was still encrypted and not plain text. The connection was just not secure against all forms of attacks. >> Take the example Mozilla and please explain why it works without an "OpenSSL >> trust store" ? > > > Mozilla applications ship with their own trust store and do not use > OpenSSL, but incorporate their own TLS library called NSS. O.K. But how this helps to connect to a server with self-signed certificates? >> O.K. Then you have no request to this CA-servers for every connect to a >> server with a certificate, but every private >> server is registered there and every client will request the "trust" once to >> access the server. >> So you can made a profil who is using a server. That's the simple goal of it. > > > No, where does that access happen? The trust store is local to your > computer and fetchmail might use your system's DNS resolver (which can > have privacy implications) and will connect to the servers you point it to. First you send your certificate to the public CA to sign it. Then an client must connect the CA to proove that the public certificate is correct signed. Correct or wrong? > It uses OpenSSL's unless you override that (see man fetchmail for > --ssl... options). I promise to take the time to learn this part about using OpenSSL. > I understand, but too many variables involved and neither of us has time > for guesswork. I don't know how your CA (even if only implied for that > certificate) is set up or whatever else is needed, and I don't intend to > do consulting. I only used this silly OpenSSL command to generate the self-signed certificate and filled the questions OpenSSL asked. It should not be much more complicate to use a local trust store. > Figuratively speaking, you need to learn how to fish, not be given the fish. Fishing get's more and more complex. But it's true and i must learn it. >> When this is a standard procedure, why it is not possible to find existing >> examples how to handle it? >> Why it is still possible to fetch Data with TLS1.2 from the FTP-Server >> without similar problems? > > fetchmail doesn't do FTP, and FTP is being phased out because it's hard > to get right with its two connections, active/passive mode, > firewalls/NAT/conntrack, TLS being added afterwards and I guess it was > superseded by many other protocols that either tunnel through SSH or use > one TLS connection, for instance, DAV. That's the way i thought it is working. TLS is used to establish a secure encrypted connection and afterwards the rest is tunneled through it? Then it is not crucial how complex the protocol is. when two or more ports are needed then more secure connections must be established. > It is probably not about TLS version numbers anyways, but generally > tightened security. You upgraded the entire client system, and that > brought a lot of changes. > https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1 > might also be involved. I have to go through each different service that uses encryption, email, ftp, xmpp, etc. Maybe i will find a general better way to manage the certificates for encryption. Thank you for your invested time! karsten
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
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
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 14:03 schrieb Karsten: Am 02.01.22 um 12:15 schrieb Matthias Andree: I am the owner of the domain so nobody is hijacked! Are you the owner of "mydomain.de" or of the unnamed domain you intended not to show to the public? Do you want to help with this new certificate issue or discuss the ownership of domains? In this case, the latter. There are dedicated domain names for everyone to use for documentation and test purposes, https://datatracker.ietf.org/doc/html/rfc6761#section-6.5 With the search "install OpenSSL trust store" i could find this article: https://support.code42.com/CP/Admin/On-premises/6/Configuring/Use_OpenSSL_to_install_a_keystore that explains much of the stuff, but not how to use an self-signed certificate. https://unix.stackexchange.com/questions/90450/adding-a-self-signed-certificate-to-the-trusted-list/ but check the fine print and lower rated comments, too -- for recent ca-certificates packages. Basically you can install the self-signed certificate (if you or a trusted party signed it, and you have transmitted it over a secure channel, for instance, via SFTP or SCP) into the trust store (assuming it suits both the TLS server and the signing CA roles - which was set when you created it). This worked for more then 5 years with TLS1.2 without any problem. Why this must be a problem now? Because "working" does not imply "working safely and securely". Take the example Mozilla and please explain why it works without an "OpenSSL trust store" ? Mozilla applications ship with their own trust store and do not use OpenSSL, but incorporate their own TLS library called NSS. Untrue. Mozilla's certificates are installed for offline use by Debian, Fedora, FreeBSD and derived distros under names such as ca-certificates, ca_root_nss or similar. AFAICS and up to and including OpenSSL 3.0.0, OpenSSL does not perform Online Certificate Status Protocol (OCSP) polls, so no calling home involved to date. O.K. Then you have no request to this CA-servers for every connect to a server with a certificate, but every private server is registered there and every client will request the "trust" once to access the server. So you can made a profil who is using a server. That's the simple goal of it. No, where does that access happen? The trust store is local to your computer and fetchmail might use your system's DNS resolver (which can have privacy implications) and will connect to the servers you point it to. Thanks - but now i still have no idea where to search for the trust store of fetschmail? It uses OpenSSL's unless you override that (see man fetchmail for --ssl... options). Why it is not possible to give the needed commands like before, like openssl req -x509 -newkey rsa:4096 -keyout /etc/exim4/exim.key.pem -out /etc/exim4/exim.cert.pem -days 365 -nodes ? The reason is the lack of understanding what has changed and what must be done and not to bother you. I understand, but too many variables involved and neither of us has time for guesswork. I don't know how your CA (even if only implied for that certificate) is set up or whatever else is needed, and I don't intend to do consulting. Figuratively speaking, you need to learn how to fish, not be given the fish. When this is a standard procedure, why it is not possible to find existing examples how to handle it? Why it is still possible to fetch Data with TLS1.2 from the FTP-Server without similar problems? fetchmail doesn't do FTP, and FTP is being phased out because it's hard to get right with its two connections, active/passive mode, firewalls/NAT/conntrack, TLS being added afterwards and I guess it was superseded by many other protocols that either tunnel through SSH or use one TLS connection, for instance, DAV. It is probably not about TLS version numbers anyways, but generally tightened security. You upgraded the entire client system, and that brought a lot of changes. https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1 might also be involved.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
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.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
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
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 12:15 schrieb Matthias Andree: >> I am the owner of the domain so nobody is hijacked! > > Are you the owner of "mydomain.de" or of the unnamed domain you intended > not to show to the public? Do you want to help with this new certificate issue or discuss the ownership of domains? >> A self signing certificate is absolutely sufficient and perfect for private >> use. > > Then install your own CA or (if marked as CA-suitable) issuer > certificate it into your fetchmail client's OpenSSL trust store, or a > separate location, and move on. I want to do this - what must be done? >> The same TLS1.2 as before shall be used, so it is not understandable why >> addtional things are mandantory now? >> Why old certificates cannot be used any more when the client that uses a >> server is upgraded? > > It is not about certificates, but - as László pointed out - about > repairing fetchmail's security requirements from substandard to "Stand > der Technik". fetchmail 6.4.0 made --sslcertck the default, as various > places of the documentation (man page, NEWS file) point out. When this method is "state of the art", why it is not explained somewhere? With the search "install OpenSSL trust store" i could find this article: https://support.code42.com/CP/Admin/On-premises/6/Configuring/Use_OpenSSL_to_install_a_keystore that explains much of the stuff, but not how to use an self-signed certificate. > The standard use case for fetchmail is to fetch mail from "big sites" > and those can be expected to handle proper certification chains. I agree - but is a private mail-server something that must be eliminated? > Your use case is "run my own TLS server"; in that case fetchmail can > safely assume people are aware what they are doing and how to handle trust. This worked for more then 5 years with TLS1.2 without any problem. Why this must be a problem now? In the Internet are a mass of similar problems with fetchmail, but no description what exactly must be done to solve it. >>> Because "similar problems" are usually a broken setup of either >>> server-side certificates that don't trace back to commonly used and >>> trusted stores (Mozilla's trusted CA package, mostly), or local broken >>> setups. Take the example Mozilla and please explain why it works without an "OpenSSL trust store" ? >> This "stores" are a big problem of public monitoring, because every >> certificate causes requests to this central "stores". > > Untrue. Mozilla's certificates are installed for offline use by Debian, > Fedora, FreeBSD and derived distros under names such as ca-certificates, > ca_root_nss or similar. AFAICS and up to and including OpenSSL 3.0.0, > OpenSSL does not perform Online Certificate Status Protocol (OCSP) > polls, so no calling home involved to date. O.K. Then you have no request to this CA-servers for every connect to a server with a certificate, but every private server is registered there and every client will request the "trust" once to access the server. So you can made a profil who is using a server. That's the simple goal of it. > https://manpages.debian.org/buster/ca-certificates/update-ca-certificates.8.en.html > might be a starting point. Thanks - but now i still have no idea where to search for the trust store of fetschmail? Why it is not possible to give the needed commands like before, like openssl req -x509 -newkey rsa:4096 -keyout /etc/exim4/exim.key.pem -out /etc/exim4/exim.cert.pem -days 365 -nodes ? The reason is the lack of understanding what has changed and what must be done and not to bother you. >> But it would be helpful for others what must be done to create and install >> this new "client side certificate" that >> appears about 2018? > > That's standard TLS library procedure and not specific to fetchmail. The > only specific part is that fetchmail uses OpenSSL, so your self-signing > server certificate belongs into OpenSSL's trust store, or you can use > one or both of the --sslcert* options to fetchmail. When this is a standard procedure, why it is not possible to find existing examples how to handle it? Why it is still possible to fetch Data with TLS1.2 from the FTP-Server without similar problems? Thank you for your help - we are coming to an solution in little steps. Cheers karsten
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 11:54 schrieb Karsten: Am 01.01.22 um 17:53 schrieb László Böszörményi (GCS): On Sat, Jan 1, 2022 at 2:30 PM Karsten wrote: 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. 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. 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. And another question to ask is "why do users ignore manuals and NEWS files of the applications they use" 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?". 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. 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.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 01.01.22 um 14:26 schrieb Karsten: Hello Matthias, Am 01.01.22 um 14:10 schrieb Matthias Andree: Notice something? i notice everything. :-) You hijack somebody else's domain for "anonymization" purposes and expect someone to help you, and you did not respond to hints the server CA's signing certificate might be missing from the trust store. I am the owner of the domain so nobody is hijacked! Are you the owner of "mydomain.de" or of the unnamed domain you intended not to show to the public? A self signing certificate is absolutely sufficient and perfect for private use. Then install your own CA or (if marked as CA-suitable) issuer certificate it into your fetchmail client's OpenSSL trust store, or a separate location, and move on. The same TLS1.2 as before shall be used, so it is not understandable why addtional things are mandantory now? Why old certificates cannot be used any more when the client that uses a server is upgraded? It is not about certificates, but - as László pointed out - about repairing fetchmail's security requirements from substandard to "Stand der Technik". fetchmail 6.4.0 made --sslcertck the default, as various places of the documentation (man page, NEWS file) point out. The standard use case for fetchmail is to fetch mail from "big sites" and those can be expected to handle proper certification chains. Your use case is "run my own TLS server"; in that case fetchmail can safely assume people are aware what they are doing and how to handle trust. In the Internet are a mass of similar problems with fetchmail, but no description what exactly must be done to solve it. Because "similar problems" are usually a broken setup of either server-side certificates that don't trace back to commonly used and trusted stores (Mozilla's trusted CA package, mostly), or local broken setups. This "stores" are a big problem of public monitoring, because every certificate causes requests to this central "stores". Untrue. Mozilla's certificates are installed for offline use by Debian, Fedora, FreeBSD and derived distros under names such as ca-certificates, ca_root_nss or similar. AFAICS and up to and including OpenSSL 3.0.0, OpenSSL does not perform Online Certificate Status Protocol (OCSP) polls, so no calling home involved to date. https://manpages.debian.org/buster/ca-certificates/update-ca-certificates.8.en.html might be a starting point. But it would be helpful for others what must be done to create and install this new "client side certificate" that appears about 2018? That's standard TLS library procedure and not specific to fetchmail. The only specific part is that fetchmail uses OpenSSL, so your self-signing server certificate belongs into OpenSSL's trust store, or you can use one or both of the --sslcert* options to fetchmail.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 01.01.22 um 17:53 schrieb László Böszörményi (GCS): > On Sat, Jan 1, 2022 at 2:30 PM Karsten wrote: >> 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. > OpenSSL might not have forced its usage or just ignored it if it > wasn't present? But in modern times everyone should be aware of > privacy and if s/he really connects to the valid server and not > suffering a man in the middle attack. As noted, if you don't care > about your own safety, just use fetchmail with --nosslcertck. I'm caring about safety and privacy, that's the reason encryption with private certificates are used. > You should already have your Certificate Authority (CA) key. The > missing step documented there: > https://www.ssl.com/how-to/export-certificates-private-key-from-pkcs12-file-with-openssl/ > and is (where INFILE is your CA key in PKCS #12 format): > openssl pkcs12 -in INFILE.p12 -out OUTFILE.crt -nokeys > Then feed it to fetchmail with --sslcertfile. But I don't do it often, > might be wrong as I don't even know your particular state. In this case the original private certificate from the server is needed? Why a client must have additional files now to access an server? Sorry, but this basics are not understandable. Cheers karsten
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
On Sat, Jan 1, 2022 at 2:30 PM Karsten wrote: > 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. OpenSSL might not have forced its usage or just ignored it if it wasn't present? But in modern times everyone should be aware of privacy and if s/he really connects to the valid server and not suffering a man in the middle attack. As noted, if you don't care about your own safety, just use fetchmail with --nosslcertck. You should already have your Certificate Authority (CA) key. The missing step documented there: https://www.ssl.com/how-to/export-certificates-private-key-from-pkcs12-file-with-openssl/ and is (where INFILE is your CA key in PKCS #12 format): openssl pkcs12 -in INFILE.p12 -out OUTFILE.crt -nokeys Then feed it to fetchmail with --sslcertfile. But I don't do it often, might be wrong as I don't even know your particular state. Regards, Laszlo/GCS
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Hello Matthias, Am 01.01.22 um 14:10 schrieb Matthias Andree: > Notice something? i notice everything. :-) > > You hijack somebody else's domain for "anonymization" purposes and > expect someone to help you, and you did not respond to hints the server > CA's signing certificate might be missing from the trust store. I am the owner of the domain so nobody is hijacked! A self signing certificate is absolutely sufficient and perfect for private use. Why everybody has to be forced to use official certificates? > Checking with another computer that has a proper installation is > impossible if you fake data. Sorry for that, but we are talking about private data and this is an official portal here. > Be sure to install and configure the ca-certificates package - in case > you had installed fetchmail with --no-install-recommends. The server has been upgraded from Debian 9 to Debian 11. So nothing has been manually installed or configured, espacially any ca-certificates package. The same TLS1.2 as before shall be used, so it is not understandable why addtional things are mandantory now? Why old certificates cannot be used any more when the client that uses a server is upgraded? >> In the Internet are a mass of similar problems with fetchmail, but no >> description what exactly must be done to solve it. > > Because "similar problems" are usually a broken setup of either > server-side certificates that don't trace back to commonly used and > trusted stores (Mozilla's trusted CA package, mostly), or local broken > setups. This "stores" are a big problem of public monitoring, because every certificate causes requests to this central "stores". Another problem is to work with certificates and networks, that have no internet connection. > HTH - else you need to provide original data and more information. I can send this private to your email address. But it would be helpful for others what must be done to create and install this new "client side certificate" that appears about 2018? Best regards karsten
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Hello Matthias, Am 31.12.21 um 20:05 schrieb Matthias Andree: >> What must be done to get it working again? This question has not been answered. I could only find out that this problems did arrive with the introduction of TLS1.3. > Unless you own "mydomain.de" you've now hit innocent bystanders, and in > that case, making up log data with a domain you do not own is not helpful. The security relevant logdata is of course anonymized or altered. > > If Thunderbird can fetch, either it has a local trust setting, or you've > missed installing the ca-certificates package, or, as László suggested, > the certificate is self-signed and you have not installed the signing > CA's certificate in the trust store. The OS of the client PC with Thunderbird and of the mailserver has not been upgraded, so why there should appear any problem? The problem only appears on the upgraded server, that downloads the emails and provides them internally. There where no problems with the upgrade of exim or dovecot, only with fetchmail. In the Internet are a mass of similar problems with fetchmail, but no description what exactly must be done to solve it. So maybe it would be a good idea to create such needed certificates with the upgrade scripts. Happy new year karsten
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Happy new year Karsten. Am 01.01.22 um 13:53 schrieb Karsten: Hello Matthias, Am 31.12.21 um 20:05 schrieb Matthias Andree: What must be done to get it working again? This question has not been answered. [...] The security relevant logdata is of course anonymized or altered. Notice something? . . . You hijack somebody else's domain for "anonymization" purposes and expect someone to help you, and you did not respond to hints the server CA's signing certificate might be missing from the trust store. Checking with another computer that has a proper installation is impossible if you fake data. Be sure to install and configure the ca-certificates package - in case you had installed fetchmail with --no-install-recommends. In the Internet are a mass of similar problems with fetchmail, but no description what exactly must be done to solve it. Because "similar problems" are usually a broken setup of either server-side certificates that don't trace back to commonly used and trusted stores (Mozilla's trusted CA package, mostly), or local broken setups. HTH - else you need to provide original data and more information. Regards, Matthias
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
On Fri, Dec 31, 2021 at 8:09 PM Matthias Andree wrote: > > The log says: [...] > > fetchmail: Server certificate verification error: self signed certificate > > fetchmail: Missing trust anchor certificate: [...] > > What must be done to get it working again? Snipped to the relevant part of the log for both of you. > Unless you own "mydomain.de" you've now hit innocent bystanders, and in > that case, making up log data with a domain you do not own is not helpful. Yeah, she mocked her mail (and web) domain badly. She might have used [mydomain] or just localhost.localdomain > If Thunderbird can fetch, either it has a local trust setting, or you've > missed installing the ca-certificates package, or, as László suggested, > the certificate is self-signed and you have not installed the signing > CA's certificate in the trust store. I think it's the latter. She can test it with openssl as well: openssl s_client -showcerts -connect [her_domain]:993 -servername [her_domain] She will see something like the following: CONNECTED(0003) [...] No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA Server Temp Key: ECDH, P-384, 384 bits --- SSL handshake has read 2513 bytes and written 462 bytes Verification error: self signed certificate --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Thus OpenSSL will also raise the error for the self signed certificate and show that no client certificate exists. There's nothing we can do instead of Karen. It's better to close this bug report. Regards, Laszlo/GCS
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 31.12.21 um 16:32 schrieb Karsten: Package: fetchmail Version: 6.4.16-4+deb11u1 Severity: important I upgraded the server from Debian 9 to 11 and afterwards it seems not possible to get fetchmail to work. I tried every possible option of ssl and sslproto, but fetchmail can't fetch the mails. The log says: fetchmail: Trying to connect to 185.11.xxx.xxx/993...connected. fetchmail: Server certificate: fetchmail: Issuer Organization: mydomain fetchmail: Issuer CommonName: mydomain.de fetchmail: Subject CommonName: mydomain.de fetchmail: mydomain.de key fingerprint: 7C:CA:43:33:2A:12:B6:8D:83:3C:6E:88:0F:40:4B:6F fetchmail: Server certificate verification error: self signed certificate fetchmail: Missing trust anchor certificate: /C=DE/ST=germany/L=here/O=mydomain/OU=Privacy/CN=mydomain.de/emailAddress=webmas...@mydomain.de fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. See README.SSL for details. fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed fetchmail: mydomain.de: SSL connection failed. It is possible to work with Tunderbird (Debian11) direct with the mailserver (Dovecot on Debian 8), but not to download the emails with fetchmail. What must be done to get it working again? Unless you own "mydomain.de" you've now hit innocent bystanders, and in that case, making up log data with a domain you do not own is not helpful. If Thunderbird can fetch, either it has a local trust setting, or you've missed installing the ca-certificates package, or, as László suggested, the certificate is self-signed and you have not installed the signing CA's certificate in the trust store.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Hi Karsten, On Fri, Dec 31, 2021 at 4:36 PM Karsten wrote: > I upgraded the server from Debian 9 to 11 and afterwards it seems not > possible to get fetchmail to work. > > I tried every possible option of ssl and sslproto, but fetchmail can't fetch > the mails. > The log says: [...] > fetchmail: Server certificate verification error: self signed certificate > fetchmail: Missing trust anchor certificate: > /C=DE/ST=germany/L=here/O=mydomain/OU=Privacy/CN=mydomain.de/emailAddress=webmas...@mydomain.de > fetchmail: This could mean that the root CA's signing certificate is not in > the trusted CA certificate location, or that > c_rehash needs to be run on the certificate directory. For details, please > see the documentation of --sslcertpath and > --sslcertfile in the manual page. See README.SSL for details. [...] > What must be done to get it working again? Did you read the verbose information? Your server uses a self-signed certificate, which doesn't have any trust. You can supply the client side certificate with --sslcertfile or (by shooting yourself on the foot) you can disable the certificate validation setting with --nosslcertck. Regards, Laszlo/GCS
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Package: fetchmail Version: 6.4.16-4+deb11u1 Severity: important I upgraded the server from Debian 9 to 11 and afterwards it seems not possible to get fetchmail to work. I tried every possible option of ssl and sslproto, but fetchmail can't fetch the mails. The log says: fetchmail: Trying to connect to 185.11.xxx.xxx/993...connected. fetchmail: Server certificate: fetchmail: Issuer Organization: mydomain fetchmail: Issuer CommonName: mydomain.de fetchmail: Subject CommonName: mydomain.de fetchmail: mydomain.de key fingerprint: 7C:CA:43:33:2A:12:B6:8D:83:3C:6E:88:0F:40:4B:6F fetchmail: Server certificate verification error: self signed certificate fetchmail: Missing trust anchor certificate: /C=DE/ST=germany/L=here/O=mydomain/OU=Privacy/CN=mydomain.de/emailAddress=webmas...@mydomain.de fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. See README.SSL for details. fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed fetchmail: mydomain.de: SSL connection failed. It is possible to work with Tunderbird (Debian11) direct with the mailserver (Dovecot on Debian 8), but not to download the emails with fetchmail. What must be done to get it working again? Cheers karsten -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
