Menu
▾
▴
[fetchmail-devel] [Bug #16000] fetchmail should support multiple sslfingerprints
|
From: <ad...@be...> - 2013-03-14 03:36:23
|
Bug #16000, was updated on 2009-Jul-15 20:40 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: jw9 Assigned to : none Summary: fetchmail should support multiple sslfingerprints 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: 2013-Mar-13 22:36 By: grarpamp Comment: There also needs to be a facility to list multiple acceptable fingerprints per host, aka: account / poll. This is needed because there are often cases where there are multiple hosts behind a single hostname, whether by DNS, anycast, load balancers, etc... and those hosts do not all have the same certificate. The certs are often valid but may be regionally managed, in a state of local testing, being rolled out over time, rolled out with overlap in expiry times, or any number of other cases where this becomes necessary. For example, right now, depending on where you are in the world, fetchmail will choke at least half the time on pop3.live.com for any user who has configured a fingerprint. I'm adding this here because it's in the same work area It would be nice to see some work occur in this area. Thanks. ------------------------------------------------------- Date: 2010-Apr-09 03:49 By: m-a Comment: I have reconsidered the issue and raised the bug priority. It would seem that such a security feature is warranted even in a stable release to counter MITM attacks that exchange certificates on the flight. ------------------------------------------------------- Date: 2009-Aug-19 05:13 By: m-a Comment: reopening after grarpamp's comments. On the suggestion, based on the rationale below, I might indeed rather correct the documentation and indeed support certificate fingerprint lists. I do however not subscribe to the assertion that the fingerprint were necessary to detect MITM attacks - the certificates should be sufficient as long as you're happy with the signing CA's verification policies (including the hash used). I currently second the view that verifying both the MD5 and SHA1 of a certificate has been considered reasonably safe recently, i. e. I'm not aware of efficient attacks that collide both MD5 and SHA1 at the same time. I wonder if the hash grouping can be configured in a simpler way, for instance --sslfingerprint {MD5}DE:AD:BE:...:EF&{SHA1}F0:0D:04:13:...:37 or similar. I'll need to think about this a bit more when it comes to the real implementation. It may be awkward to edit on your netbook screen or smartphone, but it's likely simpler to implement. Given this is more a feature request than a real bug, it will probably not make a 6.3.X release though. ------------------------------------------------------- Date: 2009-Aug-11 17:55 By: grarpamp Comment: Adding content for those who use this interface... Hi :) Folks appear to be misunderstanding things about the underlying crypto and why fingerprints are a necessary safety check. If one simply relies on checking the cert chain and blindly trusts that model, as most of the world is conditioned to believe it is sound, you are open to attack. Namely, of the sort in the posted url, it is a good read, as are the referenced prior art. Both MD5 and SHA1 are theory broken and MD5 demonstrably so, as noted in the literatre. So the hash part is of concern, at least in this case. A CA takes a MD5 over certain fields in the cert and signs that MD5 digest, not the entire cert contents. CA's previously used MD5 and failed to change their cert practices to SHA1 until a real world break, oops. Anyways... So I don't have to swipe their private key. All I have to do to forge a server cert is copy the signature from any candidate real cert into my cert and manufacture the rest of my cert contents so that they: a) work, b) make the fields have the same digest as the real one. Which, as we all know by now is possible, given time or new art, due to the whole hash collision thing. However... if I copy a known good cert via trusted channels, and take both the MD5 and SHA1 fingerprints of the DER form of that cert, it's much closer to cryptographically impossible to manufacture a cert that would match evarything. I could just as easily make formal contact with the cert holder and get the prints that way or receive them as part of a high security programme. Banks do this. So there are two different fingerprints covering different areas. Checking fingerprints over the entire DER cert will foil this attack because it detects the contents that I manipulated to match the field digest that was later signed. That is why openssl, browsers, ssh, etc provide fingerprint calculating and verification functions... totally separate from signature calc/verif capabilities. So two types of checks should always be performed for maximum security: A) cert chain trust = sig(hash(contents)) -> pki This is done with openssl verify -verbose aka: sslcertck B) DER fingerprint = hash(sig(hash(contents)) This is done with openssl x509 -in <PEMcert> -noout -fingerprint -<sha1|md5> or openssl x509 -in <PEMcert> -outform DER | <sha1|md5> aka: sslfingerprint... with the enhancements in the prior note Enhancing fetchmail to doubly check B with both MD5 and SHa1 shouldn't be much extra coding or user effort. As an aside, it's fairly common to find places using/publishing both hashes for various purposes. Removing the check in B places all the beans on the hash function in A, which is not good. Private keys are not even involved in this. Defense in depth will save your butt :) Give the user tools, let them decide how many they wish to deploy and manage. I would adapt the docs to say that one should use both A and B, or neither, with some short reasons why. And continue to provide example openssl usage as is there now, to allow them to accomplish it. Note1: Not checking the fingerprints on self-signed certs... such as are commonly found in internal corporate nets, edu's, org's, and the many end user, developer, hacker and other low budget/tier sites... is asking for trouble. Not publishing your prints, signed by OpenPGP, is bad too. Note2: The random serial fix just helps eliminate easier forms of the hash collision attack, see the paper. It doesn't necessarily prevent other forms or completely new math attacks, and definitely doesn't prevent brute force. Note3: The lists.berlios.de cert is expired, and MD5, though that doesn't matter :) The Berlios_CA cert may be self-signed. I'm out of time at the moment to help out with correcting what is already in here, perhaps later. Thanks again for keeping up with all the maintenance to fetchmail :) ------------------------------------------------------- Date: 2009-Aug-11 17: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 14: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 11: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 09: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 09: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 09: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 08: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 07: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 07: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 07: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 06: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 |
