Re: [Openvpn-devel] OpenVPN Interactive Service Branding

[Selva]

Hi,

On Tue, Oct 31, 2017 at 5:19 PM, Simon Rozman  wrote:

> Hi,
>
> > Instead of a pipe name set at compile-time, I think its better to make
> this
> > customizable by the installer. That is, we could take service name from
> an
> > optional registry entry so that it may be renamed by the installation
> package.
>
> Honestly, to make the name of the named pipe and the registry

dynamically configurable was my first idea too. Only to find out

that openvpnserv.exe already supports compile-time customization

of the settings registry key. Thus, extending this practice to the

named pipe was the "KISS" approach.
>
> I'd propose to use a service command line argument. Something

like "--instance name". When --instance is not specified the name

defaults to "OpenVPN". The service command line is stored in

registry after all: HKEY_LOCAL_MACHINE\SYSTEM\Curr
> entControlSet\Services\\ImagePath.

Example: Microsoft SQL Server is using service command

line arguments to support multiple instances.


> If we could make this patch merged into the official OpenVPN distribution,

it would be a big win for us too, as we would no longer require to compile

openvpnserv.exe ourselves anymore.
>

Named instances sounds like is a good idea. As you pointed out, Microsoft
itself uses command line parameters on service (like -i NAME for SQL server)
so that looks kosher.

There is a problem though: multiple instances also need multiple service
names but the service name is hardcoded in the source. In our case even
the dispatcher needs to know the service name(s) as we use
SERVICE_WIN32_SHARE_PROCESS and share the process between
the legacy service[*] and the interactive service.

Looks like the service name also will have to be dynamically-generated
from the instance name.

If you want to support multiple installations of openvpn.exe/service,
building with a different PACKAGE_NAME can't be avoided, can it?.
Instead, if using the "official" executables is ok, why not just use
oepnvpnserviceinteractive as is. Does eduVPN really need its own instance
of the service?

That said, I like the idea of being able to run multiple (named) instances
of the service each with its own service pipe.

Selva
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Interactive Service Branding

[Simon Rozman]

Hi,

> Instead of a pipe name set at compile-time, I think its better to make this
> customizable by the installer. That is, we could take service name from an
> optional registry entry so that it may be renamed by the installation package.

Honestly, to make the name of the named pipe and the registry dynamically 
configurable was my first idea too. Only to find out that openvpnserv.exe 
already supports compile-time customization of the settings registry key. Thus, 
extending this practice to the named pipe was the "KISS" approach.

I'd propose to use a service command line argument. Something like "--instance 
name". When --instance is not specified the name defaults to "OpenVPN". The 
service command line is stored in registry after all: 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\\ImagePath. 
Example: Microsoft SQL Server is using service command line arguments to 
support multiple instances.

If we could make this patch merged into the official OpenVPN distribution, it 
would be a big win for us too, as we would no longer require to compile 
openvpnserv.exe ourselves anymore.

> That way eduVPN's GUI will remain compatible with official service if a user
> wishes to use it as a replacement for OpenVPN-GUI

Exactly!

> The hard coded admin group name is only a default to fall back on, when no
> entry is found in the registry. Just set the desired name in registry while
> installing the package.
> 
> The firewall rules are always added to the same sublayer by all instances of
> openvpn. And this has to remain so to avoid conflicts between rules added
> by multiple instances. A name change will only affect error messages. If that
> is the aim, why pick only the firewall code?

They remained the last two hardcoded "OpenVPN" strings in the openvpnserv.exe 
code. I decided to change them to compile-time customizable for the sake of 
consistency. Not any practical added value indeed.

Best regards,
Simon
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Topics for the community meeting (Wed, 1st Nov 2017)

[Samuli Seppänen]

NOTE: This meeting starts at 11:30 CET.

---

Hi,


We're going to have an IRC meeting tomorrow starting at 11:30 CET
(10:30 UTC) on #openvpn-meeting  irc.freenode.net. You do not have
to be logged in to Freenode to join the channel.

Current topic list along with basic information is here:



If you have any other things you'd like to bring up, respond to this
mail, send me mail privately or add them to the list yourself.

