Version: unspecified (using Devel) OS: Linux Handle Channel.Type.ServerTLSConnection Reproducible: Didn't try Actual Results: If the certificate of the server is not valid, i see a gtk window popping up. Expected Results: If the certificate of the server is not valid, i see a nice kde window popping up.
We need this soon. Any volunteers for this?
*** Bug 282215 has been marked as a duplicate of this bug. ***
If you can talk me through it, I can probably get it done.
I tried some time ago to get the TLS stuff working, but the problem at the time was that the auth handler couldn't receive any ofT.Authentication.TLSCertificate object path, so I gave up at that time, but I don't know if this was fixed upstream or not I agree that this is should be in 0.4, and since Martin already volunteered, I'll just leave all the fun to him ;) @mkc182 I can try to help as well, but the best person to ask about this is probably andrunko...
@DrDanz I fixed the bug you had. I know what to do now, just haven't had time. Assigning to me, deferring to 0.5
Git commit 036d71f4f241a1b0e07c74a8f4a18e370957bcfe by Daniele E. Domenichelli. Committed on 28/10/2012 at 03:48. Pushed by ddomenichelli into branch 'master'. Merge branch 'tls-handler' This adds a very basic handling of ServerTLSConnection channels (Still not enabled, you need to enable the TLS handler from main) http://commits.kde.org/telepathy-auth-handler/036d71f4f241a1b0e07c74a8f4a18e370957bcfe
The "hard" part is done, now we just need a nice dialog, so I'm marking this as a Junior Job
No it is not. You've done the easy code bit, which I'd got up to (and lost) The hard part is checking the QSSL Certificate is legit against the KDE verified root certificates. (and no QSslCerticiate::isValid() does not do it)
*** Bug 294369 has been marked as a duplicate of this bug. ***
*** Bug 294371 has been marked as a duplicate of this bug. ***
I did a little research on this and there is problem: the entire SSL API in KDE is not public, which means that we can't access the KDE certificate manager, certificates rules etc. from the auth-handler.
David try making it public, but he didn't succeed afair - see http://lists.kde.org/?l=kde-core-devel&m=133366816318843&w=2 for details
Ok, I feel I should give an update on where we are: We have a list of QSslCertificates in a chain, we can get the hostname of the server we're trying to connect to from dbus too. We can get the list of valid CACertificates using http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKSslCertificateManager.html caCertificates. What I can't find, is the code to check a certificate is valid for a given hostname, and the cert signing it is valid.. up until the root certificate. What I can't find is the code to do this. This is the part that needs researching and is currently blocking. /Finally/ if it fails show a dialog to a user. There's some nice code in Rekonq for showing a dialog which takes a certicate and a list of KSSlErrors's indicating what failed. In the event of the user cancelling the dialog we need to turn the KSSlErrors into Tp error codes - which is all pretty trivial.
(In reply to comment #13) > Ok, I feel I should give an update on where we are: > > We have a list of QSslCertificates in a chain, we can get the hostname of > the server we're trying to connect to from dbus too. KSSLD? Nope. It takes/returns KSslCertificateRule objects which are not part of public API. > We can get the list of valid CACertificates using > http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/ > classKSslCertificateManager.html caCertificates. KSslCertificateManager is not public API either (it is exported, but headers are not installed) - it's mentioned in the ML thread Martin posted above that we could ship our own headers, but that can cause lots of troubles. > What I can't find, is the code to check a certificate is valid for a given > hostname, and the cert signing it is valid.. up until the root certificate. > What I can't find is the code to do this. This is the part that needs > researching and is currently blocking. > > /Finally/ if it fails show a dialog to a user. There's some nice code in > Rekonq for showing a dialog which takes a certicate and a list of > KSSlErrors's indicating what failed. In the event of the user cancelling the > dialog we need to turn the KSSlErrors into Tp error codes - which is all > pretty trivial.
Rekonq had to solve this same issue (certificates checking), I suggest we look what they did/ask for their help.
Won't help, that uses KIO for HTTP - SSL checking is inbuilt.
Git commit 8a2ab704e6e19c6a06c753a1ed75efd7a29161c0 by Dan Vrátil. Committed on 06/02/2013 at 13:23. Pushed by dvratil into branch 'master'. Merge branch 'tls-handler' REVIEW: 108791 M +10 -9 CMakeLists.txt http://commits.kde.org/telepathy-auth-handler/8a2ab704e6e19c6a06c753a1ed75efd7a29161c0
(In reply to comment #17) Thanks a lot!