GNOME Bugzilla – Bug 205325
Connecting to IMAP SSL server reports "Bad Certificate"
Last modified: 2013-09-10 14:02:36 UTC
I have self-signed SSL certificate for my IMAP server so each time Evolution asks me whether I want to continue connecting or not. Is it possible to add a check box that would remember my settings so I doesn't ask me over and over whether I want to connect. Thanks, Vladimir
Marking this up to minor.
Created attachment 40044 [details] Error while Scanning folders box
This is probably related so I am including it with this particular bug. The attachment I just included shows a message I get every time I start evolution. The error message comes up while the last icon on the splash screen is being loaded and says Error while 'Scanning folders in "IMAPv4 server myimapserver"': Could not connect to myimapserver (port 993): Success
I also experience this problem. Like Vladimir, I have an IMAP server with a self-signed SSL certificate, and would also would appreciate a way to have of simply opening evolution and having access to my mail instead of having to fiddle with it. This is still a problem as of beta 2.(meaning now) Possibly a check box by "Accept bad SSL certificates?" in the account options? (with the prerequesite security warning about not using official verisign yadda yadda yadda...)
I appologize, but I have to ask... where's the security in trusting a server with a self-signed certificate?
Many organizations sign their own certificates due to reasons of cost and all they care in most cases is that passwords are not flying in clear over the wire. A CS department at a college I was attending decided to SSL-ize their IMAP after such an incident when a machine was compromised and passwords were exposed. I hope this makes it a little bit more clear. Thanks, Vladimir
Yeah, self-signed certs are very useful when the cost or time-consumption of buying a cert is relevant. As long as you know the provider of the cert (when I was at school, it was the admin of the LUG) then there is a reasonably high level of security. Hell, I'd argue that that is more secure than a commercially provided one.
Well, the problem with self-signed certs is that then it is trivial for an unknown third party to pretend to be the server -- all they have to do is create a certificate with the same information and self-sign it. Whereas if you have a trusted third party signing the cert, then if someone else tries to create a duplicate cert they can't get it signed by the same trusted third party (hopefully). Anyway, the error: Success message is due to the SSL code getting a "certificate verify failed" error, which it has no mechanism of communicating to the calling code because there is no CamelException, only errno,
But IFRC the certificate fingerprint will be different. You can social-engiener somebody into accepting the certificate, but if the certificate is correctly installed it seems safe to me.
Peter brings up a valid point but as I have mentioned previously most place will not go through the trouble of actually purchasing certificates and will want the "protection" of SSL encryption. This is especially the case if you are connected via a hub and everyone can sniff each others traffic. I also have to point out the high cost of certificates. Maybe to people in US $80-$200 for a certificate is not much but in lot of places that could be someone's monthly salary so those people are highly unlikely to obtain a SSL certificate. In Mozilla one is prompted to accept the certificate permanently if one so wishes. I don't think it is too much to ask that Evolution does the same.
I think this is now fixed in CVS.
Um, doesn't work for me using OpenSSL. Known?
I'm still seing this bug in 0.12. In fact, I'm warned of the bad certificate three times every time I connect to my imap server (which uses a self-signed certificate). Requiring the user to accept a bad certificate every tmie they connect hurts security. It desensitizes the user to bad certificates, and it allows a man-in-the-middle attack on every connection, as opposed to just the on the first connection. Also, the information presented about certificates is not very useful at all. Perhaps a Druid to guide the user through the decision of whether to accept the cert or not (a la netscape) would be better. Thanks for the great work. Best, Rob
Rob: I may be stating the obvious, but fixing it in CVS two days ago doesn't magically fix it in your (now quite old) 0.12.
I have just built Evolution from CVS and still have the "issue" of not being able to accept it permanently.
I didn't fix it for OpenSSL. I assume that's what you're using... I only fixed it for Mozilla's NSS which is the "officially supported" way of doing SSL in Evolution.
OK can you then tell us how to compile in Mozilla's SSL support since ./configure seems to pick up OpenSSL only even though I have the mozilla-devel package installed. I even deinstalled openssl-devel told it ./configure --with-nss-includes=/usr/include/mozilla --with-nspr-includes=/usr/include/mozilla --with-nss-libs=/usr/lib/mozilla --with-nspr-libs=/usr/lib and still I get no SSL ie. Mail Directory: /var/spool/mail, writable by group mail LDAP support: no NNTP support: no Pilot conduits: no Kerberos 4/5: no/no SSL support: no S/MIME support: no Use movemail: no Dot Locking: yes File Locking: fcntl Gtk-doc: no Any clues would be helpful.
maybe you don't have the nss libs installed? I dunno... [fejj@tazmanian-devil mail]$ ./autogen.sh --prefix=/usr --with-db3-includes=/opt/include/ --with-db3-libs=/opt/lib/ --with-nspr-includes=/usr/include/mozilla --with-nspr-libs=/usr/lib --with-nss-includes=/usr/include/moznss --with-nss-libs=/usr/lib that's my configure line, however the compile fails for me now. Looks like Netscape decided to make these functions internal-only: ../camel/.libs/libcamel.so: undefined reference to `CERT_MakeCANickname' ../camel/.libs/libcamel.so: undefined reference to `CERT_AddTempCertToPerm' ../camel/.libs/libcamel.so: undefined reference to `CERT_NewTempCertificate' If I can't use those functions, then I can't solve this bug.
*** bug 209391 has been marked as a duplicate of this bug. ***
*** bug 209746 has been marked as a duplicate of this bug. ***
1) This is still a problem with the NSS libraries and with last night's build. 2) This makes SSL very, very irritating with 'bad' certificates (which, apparently, includes certs from Thawte, which is the world's second largest cert signer according to their website and is the signee for Duke U's certs) so upping to Major.
I'm sure when you fix this SSL quirk in IMAP it will fix it in all but I just wanted to be sure you knew, it happens with SSL POP3 too. ( version evolution-0.14.99-snap.ximian.200109220808 )
yep, it will...but I have no idea how to fix it. there seems to be no way that I can add entries to the certificate database.
*** bug 210784 has been marked as a duplicate of this bug. ***
*** bug 210887 has been marked as a duplicate of this bug. ***
*** bug 210935 has been marked as a duplicate of this bug. ***
*** bug 211164 has been marked as a duplicate of this bug. ***
*** bug 208712 has been marked as a duplicate of this bug. ***
*** bug 211175 has been marked as a duplicate of this bug. ***
*** bug 208777 has been marked as a duplicate of this bug. ***
fejj: there has to be /some/ way. moz does it all the time. It may just be undocumented. Either way, this is borderline on being critical- it's a huge irritation for people in a business/academic environment. Are there any moz people you (or maybe frank) could poke for help?
lack of documentation in Mozilla libraries is like, a *major* problem :-) I've gone and tried to read their command-line utility programs that modify the database, and they used the same functions that I had been trying to use, so it seems that they have not yet updated their command-line utils to not use the deprecated functions. And believe me, I don't want to go digging in Mozilla web-browser code to find out if the browser portion uses the right functions...I anticipate much pain. As a side note, I did find some functions in NSS that take a SECItem and merge it into the database (or so it would seem based on the function names...?) but how the hell do I get a CERT_Certificate item to become a SECItem item? Not to mention the function wants a SECItem *** so I take it that the function expects the address of an array of SECItem pointers... Can I assume that the SECItem array needs to be NULL terminated? I also need to know if these SECItem's have to be allocated memory - god knows what those functions actually do to the array members. As you may have guessed, implementing this will be a complete nightmare.
I know this is not a discussion board, but I would like to comment the following comment: >------- Additional Comments From Jeff Stedfast 2001-08-07 22:45 ------- > >I appologize, but I have to ask... where's the security in trusting a >server with a self-signed certificate? The SSL-system is basicly the same public-key system as SSH uses.As you log with SSH to a new host, you are asked to accept its key. Then, in future logins to that host the same key will be used until is expires or the host changes the key. When you go to a SSL-secured site, the procedure is the same: you accept a key and may use is until it expires or changes. The difference with registered and unregistered certificates (which contain the key) is that registered ones are accepted automaticly. Unregistered keys are not less secure, IF THEY GET SAVED LOCALLY (so in Evolution 0.14 unreg. cert. are still unsecure). This public-key encryption is vulnerable to so called man-in-the-middle attacks where the attacker somehow directs the login to the target host to a host he controls himself. Then when the user enters something (like passwords etc) the attacker in the middle sees them and forwards them to the target host, gets the reply and forwards it back to the user. The only thing the attacker can't get control of is the target hosts key to decrypt messages which are encrypted with the targets host's key/certificate. But the attacker can make a keypair of his own and send it to the user. The user will be prompted to accept a new key/certificate. This is why you always should think a few seconds before accepting a new key from some host you are trying to log in to using SSH - is it the admins who have generated a new key or is it somebody trying to intervene in the session? But if the software you are using does not save the key (like Evolution) and you have to accept a key every time you log on to the system, then there is now way for you to even suspect that you may be under attack.. So please make Evolution give the user a possibility to save the certificate! If I expressed myself unclearly while explaining why Evolution is now unsecure while using unreg. cert., please drop me a line an tell me what I should explain better. thanks for a great job, otto@sange.fi
sent off questions to the Mozilla NSS developers...
added the following code (which is what the moz devs said to use): SECItem *certs[1]; SECStatus ret; if (!cert->trust) cert->trust = PORT_ZAlloc (sizeof (CERTCertTrust)); cert->trust->sslFlags = CERTDB_VALID_PEER | CERTDB_TRUSTED; certs[0] = &cert->derCert; CERT_ImportCerts (CERT_GetDefaultCertDB (), certUsageSSLServer, 1, certs, NULL, TRUE, FALSE, cert->nickname); even though ImportCerts always return success in the camel code, somehow it didn't solve the issue and I don't know why. I'm wondering if it's a bug in NSS. Regardless, there seems to be nothing else I can do.
marking as NOTXIMIAN as I believe this to be an NSS bug.
Arrrgh. Re-opening; this is almost definitely the bug that makes me come up with a 'not really ximian but still our problem' state. If we don't/can't fix it, fine, but it is still a bug. Period. Sorry to be such a bitch about this, jeff.
fine, I wrote a hack around it. don't ask how I did it because you won't like it, trust me. But to hell with it, I really don't care.
*** bug 212295 has been marked as a duplicate of this bug. ***
*** bug 212810 has been marked as a duplicate of this bug. ***
*** bug 213190 has been marked as a duplicate of this bug. ***
It appears that it was "fixed" by disabling the certificate check. I would hope that this is only a temporary workaround and would definitely not mark the bug as "RESOLVED FIXED".
uh, that's not true at all. it prompts for the certificate and if you say "Accept" it saves the cert and no longer prompts you for it. That's exactly what you asked for.
Well the other day I had a problem with a new snapshot crashing. I deleted my ~/evolution directory, did oaf-slay and tried setting up Evolution from scratch. I set up my mail sources and at no time did it complain about a "bad certificate". The snapshot in question is 10-18.
it doesn't save the tuff in ~/evolution, it saves it in ~/.camel_certs
I have two "self-signed"IMAP server. Files stored in ~/.camel_certs have size 0 (zero).
yep, that would be correct.
Couple points 1. I had a user connect using SSL with RC1 and at no time was he asked whether the certificate should be accepted or not. To me that means checking has been disabled. 2. Let's suppose you did implement the "Accept the key forever" I don't see where is that store. .camel_certs contains files of size=0 which means that there could be a "man-in-the-middle" attack since there is nothing there that will allow Evolution to compare the keys. It seems that we have gone from one extreme to another. Instead of being prompted to Accept the key each time now we are not prompted at all and the certificates are really not checked. This might be a fine workaround but labeling this as "FIXED" might be wishful thinking. I can see the day when someone posts a post on Bugtraq with the Subject "Evolution allows man in the middle attacks".
it prompts for me and everyone else for bad certs. In fact, if you look at the code you'll see that there is no way it won't ask at least once (unless the certificate can be found to be trusted - ie it was signed by VeriSign or Netscape's CA) Also, if you look at the code you'll also notice that I save the certificates in the nss cert7.db file as well, the ~/camel_certs directory is a "just in case user switches which SSL implementation they use"
I had a bug to report regarding a certificate (a valid one I accepted). However, I cannot find a way to "unaccept" the certificate. There should be a way to view this and modify what is accepted.
sure, but that's covered by another bug (might be under an S/MIME feature request)
(In reply to comment #51) > However, I cannot find a way to "unaccept" the > certificate. There should be a way to view this and modify what is > accepted. This is bug 600445.