[
https://issues.apache.org/jira/browse/KNOX-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428187#comment-15428187
]
Larry McCay edited comment on KNOX-733 at 8/21/16 3:36 PM:
-----------------------------------------------------------
I am thinking that we could use a permissive TrustStrategy for demo mode.
For convenience, Knox will continue to create its own selfsigned cert with a
particular DN.
We could create a custom TrustStrategy - say DemoTrustStrategy - that verifies
that particular DN and allows it anything else would be untrusted.
OTOH, if you indicate that you are running in demo mode - do you really care
much about the cert?
When not in demo mode, we will create an SSLContext to use for the connection
with the appropriate truststore loaded.
The truststore (keystore) should be loadable from the classpath which will
allow it to be found within jars.
When the expected truststore is not found on the classpath it should fall back
to the JVM default - cacerts.
KnoxCLI should also be extended to provide an export truststore command which
will extract the current gateway-identity aliased public cert and create a
truststore that can be provided to clients.
It should also provide an export to pem format that can be then used to add the
cert to cacerts for the default truststore usecase.
was (Author: lmccay):
I am thinking that we could use a permissive TrustStrategy for demo mode.
For convenience, Knox will create its own selfsigned cert with a particular DN.
We could create a custom TrustStrategy - say DemoTrustStrategy - that verifies
that particular DN and allows it anything else would be untrusted.
OTOH, if you indicate that you are running in demo mode - do you really care
much about the cert?
When not in demo mode, we will create an SSLContext to use for the connection
with the appropriate truststore loaded.
The truststore (keystore) should be loadable from the classpath which will
allow it to be found within jars.
When the expected truststore is not found on the classpath it should fall back
to the JVM default - cacerts.
KnoxCLI should also be extended to provide an export truststore command which
will extract the current gateway-identity aliased public cert and create a
truststore that can be provided to clients.
It should also provide an export to pem format that can be then used to add the
cert to cacerts for the default truststore usecase.
> Knox shell client is susceptible to man-in-the-middle attack
> -------------------------------------------------------------
>
> Key: KNOX-733
> URL: https://issues.apache.org/jira/browse/KNOX-733
> Project: Apache Knox
> Issue Type: Bug
> Reporter: chris snow
> Assignee: chris snow
> Fix For: 0.10.0
>
>
> The Knox shell client does not verify the certificate of the server.
> One option would be to provide another method where developers can provide
> their own client, e.g.
> public static Hadoop login( String url, String username, String password,
> HttpClient client ) throws URISyntaxException { }
> https://github.com/apache/knox/blob/master/gateway-shell/src/main/java/org/apache/hadoop/gateway/shell/Hadoop.java#L60
> I can provide a patch if you are happy with this approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
