I wasn't sure whether to post this to newbie or security. Opted for the latter.

In the Evolution email account editor, you have the option to set up a secure connection using SSL Encryption. You also have the separate option to set up various authentication types.

Can anyone explain how these two relate to one another? For example, if I set up SSL with "password authentication" (which sounds a lot like plain text to me - as opposed to say the option for CRAM-MD5), do I defeat the secure setup?

My isp does provide ssl access to email but without support and they don't say anything in their documentation about what kind of authentication to use. The Evolution check facility suggests CRAM-MD5 may be available. If I try that I get a certificate notice which looks like a lot of gibberish to me - guess from the context it is OK but who knows..

(I've hunted the internet for a while trying to understand this point, including Evolution FAQs, without success.)

Thanks
Jacek

If the session is encrypted with SSL/TLS then any data you send is encrypted during that session. That means it's "safe" to use a plaintext password when the session is encrypted.

A separate question is whether the SSL/TLS connection is really negotiated with your ISP, or whether someone is attempting to hijack the session by using their own certificate. Unfortunately "gibberish" is a completely worthless description, so no one will have any idea what certificate is being presented. Next time, try writing the "gibberish" down so that you can ask someone to look at it for you.

Chort,
Thanks for the info. I've now grabbed the text from the certificate confirmation dialog:

It occurred to me that if I didn't accept it, I wouldn't be able to use ssl connection and have to use the unencrypted type, so presumably saying yes was no more risk. I'm sure if this was unsound reasoning you'll tell me! ..but it does seem to work after the event - in that I can access my emails, so presume it was OK after all.

Jacek

That's not exactly true. If the certificate validation is failing because someone is conducting a man-in-the-middle attack, you're a lot worse off accepting it, because then you will falsely believe your data is safe when in fact someone else is reading it.

Here's the site the certificate was issued to:Is that the hostname you have typed in your mail client for the mail server? If you have a different hostname entered, it's going to fail validation.

If the hostname matches, then probably your client doesn't trust the Geotrust CA. You would have to find the list of trusted issuers that your mail client is using and add the right CA root. I believe this is the one that signed that cert: https://www.geotrust.com/resources/r..._Authority.cer . The strange thing is Geotrust's page says that CA is for non-QuickSSL certs, but as you can see the cert you're getting appears to be a QuickSSL cert... odd.

The Geotrust CA page can be found here: https://www.geotrust.com/resources/root-certificates/

Chort,
Mailserver address is correct. As for the rest it rather goes over my level of understanding. Adding the CA root to my client will presumably make it accept the certificate, but won't make it valid. So we're still guessing - I guess.. Or as I said, there's probably a lot about security that I don't understand.
Thanks
Jacek

Adding the root CA will make the certificate valid if the only complaint was that it is signed by an "untrusted" root. In that respect, the only difference between a "valid" and "invalid" certificate is whether you trust the root CA. There are other aspects that will make a certificate invalid regardless of whether you trust the root (the date is out of range, the hostname doesn't match, etc).