Re: [Evolution-hackers] ssl always/when-possible/never etc proposal

[Not Zed <notzed ximian com>]

On Tue, 2004-08-24 at 14:22 -0400, Jeffrey Stedfast wrote:
> On Tue, 2004-08-24 at 12:54 -0400, JP Rosevear wrote:
> > On Tue, 2004-08-24 at 12:19 -0400, Jeffrey Stedfast wrote:
> > > On Tue, 2004-08-24 at 12:12 -0400, JP Rosevear wrote:
> > > > On Tue, 2004-08-24 at 10:35 +0800, Not Zed wrote:
> > > > > On Mon, 2004-08-23 at 16:06 -0400, Jeffrey Stedfast wrote:
> > > > > > Since there was confusion again today on the difference between
> > > > > > always/whenever-possible, I guess it's a good time to bring this up.
> > > > > > 
> > > > > > I was thinking in the future, we could re-work the UI for the SSL
> > > > > > options to look something more like this:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > This would make the backend logic a little simpler too, because we
> > > > > > would haven't try and guess which SSL method to use based on trial-
> > > > > > and-error.
> > > > > 
> > > > > This seems very technical/meaningless, i dont even know what it means.
> > > > > 
> > > > > IMHO we should have SSL and TLS separated, they're different.
> > > > > "whenver possible" makes absolutely zero sense technically or visibly
> > > > > since it doesn't relate to what it appears to be at face value.
> > > > > 
> > > > > i.e. something to the effect of:
> > > > > 
> > > > > Security: None / TLS / SSL
> > > > > 
> > > > > which is what we really mean.
> > > > 
> > > > But you can use TLS via a secure transmission pipe or not correct?  I
> > > > think we need to distinguish those two cases as well otherwise the user
> > > > maybe unable to determine the level of security used via the UI.
> > > 
> > > if the user can't distinguish between "always" and "whenever possible",
> > > then they certainly can't distinguish between TLS and SSL.
> > 
> > They can certainly distinguish between "secure" and "insecure" though if
> > we can give them that information (the problem I'm trying to point out
> > is that TLS could be either).
> > 
> > -JP
>
> no, notzed's "TLS" option wouldn't work the same as "ehenevr possible"
> does now. instead, what notzed is suggesting is that "TLS" would just
> use STARTTLS or fail. Just like "SSL" would use the ssl port or fail.
>
> there would be no "use it only if available" option.
>
> both options are "use it or fail"

I think this is a much better idea - because the user knows exactly what they're getting.  With whenever possible, there is no way to tell what is happening.  I guess some could argue users dont want to know, but i think they do want to know if they're connected using an open channel when they thought they were using a secure one.

By listing each option explictly, at least if it fails they have to explictly say 'i'll use an open channel then'.

The 'check for supported auth methods' thing could also check for possible connection methods perhaps, although that would requie api changes too, which it probably should have anyway rather than the provider bits so it can be more flexible.

_obviously_ we can't just use 'TLS' as the label.  Even using 'ssl' is a bit meaningless unless you're "in the know".  Perhjaps it should be (... _something along the lines of_ - use your imagination ...):

Security: None / Secured connection (SSL) / Encryption over plain connection (TLS) / Encryption over Secured Connection (TLS/SSL)

--

Michael Zucchi <notzed ximian com> "born to die, live to work, it's all downhill from here" Novell's Evolution and Free Software Developer