Menu
▾
▴
[fetchmail-devel] [Bug #16000] fetchmail should support multiple sslfingerprint's
|
From: <ad...@be...> - 2009-08-11 23:50:59
|
Bug #16000, was updated on 2009-Jul-16 02:40 Here is a current snapshot of the bug. Project: Community Fetchmail Category: None Status: Closed Resolution: Invalid Bug Group: None Priority: 5 Submitted by: jw9 Assigned to : none Summary: fetchmail should support multiple sslfingerprint's Details: Some mail servers, such as pop3.live.com, have multiple hosts available at a single IP address (currently pop3.live.com appears to have two hosts behind that one IP address). Other mail servers, such as imap.gmail.com, resolve to rotating IP addresses. It should be possible to specify multiple 'sslfingerprint' entries so that any one of those fingerprints can match. Follow-Ups: Date: 2009-Aug-11 23:50 By: none Comment: Adding content for those who use this interface... Hi all :) Fetchmail needs the ability to specify multiple 'sslfingerprint' options and digests per 'poll' stanza. I noticed this when connecting to gmail. I think it's a load sharing thing providers use. Google also has their own intermediate CA now so more cert deployments could be expected. At the moment, if you specify multiple sslfingerprint rc lines or command line options, only the last one specified is checked. Any prior sslfingerprint options are silently ignored. And the only digest available is md5. This is obviously frustrating users mail collection attempts :( To reproduce the problem, run this and examine the certs and hashes. The gmail certs happen to verify back to the root CA's. The 44a8...f1a9 cert occurs more frequently, the 9273...9f33 cert is rarer. I've attached them both and the CA's involved. If you are not seeing multiple certs, you may need to 'travel' and debug with different source ip addresses... such as provided with a worldwide proxy network like Tor. i=10 ; while : ; do LD_PRELOAD=/tmp/tor/libtsocks.so.1 TSOCKS_CONF_FILE=/tmp/tor/tsocks.conf \ openssl s_client -connect pop.gmail.com:pop3s < /dev/null > tcert$i 2>&1 echo -n "$i: " openssl x509 -noout -fingerprint -md5 -in tcert$i i=`expr $i + 1` done Also related... from the BRANCH_6-3 NEWS file: * --sslfingerprint may be removed from a future fetchmail version, because it's just too easily abused to create a false sense of security. PLEASE don't remove this feature. I like it a lot and use it everywhere possible, with --ssl and --sslcertck at the same time as well, from trusted sources beforehand of course. Knowing when the cert changes out from under you is very useful, even if only for debugging or system verification. Especially if you connect from untrusted locations or paths. Or you want to know about and resolve them. It's also handy if the machine a user is connecting from has a poor, untrusted or nonexistent collection of CA certs. In that case, just the digest can be imported and used. Note that openssl does not ship with a CA cert collection... admins usually have to get it from mozilla... if they value PKI enough to think of and bother with it. There are blurbs in the man page that even talk about self-signed certs being accepted with 'sslcertck'. Overall, it would be good to see this feature enhanced to do both md5 and sha1 to make cert collision attacks much more improbable going forward... at least until the NIST 'SHA-3' hash competition is done and that trickles down to the CA's and apps years from now. Usage in the case of a single cert, where both must match, might be like... poll sslfingerprint-md5 <fp_md5> sslfingerprint-sha1 <fp_sha1> In the case where multiple certs may be presented, group the hashes as a set. Both hashes in the set must match. First check set cert1, then set cert2, then set cert[n] until one set, or none, match the presented cert... poll sslfingerprint-cert1-md5 <fp_md5> sslfingerprint-cert1-sha1 <fp_sha1> sslfingerprint-cert2-md5 <fp_md5> sslfingerprint-cert2-sha1 <fp_sha1> sslfingerprint-cert[n]-md5 <fp_md5> sslfingerprint-cert[n]-sha1 <fp_sha1> The '--' command line version of this should also do the right thing. Fetchmail should also print both the md5 and sha1 fingerprints from the received certificate in the debug output. Note that openssl supports mdc2, md2, md5, sha1. I understand that some CA's also used, or may still use, the non-sha1 digests. Though I guess sha1 is the only one used by sane CA's for new certs these days. I don't know how many old ones are still in use on hosts. md5 and sha1 are enough until SHA-3. And since the past always seems to apply to some future scenario with new twists, this is surely not the last of the breed to be proven out: http://www.win.tue.nl/hashclash/rogue-ca/ Extra checks are always good thing to have available. Openssl probably has simple library routines to do this. Thanks guys, and for fetchmail too, been using it for years :) ------------------------------------------------------- Date: 2009-Jul-16 20:20 By: m-a Comment: Compatibility. Basically 6.3.X should be as compatible with 6.2.0 as reasonably possible - and it turned out that 6.3.X has lived for quite a while now... Compatibility was needed at the time to pave the upgrade path for 6.2.X users, as 6.3.0 had around one hundred bug fixes over 6.2.5 - and those were more important than cleanups. ------------------------------------------------------- Date: 2009-Jul-16 17:44 By: jw9 Comment: Good. You should remove sslfingerprint asap. Cannot understand why the feature was implemented in the first place. And why such a broken "feature" has endured for so long. Have a nice day. ------------------------------------------------------- Date: 2009-Jul-16 15:19 By: m-a Comment: [Now the bug tracker is messing things up, my comment appeared twice in spite of being submitted once around 14:35, not again at 15:03. Sorry for that, but it has happened outside my control.] I don't doubt your technical and intellectual skills to download the server's certificate or its fingerprint. BUT then your security hinges on the useless assumption that your connection is not under attack in the very moment that you're downloading the cert/fingerprint. You can't know if you're under attack unless you can verify the FP through a secure channel: You're using the same channel you'd later use for the actual mail-fetching connection; so you'd happily download the attacker's certificate or fingerprint. Fetching the fingerprint through a DIFFERENT or at least a known-secure channel is crucial here. I will not abolish the option for 6.3.X versions for compatibility reasons. If I'll drop it later is left for later decision, as the fingerprint is the easier alternative compared to downloading the *server* certificate and stuffing it into <prefix>/ssl/certs/. The canonical way is still to install the root-signing certificate though. I don't see much use in listing hundreds of ssl fingerprints and keeping that list up to date when instead you can just save the certificate of the signing CA. It's less of a hassle. And if you can't trust, for instance, CyberTrust, then don't install their certificate, but Microsoft's certificate instead - providing you have a way of verifying that... I'll see to marking the sslfingerprint feature candidate for removal for 6.4.X or newer fetchmail releases. ------------------------------------------------------- Date: 2009-Jul-16 15:03 By: m-a Comment: Two things: 1a. sslfingerprint is unnecessary in "--sslcertck --sslproto tls1" and in "--sslcertck --sslproto ssl3 --ssl" configurations, and shouldn't be used. It doesn't add security unless your ISP provides you with the finger prints through a separate channel (such as your walking up to the site and fetching a sheet with finger prints). The assumption is that the MITM (=attacker) cannot forge the signature of the certification authorities you trust. He may forge the server's certificate, but he'll hardly be able to forge the root signing certificate from Equifax, Verisign, or whoever. sslcertck is sufficient unless you follow stupid guides that suggest capturing and saving the server certificate (while that works to shut up complaints about certificates, it doesn't add protection against MITM attacks: you might already download the counterfeit certificate that you save as trusted, if you're already under attack at the time). 1b. sslfingerprint, as you observed, isn't useful with certain load balancing setups, when servers have individual certificates that are signed by a common CA. 2. for complaints about the newest-first ordering of the comments, please file a support request against BerliOS itself, not against individual projects. ------------------------------------------------------- Date: 2009-Jul-16 15:02 By: jw9 Comment: I can determine the proper fingerprint from any other server on any other network that I have access to. I don't have to ask any "ISP" to provide fingerprints through another channel because I am quite able to do that myself. So, as you state, it does add extra security. Especially in today's world where most people have access to more than one "ISP" or network (eg your workplace if you have one, and most people do!). In which case you should allow a set of sslfingerprints to be specified. Otherwise, to be consistent with your argument (that sslfingerprint is unnecessary), you should completely remove the sslfingerprint option. Fix it or lose it. ------------------------------------------------------- Date: 2009-Jul-16 14:35 By: m-a Comment: Two things: 1a. sslfingerprint is unnecessary in "--sslcertck --sslproto tls1" and in "--sslcertck --sslproto ssl3 --ssl" configurations, and shouldn't be used. It doesn't add security unless your ISP provides you with the finger prints through a separate channel (such as your walking up to the site and fetching a sheet with finger prints). The assumption is that the MITM (=attacker) cannot forge the signature of the certification authorities you trust. He may forge the server's certificate, but he'll hardly be able to forge the root signing certificate from Equifax, Verisign, or whoever. sslcertck is sufficient unless you follow stupid guides that suggest capturing and saving the server certificate (while that works to shut up complaints about certificates, it doesn't add protection against MITM attacks: you might already download the counterfeit certificate that you save as trusted, if you're already under attack at the time). 1b. sslfingerprint, as you observed, isn't useful with certain load balancing setups, when servers have individual certificates that are signed by a common CA. 2. for complaints about the newest-first ordering of the comments, please file a support request against BerliOS itself, not against individual projects. ------------------------------------------------------- Date: 2009-Jul-16 13:09 By: jw9 Comment: It would appear that additional comments appear in a push-down stack order. This makes it very hard to follow the natural order of things. This is very strange. Here in the western world we are used to reading left-to-right and top-to-bottom. We certainly don't expect to have to read from bottom-to-top. I suppose I can turn my monitor upside down and then they might follow in a proper order. But wait, that would make the characters appear upside-down! In any case, if one is to be able to check the sslfingerprint of a server to protect against man-in-the-middle attacks, and if the fingerprint does actually change randomly (and not because of a man-in-the-middle attack), then we need to be able to specify a set of fingerprints and only require that at least one of them matches. ------------------------------------------------------- Date: 2009-Jul-16 13:03 By: jw9 Comment: Why do comments appear in such a strange place (after my original submission)? Shouldn't additional comments follow in a logical order after other people's followup comments? Very strange! ------------------------------------------------------- Date: 2009-Jul-16 13:00 By: jw9 Comment: II think you misunderstand. The sslfingerprint is used to verify the identity of the server and to protect against man-in-the-middle attacks. The configuration also has proper certificate and "ssslcertck" and "sslcertpath" settings. To protect again man-in-the-middle attacks one needs to be able to ensure that the fingerprint of the server hasn't changed. ------------------------------------------------------- Date: 2009-Jul-16 12:33 By: m-a Comment: I don't think fetchmail should do that. sslfingerprints are just a convenience shortcut, and closely resemble stuffing the server's certificate into the directory of trusted certification authority certificates, usually /usr/ssl/certs, /etc/ssl/certs (and running c_rehash afterwards), or similar. The canonical way is to install the GTE CyberTrust Global Root (for Microsoft/live.com) or the Equifax Secure Certificate Authority (for Google Mail) and use certificate-based authentication. See also: http://gagravarr.org/writing/openssl-certs/others.shtml ------------------------------------------------------- For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=16000&group_id=1824 |
