[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:
-------------------------------------
    Fix Version/s: 4.3.0.Beta1


> 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 message was sent by Atlassian JIRA
(v6.3.11#6341)