Workaround for SSL events in JSSEngine #1022
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently JSSEngine does not generate SSL events although it seems to receive the alerts from NSS. As a temporary workaround, the SSLFDProxy has been updated to keep a list of SSL socket listeners, then JSSEngine will add a listener into it. When NSS generates an SSL event, it will be passed to SSLFDProxy listeners directly, then eventually to JSSEngine listeners as well. The code that creates the SSL event in JSS_NSS_addSSLAlert() has been moved into JSS_NSS_createSSLAlert() so it can be reused.
|
fmarco76
reviewed
Aug 26, 2024
There was a problem hiding this comment.
I have tested the NonBlockingSocketFactory with patched and not patched JSS. Using the master not patched JSS I have these two scenario:
- CA signing certificate not trusted, the output is
[root@pki jss]# pki -D org.dogtagpki.client.socketFactory=org.dogtagpki.client.NonBlockingSocketFactory -d $HOME/pluto info
Server URL: https://pki.example.com:8443/
WARNING: UNTRUSTED ISSUER encountered on 'CN=pki.example.com,OU=pki-tomcat,O=EXAMPLE' indicates a non-trusted CA cert 'CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE'
Trust this certificate (y/N)? N
IOException: Unable to write to socket: Unable to validate CN=pki.example.com, OU=pki-tomcat, O=EXAMPLE: Untrusted issuer: CN=CA Signing Certificate, OU=pki-tomcat, O=EXAMPLE
- CA signing certificate trusted and self signed user certificate, the output is
[root@pki jss]# pki -D org.dogtagpki.client.socketFactory=org.dogtagpki.client.NonBlockingSocketFactory -d $HOME/pippo -n pippo info
Server URL: https://pki.example.com:8443/
SEVERE: FATAL: SSL alert received: UNKNOWN_CA
SEVERE: FATAL: SSL alert sent: UNEXPECTED_MESSAGE
RuntimeException: Unexpected error trying to construct channel: Unable to perform operations on a closed socket!
In this second case the event are correctly fired (with JSS from master).
As a result I think there is a problem with the handling of the CA authorisation and not with the event itself. In fact, server side SSL events are fired correctly since there is not this option
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently
JSSEnginedoes not generate SSL events although it seems to receive the alerts from NSS.As a temporary workaround, the
SSLFDProxyhas been updated to keep a list of SSL socket listeners, thenJSSEnginewill add a listener into it. When NSS generates an SSL event, it will be passed toSSLFDProxylisteners directly, then eventually toJSSEnginelisteners as well.The code that creates the SSL event in
JSS_NSS_addSSLAlert()has been moved intoJSS_NSS_createSSLAlert()so it can be reused.Note: This PR is needed by dogtagpki/pki#4832