On Mar 2, 1:48 pm, Robert Schöftner <[email protected]> wrote: > On 2010-03-01 23:02, Hartmut Goebel wrote:> It now took me about half an hour > trying to convince you about "my" > > solution. This time could have been spend much more productive in > > writing some documentation for SSL. But you "only trust fact". If you > > would have listen to my experience, we would have been much more > > productive already. > > > BTW: I already have a secure Tryton client implementation. But I'm these > > discussions and your code-nitpicking are discouraging me. You are acting > > like a king and > > This kind of "discussion" is disgusting, even to the non-involved casual > lurker. Suggestions like those above lead to nowhere. Accusing somebody > of being stupid and not understanding anything about this and that on a > public mailing list will not make you friends or earn any trust. Not in > this kind of project. Things trivial to one self may be non-obvious to > the next person, bitching about "this is trivial" doesn't make it so. > > So, to add something on-topic to this discussion: > > The problem to be solved is not really agreed upon, it seems. I suggest > to define the WWW with https and common web-browsers as "ideal", i.e. > what one wants to achieve. Therefore threat-model and what to do about > it is not to be discussed. What's good enough for online-banking should > be good enough for an ERP. At least at the beginning ;)
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. > > Therefore: > > * server either uses SSL or not > * in case of SSL, server may use CA-signed cert or self-signed > * server can be configured to only accept SSL connections > * server can be configured to only accept clients with valid > client-side certificate (CA-signed). (I think accepting > self-signed client certificates with some UI to choose with > client-certs to accept would not buy anything at all) > * client can be configured to require SSL connection > * client per default will present some scary dialog window in case > something is fishy about the server certificate, with the option > to inspect the certificate, and add it to the "trusted" pool. > should behave just like for example firefox or chrome when > connecting to some https website with an untrusted/invalid > certificate. > * client can be configured to not allow addition of new certificates > * client can be configured to send client certificate. 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. - 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. > > 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. 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. > > I also don't think that using self-cooked fingerprints is the right > approach, especially when storing the server or ca certificate in a > "trusted issuers/signers" file and using standard OpenSSL stuff amounts > to the same intended outcome. 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. > firefox & co seem to essentially do the > same thing. Of course because user must write his personal sensitive data in his own home. > 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. -- [email protected] mailing list
