On 02/03/10 16:08 +0100, Robert Schöftner wrote: > On 2010-03-02 15:04, ced wrote: > > The problem is quite different then for commercial website because > > commercial > > websites need to be trusted by casual users and not corporate users. > > This is why there is all those certificate authorities that are used > > as trusted parties > > because everybody relies on their. > > > Even small to medium corporations usually have their own CA, e.g. tied > to active directory.
Most of the SMB (non-IT) that I have seen don't have any CA certificate. > In the "software as a service" case, I think the > situation is quite comparable to online banking. > > There is two issues for using python CA check: > > > > - We must add something to force using SSL for connection. This make > > login > > window more complicated and less user-friendly. Otherwise, MIM > > server could > > drop the SSL and it will not be checked by the CA check. > > > A simple check box "use SSL" would be enough. If this is checked, client > should warn when about to or refuse to connect to untrusted server. This doesn't offer anything. Except complicate the interface. > the > admin should be able to forbid connections to non-trusted SSL and > non-SSL servers in site-wide, only-root modifiable configuration. Why? Do you really think it is doable? The user will not be able to download the Tryton client in his home and run it by removing the control of the only-root configuration. > >> this sort of client-configuration should happen in some site-wide > >> non-user-writeable config file, e.g. /etc/tryton/client.conf, and should > >> not be overrideable by non-root users. > >> > > I don't understand why? The goals of this feature is to help user to > > not be attacked > > not to remove his freedom. > > > most corporate deployments will not want to give the user any freedom > the user doesn't need, especially if it is potentially harmful. IMHO it > should be able for an admin to "lock down" the installation so you > cannot by accident accept some fishy certificate. Of course if you use CA certification and you can be poisoned by untrested CA that will break the security in the chains. But with the current fingerprint implementation, it stores only fingerprint for one specific connection parameter. > > I find current patch good because it provides us what we need and keep > > the GUI simple: > > > > - Verification of the server identity. > > - Enforce the usage of SSL for specific servers. > > - Human readable file. > > > > And the fingerprint check is not so exceptional, it used in OpenSSH > > per example. > > > I only had a quick glance over the patch. Of course the fingerprint > check is not exceptional, everybody and their Pretty Grand Parent uses it ;) > > The question is, can you trust your users to make informed decisions > about these things (e.g. really check the fingerprint), or do you prefer > being able to install some configuration and trusted-CAs file on that > computer and everything is set. It seems you did not test the patch. Otherwise you will see that nothing is asked to the user. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpLnzaUQhK6J.pgp
Description: PGP signature
