Pileus Git - ~andy/fetchmail/blob - README.SSL

   1 Fetchmail SSL support
   2 =====================
   3
   4 Note: there is a separate document describing the server-side
   5 requirements for proper SSL support. It has checklist-style and not
   6 specific to fetchmail.
   7
   8 In case of troubles, mail it to your ISP and have them check it.
   9
  10         -- Matthias Andree, 2009-05-09
  11
  12
  13 Fetchmail's client-side SSL support
  14 -----------------------------------
  15
  16 NOTE: This text is maybe not explanatory enough, so a little knowledge about
  17 public-key-cryptography and associated topics is required.
  18
  19 Using the fetchmail ssl option, you can have the data transferred between you
  20 and the server in an encrypted form, so that eavesdropping should become
  21 practically impossible.
  22
  23 This works as following: the server has a key pair (a secret and a public key),
  24 and it sends the client it's public key. Messages encrypted with the public key
  25 can be decrypted using the private one and vice versa.
  26 A symmetric session key (symmetric means that the same key is used for
  27 encryption and decryption) can now be agreed upon by the two parties using
  28 the secure channel the key pair builds. The session key is now used to encrypt
  29 the traffic.
  30
  31 In the fetchmail case, the client can now authenticate itself to the server by
  32 using the usual POP/IMAP/whatever authentication mechanisms.
  33
  34 However, so called man-in-the-middle attacks are still possible: in such a
  35 setting, an attacker imposes the server, and thus can e.g. get your
  36 authentication information if you don't use a challenge based authentication
  37 mechanism (because he is thought to be the real server, fetchmail will try to
  38 authenticate against it by telling it your password).
  39
  40 So, not only you need to prove your identity to the server, the server likewise
  41 needs to prove it's to you.
  42 In the standard setting, the server has a certificate (the client can have a
  43 certificate too to prove its identity, but this is not covered by this
  44 document). This certificate contains the server's public key, some data about
  45 the server, and a digital signature and data about the signer.
  46 Digital signatures can also be made using a key pair as described earlier.
  47
  48 To check this certificate, you may use the new option sslcertck. When it is
  49 specified, the signature of server certificate is checked against local trusted
  50 certificates to see whether the owner of one of the ceritificates has signed
  51 that server certificate, and if so, whether the signature is valid.
  52 So, if the server certificate is signed by a Certification Authority (CA),
  53 you put the CA's certificate into a directory where you keep trusted
  54 certificates, and point fetchmail to it. Fetchmail will then accept certificates
  55 signed by the owner of that certificate with the private key belonging to the
  56 public key in the certificate.
  57 You can specifiy this path using the sslcertpath option.
  58 The idea is that the CA only gives certificates to entities of which it has
  59 checked and verified the identity of (and in this case, that the server name you
  60 specify does belong to it). So, if you chose the intentions and the thoroughness
  61 of a CA, you can be reasonably sure that if a certificate is signed by the CA,
  62 it really belongs to the server and owner that it claims to.
  63
  64 Certificates are only valid in a certain time window, so your system clock
  65 should be reasonably accurate when checking certificates.
  66
  67 Additionally, CAs keep Certificate Revocation Lists (CRLs) in which they note
  68 the certificates that are to be treated as invalid (e.g. because the server
  69 name has changed, another ceritifcate was granted, or even because the
  70 certificate was not granted to the rightful owner).
  71
  72 The really paranoid (who chose to not trust a CA) can check the fingerprint of
  73 the public key that is used by the server. The fingerprint is a hash of that
  74 key that (hopefully) has few collisions and is hard to attack using a "birthday
  75 attack", i.e. nobody can generate a second key that hashes to the same value
  76 of the original key in reasonable time. So, if the fingerprint matches, you
  77 can be reasonable sure that you talk to the original server, because only that
  78 knows the secret key, and it is very hard to generate a matching secret key from
  79 the public key. If it doesn't, it might be an attack, but keep in mind that the
  80 server key may also have changed legitimately before panicing ;)
  81
  82 fetchmail will present the fingerprint to you. Another mode, that strictly
  83 checks the fingerprint, is available (using the sslfingerprint option, and
  84 giving the desired fingerprint as an argument). If you want to check finger-
  85 prints, you should use that option, because otherwise, it may be too late
  86 to cancel if you see the fingerprint (your password may already have been
  87 transmitted)!
  88
  89 The certificate directory must be hashed in a way OpenSSL expects it: each
  90 time you modify a file in that directory or add a file to it, you need
  91 to use the c_rehash perl script that comes with OpenSSL (in the tools/
  92 subdirectory, in case that it isn't installed). Additionally, you might
  93 need to convert the ceriticates to different formats (the PEM format is expected
  94 and usually is available, DER is another one; you can convert between
  95 both using the openssl(1) utility).
  96
  97 The fingerprints fetchmail uses are MD5 sums. You can generate them e.g. useing
  98 the openssl(1) "x509 -fingerprint" command. The format is a hexadecimal string
  99 with a ":" separating two byes (i.e. a ":" every two hex "digits"). The letter
 100 hex digits must be in upper case!
 101
 102 *CAVEAT*: OpenSSL seems to be unable to check CRLs at the moment!
 103
 104         - Thomas Moestl <tmoestl@gmx.net>