On 17-Sep-08, at 4:55 PM, Ben Bucksch wrote:
> I don't think the "TLS, if available" is important anymore, and is
> dangerous. Therefore, I propose to remove it from the UI in the
> Account
> Manager as well. It could stay as backend pref for edge cases and
> existing users - the Account Manager UI would show the option only
> when
> it's already set in the prefs, and show a warning; otherwise, the
> option
> would simply be hidden.
>
> I worry about existing users, given that "TLS, if available" was the
> default so far. I would propose that TB3, when it sees such a
> setting in
> an existing account for the first time, informs the user, and runs a
> limited version of our probing code of the new setup dialog (just the
> backend code, different UI) to check whether the server supports TLS
> or
> SSL. If it does, it tells the user and asks him whether we can change
> the setting to TLS/SSL always. If the server does not support SSL, we
> inform the user (same as in the setup dialog) (and set a pref so
> that we
> don't run the migration code again).
I think it would be helpful to have Bryan comment in here since I know
the account creation process is being dramatically revamped in TB3.
We had a brief conversation about it yesterday though, where I came to
a slightly different conclusion, that I think is nevertheless
compatible. I would be interested in your thoughts.
My suggestion was that:
- We should not expose STARTTLS in the set up process, since it will
not be meaningful to most users, and risks deceiving the others into
assuming they are secure when they aren't, BUT
- We should turn it ON by default on non-secure connections, because
even though we know full well that the connection is subject to
subversion, we have a nearly-free way to marginally reduce the attack
surface in the background.
- And yes, there should be some way to turn it off in case you have
an ancient or broken server that's confused by STARTTLS requests
To be clear here: I think at no time should we suggest that STARTTLS
is "secure", or "safer", or better in any way, really, in the UI. I
think the nuance there ("encrypted, but subject to downgrade attacks")
is not something that is reasonable to force our users to understand.
But I do think that if we have an opportunity to make things better in
the background while still marking the server as an unsecured one, it
makes sense to do so. To my mind, it's akin to the question of HTTP
Basic Auth vs. Digest Auth. It's not really worth it to me to explain
the differences in the UI there, it's not at all ironclad, but we
might as well use the slightly better technology if it exists.
Am I wrong, here? Is there a hidden cost to STARTTLS that makes it
decidedly worse than vanilla, unencrypted traffic, other than the
false sense of security it creates?
Cheers,
Johnathan
PS - And yes, whether or not my suggestions above are riddled with
holes, I agree with Nelson that the labelling on the prefs, once
thusly-re-arranged should really reflect what's actually happening. I
think more about this than most people, and I would still draw the
wrong conclusion from a checkbox that said "TLS", in this case.
---
Johnathan Nightingale
Human Shield
[EMAIL PROTECTED]
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
