Opened 7 months ago

Last modified 6 months ago

#977 new Bug / Defect

Cryptoapicert and TLS 1.2 issue

Reported by: lalamper Owned by:
Priority: major Milestone: release 2.4.5
Component: Certificates Version: OpenVPN 2.4.4 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Steffan Karger, selvanair



I have a working server (pfSense)/client (Windows 10) setup, where client key and cert are included in OVPN file.

I wanted to move to the next level of security by storing P12 in Windows Cert Store, so I successfuly imported P12 ang get its THUMB and NAME for OVPN config. I enabled Windows' CryptoAPI warning when private key is accessed during import.

As soon as I changed the config to use "cryptoapicert "THUMB:11 22 33 .."" or "cryptoapicert "SUBJ:...."" (no matter which one and nothing other touched), I was unable to connect, but getting the following errors in log. I even did not get a warning message from Windows' CryptoAPI that my private key is accessed.

an 09 12:51:10 2018 us=369940 TLS: Initial packet from [AF_INET], sid=56c5db6f 106080b1
Tue Jan 09 12:51:10 2018 us=416820 OpenSSL: error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
Tue Jan 09 12:51:10 2018 us=416820 TLS_ERROR: BIO read tls_read_plaintext error
Tue Jan 09 12:51:10 2018 us=416820 TLS Error: TLS object -> incoming plaintext read error
Tue Jan 09 12:51:10 2018 us=416820 TLS Error: TLS handshake failed

Now turns the worm!

I am using the following security setting both in server and client:
cipher aes-256-gcm
auth sha512
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
tls-version-min 1.2

Next step was to reduce security, so I moved to a less secure tls-cipher and tls-version. When using TLS 1.1 I was able to login with cryptoapi, Windows prompted me about accessing my private key, and everything went fine.

Based on the details above I think there is some compatibility issue between TLS 1.2 and Windows or OpenSSL cryptoapicert function.

Change History (4)

comment:1 Changed 7 months ago by Gert Döring

Cc: Steffan Karger selvanair added

Cryoptoapicert does not support TLS 1.2 yet.

Coincidentially, there has been a patch set sent to the openvpn-devel list just yesterday that aims to fix this, but no time for review yet.

comment:2 Changed 7 months ago by lalamper

Strange.. TLS 1.1 is publicly vulnerable. In this case it is a security trade off.

comment:3 in reply to:  2 Changed 7 months ago by Gert Döring

Replying to lalamper:

Strange.. TLS 1.1 is publicly vulnerable.

Not the way OpenVPN does TLS. But that is not a really relevant argument as we are working on getting 1.2 in, it's just lots of work and that needs time.

In this case it is a security trade off.

Indeed. So if you want 1.2 now, do not use cryptoapicert.

It is being worked on, but since the windows API currently in use does not do 1.2, we need to change our code to use the new API, and that needs review - to ensure the resulting code is actually more secure and not less secure.

comment:4 Changed 6 months ago by selvanair

Milestone: release 2.4.4release 2.4.5

Update: cyrptoapicert with RSA and TLS1.2 is now supported. Will be available in the next release (2.4.5).

commit 6c54745b8d417a534a6081588b1ecc7ff01fa9f7
Author: Selva Nair <selva.nair@…>
Date: Fri Jan 19 23:52:54 2018 -0500

TLS v1.2 support for cryptoapicert -- RSA only

  • If an NCRYPT handle for the private key can be obtained, use NCryptSignHash from the Cryptography NG API to sign the hash.

This should work for all keys in the Windows certificate stores
but may fail for keys in a legacy token, for example. In such
cases, we disable TLS v1.2 and fall back to the current
behaviour. A warning is logged unless TLS version is already
restricted to <= 1.1

Signed-off-by: Selva Nair <selva.nair@…>
Acked-by: Steffan Karger <steffan.karger@…>
Message-Id: <1516423974-22159-1-git-send-email-selva.nair@…>
Signed-off-by: Gert Doering <gert@…>
(cherry picked from commit 51d57d7dad6c6380df7b76bbec1897ea4f98474d)

Note: See TracTickets for help on using tickets.