nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Oslebo <arne.osl...@uninett.no>
Subject Re: minifi secure connection
Date Wed, 21 Feb 2018 12:02:45 GMT
Hello Marc,

thank you for committing a fix for the Debian issues. Minifi now
compiles without any warnings but unfortunately I'm still having some
problems getting things to work properly. My config.yml is now a copy of
the example in the readme file where you have a GetFile and a RPG. Using
unsecured communication everything works fine. I then add a
SSLContextService and reference it from the RPG. The full config.yml is:

Flow Controller:
    id: 471deef6-2a6e-4a7d-912a-81cc17e3a205
    name: MiNiFi Flow
Processors:
    - name: GetFile
      id: 471deef6-2a6e-4a7d-912a-81cc17e3a206
      class: org.apache.nifi.processors.standard.GetFile
      max concurrent tasks: 1
      scheduling strategy: TIMER_DRIVEN
      scheduling period: 1 sec
      penalization period: 30 sec
      yield period: 1 sec
      run duration nanos: 0
      auto-terminated relationships list:
      Properties:
          Input Directory: /tmp/test
          Keep Source File: false
Controller Services:
- name: SSLServiceName
  id: 2438e3c8-015a-1000-79ca-83af40ec1974
  class: SSLContextService
  Properties:
      Client Certificate: /opt/minifi/conf/client.pem
      Private Key: /opt/minifi/conf/key.pem
      CA Certificate: /opt/minifi/conf/nifi-cert.pem
Connections:
    - name: TransferFilesToRPG
      id: 471deef6-2a6e-4a7d-912a-81cc17e3a207
      source name: GetFile
      source id: 471deef6-2a6e-4a7d-912a-81cc17e3a206
      source relationship name: success
      destination id: 8e7979f9-0161-1000-941e-3be83b4479b0
      max work queue size: 0
      max work queue data size: 1 MB
      flowfile expiration: 60 sec
Remote Processing Groups:
    - name: NiFi Flow
      id: 471deef6-2a6e-4a7d-912a-81cc17e3a208
      url: https://***:8443/nifi
      timeout: 30 secs
      yield period: 10 sec
      Input Ports:
          - id: 8e7979f9-0161-1000-941e-3be83b4479b0
            name: Input
            max concurrent tasks: 1
            Properties:
               Port: 10433
               Host Name: ***
               SSL Context Service: SSLServiceName

From the nifi-user.log i see that minifi connects and authenticates
properly. The problem is that when I add a file to the /tmp/test
directory I get the following error from minifi:
[2018-02-21 12:56:22.943]
[org::apache::nifi::minifi::sitetosite::RawSiteToSiteClient] [error]
Site2Site Protocol Version Negotiation failed
[2018-02-21 12:56:22.943]
[org::apache::nifi::minifi::RemoteProcessorGroupPort] [info] Have 0 peers
[2018-02-21 12:56:22.943]
[org::apache::nifi::minifi::RemoteProcessorGroupPort] [info] no
protocol, yielding

In nifi-app.log I get:
2018-02-21 12:56:09,654 ERROR [Site-to-Site Worker Thread-0]
o.a.n.r.io.socket.ssl.SSLSocketChannel
org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel@21e3bcdc Failed to
connect due to {}
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
    at
sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:156)
    at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868)
    at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
    at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
    at
org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.performHandshake(SSLSocketChannel.java:237)
    at
org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.connect(SSLSocketChannel.java:163)
    at
org.apache.nifi.remote.SocketRemoteSiteListener$1$1.run(SocketRemoteSiteListener.java:166)
    at java.lang.Thread.run(Thread.java:748)
2018-02-21 12:56:09,655 ERROR [Site-to-Site Worker Thread-0]
o.a.nifi.remote.SocketRemoteSiteListener RemoteSiteListener Unable to
accept connection from Socket[unconnected] due to
javax.net.ssl.SSLException: Inbound closed before receiving peer's
close_notify: possible truncation attack?

I've tried both nifi-1.5.0 and nifi-1.6.0-SNAPSHOT.

Any suggestions as to what might be wrong?

Best regards,
Arne


