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. 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. the
admin should be able to forbid connections to non-trusted SSL and
non-SSL servers in site-wide, only-root modifiable configuration.
- CA cert files are not human readable. So it will require a GUI to
manage it
because we will need perhaps to tell users to remove this corrupted
certificate etc.
So this will create really much more code then my current patch.
there are different (standard) encodings, some are plain ascii, and it
should be possible to add human readable information. the output from
"openssl x509 -text -in <somecertificate>" is quite human readable, and
also acceptable as a certificate.
this bundle should be either managed by the client program, or by the
admin (that by (my) definition has a clue about things SSL).
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.
Many software uses users configuration file to store such information
like OpenSSH
with ~/.ssh directory. It just requires to be readable by only the
user.
openssh also honors site-wide configuration in e.g.
/etc/wherever/ssh_config. and ssh is kind of a "power user" tool that
you don't want your average user to mess around with.
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.
in the self-signed case, if the user approves of the
certificate, the client stores the received certificate in this special
file. in the ca-case, this file lives in e.g. /etc/tryton/ca-bundle.txt,
and is not user-modifiable.
Don't forget that we don't only work for UNIX system but also for
Windows and MacOSX.
for the sake of simplicity I only mention a somewhat typical linux case,
but windows and macosx also have their notion of "root" and proper
places to store universally available non-user-modifiable configuration.
I agree that a solution based on certificates results in more code, and
perhaps a more complex GUI to inspect the certificate. nonetheless, it
would be the right thing to do ;) perhaps tinyca could provide some
inspiration?
I'm not in a position to offer a patch myself, so I will continue to
shut up.
Robert
--
[email protected] mailing list
