[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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). --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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: * `HandleHTTPRequest` * `ListenBeats` * `DistributedCacheServer`/`DistributedSetCacheServer`/`DistributedMapCacheServer` * `ListenSMTP` * `ListenGRPC` * `ListenLumberjack` (*Deprecated*) * `ListenRELP` * `ListenSyslog` * `ListenTCP`/`ListenTCPRecord` Also: * `AbstractSiteToSiteReportingTask` * `org.apache.nifi.processors.slack.TestServer` * `WebSocketService`/`JettyWebSocketService` --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 that I could only provide it
with a `StandardRestrictedSSLContextService` implementation. I verified that it
received incoming requests (*only*) over TLS v1.2.
```
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto
ð 27314s @ 18:11:29 $ openssl s_client -connect localhost: -debug
-showcerts
CONNECTED(0003)
write to 0x7f80b0d89fd0 [0x7f80b1807e00] (308 bytes => 308 (0x134))
- 16 03 01 01 2f 01 00 01-2b 03 03 29 cb d3 e6 54 /...+..)...T
...
0050 - 64 f9 0d 7b c4 03 6b 71-03 4d a4 1d 8a f7 4d 45 d..{..kq.MME
---
Certificate chain
0 s:/OU=NIFI/CN=nifi.nifi.apache.org
i:/OU=NIFI/CN=localhost
...
---
Server certificate
subject=/OU=NIFI/CN=nifi.nifi.apache.org
issuer=/OU=NIFI/CN=localhost
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2241 bytes and written 490 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher: ECDHE-RSA-AES256-SHA384
Session-ID:
59A0CAC680787984AD9B43E8A39BCFB0F4C5EA4F8AC10223C073296EDB8FB66B
Session-ID-ctx:
Master-Key:
236BC9B03CD3F7B02C363C8DA15F36EA908A631DB0D3828A0CE05E3834D07BB58E9D1A7023A5161DCE13BF58029BCD61
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1503709893
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
Q
DONE
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto
ð 27323s @ 18:11:38 $ openssl s_client -connect localhost: -debug
-showcerts -tls1_1
CONNECTED(0003)
write to 0x7fd06181a060 [0x7fd06280f003] (200 bytes => 200 (0xC8))
- 16 03 01 00 c3 01 00 00-bf 03 02 18 09 95 74 f0 ..t.
... .(
140735215808592:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:s3_pkt.c:1494:SSL alert number 40
140735215808592:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake
failure:s3_pkt.c:659:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.1
Cipher:
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1503712071
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto
ð 29497s @ 18:47:53 $
```
I also set up two `InvokeHTTP` processors and used a
`StandardSSLContextService` and `StandardRestrictedSSLContextService` for each.
Both were able to successfully make outgoing `GET` requests to
`https://nifi.apache.org`.
Contrib-check and all tests pass. Just need Michael to respond to the few
comments above.
---
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 feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 `StandardSSLContextService` to allow only certain protocols. In particular, _only_ TLSv1.2. I then changed `ListenHTTP` to only allow `RestrictedSSLContextService` implementations. Please let me know if there are any other changes you'd like for me to make. --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 two lines. One is StandardSSLContextService which works as our current one does, supports numerous protocols including those we do not recommend be in continued use but that we need to support for interacting/initiating connections to systems using legacy protocols. The other would be a more restricted/conservative set of protocols like TLSv1.2. I recommend we call that RestrictedSSLContextService. We can document on the existing Standard service what it is for and allowable for. And we can do the same on restricted indicating it is only for 'safe' protocols and may evolve as more is learned/made available. Both would follow the same interface most likely. 2. We update ListenHTTP,HandleRequest,(any proc that acts as a listen/server) to allow only the RestrictedSSLContextService. This is within the documented transition changes between minor versions, can be captured in our release/migration notes, and will improve the user experience to only accept allowed protocols. 3. We should avoid to the extent possible ever doing validation of a given configuration of a component/processor only once started. And we should avoid using onScheduled to block startup/etc.. Once a user is passed the validation phase this is what process yielding is for. The logic to test whether the protocols used, which would not matter if (1) and (2) above are done, should be done as early in the lifecycle as possible to let the user resolve the issue before we slap their hand by stopping their process (and that is only when considering this done in a non-programmatic case). I realize this isn't purely clear all the time but am saying this from an intent of the API, thinking about when we bind validation issues, and considering that the API is for both programmatic and human interaction. --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 automatically negotiated with the client and the configured SSLContextService protocol was ignored. Since the fact that this is misleading and in an effort to not change processor communications behavior, i decided to stop the processor on startup if an invalid protocol was selected and log that the protocol selected wasn't supported with a recommendation to choose another -- this is evident from the screenshot i posted above. As pointed out, this will cause processors to break if they were configured with SSLv3, for example, prior to this change. Additionally, I didn't want to change the global list of selectable protocols in SSLContextService if only one (or a few) processor(s) impacted that list. That's why i attempted to localize the restriction to the one processor. So instead of breaking the processor if the SSLContextService is configured with a protocol that isn't supported by ListenHTTP, i see 2 options: 1. If the SSLContextService is configured with something that ListenHTTP doesn't support, override the protocol to (possibly configured) TLSv1.2 since that's what it was doing previously and log a warning indicating that this happened. 2. Build another SSLContextService in which a processor can inform which protocols should be selectable. The second is a bit of work and perhaps outside the scope of this issue, but i'm happy to do whatever is recommended. --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 execution. So, - SSLContextService should only allow selection of supported protocols, if SSLv3 will not work it should be removed from the list, and - if we need SSLv3 in some places we either need 2 variations of SSLContextService like @alopresto mentioned earlier or the ability to configure and query the security level so processors requiring only the higher security protocols can invalidate in the GUI (before execution) if provided a less secure service. Does that make sense? --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 `ListenHTTP` period. * Current situation: the connection will fail, and the error presented to the client will be some form of `INVALID PROTOCOL VERSION`. No error in NiFi. * Proposed error on config: New flows can't start, as the processor is invalid. Existing flows which use `SSLv3` will stop working, and the error simply says "SSLv3 isn't valid". No open port for client to connect to, so that's the error on that end. * Proposed restricted list implementation: *Can't get to invalid state on new processor config.* Existing flows which use `SSLv3` will stop working, and the error says "SSLv3 isn't valid -- pick TLSv1.2". No open port for client to connect to, so that's the error on that end, but the NiFi DFM at least knows a "valid" option to report back to the external client admin/operator. --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 configuration is far less compelling --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 better -- from an "informed user" perspective, being notified that `SSLv3` is not valid is good. From a "just works" perspective, stopping the flow (especially with an error that doesn't tell them *why* `SSLv3`, an option they selected from a dropdown as opposed to typing in manually, doesn't work or *how* to fix it) is worse. I reproduced this on 1.4.0 master and even manually selecting `SSLv3` for the controller service, it exposed a port that only accepted `TLSv1.2`:   ``` hw12203:...space/nifi/nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT (master) alopresto ð 9s @ 17:58:59 $ openssl s_client -connect localhost: -debug -state -CAfile conf/nifi-cert.pem ... New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 ## This is a legacy output of s_client, it's not actually using SSLv3 as shown below Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-SHA384 Session-ID: 597698...709D69 Session-ID-ctx: Master-Key: 4CA2AD...6926BA Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1500944417 Timeout : 300 (sec) Verify return code: 0 (ok) --- hw12203:...space/nifi/nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT (master) alopresto ð 87s @ 18:00:18 $ openssl s_client -connect localhost: -debug -state -CAfile conf/nifi-cert.pem -ssl3 ... --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : SSLv3 Cipher: Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1500944681 Timeout : 7200 (sec) Verify return code: 0 (ok) --- ``` I am not opposed to throwing an error if an invalid protocol is somehow provided to the context factory, I just think we should be doing more to prevent that scenario from happening in the first place, and this behavior isn't compelling enough to me that I think it needs to be merged immediately and the UX improvement added later. --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 ignored (i.e. , if the user did select SSLv3 in the StandardSSLContextService, expecting the ListenHTTP to support SSLv3, that didn't happen). --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 up after understanding the entire thread. However, I feel that my second point, regarding restricting the dropdown list of available protocol versions to provide a better user experience rather than throwing an exception on 71% of the available options still stands. I understand it's more work for the developers at this time, but in general I favor more work for us to vastly improve the user experience, as once this is used by thousands of people, those little problems add up quickly. --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 allows selection of supported protocols StandardSSLContextService (that jetty also supports). --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 components). This is now leading me to think we may need to create a new implementation of the [`SSLContextService`](https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-service-api/src/main/java/org/apache/nifi/ssl/SSLContextService.java#L33-L33) interface called `ModernSSLContextService` or `IncomingSSLContextService` which only supports the `TLSv1.2` protocol version. Existing processors would not change because they can still accept `StandardSSLContextService`, but the `ListenHTTP` component would only accept this new implementation. It could even extend `StandardSSLContextService` to delegate most of the code there and simply override the protocol versions by implementing its own [`#buildAlgorithmAllowableValues()`](https://github.com/apache/n ifi/blob/master/nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/StandardSSLContextService.java#L473) method. --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 outgoing connections to remote services, which may be legacy systems that do not support new TLS protocol versions. While I would discourage integrating with those systems as well, as `SSLv3` provides little effective security at this point, we are not exposing a vulnerability in NiFi by supporting that protocol version. Jetty intentionally disables any protocol version below `TLSv1.2`, and thus we require any incoming connections to support this protocol version. I believe the proper solution here is to remove `SSLv2` and `SSLv3` (along with `TLSv1` and `TLSv1.1`) from the dropdown list of the `SSLContextService` when used for *listening* (i.e. accepting incoming connections) as they will not be supported, rather than throwing an exception if an invalid one is selected (by my count, 5 of the 7 available are invalid for incoming connections -- `SSL`, `SSLv2Hello`, `SSLv3`, `TLSv1`, and `TLSv1.1`; `TLS` and `TLSv1.2` are valid). --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 start it:
---
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 feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 throw an exception with a message explaining why if the processor doesn't support that protocol. In the ListenHTTP case, Jetty has some SSL protocols and ciphers disabled by default that may be available to the JVM. There are two reasons i wouldn't want to tweak ListenHTTP to allow any configured protocol. 1) It changes the processor behavior since those Jetty-disabled protocols wouldn't have worked previously anyway and 2) it possibly opens another can of worms with cipher suite configuration since Jetty has a set of ciphers disabled by default as well. Thoughts? --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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. --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 encourage use of
SSLv3?
---
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 feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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.oracle.com/technetwork/java/javase/8u31-relnotes-2389094.html) and [Java 7 Update 75](http://www.oracle.com/technetwork/java/javase/7u75-relnotes-2389086.html)? --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
