You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Larry Kirby <lk...@gmail.com> on 2016/07/14 15:11:41 UTC
TLSv1.2 in GetHttp vs. InvokeHttp
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
Re: TLSv1.2 in GetHttp vs. InvokeHttp
Posted by Andy LoPresto <al...@apache.org>.
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
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Jul 14, 2016, at 1:25 PM, Andy LoPresto <al...@apache.org> 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
> alopresto@apache.org <ma...@apache.org>
> alopresto.apache@gmail.com <ma...@gmail.com>
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
>> On Jul 14, 2016, at 12:59 PM, Bryan Bende <bbende@gmail.com <ma...@gmail.com>> 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 <lkirby1266@gmail.com <ma...@gmail.com>> 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
>>>
>
Re: TLSv1.2 in GetHttp vs. InvokeHttp
Posted by Andy LoPresto <al...@apache.org>.
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
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Jul 14, 2016, at 12:59 PM, Bryan Bende <bb...@gmail.com> 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 <lk...@gmail.com> 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
>>
Re: TLSv1.2 in GetHttp vs. InvokeHttp
Posted by Bryan Bende <bb...@gmail.com>.
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 <lk...@gmail.com> 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
>