[
https://issues.apache.org/jira/browse/FLINK-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16473448#comment-16473448
]
ASF GitHub Bot commented on FLINK-9312:
---------------------------------------
Github user StephanEwen commented on the issue:
https://github.com/apache/flink/pull/5966
I agree, we need different key/truststores for the internal/external
connectivity. This PR was meant as a step in that direction, separating at
least within the SSL Utils the internal and external context setup.
In your thinking, is there ever a case for a different internal
authentication method than "single trusted certificate"? What if were not tied
to akka? (Side note: I think for internal communication, 'authentication is
authorization' is probably reasonable, because the are no different users/roles
for internal communication).
Would you assume that internally, we never do hostname verification?
> Perform mutual authentication during SSL handshakes
> ---------------------------------------------------
>
> Key: FLINK-9312
> URL: https://issues.apache.org/jira/browse/FLINK-9312
> Project: Flink
> Issue Type: New Feature
> Components: Security
> Reporter: Stephan Ewen
> Priority: Major
> Fix For: 1.6.0
>
>
> Currently, the Flink processes encrypted connections via SSL:
> - Data exchange TM - TM
> - RPC JM - TM
> - Blob Service JM - TM
> However, the server side always accepts any client to build up the
> connection, meaning the connections are not strongly authenticated.
> Activating SSL mutual authentication solves that - only processes that have
> the same certificate can connect.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
