Menu
▾
▴
[fetchmail-devel] [Bug #16000] fetchmail should support multiple sslfingerprint's
|
From: <ad...@be...> - 2009-07-16 15:19:22
|
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-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 |
