Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Art B. <ac...@in...>]

On Mar 6, 2014, at 4:15 AM, Nate Bargmann <n0...@n0...> wrote:
> As opposed to OpenVPN, how does an SSH tunnel compare?  

SSH tunnels need to be set up individually, one for each data connection (the control and one or more content channels) and all they buy you is encryption.  They don't help with routing or firewall issues and don't bundle the complete network interface into a single identifiable network connection.  They also require that the remote user has at least some system-level privileges on the server.  As far as encryption strength goes they're comparable.

> In other words, is authentication/encryption necessary in Station
> Server?  Could this be handled by a recommended "best practice" for
> a OpenVPN/SSH tunnel by those interested in doing so?  

It could.  However, that gets back to an underlying requirement, the one for the ability to have multiple client connections with varying levels of privilege (read-only, read-write, admin, etc.)  That varying-levels bit implies being able to verify who's who, else the distinction is pointless... much simpler just to make every connection full-privilege.  

And if we're going to distinguish between sessions that means having some sort of shared-secret identity token... a password is the most common, although a shared key (certificate) also works... and it's never good practice to be passing such "secrets" around a network in the clear, even on a LAN.  (I'd point to pretty much any recent day's headlines for examples of what happens when security gets postponed or tossed onto the too-hard stack.)

The existing hamlib is a processor-centered design that does everything inside a single box.  If we want to move to a network-based client-server model we're going to need to learn some new tricks.  Otherwise, we're just refactoring the existing code... which may be a good exercise, albeit a less interesting one.

Anyway, this is a good discussion to be having, and I hope folks will read the requirements document and consider each point carefully, as that's really the stage where we want to define project scope so as not to spin our wheels further down the road.

> I'd rather leave
> security to those who understand it well (I don't understand it well at
> a programming level).

Yes, that's why I suggested an established, state-of-the-art package like OpenVPN rather than a "roll your own" approach.  It's a turnkey solution, no programming involved, and it's been refined and vetted over a number of years by actual security boffins.  I'd encourage folks to learn about it, if only as another tool in the toolkit.

But again... and I'll say it one last time and then give up... using a VPN is about much more than just security.

- Art KD6O