Hi,
Great work! Replies inline bellow.
anonym wrote (11 Jan 2012 20:54:21 GMT) :
> 2. Fetch configuration from email service provider: Disabled when
> ssl_only == true.
> It would be easy to make it try https first, and then fallback to http
> only if ssl_only == false, but a comment in the code makes me unsure if
> I want to do so:
>> To support domain hosters, we cannot use SSL. That means we
>> rely on insecure DNS and http, which means the results may be
>> forged when under attack. The same is true for guessConfig(), >though.
> Any one that understands the issue?
I don't think there's anything more to understand than "they're aware
than fetching over HTTP is deeply insecure, they even know some
reasons why it's insecure, but they do it nevertheless because most
crappy ISP's don't bother to serve their autoconfig file over HTTPS".
I think the change you're hesitating to make would be consistent with
the way ssl_only works.
> Issues I'd like input on:
> * ssl_only really does two separate things:
> 1. It forces SSL for *fetching* configs.
> 2. It forces SSL or STARTTLS in the *resulting* configuration when
> *guessing* the config.
> Is this confusing?
Anything else would look strongly inconsistent to me, at least in the
threat model I think we're considering. So I don't find it confusing.
OTOH, I don't understand what exactly "*resulting*" means above, so
I may very well be entirely confused wrt. how ssl_only behaves in
GuessConfig city.
> * ssl_only does not check whether any fetched config (like in step
> 1 and 3) uses plaintext smtp, pop or imap. Do we want this?
> I wouldn't ask if it was a trivial change, but this code is
> a complete mess and would need a complete reorganization for this
> feature. It would make the above point less confusing. But can we
> live without it?
If things are kept as is, it seems to me ssl_only makes things more
secure *only* for a given user if her email provider:
- serves the email protocols over SSL;
- does not serve an autoconfig file pointing her MUA to non-SSL.
I'm not sure how we can possibly help other users: suddenly denying
them access to their email does not look that appalling to me.
OTOH, I would find it great if we could make it clear to them what
risk they are taking. How hard would it be to implement this? (This
would be a low-priority enhancement: I don't think our current Claws
Mail setup has anything to say against SSL.)
In any case, the current situation makes the "Only use secure
protocols" checkbox a wrong statement, isn't it?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Who wants a world in which the guarantee that we shall not
| die of starvation would entail the risk of dying of boredom ?
