Thanks much. Ying On Tue, May 30, 2017 at 1:07 PM, Thejas Nair <thejas.n...@gmail.com> wrote:
> It went in under guise of the jira - HIVE-13390. > Commit - https://github.com/apache/hive/commit/ > 3b2ea248078bdf3a8372958cf51a989dc3883bcc > > On Tue, May 30, 2017 at 12:35 PM, Ying Chen <ying.in...@gmail.com> wrote: > >> Hello - >> Was there a particular JIRA(s) that went into Hive 1.2.2 that fixed this >> issue? >> Thanks much. >> Ying >> >> >> On Wed, May 24, 2017 at 3:56 PM, Vaibhav Gumashta < >> vgumas...@hortonworks.com> wrote: >> >>> Severity: Important >>> >>> Vendor: The Apache Software Foundation >>> >>> Versions Affected: >>> Apache Hive 0.13.x >>> Apache Hive 0.14.x >>> Apache Hive 1.0.0 - 1.0.1 >>> Apache Hive 1.1.0 - 1.1.1 >>> Apache Hive 1.2.0 - 1.2.1 >>> Apache Hive 2.0.0 >>> >>> Description: >>> >>> Apache Hive (JDBC + HiveServer2) implements SSL for plain TCP and HTTP >>> connections (it supports both transport modes). While validating the >>> server’s certificate during the connection setup, the client doesn’t seem >>> to be verifying the common name attribute of the certificate. In this way, >>> if a JDBC client sends an SSL request to server abc.com, and the server >>> responds with a valid certificate (certified by CA) but issued to >>> xyz.com, the client will accept that as a valid certificate and the SSL >>> handshake will go through. >>> >>> Mitigation: >>> >>> Upgrade to Apache Hive 1.2.2 for 1.x release line, or to Apache Hive >>> 2.0.1 or later for 2.0.x release line, or to Apache Hive 2.1.0 and later >>> for 2.1.x release line. >>> >>> Credit: This issue was discovered by Branden Crawford from Inteco >>> Systems Limited (inetco.com). >>> >> >> >