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 [2] https://github.com/apache/nifi/pull/624 <https://github.com/apache/nifi/pull/624> Andy LoPresto [email protected] [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]> 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]> 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 >> >> 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
