Re: [Openvpn-devel] Feature proposal: tls-crypt

[Steffan Karger]

Hi,

On 27 July 2016 at 16:42, Steffan Karger  wrote:
> Our customers, as well as community users, have asked for encryption of
> control channel packets to hide their certificate (containing perhaps
> the users' name or organisation), or to provide some basic form of
> post-quantum security (see e.g. trac #633).
>
> We've been thinking about this for a while, and would like to implement
> such a feature.  I've attached a proposal for an extension of tls-auth
> to achieve this in OpenVPN.  Comments and/or questions are very welcome.
>  I hope to be able to start implementing this soon.

I just pushed an experimental branch with --tls-crypt support:
https://github.com/syzzer/openvpn/tree/tls-crypt-preview

Any comments and test results or very much welcome.

This code has not yet been reviewed, or tested by anyone else but me,
so do not use in production yet.

-Steffan

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Feature proposal: tls-crypt

[Selva Nair]

Hi,

On Sun, Sep 18, 2016 at 8:25 AM, Steffan Karger  wrote:

> Hi,
>
> On 27 July 2016 at 16:42, Steffan Karger 
> wrote:
> > Our customers, as well as community users, have asked for encryption of
> > control channel packets to hide their certificate (containing perhaps
> > the users' name or organisation), or to provide some basic form of
> > post-quantum security (see e.g. trac #633).
> >
> > We've been thinking about this for a while, and would like to implement
> > such a feature.  I've attached a proposal for an extension of tls-auth
> > to achieve this in OpenVPN.  Comments and/or questions are very welcome.
> >  I hope to be able to start implementing this soon.
>
> I just pushed an experimental branch with --tls-crypt support:
> https://github.com/syzzer/openvpn/tree/tls-crypt-preview
>
> Any comments and test results or very much welcome.
>

Not qualified to comment on the implementation details, but the feature
looks very useful to have. Arguably its too early to plan for a
post-quantum world, but encrypting control channel packets is nice..
.
Does this mean that --tls-crypt will imply --tls-auth with the same
key-file (or make the latter redudnant?). The man-page description in the
patch appears to imply so, but not very clear..

Selva
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Feature proposal: tls-crypt

[Steffan Karger]

Hi,

On 18 September 2016 at 22:07, Selva Nair  wrote:
> Does this mean that --tls-crypt will imply --tls-auth with the same key-file
> (or make the latter redudnant?). The man-page description in the patch
> appears to imply so, but not very clear..

--tls-crypt also includes authentication, and thereby makes --tls-auth
redundant.  --tls-crypt uses the same type of key as --tls-auth does.
I'll make that more clear in the docs.

-Steffan

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Feature proposal: tls-crypt

[Steffan Karger]

Hi developers,

Our customers, as well as community users, have asked for encryption of
control channel packets to hide their certificate (containing perhaps
the users' name or organisation), or to provide some basic form of
post-quantum security (see e.g. trac #633).

We've been thinking about this for a while, and would like to implement
such a feature.  I've attached a proposal for an extension of tls-auth
to achieve this in OpenVPN.  Comments and/or questions are very welcome.
 I hope to be able to start implementing this soon.

-Steffan
Title: Control channel encryption (--tls-crypt)






Control channel encryption (--tls-crypt)

This is a proposal for a --tls-crypt option, which uses a pre-shared
static key (like the --tls-auth key) to encrypt control channel packets.
Encrypting control channel packets has three main advantages:

It provides more privacy by hiding the certificate used for the TLS
connection.
It is harder to identify OpenVPN traffic as such.
It provides "poor-man's" post-quantum security, against attackers who will
never know the pre-shared key.


Control channel packet encryption
We propose to use the following encryption method, based on the SIV
construction [0], to achieve nonce misuse-resistant authenticated
encryption:

msg  = control channel plaintext
header   = opcode (1 byte) || session_id (8 bytes) || packet_id (4 bytes)
Ka   = authentication key (256 bits)
Ke   = encryption key (256 bits)
(Ka and Ke are pre-shared keys, like with --tls-auth)

auth_tag = HMAC-SHA256(Ka, header || msg)
IV   = 128 most-significant bits of auth_tag
ciph = AES256-CTR(Ke, IV, msg)

output   = Header || Tag || Ciph

This boils down to the following on-the-wire packet format:

-opcode- || -session_id- || -packet_id- || auth_tag || * payload *

Where
- XXX - means authenticated, and
* XXX * means authenticated and encrypted.

Which is very similar to the current tls-auth packet format, and has the
same overhead as --tls-auth with --auth SHA256.
The use of a nonce misuse-resistant authenticated encryption scheme allows us
to worry less about the risks of nonce collisions.  This is important, because
in contrast with the data channel in TLS mode, we will not be able to rotate
tls-crypt keys often or fully guarantee nonce uniqueness.  For non
misuse-resistant modes such as GCM [1], [2], the data channel in TLS mode
only has to ensure that the packet counter never rolls over, while tls-crypt
would have to provide nonce uniqueness over all control channel packets sent by
all clients, for the lifetime of the tls-crypt key.
Unlike with tls-auth, no --key-direction has to be specified for tls-crypt.
TLS servers always use key direction 1, and TLS clients always use key
direction 2, which means that client->server traffic and server->client traffic
always use different keys, without requiring configuration.
Using fixed, secure, encryption and authentication algorithms makes both
implementation and configuration easier.  If we ever want to, we can extend this
to support other crypto primitives.  Since tls-crypt should provide privacy as
well as DoS protection, these should not be made negotiable.


Security considerations:
tls-crypt is a best-effort mechanism that aims to provide as much privacy and
security as possible, while staying as simple as possible.  The following are
some security considerations for this scheme.

The same tls-crypt key is potentially shared by a lot of peers, so it is
quite likely to get compromised.  Once an attacker acquires the tls-crypt
key, this mechanism no longer provides any security against the attacker.
Since many peers potentially use the tls-crypt key for a long time, a lot of
data might be encrypted under the tls-crypt key.  This leads to two potential
problems:
The opcode || session id || packet id combination might collide.  This
is quite likely to happen in larger setups, because the session id
contains just 64 bits or random.  Using the uniqueness requirement from
the GCM spec [3] (a collision probability of less than 2^(-32)),
uniqueness is achieved when using the tls-crypt key for at most 2^16
(65536) connections.  Large setups are likely to violate this constraint.
When a collision happens, an attacker can learn whether colliding packets
contain the same plaintext.  Attackers will not be able to learn anything
else about the plaintext (unless the attacker knows the plaintext of one
of these packets, of course). Since the impact is limited, I consider this
an acceptable remaining risk.
The IVs used in encryption might collide.  When two IVs collide, an
attacker can learn the xor of the two plaintexts by xorring the
ciphertexts.  This is a serious loss of confidentiality.  The IVs are
128-bit, so when HMAC-SHA256 is a secure PRF (an assumption that must also
hold for TLS), and we use the same uniqueness requirement from [3], this
limits the total amount of control channel messages for all peers in the
setup to 2^48.  Assuming a large setup of 

Re: [Openvpn-devel] Feature proposal: tls-crypt

[ValdikSS]

Experimental branch doesn't work in TCP mode. Client gets the following error 
right after sending P_CONTROL_HARD_RESET_CLIENT_V2:

Assertion failed at socket.c:2992 (buf_write_prepend (buf, , sizeof (len)))


On 09/18/2016 03:25 PM, Steffan Karger wrote:
> Hi,
>
> On 27 July 2016 at 16:42, Steffan Karger  wrote:
> I just pushed an experimental branch with --tls-crypt support:
> https://github.com/syzzer/openvpn/tree/tls-crypt-preview
>
> Any comments and test results or very much welcome.
>
> This code has not yet been reviewed, or tested by anyone else but me,
> so do not use in production yet.
>
> -Steffan
>
> --




signature.asc
Description: OpenPGP digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel