Github user trkurc commented on the issue:
https://github.com/apache/nifi/pull/1986
reviewing now
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user trkurc commented on the issue:
https://github.com/apache/nifi/pull/1986
It seems as though if I change to SSLv3, for example, that I am unable to
POST.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user jskora commented on the issue:
https://github.com/apache/nifi/pull/1986
@trkurc Have you [enabled
SSLv3](https://stackoverflow.com/questions/28236091/how-to-enable-ssl-3-in-java)
in the JVM?
It is disabled by default starting with [Java 8 Update
31](http://www.or
Github user m-hogue commented on the issue:
https://github.com/apache/nifi/pull/1986
Jetty explicitly disables it as well. The default set of protocols
disallowed by Jetty are {"SSL", "SSLv2", "SSLv2Hello", "SSLv3"}
I'm happy to alter Jetty's default config, but should we enco
Github user trkurc commented on the issue:
https://github.com/apache/nifi/pull/1986
Joe and Mike, sort of to my point, and both of your comments reinforced it,
it was counter intuitive that I could select a protocol, and have it not work
or give an error message that was substantive.
Github user m-hogue commented on the issue:
https://github.com/apache/nifi/pull/1986
I'll track down error reporting.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and
Github user m-hogue commented on the issue:
https://github.com/apache/nifi/pull/1986
@trkurc and @jskora : After working through a few test cases, I have a
proposal i'd like your thoughts on.
What if we allow the user to select any SSL protocol available through the
UI, but
Github user trkurc commented on the issue:
https://github.com/apache/nifi/pull/1986
@m-hogue - where would the exception occur? would it prevent the processor
from starting, or just when it fires up the jetty server? would the problem be
evident on the UI?
---
If your project is set
Github user m-hogue commented on the issue:
https://github.com/apache/nifi/pull/1986
@trkurc : It'd occur when the processor {{@OnScheduled}} method is called,
which would prevent the processor from starting. This would be evident in the
UI as a red flag on the processor when you star
Github user trkurc commented on the issue:
https://github.com/apache/nifi/pull/1986
the approach looks good.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user m-hogue commented on the issue:
https://github.com/apache/nifi/pull/1986
@trkurc : Pushed changes. Please let me know if you'd like any additional
changes.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If y
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/1986
I'm sorry I'm late on this, but why are we trying to allow `SSLv3` for
anything? I understand the original reason for this work was to be in line with
the `PostHTTP` processor, but this makes outgoi
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/1986
I realize that performing this logic (controller service used for listening
vs. outgoing connections) dynamically may be challenging or not possible (CS
can be used by multiple referencing component
Github user trkurc commented on the issue:
https://github.com/apache/nifi/pull/1986
@alopresto - I'm not sure I understand your concerns. The current
implementation won't support SSLv3, and will throw an error if someone selects
that protocol in their StandardSSLContextService and all
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/1986
@trkurc My initial reaction was to earlier comments that I interpreted to
open the idea of manually overriding the current state, which does not allow
`SSLv3` to be used. I should have cleaned that
Github user trkurc commented on the issue:
https://github.com/apache/nifi/pull/1986
@alopresto - fair points, however, I do think this is a step in the right
direction in terms of user experience - previously, when selecting an
StandardSSLContextService and protocol, the choice was ig
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/1986
What was the previous behavior if an unavailable protocol version was
selected? My understanding is that it will silently use a more secure available
protocol. This is debatable about which is bette
Github user trkurc commented on the issue:
https://github.com/apache/nifi/pull/1986
From a "just works" perspective, if I happened to have a client that only
worked with SSLv3 for whatever reason and attempted to configure it as such, I
think no user feedback and an unexpected configu
Github user trkurc commented on the issue:
https://github.com/apache/nifi/pull/1986
@m-hogue - do you have ideas on how to improve the user experience given
the above feedback?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/1986
I am trying to walk the line between "make everything configurable" and
"sometimes people who don't understand this configure it". If you have a client
that only supports `SSLv3`, it won't work with
Github user jskora commented on the issue:
https://github.com/apache/nifi/pull/1986
I don't want to complicate this, but I feel like I must be missing
something.
As much as possible, the validation at configuration time should provide
the user feedback, not failure upon exe
Github user m-hogue commented on the issue:
https://github.com/apache/nifi/pull/1986
@alopresto @jskora : So i mentioned above that there were two reasons why I
opted for this approach. Previous to this PR and confirmed by @alopresto and
@trkurc, the protocol used by ListenHTTP was au
Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/1986
Some thoughts on this thread. First it is good to get this cleaned up and
easier for the user so this is a great discussion.
1. It sounds prudent that we delineate our SSLContextService along
Github user m-hogue commented on the issue:
https://github.com/apache/nifi/pull/1986
All - I've added a `RestrictedSSLContextService` interface which extends
the `SSLContextService` interface and a `StandardRestrictedSSLContextService`
implementation which extends `StandardSSLContextS
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/1986
Ok I left some minor comments on the code. If Michael can reply to those
and make the changes, I think this is good and ready to be merged. I set up a
flow with a `ListenHTTP` processor and verified
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/1986
Also, as @joewitt noted earlier, we should change the available interface
for other "listener" processors. Here's a preliminary list I put together, but
I would like confirmation from another member
Github user m-hogue commented on the issue:
https://github.com/apache/nifi/pull/1986
@alopresto : I've replied with a couple of questions on your comments.
Also, i'll create an issue to update the SSL Context Service interface for
the listed processors (once confirmed).
---
Github user m-hogue commented on the issue:
https://github.com/apache/nifi/pull/1986
@alopresto : All of your recommendations have been implemented. Please let
me know if you'd like any more changes.
---
If your project is set up for it, you can reply to this email and have your
repl
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/1986
Ran `contrib-check` and all tests pass. +1, merging.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have th
29 matches
Mail list logo
