Does an SSLServerSocket cache the trusted certs?
I implemented a TrustStoreManager for an SSLServerSocket so that checkClientTrusted() returns if the cert is acceptable. But through debugging code I see that once checkClientTrusted() returns normally, it doesn't get invoked when a subsequent connection is made to the same server socket.
This is causing a problem because I have a "trust all certs" override in the app. If I send a bad cert, the TrustManager correctly rejects it. Then I set the "trust all certs" override and the server accepts the connection as expected. But then when I turn the override off again, the server does not reject the connection. And my debug tells me that checkClientTrusted() is not even invoked.
The only conclusion I can draw is that the socket remembers that a specific cert is trusted, and doesn't check it again for subsequent connections. Is this correct? If so, is there a way to make the socket "forget" trusted certs? I'd prefer not to tell the user she has to restart the app whenever she resets the "trust all cert" override.
# 1
> This is causing a problem because I have a "trust all certs" override in the app.
Why? This is very bad practice. SSL is not secure without correct authentication of certificates.
If you ever accept a certificate from a client IP address it will be remembered in the SSLSession. You can invalidate the session if you want the server to forget about the certificate.
ejpa at 2007-7-12 10:37:20 >
# 2
> Why? This is very bad practice. SSL is not secure
> without correct authentication of certificates.
The app I'm writing permits a client to copy its clipboard and/or selected files to the server. It may be used across a public network or the client and server may reside on a local LAN that is either not connected to a public network or at least the port in use is not open through the firewall. In the latter case, the user can forgo setting up and maintaining certs in the TrustStore if they choose (private key entries for the SSL session to use are created automatically). The user is warned with a pop-up of the consequences of trusting all certs, when that option is selected.
Another use case where the same issue arises is when the user removes a trusted cert from the TrustStore, and the client using that cert subsequently attempts to connect. The user can remove certs from the TrustStore very easily, from a control panel while the server is running. If I didn't invalidate the session, the user would believe that the cert in question was no longer trusted, but the server would still accept connections authenticated with it.
At any rate, your answer solved my problem. I was closing the connection after each client-server transaction, but overlooking the fact that a subsequent connection on the same socket would continue the SSL session. Now I'm invalidating the session after closing the connection, and changes to the trust policy are effective on the next connection.
Thanks for your help.
-Mark
