Just to follow up, this is now reported as NIFI-2266 [1]. [1] https://issues.apache.org/jira/browse/NIFI-2266 <https://issues.apache.org/jira/browse/NIFI-2266>
Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Jul 14, 2016, at 1:25 PM, Andy LoPresto <[email protected]> wrote: > > Larry, > > Thanks for pointing this out. I just fixed the same issue in PostHTTP [1][2], > but as you correctly asserted InvokeHTTP handles this in a better mechanism. > GetHTTP and PostHTTP were “legacy” processors originally designed to move > flowfiles between systems over HTTP, while InvokeHTTP was developed as a > general use HTTP processor. > > I recommend all users moving forward to use InvokeHTTP, but will fix the > issue in GetHTTP (and likely PutHTTP) as I have done for PostHTTP. > > If you would like to report a Jira for this, please do; if not I will try to > get to that today. > > [1] https://issues.apache.org/jira/browse/NIFI-1688 > <https://issues.apache.org/jira/browse/NIFI-1688> > [2] https://github.com/apache/nifi/pull/624 > <https://github.com/apache/nifi/pull/624> > > Andy LoPresto > [email protected] <mailto:[email protected]> > [email protected] <mailto:[email protected]> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >> On Jul 14, 2016, at 12:59 PM, Bryan Bende <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Larry, >> >> Thanks for pointing this out. I'm not an SSL expert either, but it >> definitely seems like we should not be hardcoding TLSv1 in GetHTTP. >> The SSLContextService has a property for specifying the algorithm, so I'm >> wondering why we wouldn't use the value of that property here so the user >> can choose. >> >> I'll wait to see if others concur, but sounds like we should create a JIRA >> for this. >> >> Thanks, >> >> Bryan >> >> >> On Thu, Jul 14, 2016 at 11:11 AM, Larry Kirby <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Not an SSL expert but I have a system running java 8 where all but TLSv1.2 >>> is disabled. I had some GetHttp processors that were failing with: >>> >>> javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is >>> disabled or cipher suites are inappropriate) >>> >>> I turned on SSL debug and noticed it was rejecting TLSv1 >>> >>> Looking at the source code of GetHttp on git: >>> >>> >>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/GetHTTP.java >>> >>> <https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/GetHTTP.java> >>> >>> I noticed the following. >>> >>> final SSLConnectionSocketFactory sslsf = new >>> SSLConnectionSocketFactory(sslContext, >>> new String[]{"TLSv1"}, null, SSLConnectionSocketFactory. >>> BROWSER_COMPATIBLE_HOSTNAME_VERIFIER); >>> >>> I did not see anything similar in InvokeHttp so I went ahead and changed my >>> processors to use that and it worked. GetHttp doesn't really offer >>> anything over InvokeHttp other than a more simple configuration so I'm fine >>> with my current situation but thought you might want to know. >>> >>> Larry >>> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
