GNOME Bugzilla – Bug 573029
More TLS control support
Last modified: 2012-01-22 05:34:12 UTC
In some cases there is need of greater control over TLS connection. Namly: 1) Specifing more precise ciphers & co. For example one may prefere to choose security over performance. The 2 most simple solutions would be: - Have a predefined enum specifing the predefined sets. - Allowing to specify the priority string 'by hand' 2) Verifing the credentials of server - allowing for example to notify the user that the certificate is expired: - Setting specific property - By some type of callback 3) Allowing to verify the client by certificate. a) Should this bug be a meta-bug or single one is sufficient? b) Should I create a 'mock' patches of mentioned solutions of should they be discussed first?
i agree. this is one place where gnio is currently lacking quite a bit. as for #2, i think the best way to do this is to be as transparent as possible. specifically, we should support a simple case of just using the client's hostname as specified in the connect call, if possible. if we do STARTTLS then a 'expected' hostname can be given at that point. this will do all the checks (like verifying hostname, not expired, etc). i haven't thought too much about #1 or #3 but i agree that they must be addressed.
Doing anything complicated requires having certificate types, and methods to act on them, etc. This could mean either exporting the GNUTLS types, or else providing glib wrappers around them. One argument for providing glib wrappers is that that would let us either switch the underlying crypto library later, or else have pluggable crypto libraries. One particular reason this might be important is that NSS has certain advantages that GNUTLS and OpenSSL are not likely to ever match (http://fedoraproject.org/wiki/FedoraCryptoConsolidation#FIPS_140), though at the same time NSS is currently unsuitable for use as a glib-level SSL library (https://bugzilla.redhat.com/buglist.cgi?bug_id=466313,466317). A glib ssl abstraction may also be useful for integrating with Windows or OS X SSL APIs (though it may be the case that they don't have SSL APIs that could integrate with gnio). A simpler solution is to just not provide any API for doing anything "complicated". Eg, you can either accept the certificate, or reject it, but you can't ask the user if he trusts its signing authority. (Hint: he does.)
(In reply to comment #2) > One argument for providing glib wrappers is that that would let us either > switch the underlying crypto library later, or else have pluggable crypto > libraries. One particular reason this might be important is that NSS has > certain advantages that GNUTLS and OpenSSL are not likely to ever match > (http://fedoraproject.org/wiki/FedoraCryptoConsolidation#FIPS_140), though at > the same time NSS is currently unsuitable for use as a glib-level SSL library > (https://bugzilla.redhat.com/buglist.cgi?bug_id=466313,466317). > > A glib ssl abstraction may also be useful for integrating with Windows or OS X > SSL APIs (though it may be the case that they don't have SSL APIs that could > integrate with gnio). > The ssl wrapping possibly could be an extention delayed to next release (i.e. 2.24 (3.0?) not 2.22) if we do not get in time. AD. NSS: I guess that https://bugzilla.redhat.com/show_bug.cgi?id=466313 is the worst. BTW. Why GnuTLS does not have FIPS 140? If not from technical reasons we could have 2 backends: - async-compatinle (GnuTLS) - FISP 140-compatible (NSS) AD. Windows ans OS X: "Implementations SSL and TLS have been widely implemented in several open source software projects. Programmers may use the OpenSSL, NSS, or GnuTLS libraries for SSL/TLS functionality. Microsoft Windows includes an implementation of SSL and TLS as part of its Secure Channel package. Delphi programmers may use a library called Indy." http://en.wikipedia.org/w/index.php?title=Transport_Layer_Security&oldid=273150628#Implementations > A simpler solution is to just not provide any API for doing anything > "complicated". Eg, you can either accept the certificate, or reject it, but you > can't ask the user if he trusts its signing authority. (Hint: he does.) > I'm not asking about CA authorities on the disk. But sometimes on servers such certs are used: - Expired - Self-signed - For other hostname - Revoked In each case (except may be the last) user should be notified as it is potential risk (in the last one I guess it might be just warning and closed connection) as: - Automatically reject would result in breaking many home servers/FLOSS servers. I'm not going to pay a few houndred $$$ just to secure the CUPS server. - Automatically accept would result in breaking the security model - I need to just take over the DNS server and redirect yourbank.com to crackers-and-hackers.com and add any certificate. Simply ignoring the problem is not good as any reasonable application would have to reimplement it wich creates the question why it is included in gnio.
(In reply to comment #3) > Why GnuTLS does not have FIPS 140? It's a certification process, not just like an API or something. And even if someone did get one release certified, the next release would need recertification. Mozilla has the money and manpower (and commercial incentives) to do this for NSS. > If not from technical reasons we could have 2 backends: > - async-compatible (GnuTLS) > - FIPS 140-compatible (NSS) If the NSS backend can't do async, then the two backends would obviously not be API-compatible, so that's no good. > - Automatically accept would result in breaking the security model - I need to > just take over the DNS server and redirect yourbank.com to > crackers-and-hackers.com and add any certificate. The security model is already broken. If the user is trying to connect to yourbank.com, and his web browser asks him if he wants to accept a self-signed certificate for crackers-and-hackers.com, he will say "yes".
(In reply to comment #4) > (In reply to comment #3) > > Why GnuTLS does not have FIPS 140? > > It's a certification process, not just like an API or something. And even if > someone did get one release certified, the next release would need > recertification. Mozilla has the money and manpower (and commercial incentives) > to do this for NSS. > That what I thought. > > If not from technical reasons we could have 2 backends: > > - async-compatible (GnuTLS) > > - FIPS 140-compatible (NSS) > > If the NSS backend can't do async, then the two backends would obviously not be > API-compatible, so that's no good. > Not exactly. NSS could have call something like g_idle_add(sync_nss_method) - or even run in separate thread if needed. It will not be true async but will be API-compatible. > > - Automatically accept would result in breaking the security model - I need to > > just take over the DNS server and redirect yourbank.com to > > crackers-and-hackers.com and add any certificate. > > The security model is already broken. If the user is trying to connect to > yourbank.com, and his web browser asks him if he wants to accept a self-signed > certificate for crackers-and-hackers.com, he will say "yes". > Actually I once entered yrebank.com instead of yourbank.com and I rejected the cert. If I acepted the cert then I could blame only myself. If I haven't been warned I would be angry on the browser. Even if 99% of users would automatically click OK that is no reason to exposing the 1% to risk.
duping to the current GSocket TLS bug. if you think there are issues in this bug that aren't addressed there, let me know (in that bug). (there's not a lot of discussion there yet, but there is support for overriding certificate acceptance, etc in the code.) *** This bug has been marked as a duplicate of bug 588189 ***