[ZBXNEXT-4478] PSK Identity - Code or Documentation Issue Created: 2018 Apr 03  Updated: 2024 Apr 10  Resolved: 2020 Feb 24

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Agent (G), Proxy (P), Server (S)
Affects Version/s: 3.4.7
Fix Version/s: 5.0 (plan)

Type: Change Request Priority: Trivial
Reporter: Larry Dorman Assignee: Marina Generalova (Inactive)
Resolution: Fixed Votes: 1
Labels: documentation, encryption
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Attachments: PNG File image-2020-02-24-09-50-29-103.png     PNG File image-2020-02-24-09-51-53-300.png    
Team: Team D
Sprint: Sprint 56 (Sep 2019), Sprint 55 (Aug 2019), Sprint 54 (Jul 2019), Sprint 57 (Oct 2019), Sprint 58 (Nov 2019), Sprint 59 (Dec 2019), Sprint 60 (Jan 2020), Sprint 61 (Feb 2020)

 Description   

I assume this applies to all versions of Zabbix that support PSK encryption.

PSK Identity must be unique across every host that has a different PSK Value.

Example:
host1.some.domain: PSK Identity: ZABBIX_AGENT PSK: 1234567890
host2.some.domain: PSK Identity: ZABBIX_AGENT PSK: 0987654321

This configuration will result in failures to communicate with both hosts. This might be as intended. If that is the case, the documentation needs to be much more explicit.

From the documentation: "Before Zabbix server connects to agent using PSK, the server looks up the PSK identity and PSK value configured for that agent in database (actually in configuration cache). Upon receiving a connection the agent uses PSK identity and PSK value from its configuration file. If both parties have the same PSK identity string and PSK value the connection may succeed."

This suggests that this is checked only at the agent level. However, the PSK Identity appears to be global in scope.

The additional caution in the documentation hints at this, but leaves it ambiguous. "It is a user responsibility to ensure that there are no two PSKs with the same identity string but different values. Failing to do so may lead to unpredictable disruptions of communication between Zabbix components using PSKs with this PSK identity string."

The documentation needs to explicitly state that for any given PSK Identity defined on the Zabbix Server that there can be only one paired PSK value. The only way to use the same PSK Identity on two or more hosts is to also use the same PSK value on those same hosts. As a best practice, the documentation should further suggest that every agent be assigned a unique PSK Identity and PSK value pair.



 Comments   
Comment by Glebs Ivanovskis (Inactive) [ 2018 Apr 04 ]

I have a couple of questions.

This suggests that this is checked only at the agent level.

What is checked only at the agent level?

I may be wrong, but for me

for any given PSK Identity defined on the Zabbix Server that there can be only one paired PSK value

and

ensure that there are no two PSKs with the same identity string but different values

express exactly the same idea.

Documentation has also warned you about possible consequences of such misconfiguration. And if you check server's log file there must be warnings about that too.

I wouldn't say that this is intentional, but this design flaw was realized too late during ZBXNEXT-1263 implementation. Probably it should be fixed some day...

Comment by Larry Dorman [ 2018 Apr 04 ]

Larry: This suggests that this is checked only at the agent level.
Vjaceslav: What is checked only at the agent level?

This verbiage from the documentation: "the server looks up the PSK identity and PSK value configured for that agent" The way this is worded it would suggest that it looks up the PSK Identity and PSK value on a host by host basis and would allow for the same PSK Identity and a different PSK value on different hosts."

express exactly the same idea.

While they express the same idea, they do so in a different way. My suggested language is to make it unmistakably clear that a PSK Identity must be globally unique. When new to this configuration I found the documentation ambiguous. Now that I'm familiar with how the process works the cautionary statement can now be understood. Initially that caution was read as reinforcing that if the PSK Identity matched and the PSK value didn't then it would not work. Of course, one already familiar with this detail no longer needs the documentation. Surely it's not too difficult to update the documentation?

Similarly, the PSK Troubleshooting (https://www.zabbix.com/documentation/3.0/manual/encryption/troubleshooting/psk_problems) documentation should be updated. The "Same PSK identity but different PSK values used by communicating components (example with OpenSSL)" section should explicitly state that this means that two or more hosts are using the same PSK Identity with different PSK values. As it's worded it's easy for the new person to read that as the Zabbix Agent is one component and the Zabbix Server/Proxy is the other component and that the PSK identity doesn't match on those 'communicating components'.

Comment by Glebs Ivanovskis (Inactive) [ 2018 Apr 04 ]

If agent uses encryption server cannot tell which agent it is talking to before decrypting. So it takes PSK from the global PSK storage based on PSK identity sent by agent. But after decryption server will know which agent it is and verifies that it used PSK identity it was supposed to use. Agent cannot just use any PSK server knows about.

should explicitly state that this means that two or more hosts are using the same PSK Identity with different PSK values

I disagree, this is not the only scenario leading to such error messages. For example, user can make a mistake and configure one PSK value in the frontend and another one on the agent side.

Dear martins-v, do you think we can improve documentation somehow? If yes, let's create a separate ZBX for that, because this ZBXNEXT should stay as a request to improve design of Zabbix.

Comment by Marina Generalova (Inactive) [ 2020 Feb 18 ]

Documentation updated:

Encryption -> 2 Using pre-shared keys in:

Generated at Fri Apr 26 00:47:29 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.