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 >