On 13/02/2018 18:53, Marc wrote:
> Arne,
>   I took a break from the issue and came back and tried installing a
> different version of openssl on top of the distro. When doing so it
> linked properly and I'm able to send data through a secure Socket. Now
> that I have a solution, I will move this discussion to the ticket. 
>
>   As a result of my testing, I will make updates to the bootstrap
> script and build instructions to instruct users to install libssl1.0
> on Debian Stretch ( and perhaps Raspbian ). Any comments on the ticket
> will be
> appreciated: https://issues.apache.org/jira/browse/MINIFICPP-400
> <https://issues.apache.org/jira/browse/MINIFICPP-400> . I will have a
> fix once I finish testing across a few platforms. 
>   
>   Thanks,
>   Marc
>
> On Tue, Feb 13, 2018 at 9:55 AM, Marc P. <marc.parisi@gmail.com
> <mailto:marc.parisi@gmail.com>> wrote:
>
>     Arne,
>
>     Thanks for the info. I'm running the same environment with the
>     same warnings produced -- and segfault -- aso I'll get back to you
>     once I've identified the issue.
>
>     TL;DR: Created a ticket
>     ( https://issues.apache.org/jira/browse/MINIFICPP-400
>     <https://issues.apache.org/jira/browse/MINIFICPP-400>. ) to help
>     insulate users from this more.
>
>     More explanation:
>
>
>       In regards to the different versions, there were a number of
>     tickets on Debian's bug report logs regarding the curl ABI. An
>     example [1] was solved by changing linked versions of libraries. 
>
>       The gist is that the SSL_CTX struct changes. I've validated with
>     gdb that the struct is being passed in on U16 ( and works ) AND
>     Debian stretch ( does not work ). The structures are slightly
>     different. I'm going to dive deeper into this. I've created
>     [2] https://issues.apache.org/jira/browse/MINIFICPP-400
>     <https://issues.apache.org/jira/browse/MINIFICPP-400>. 
>
>        [2] has more recent conversation as the issue still exists.
>     This will require an soname change hence why they've likely been
>     discussing this for two years. I think our job will be to insulate
>     users, so [3] will be our efforts to do so. Thanks for identifying
>     this. I'll continue to investigate this to address it seamlessly
>     through either our bootstrap script ( bootstrap.sh in the root )
>     or within CMAKE. Obviously we don't want to alienate Debian users. 
>       
>
>     [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018
>     <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018>
>     [2] https://issues.apache.org/jira/browse/MINIFICPP-400
>     <https://issues.apache.org/jira/browse/MINIFICPP-400>. 
>     [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858398
>     <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858398>
>
>     On Tue, Feb 13, 2018 at 8:28 AM, Arne Oslebo
>     <arne.oslebo@uninett.no <mailto:arne.oslebo@uninett.no>> wrote:
>
>         Marc,
>
>         I'm running it on Debian Stretch. libssl version might be the
>         problem. I see that both libssl1.0.2 and libssl1.1 are
>         installed. I took another look at the build log and found this:
>         /usr/bin/ld: warning: libssl.so.1.0.2, needed by
>         /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcurl.so,
>         may conflict with libssl.so.1.1
>         /usr/bin/ld: warning: libcrypto.so.1.0.2, needed by
>         /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcurl.so,
>         may conflict with libcrypto.so.1.1
>
>         I'll see if can remove one of the versions to avoid possible
>         conflict.
>
>         The full backtrace log is attached and thanks for looking into
>         this,
>
>         Arne
>
>
>
>         On 13/02/2018 12:55, Marc wrote:
>>         Arne,
>>            Sorry for your troubles! Can you give me some insight into
>>         your distro?
>>
>>            I've been unable to replicate the issue on OSX, u16, and
>>         arch...but all are running a different version of OpenSSL.
>>         What version of OpenSSL are you running and on what distro?
>>         I'll be happy to try it to track this down. 
>>
>>            Additionally, do you have the log file you can pass on?
>>         The reason I ask is that the line specified in gdb is a log
>>         statement with usage of constructs that are inherent to
>>         libstdc++, so they won't cause a memory error. The log file
>>         should help identify this and give me insight into what
>>         occurred just before the error.
>>
>>            Thanks,
>>            Marc
>>
>>         On Tue, Feb 13, 2018 at 6:17 AM, Arne Oslebo
>>         <arne.oslebo@uninett.no <mailto:arne.oslebo@uninett.no>> wrote:
>>
>>             Hello Mark,
>>
>>             thanks for the update. I tried running master from github
>>             but unfortunately I now get a segmentation fault:
>>
>>             Thread 1 "minifi" received signal SIGSEGV, Segmentation
>>             fault.
>>             0x00007ffff777420a in ?? () from
>>             /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>>             (gdb) bt full
>>             #0  0x00007ffff777420a in ?? () from
>>             /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>>             No symbol table info available.
>>             #1  0x00007ffff7799681 in ?? () from
>>             /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>>             No symbol table info available.
>>             #2  0x00007ffff777f2f6 in SSL_CTX_use_certificate () from
>>             /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>>             No symbol table info available.
>>             #3  0x00007ffff777f6c0 in SSL_CTX_use_certificate_file ()
>>             from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>>             No symbol table info available.
>>             #4  0x0000555555ef91cb in
>>             org::apache::nifi::minifi::controllers::SSLContextService::configure_ssl_context
>>             (this=0x5555569948b0, ctx=0x555556a28430) at
>>             /usr/local/src/nifi-minifi-cpp/extensions/http-curl/../../libminifi/include/controllers/SSLContextService.h:165
>>                     retp = 1
>>             #5  0x0000555555ef9be4 in
>>             org::apache::nifi::minifi::utils::HTTPClient::configure_ssl_context
>>             (curl=0x555556a149e0, ctx=0x555556a28430,
>>             param=0x5555569948b0) at
>>             /usr/local/src/nifi-minifi-cpp/extensions/http-curl/client/HTTPClient.h:177
>>                     ssl_context_service = 0x5555569948b0
>>
>>             Any idea what the problem might be?
>>
>>             My full config.yml:
>>
>>             Flow Controller:
>>               name: MiNiFi Flow
>>             Controller Services:
>>             - name: SSLServiceName
>>               id: 2438e3c8-015a-1000-79ca-83af40ec1974
>>               class: SSLContextService
>>               Properties:
>>                   Client Certificate: /opt/minifi/conf/client.pem
>>                   Private Key: /opt/minifi/conf/client.key
>>                   Passphrase: secret
>>                   CA Certificate: /opt/minifi/conf/nifi-cert.pem
>>             Processors:
>>             - id: cecb1868-9e5a-3e6c-0000-000000000000
>>               name: TailFile
>>               class: org.apache.nifi.processors.standard.TailFile
>>               max concurrent tasks: 1
>>               scheduling strategy: TIMER_DRIVEN
>>               scheduling period: 0 sec
>>               penalization period: 30 sec
>>               yield period: 1 sec
>>               run duration nanos: 0
>>               auto-terminated relationships list: []
>>               Properties:
>>                 File Location: Local
>>                 File to Tail: /tmp/test.log
>>                 Initial Start Position: Beginning of File
>>                 Rolling Filename Pattern:
>>                 tail-base-directory:
>>                 tail-mode: Single file
>>                 tailfile-lookup-frequency: 10 minutes
>>                 tailfile-maximum-age: 24 hours
>>                 tailfile-recursive-lookup: 'false'
>>             Connections:
>>             - id: 76ad4bc4-6557-3e23-0000-000000000000
>>               name: TailFile/success/56ae5abc-0161-1000-aa9e-c340d726e043
>>               source id: cecb1868-9e5a-3e6c-0000-000000000000
>>               source relationship names:
>>               - success
>>               destination id: 56ae5abc-0161-1000-aa9e-c340d726e043
>>               max work queue size: 10000
>>               max work queue data size: 1 GB
>>               flowfile expiration: 0 sec
>>               queue prioritizer class: ''
>>             Remote Processing Groups:
>>             - id: 3a25e1a3-c1b2-3e78-0000-000000000000
>>               name: ''
>>               url: https://w.x.y.z:8443/nifi
>>               comment: ''
>>               timeout: 30 sec
>>               yield period: 10 sec
>>               transport protocol: RAW
>>               proxy host: ''
>>               proxy port: ''
>>               proxy user: ''
>>               proxy password: ''
>>               local network interface: ''
>>               Input Ports:
>>               - id: 56ae5abc-0161-1000-aa9e-c340d726e043
>>                 name: Minifi
>>                 comment: ''
>>                 max concurrent tasks: 1
>>                 use compression: false
>>                 Properties:
>>                   Port: 10443
>>                   SSL Context Service: SSLServiceName
>>                   Host Name: w.x.y.z
>>               Output Ports: []
>>             Provenance Reporting:
>>
>>
>>
>>             On 09/02/2018 20:18, Marc wrote:
>>>             Arne,
>>>               I submitted a
>>>             PR https://github.com/apache/nifi-minifi-cpp/pull/263
>>>             <https://github.com/apache/nifi-minifi-cpp/pull/263> to
>>>             address these issues. 
>>>
>>>             On Fri, Feb 9, 2018 at 8:38 AM, Marc
>>>             <phrocker@apache.org <mailto:phrocker@apache.org>> wrote:
>>>
>>>                 Arne,
>>>                    Evidently the HTTPClient relies on an SSL Context
>>>                 Service. Try the following configuration in the
>>>                 config.yml file, where you define the context
>>>                 service and reference it from the RPG. Let me know
>>>                 if that works for you!
>>>
>>>                   Additionally, I think you pointed out an
>>>                 inconsistency where we can improve the configuration
>>>                 and documentation. I've
>>>                 created https://issues.apache.org/jira/browse/MINIFICPP-396
>>>                 <https://issues.apache.org/jira/browse/MINIFICPP-396>
>>>                 and will take care of that ASAP. Thanks 
>>>                   very much for identifying this!
>>>
>>>                 Remote Processing Groups:
>>>                     - name: NiFi Flow
>>>                       id: 2438e3c8-015a-1000-79ca-83af40ec1998
>>>                       url: https://127.0.0.1:8383/nifi
>>>                       timeout: 30 secs
>>>                       yield period: 5 sec
>>>                       Input Ports:
>>>                           - id: 2438e3c8-015a-1000-79ca-83af40ec1999
>>>                             name: fromnifi
>>>                             max concurrent tasks: 1
>>>                             Properties:
>>>                                 Port: 10443
>>>                                 SSL Context Service: SSLMe
>>>                                 Host Name: 127.0.0.1
>>>                       Output Ports:
>>>                           - id: ac82e521-015c-1000-2b21-41279516e19a
>>>                             name: tominifi
>>>                             max concurrent tasks: 2
>>>                             Properties:
>>>                                 Port: 10443
>>>                                 SSL Context Service: SSLMe
>>>                                 Host Name: 127.0.0.1
>>>
>>>                 Controller Services:
>>>                     - name: SSLMe
>>>                       id: 2438e3c8-015a-1000-79ca-83af40ec1974
>>>                       class: SSLContextService
>>>                       Properties:
>>>                           Client Certificate:
>>>                 /opt/minifi/conf/client.pem
>>>                           Private Key: /opt/minifi/conf/client.key
>>>                           Passphrase: /opt/minifi/conf/password
>>>                           CA Certificate certificate:
>>>                 /opt/minifi/conf/nifi-cert.pem
>>>
>>>                 On Fri, Feb 9, 2018 at 5:54 AM, Arne Oslebo
>>>                 <arne.oslebo@uninett.no
>>>                 <mailto:arne.oslebo@uninett.no>> wrote:
>>>
>>>                     Hello,
>>>
>>>                     I'm trying to set up secure communication
>>>                     between minifi-cpp 0.4.0 and
>>>                     nifi, but unfortunately it fails with the
>>>                     following errors:
>>>
>>>                     [org::apache::nifi::minifi::utils::HTTPClient]
>>>                     [error]
>>>                     curl_easy_perform() failed SSL connect error
>>>                     [org::apache::nifi::minifi::RemoteProcessorGroupPort]
>>>                     [error]
>>>                     ProcessGroup::refreshRemoteSite2SiteInfo --
>>>                     curl_easy_perform() failed
>>>
>>>                     I looked quickly at the code and it seems the
>>>                     problem is that HTTPClient
>>>                     never calls configure_secure_connection and
>>>                     therefor never presents a
>>>                     client certificate to nifi.
>>>
>>>                     The config.yml file defines a TailFail that send
>>>                     data directly to a
>>>                     remote process group.
>>>
>>>                     My  minifi.properties file:
>>>                     nifi.version=0.1.0
>>>                     nifi.flow.configuration.file=/opt/minifi/conf/config.yml
>>>                     nifi.administrative.yield.duration=30 sec
>>>                     nifi.bored.yield.duration=10 millis
>>>                     nifi.provenance.repository.directory.default=/opt/minifi/provenance_repository
>>>                     nifi.provenance.repository.max.storage.time=1 MIN
>>>                     nifi.provenance.repository.max.storage.size=1 MB
>>>                     nifi.remote.input.secure=true
>>>                     nifi.https.need.ClientAuth=true
>>>                     nifi.https.client.certificate=/opt/minifi/conf/client.pem
>>>                     nifi.https.client.private.key=/opt/minifi/conf/client.key
>>>                     nifi.https.client.pass.phrase=/opt/minifi/conf/password
>>>                     nifi.https.client.ca
>>>                     <http://nifi.https.client.ca>.certificate=/opt/minifi/conf/nifi-cert.pem
>>>                     controller.socket.host=localhost
>>>                     controller.socket.port=9998
>>>
>>>                     Certificates and key are correct and have been
>>>                     verified using curl from
>>>                     the command line. Are there any other things I
>>>                     need to do to get minifi
>>>                     to set up a secure connection? As far as I
>>>                     understand the "Security
>>>                     Properties:" in config.yml is only used by the
>>>                     java version of minifi?
>>>
>>>                     Thanks,
>>>                     Arne
>>>
>>>
>>>
>>
>>
>
>
>


Mime
View raw message