Opened 4 years ago

Last modified 4 years ago

#925 new Feature Wish

Encrypted Backend Management Interface

Reported by: tony-caffe Owned by:
Priority: major Milestone:
Component: Management Version: OpenVPN 2.3.13 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:



Your documentation mentions the management interface, at least in the community version, is not secured and thus needs to be run over a unix socket or localhost interface. This is odd for a VPN to not have a secured management interface.

Having non-cleartext for management interface by default would be a major security improvement to OpenVPN along with having a U/P for Authentication.


Change History (3)

comment:1 Changed 4 years ago by Gert Döring

The management interface is intended to be used locally only, thus, unix socket or localhost (or on a protected internal network, if it must be).

I do not see why this would be a "major security improvement" to expose the management interface to unprotected networks - adding a crypto layer will add code which has bugs, adding more code that is exposed to untrusted networks adds attack surface to that code, etc.

We can leave it as "feature wish" but I see it as fairly unlikely that someone who understands crypto code can be convinced that the benefits of adding this outweigh the drawbacks (extra code to maintain, increased attack surface, ...)

comment:2 Changed 4 years ago by David Sommerseth

I agree that it would be good to have an TLS enabled TCP version of the management interface, but to implement that will require quite a lot of work.

I am also doubtful of the benefit implementing TLS vs the massive chance of introducing new bugs. In addition, I would never consider to open up the management interface to an unsecured network.

If you truly care about securing the management interface, you should currently use a local unix socket and not use the TCP approach.

What I think is a far better approach: Have a look at moving the whole OpenVPN management interface code over to a plug-in and expose all the needed features over the plug-in interface. This way we can isolate the risks and stability to a more easily replaceable plug-in. Which could enable other management approaches as well, not just TCP or TLS over TCP. And if the management plug-in is not loaded, there's no management code to exploit by attackers.

But even this effort will be quite massive and an intrusive change as well.

Last edited 4 years ago by David Sommerseth (previous) (diff)

comment:3 Changed 4 years ago by Selva Nair

As a minimal level of security the m/i does support setting a password. Use "--management localhost stdin" and the you will be prompted for a password when connecting to the management port. The Windows GUI currently uses this with an on-the-fly generated password.

Currently mgmt via tcp is the only option on Windows, though porting the current code to use Windows named pipes should not be hard. As others have said encrypted m/i looks like a luxury, nice to have, but not worth the effort..

Version 0, edited 4 years ago by Selva Nair (next)
Note: See TracTickets for help on using tickets.