anonym:
> 01/11/2012 11:35 PM, intrigeri:
>>
>> 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".
>
> Ok... it just seems weird they didn't implement this from the beginning
> (OTOH, that code was a complete mess... I refactored it to a sane state).
>
>> I think the change you're hesitating to make would be consistent with
>> the way ssl_only works.
>
> Right, implemented (PATCH 4/6)
>
>>> 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?
Sorry for popping in this thread a bit late.
I don't find this confusing at all. Those might be two quite different
things for you but it's consistent and what I would expect from such an
option.
>> 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.
>
> With resulting I just meant the fetched config after it has been parsed.
>
>>> * 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.)
>
> Turned out to be easier than I initially thought (thanks, exceptions!).
>
>> In any case, the current situation makes the "Only use secure
>> protocols" checkbox a wrong statement, isn't it?
>
> You're right. Implemented (PATCH 6/6).
And what if the server provides only plaintext? I guess the autoconf
will just fail in that case. It might be nice then to tell the user she
can try again the autoconfig without ssl_only but will get an insecure
connection.
This might not happen with many online providers but might still be the
case for a whole bunch of self-hosted small-business services.
Anyway, I think you did an amazing job!
> Unless I've missed something my work here is done, see attached patches.
> Well there is one more issue: if the email provider's http server that
> serves the config is using a self-signed certificate (like my test
> server), the user just gets an error prompt with no chance to manually
> verify it and accept it. Hmm. We'll see if I care about looking into
> this. Anyone think it's really important?
>
> Since we have no icedove repo to push to I post my current work here in
> case my primary hard drive + backup drive would fail :). Also, perhaps
> someone with more javascript skills than me could spot some bug I've
> missed (?). The patches are against commit aab48e6 in the Debian Mozilla
> team's git repo:
>
> http://anonscm.debian.org/gitweb/?p=pkg-mozilla/icedove.git
>
> Cheers!
- --
sajolida
