[jbosstools-issues] [JBoss JIRA] (JBIDE-19594) SSL callback: provide meaningful hostname verifier, drop always accepting hostnames

[Andre Dietisheim (JIRA)]

     [ https://issues.jboss.org/browse/JBIDE-19594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andre Dietisheim updated JBIDE-19594:
-------------------------------------
    Description: 
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:

{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {

		public boolean allowCertificate(X509Certificate[] chain);

		public boolean allowHostname(String hostname, SSLSession session); 
	}
{code}

The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
	@Override
	public boolean allowHostname(String hostname, SSLSession sslSession) {
		return true;
	}
{code}

We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.

This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. The ssl certificate used by 

  was:
We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:

{code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
public interface ISSLCertificateCallback {

		public boolean allowCertificate(X509Certificate[] chain);

		public boolean allowHostname(String hostname, SSLSession session); 
	}
{code}

The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
{code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
	@Override
	public boolean allowHostname(String hostname, SSLSession sslSession) {
		return true;
	}
{code}

We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.



> SSL callback: provide meaningful hostname verifier, drop always accepting hostnames
> -----------------------------------------------------------------------------------
>
>                 Key: JBIDE-19594
>                 URL: https://issues.jboss.org/browse/JBIDE-19594
>             Project: Tools (JBoss Tools)
>          Issue Type: Enhancement
>          Components: openshift
>    Affects Versions: 4.3.0.Alpha2
>            Reporter: Andre Dietisheim
>             Fix For: 4.3.0.Beta1
>
>
> We're currently using an SSL callback that will allow users to get informed and act upon "faulty" certificates (ex. self-signed ones) and mismatches btw. the host we're talking to and the one that is referenced in the ssl certificate:
> {code:title=com.openshift.client.IHttpClient.ISSLCertificateCallback}
> public interface ISSLCertificateCallback {
> 		public boolean allowCertificate(X509Certificate[] chain);
> 		public boolean allowHostname(String hostname, SSLSession session); 
> 	}
> {code}
> The callback that we are using in JBT is presenting a dialog in case the jdk cannot verify the certificate (ex. self signed certificates) and allows the user to accept/deny it.
> In case the jdk cannot verify the hostname (the host we're talking to is not matching the host that's referenced in the certificate) we're currently always accepting the hostname:
> {code:title=org.jboss.tools.openshift.express.internal.ui.wizard.connection.SSLCertificateCallback}
> 	@Override
> 	public boolean allowHostname(String hostname, SSLSession sslSession) {
> 		return true;
> 	}
> {code}
> We should find a meaningfull implementation of such a verification that does not simply always accept it. A first idea would be to present the mismatch to the user and allow it to accept/refute it.
> This issue came up JBIDE-19581 when there was no callback installed which made the hostname verification failed as in jdk. The ssl certificate used by 



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)