|
Bugzilla – Full Text Bug Listing |
| Summary: | kopete needs to display SSL certificate details | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | Thomas Biege <thomas> |
| Component: | KDE4 Applications | Assignee: | Will Stephenson <wstephenson> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P2 - High | CC: | security-team |
| Version: | GMC | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Thomas Biege
2005-05-27 09:51:16 UTC
do you know an official download place for that CA ? i already tried to inquire regarding this certificate problem, but received no feedback. it is probably not just a missing root ca If the client also verifies the CN to be the same as the server's hostname it will fail too. im.novell.com uses a cert with CN im.provo.novell.com the CA is "SERVICES2" - "Organizational CA". Whatever it is, it doesn't look trustworthy enough to be shipped as root-CA. Innerweb etc is signed by Equifax which is part of the root CA list. Besides that as Thomas already noted the certificate is issued for a totally different host (not even the same IP). As such the data is bogus and its a server configuration error. Its correct that the Certificate is rejected. Ok. We need to get in touch with the folks providing ssl certs on the novell site. I remeber there are even more problems beside the 2 mentioned above. I'll ask Ed Reed maybe he can give us a pointer. Steve Whitehouse from Novell will investigate in changing this CN. Then we could ship their CA cert and everything will be fine. Ed, was this issue solved or are there any other news you can give us. Thanks. Some internal Novell servers use self-signed certs, others use certs created through Novell's PKI hierarchy and are thus rooted in a Novell root cert (that is not widely distributed for obscure reasons), and still other services use 3rd-party defined certs. Steve Whitehouse (Novell IS&T) reports that the certs for the im server, for instance, are self=signed certs, and so are bogus - not suitable for distribution. It is their intention to continue to use their own CA for signing. Why the server name would not match the certificate name is another mystery. Steve points out that if the application (Kopete?) gives the user the chance to review the unrecognized cert and, upon inspection, accept it as valid (yes, I know the whole idea of certs was to avoid man-in-the-middle attacks, so the discerning user would want to verify the authenticity of the servers cert via some out-of-band means), then they can choose to "trust" it. Or should be able to. That's the present story. I don't think there's any further action on this required, unless there is need for a user dialog to allow users to add new certs to their trusted cache through some dialog or command-line scripted action (via YOU or YAST or Red Carpet or ZEN or whatever). Ed ok, not a KDE bug. Ed, please assign it to the responsible person. Dirk, Ed said it needs to be fixed by changing both ends a) fixing the CN in the certificate b) adding a more verbose SSL certification process (like konqueror uses) to kopete. So, it still is a KDE "bug". :) well, the main reason that isn't done is because kopete doesn't use kdelibs providers for SSL validation. At least I heard George complaining about this multiple times already. Kopete asks the user to accept or reject an invalid cert. The code in Kopete is a copy of kdelibs code adapted to work with the numerous non-kdelibs SSL backends in use in Kopete. Pending a rewrite of every protocol plugin to use kdelibs for SSL, what's the more verbose process you would like to see? 'The certificate is valid, but untrusted'? The other way around: Invalid but trusted. :) We have 2 choices with this. Either show the kopete user the certificate and its fingerprint (md5 and sha1) and let the user decide or we can include the CA cert from Novell. Here's the need: untrusted certs (from whomever) need to be dealt with once and for all - by displaying them to the user and inviting them to trust them or not, per the industry norm (at this point). There will always be customers who choose to use self-signed certs. The ONLY way to responsibly handle them is to let the user populate them into their trusted root-CA cache. Such is the "magic" of the "web of trust" security model of PGP and peer-wise PKI. KDE needs to be consistent on how this is done, and Kopete needs to use that consistent mechanism (or at least, look and feel). Why wouldn't it? Will, ideas how to solve it? I would prefer the dialog konqueror uses. But showing at least the md5 and sha1 fingerprint would be ok. There's only one good way to solve it, and that's a massive, invasive rewrite of the different SSL code in each protocol plugin in Kopete, so that it can call out to present a common prompt to the user. Either showing fingerprints or the Konq dialog requires the same approach. Since it's such a lot of work I am loath to pick it up before the scheduled massive, invasive rewrite of Kopete for KDE4. I think that it is ok and we can live with it till KDE4. Ok, closing as later. so. any improvements with kde4? Will? Will? No, the new SSL socket in kdelibs which will be able to be used all over Kopete is still being worked on, and can't be used in 4.1. Will, will this bug ever get fixed? I'm pinging upstream again to find out the socket class' status now. Just checked, and the SSL socket class (KTcpSocket) is ready for use but none of the Kopete protocol impls are using it. I'm asking upstream Kopete if they want to port. Mass-closing all my openSUSE bug reports for old openSUSE version. |