In case you can't attend the meeting, please feel free to make comments
on the topics by responding to this email or to the summary email sent
after the meeting. Whenever possible, we'll also respond to existing,
related email threads.

--
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 0/1] add engine keys keys

[Jan Just Keijser]

Hi James,

On 30/10/17 15:09, James Bottomley wrote:

On Sun, 2017-10-29 at 17:03 -0400, Selva wrote:

On Sun, Oct 29, 2017 at 12:04 PM, James Bottomley  wrote:


On Sun, 2017-10-29 at 16:24 +0100, Gert Doering wrote:

On Sat, Oct 28, 2017 at 01:02:27PM +0100, James Bottomley wrote:


Engine keys are an openssl concept for a key file which can
only be
understood by an engine (usually because it's been wrapped by
the
engine itself).  We use this for TPM engine keys, so you can
either
generate them within your TPM or wrap them from existing
private
keys.  Once wrapped, the keys will only function in the TPM
that
generated them, so it means the VPN keys are tied to the
physical
platform, which is very useful.  Engine keys have to be loaded
via
a specific callback, so use this as a fallback in openvpn if an
engine is specified and if the PEM read of the private key
fails.

How does this work in an OpenVPN context, as in, what do I have
to do
to make TPM keys work on client and server?

If you have an existing private key, you convert it to a TPM key
using
the create_tpm[2]_key binary that comes with openssl_tpm[2]_engine.
  The key you create is then locked to the TPM of the system you
create
it on (so save an offline copy of the non-TPM private key).


Do we need a new abstraction layer here somewhere, given that
this
seems to do something similar to using the windows crypto layer
to
access "private keys hidden in windows" (--cryptoapicert) and/or
pkcs11?

I don't really think so.  The engine keys are a bit of an openssl
brainfart: there's no reason why PEM_read_bio_PrivateKey couldn't
actually check for engine keys and have the whole thing transparent
to
all applications, except that openssl didn't want to do it that
way.

These keys are real files, so they're not like tokens, which is the
pkcs11 abstraction.


That means, if one has the tpm_engine for openssl installed and
TPM-wrapped keys, this should just work, is it? And, I suppose, the
patch for openvpn is required only because openssl does not
transparently use available engines.

Yes, and no.  By the time openssl sees the load request, it has a bio,
rather than a file name, so there's a bit of additional glue openssl
would need for transparent engine support.  I proposed a patch a while
ago to the openssl list, but it required an additional engine callback
and wasn't very enthusiastically received.


If so, this looks like a easy way to provide TPM support to
openssl users on some platforms. What about Windows? Is there
an openssl TPM engine and tools to convert the key to a wrapped
TSS blob on Windows?

No idea, I'm afraid.  I would suspect not because windows isn't a great
consumer of openssl, so no-one on the windows development side probably
thought to write an openssl engine for their TPMs.


I would like to see new features transparently supported on Windows
as well without the need for too much extra code and associated
maintenance burden. Our 'cryptoapicert' implementation is already in
need of a major re-write to support TLS 1.2 and newer.

Well, windows supports engines (via dlls), so the engine code will work
for Windows, just not for my use case (their being no engine) and MS
CryptoAPI is one of the supported engines.


 From that point of view, instead of file-based wrapped keys, if a
pkcs11 compatible API can be used to access TPM (that's possible
isn't it?) TPM could be more widely usable without the need of any
additional support in openssl or openvpn.

For TPM 1.2 it is possible to load the key into the TPM and then use
the TPM as a loaded token via PKCS11 but the usual key format is file
based not already present.  For TPM 2, the design is different and the
key has to be loaded each time from offline storage (the file) because
the space in the TPM is so tiny, so treating it as a token is a bit
more difficult.  Obviously with enough pressure, even a square peg will
fit in a round hole, it's just that it won't be elegant.


I'm quite interested in using a TPM to store keys - do you have a set of instructions on how to load a key into the TPM and then 
sign data using that key?  Most of the implementations I've found using something like trousers , which does NOT encrypt data 
using the TPM itself, but uses the TPM as a master key to sign other keys with.


thx,

JJK


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel