-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJPGAT1AAoJEJ5bBPQw+AosMr4QAKLejj5GaPxEzJWZ9N/LAZo8 3aUmxBr1qVla/YBL1AQqTG7LuG1zWmikN50z6Ko8mooE92CeGzhxxiDjx603EewC Y/xZORa08dU0T5YkyfUtRMses2mK01lAQp8WfheLS1t5EbQ9FlGNYJo7FUl9m6rV Fo+a1Et9yylzudo7wL3F5Pm14lSXGK/Nc6QmhZhvGmGl8vyc1CvyyfDvUYV2DR6x AmrRwg66K2onUkMoXTmvCWjHispY4jOrIjmowPVtbVMlUVvm8QtcoDt0uZHXtNdz c44feslAKb5RnwxXI/4LwoEvsdS+qMaVH4oF5S3ls8Lnqw05iQbb0/lwuYRORAWI GgR/cLdMRZ0DEsMB0eSXFs+ANG5HYx92qA18037V48Ln93n+dQv1ltJdtnUyUxo/ xJ7yJqHytBYMbVBzSC1iDMRWh7UOaYGNiWchGemCQ+iVwhSiIMQIPlzr/3AmnCnU muu+IGQ3mUTZyzDdKZ9fRC+s7J+JAfOUyH9acE6m7DA3vUUIVgHi+lqvKRUr+saZ xUz/X12b1h/gdhdneZYzBWbF96/0gGXFGnh4V/XVEKB6UHLE0Ta6uR7wVMpu7GVS obgPIHtMvtr/bONZc2WYGJD+TDE7+fA2SuEWm27J59vdicOKP2Z11BA/Qj0gbtKa EsVrdA0kODGnsKiMDijH =lykN -----END PGP SIGNATURE----- _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
