Add protocol check to encryption plugin selection
mrotteveel opened this issue · comments
Attempts to connect with protocol version 13 or 15 to Firebird 4 or Firebird 5 can lead to warnings logged about some encryption plugins failing (specifically, ChaCha and ChaCha64). This is because both Firebird and Jaybird will happily try to use ChaCha and ChaCha64, but the required data for those plugins (sent in the server keys buffer as TAG_PLUGIN_SPECIFIC) is not sent in protocol versions below 16. In other words, neither ChaCha nor ChaCha64 will work when trying to connect with v13 and v15 (Jaybird doesn't implement v14).
Though this will probably only happen in Jaybird tests (which will use older protocol versions explicitly for some tests), it does indicate that wire encryption plugins are protocol-sensitive, so we need to add something (probably to the SPI) to check if they support the protocol version, and skip them if they don't instead of trying them.
Given there should be no impact for end-users (unless they use the low-level GDS-ng API and also forcibly try to use a lower protocol version), this will not be backported to Jaybird 5.
Do you mean 'Wrong IV length, need 8, 12 or 16' message?
@AlexPeshkoff Jaybird will produce "Wrong IV length, needs 12 or 16 bytes" or "Wrong IV length, needs 8 bytes", but that is similar to the "Wrong IV length, need 8, 12 or 16" that ChaCha.cpp of Firebird produces, yes.
On my mind that's enough for mentioned case. If we don't talk about tests the only realistic case is one side with very old client or server forcibly configured to use plugin unsupported by it. I think that letting plugin check itself can it work or not is better than asking it about required protocol version. We will anyway need to notify user somehow about bad configuration, but existing way appears more flexible.
@AlexPeshkoff To be clear, I'm only talking about how Jaybird handles things, with its Java implementation of the wire encryption. And, I want to avoid unnecessary logging of things that could obscure real problems.
I agree that diagnostics can be better from user POV (like in 100500 other places of our code). What should never happen is silently ignoring configured encryption plugins - it's a matter of security, one should not hope that some crypt plugin (like chacha) is working though in fact something less secure is used.
I agree that diagnostics can be better from user POV (like in 100500 other places of our code). What should never happen is silently ignoring configured encryption plugins - it's a matter of security, one should not hope that some crypt plugin (like chacha) is working though in fact something less secure is used.
That will happen silently anyway (just with something logged), unless all selected plugins fail and encryption is required.
If error is present in the log that's better than nothing.
I will log that the plugin is skipped (on trace level).