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:9999 -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:9999 -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 : 0000
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 [email protected] or file a JIRA ticket
with INFRA.
---
