This week I started working on vanilla purpose of certificates which is authentication of the public key issuers. From Smack point of view I have to create SSLContext which is going to be processed further in Smack. This context require me to provide Trust Managers which task is to provide context with accepted issuers and validate certificates. Writing Trust Managers well is difficult job and it is easy to make mistakes that would result in accepting certificates which shouldn’t be accepted.
What makes it especially hard is that I create trust manager that will sometimes accept certificates that shouldn’t be accepted . It will be left for Spark user if he want to accept expired certificate or even revoked and by that consciously lost some of the security guarantees from validation mechanisms.
Is that wrong? Yes.
Should it be done? Definitely no.
Still even web browsers allow user to add certificate to exception list . My task is to allow Spark’s users to do the same and even provide greater flexibility at setting which parts of validation bypass. I created 2 Trust Managers. First serve as default Trust Manager which is provided in SSLContext initialization. Second one is Exceptions Trust Manager which is called internally in default Trust Manager. It contain as accepted issuers only list of exempted certificates but doesn’t do any checks on validity of it. If it fails (which will only happen when presented by server chain of certificates doesn’t contain one of the exempted certificates) then authentication logic goes back to default trust manager which make use of all trusted issuers certificates and do every required check, unless user disable particular “validity test” in certificates interface.
At the beginning of SSL/TLS connection there is conducted handshake between client and server with exchange of the certificates and information about encryption modes/ciphers. This handshake can be renegotiated at any time by any side of connection and then every check/certificate validation would be done again.
The problem is that Smack encapsulate SSL handshake and I don’t think I am able to force such renegotiation. So probably nothing will happen if certificate expires during connection but I still need to do a bit more work until I can start testing if SSL is working.
Currently Spark shows an error if “Accept all certificates” is not selected and something is bad with the certificate. I guess this comes from Smack and at least showing the same error would be better, if that can’t be handled in the certificates manager context. @Guus der Kinderen ?
There is also button “Use old SSL port method”. I have no idea why it is called “old” and further implementation is broken anyway but after some work around this I can establish SSL connection. I still have to implement some certificate validation functions and do some testing with different certificates to make sure that it will be really secured.
I’m not sure. Old SSL used 5223 port, when currently 5222 is used for both plain and secured connections. Maybe it used SSLv2 or something and new one is TLS.
Maybe it’s time for Spark to drop that legacy old SSL support completely. I will file a ticket to consider this [SPARK-1960] Drop support for Old SSL on port 5223 - IgniteRealtime JIRA