diff options
Diffstat (limited to 'README.SSL')
| -rw-r--r-- | README.SSL | 34 |
1 files changed, 18 insertions, 16 deletions
@@ -11,10 +11,9 @@ specific to fetchmail. In case of troubles, mail the README.SSL-SERVER file to your ISP and have them check their server configuration against it. -Unfortunately, fetchmail confuses SSL/TLS protocol levels with whether a -service needs to use in-band negotiation (STLS/STARTTLS for POP3/IMAP4) -or is totally SSL-wrapped on a separate port. For compatibility -reasons, this cannot be fixed in a bugfix or minor release. +Note that fetchmail up to version 6.3.26 confused SSL/TLS protocol levels with +whether a service needs to use in-band negotiation (STLS/STARTTLS for +POP3/IMAP4) or is totally SSL-wrapped on a separate port. Also, fetchmail 6.4.0 and newer releases changed some of the semantics as the result of a bug-fix, and will auto-negotiate TLSv1 or newer only. @@ -22,15 +21,19 @@ If your server does not support this, you may have to specify --sslproto ssl3+. This is in order to prefer the newer TLS protocols, because SSLv2 and v3 are broken. - -- Matthias Andree, 2016-01-10 + -- Matthias Andree, 2019-08-18 Quickstart ---------- Use an up-to-date release of OpenSSL 1.0.2 or newer, so as to get -TLSv1.2 support. Older OpenSSL versions are unsupported upstream, and -fetchmail rejects them. +TLSv1.2 support. If possibly use a TLS1.3-enabled OpenSSL v1.1.1 or newer. +Older OpenSSL versions are unsupported upstream, and fetchmail rejects them. + +In all four examples below, the (--)sslcertck has become redunant +since fetchmail v6.4.0 but since fetchmail 6.3 releases will be in circulation +for a while, we'll leave it here to be safe. For use of SSL or TLS with in-band negotiation on the regular service's port, i. e. with STLS or STARTTLS, use these command line options @@ -56,9 +59,9 @@ or these options in the rcfile (after the respective "user"... options) Background and use (long version :-)) ------------------ -Using fetchmail's "ssl" option, you can have the data transferred between you -and the server in an encrypted form, so that eavesdropping should become -practically impossible. +Using fetchmail's "ssl" and since 6.4.0 "sslproto" options, +you can have the data transferred between you and the server in an encrypted +form, so that eavesdropping should become practically impossible. This works as follows: the server has a key pair (a secret and a public key), and it sends the client its public key. Messages encrypted with the public key @@ -86,10 +89,11 @@ document). This certificate contains the server's public key, some data about the server, and a digital signature and data about the signer. Digital signatures can also be made using a key pair as described earlier. -To check this certificate, you should use the new option "sslcertck". When it -is specified, the signature of the server certificate is checked against local -trusted certificates to see whether the owner of one of the certificates has -signed that server certificate, and if so, whether the signature is valid. +To check this certificate, you should use the new option "sslcertck" (fetchmail +6.4.0 and newer enable it by default). When it is specified, the signature of +the server certificate is checked against local trusted certificates to see +whether the owner of one of the certificates has signed that server +certificate, and if so, whether the signature is valid. So, if the server certificate is signed by a Certification Authority (CA), you put the CA's certificate into a directory where you keep trusted certificates, and point fetchmail to it. Fetchmail will then accept @@ -141,7 +145,5 @@ with a ":" separating two bytes (i.e. a ":" between every two hex "digits"). The match is case insensitive since release 6.3.10 (upper-case digits A to F were required up to and including release 6.3.9). -*CAVEAT*: OpenSSL must be at least version 0.9.7 to be able to check CRLs. - - Thomas Moestl <tmoestl@gmx.net> - Matthias Andree |