Mailing-List: contact dev-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zookeeper.apache.org
Date: Mon, 27 Nov 2017 03:28:00 +0000 (UTC)
From: "Feng Shaobao (JIRA)" <jira@apache.org>
To: dev@zookeeper.apache.org
Message-ID: <JIRA.13120826.1511753182000.321283.1511753280041@Atlassian.JIRA>
In-Reply-To: <JIRA.13120826.1511753182000@Atlassian.JIRA>
References: <JIRA.13120826.1511753182000@Atlassian.JIRA> <JIRA.13120826.1511753182007@jira-lw-us.apache.org>
Subject: [jira] [Updated] (ZOOKEEPER-2949) SSL ServerName not set when using
 hostname, some proxies may failed to proxy the request.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 27 Nov 2017 03:28:05 -0000


     [ https://issues.apache.org/jira/browse/ZOOKEEPER-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Feng Shaobao updated ZOOKEEPER-2949:
------------------------------------
    Description: 
In our environment, the zk clusters are all behind a proxy, the proxy decide to transfer the request from client based on the "ServerName" field in SSL Hello packet(the proxy served on SSL only). but the Hello packets that zk client sended do proxy do not contain the "ServerName" field in it. after inspect the codes, we have found that it is because that zk client did not specify the peerHost when initializing the SSLContext.

In the method initSSL of class ZKClientPipelineFactory, it initialize the SSLEngine like below:

sslEngine = sslContext.createSSLEngine();

Actually the sslContext provide another factory method that receives the hostName and port parameter.

public final SSLEngine createSSLEngine(String hostName, int port)

If we call this method to create the SSLEngine, then the proxy will know which zk cluster it really want to access.

  was:
In the method initSSL of class ZKClientPipelineFactory, it initialize the SSLEngine like below:

sslEngine = sslContext.createSSLEngine();

Actually the sslContext provide another factory method that receives the hostName and port parameter.

public final SSLEngine createSSLEngine(String hostName, int port)

If we call this method to create the SSLEngine, then the proxy will know which zk cluster it really want to access.


> SSL ServerName not set when using hostname, some proxies may failed to proxy the request.
> -----------------------------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-2949
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2949
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: java client
>    Affects Versions: 3.5.3
>         Environment: In our environment, the zk clusters are all behind a proxy, the proxy decide to transfer the request from client based on the "ServerName" field in SSL Hello packet(the proxy served on SSL only). but the Hello packets that zk client sended do proxy do not contain the "ServerName" field in it. after inspect the codes, we have found that it is because that zk client did not specify the peerHost when initializing the SSLContext.
>            Reporter: Feng Shaobao
>             Fix For: 3.5.4
>
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> In our environment, the zk clusters are all behind a proxy, the proxy decide to transfer the request from client based on the "ServerName" field in SSL Hello packet(the proxy served on SSL only). but the Hello packets that zk client sended do proxy do not contain the "ServerName" field in it. after inspect the codes, we have found that it is because that zk client did not specify the peerHost when initializing the SSLContext.
> In the method initSSL of class ZKClientPipelineFactory, it initialize the SSLEngine like below:
> sslEngine = sslContext.createSSLEngine();
> Actually the sslContext provide another factory method that receives the hostName and port parameter.
> public final SSLEngine createSSLEngine(String hostName, int port)
> If we call this method to create the SSLEngine, then the proxy will know which zk cluster it really want to access.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)