New Feature Request: Please add greater security and authentication to Pepwave Configuration Files. Yes, they’re encrypted upon generation but a .conf from one MAX BR1 can be loaded onto another MAX BR1 without any Authentication or SN check. In my usage this represents a risk. I’d like, as an option, to be able to PW protect the .conf upon Download; as of 8.3.0 I must use another tool, such as 7zip, to add additional protection to the .conf. Also, I’d like as an option to be able to “Lock to SN” a .conf such that it can only be used on a particular SN, rather than all SNs in a particular Model and/or SW generation.
Why is this a risk? You are in control of the file?
We like this option all the time to clone configs , replace models.
If anything we need something to make it more flexible to move the same config between models.
You could always store your conf in your own 7z password protected file.
Thank you J_Pitts for your reply. I see you’re very active on this Forum and we have appreciated your feedback on other topics.
Why is this a risk? You are in control of the file? Agreed, if perfect custody is presumed then there is no risk. Risk arises if one supposes custody of the file is imperfect or altogether compromised. Once an unfriendly actor has possession of this file they can program a device of their own to play as a Node on our network, even without direct access to the sensitive contents of the file such as PW or VPN Certs. They need only possess the file and a conforming Peplink model and firmware version.
We like this option all the time to clone configs , replace models. We happen to like the current behavior too, in our primary use-case. However, we have minority use-cases with higher security/assurance requirements and where perfect custody cannot be presumed. We would like for this Feature Request NOT to break the current functionality, rather on an opt-in basis we’d like to add 1) integrated PW protection of the file and 2) SN locking of the file. Any use-case not needing either 1) nor 2) would need not opt-in for the changes. We’re imagining check-boxes which are empty by default.
If anything we need something to make it more flexible to move the same config between models. I can imagine situations where indeed more flexibility could be very useful. I’d be interested to explore that topic in a separate Feature Request with more specific use-cases and requirements.
You could always store your conf in your own 7z password protected file. Agreed. This is what we do now. In fact one major reason we like using 7-zip is higher assurance wrt the type and degree of encryption, which Peplink does not publish about their own methods. I’ve asked for details of their Encryption Practices in a Support Ticket and they demurred, not unreasonably, I might add. Reasons the 7-zip method is sub-optimal: 1) requires proficiency with and the use of a separate tool at the time of generation and again at the time of use, 2) generates additional files at both ends (original plus archive, then archive plus original), 3) still does not achieve the SN locking of the underlying .conf file.
Thanks again for your reply. Happy to keep the discussion churning.
2 Likes
I really like this idea. +1 from me.
2 Likes
I guess I’m on board if you have an option when saving the config if it it locked to s/n or not.