legacy -- allow 1024-bit RSA certs signed with SHA1
preferred -- require at least 2048-bit RSA certs signed
with SHA256 or higher
suiteb -- require NSA Suite-B
The current default is legacy.
The directive can be set in the profile or overridden/defaulted
in the client API via ClientAPI::Config::tlsCertProfileOverride
var.
TODO: implement for OpenSSL.
user-defined service objects. This commit attempts
to work around that but requires a specially patched
version of Asio that includes the virtual
async_connect_post_open() method.
The asio::io_context::work class has been replaced by a new
class having somewhat different and more verbose
semantics.
We create our own class AsioWork based on the new class
asio::executor_work_guard<asio::io_context::executor_type>
that implements the semantics of the original
asio::io_context::work class.
mutable_buffers_1 -> mutable_buffer
const_buffers_1 -> const_buffer
This patch is a granularization of a patch by David Sommerseth
<davids@openvpn.net> where only the above renames are included.
As of LZ4 v1.7, the LZ4_compress() function is deprecated and
is to be replaced with LZ4_compress_default().
This new function adds an extra argument which declares the size
of the destination buffer. In addition, if the result is 0, the
result buffer is not to be trusted as the compression failed.
Signed-off-by: David Sommerseth <davids@openvpn.net>
This patch builds on work by David Sommerseth <davids@openvpn.net>
to move the PolarSSL API from polarssl-1.3 to mbedtls-2.3, which
has significant differences in some areas.
- Strings containing keys, certificates, CRLs, and DH parameters
need to be NULL-terminated and the length argument provided to
the corresponding mbedtls parse function must be able to read
the NULL-terminator. These places have been modified with a
'+1' to the length argument (x509cert.hpp, x509crl.hpp, dh.hpp,
pkctx.hpp).
- The SSL context object has been split up in mbedtls-2.3
Now many of the SSL configurations are done in a separate
SSL config object, which is added to the SSL context once
configured. In addition private/public keys are now stored
in a separate pk_context, which is later on attached to the
SSL context. Due to this, many of the calls setting either
SSL configuration parameters or working with pk_contexts have
been refactored. (sslctx.hpp)
- The older API loading the CA chain took a hostname argument.
The new API requires mbedtls_ssl_set_hostname() explicitly to
be called setting hostname. Some refactoring was needed here
too (sslctx.hpp).
- x509_oid_get_description() is now replaced by
mbedtls_oid_get_extended_key_usage().
- when mbedTLS renamed OID_CMP to MBEDTLS_OID_CMP, the return
value was changed so that a return value of 0 now means equal
rather than not-equal.
- mbedtls/platform.h must be loaded before any other mbedtls
include files (sslchoose.hpp).
- All functions and macros related to mbedTLS are now prefixed
with mbedtls_/MBEDTLS_
- Refactored External PKI and added some options to cli.cpp
to make it easier to test that the feature still works
correctly. This included removing the sig_type var and
standardizing on a PKCS#1 digest prefix per RFC 3447.
- Updated test keys to 2048 bits.
- Updated dependency build scripts to build mbedTLS.
- Enable MD4 in mbedTLS build script (needed for NTLM auth).
- Use an allow-all X509 cert profile to preserve compatibility
with older configs. Going forward, we will implement new
options to increase strictness on minimum RSA key size and
required cert signing algs.
- Added human-readable reason strings that explain why
a given cert in the chain wasn't accepted.
- This patch doesn't rename any files or rename internal
OpenVPN 3 symbols such as PolarSSLContext. This will
be done in a separate commit.
Signed-off-by: James Yonan <james@openvpn.net>
destructor. Not doing so can cause this error:
OpenSSLContext::SSL::read_cleartext: BIO_read failed, cap=400 status=-1: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
to wrongly implicate the next SSL session.
both cryptographic and non-cryptographic algorithms, as
a failsafe, add a new virtual method assert_crypto()
that will throw an exception if the algorithm is not
crypto strength. assert_crypto() should now be called
before any RNG is used for crypto purposes.
channel messages using the new
ClientAPI::OpenVPNClient::post_cc_msg()
method:
// post control channel message
void post_cc_msg(const std::string& msg);
construction even when user/group lookup fails.
Updated calls to std::strerror() to use a saved version
of errno.
Added chown(), gid(), and additional defined() methods.
Use uid_t as the return type for uid().
to HTTP CONNECT but implemented over the OpenVPN protocol.
1. Client connects to relay server as if it were connecting
to an ordinary OpenVPN server.
2. Client authenticates to relay server using its client
certificate.
3. Client sends a PUSH_REQUEST method to relay server which
then replies with a RELAY message instead of PUSH_REPLY.
4. On receiving the RELAY message, the client attempts to
reconnect using the existing transport socket. The
server will proxy this new connection (at the transport
layer) to a second server (chosen by the relay server)
that is the target of proxy.
5. The client must establish and authenticate a new session
from scratch with the target server, only reusing the
transport layer socket from the original connection to
the relay server.
6. The relay acts as a man-in-the-middle only at the
transport layer (like most proxies), i.e. it forwards
the encrypted session between client and target server
without decrypting or having the capability to decrypt
the session.
7. The client is designed to protect against potentially
untrusted or malicious relays:
(a) The client never transmits the target server
username/password credentials to the relay server.
(b) The relay forwards the encrypted OpenVPN session
between client and target server without having
access to the session keys.
(c) The client configuration has a special directive
for relay server CA (<relay-extra-ca>) and relay
server tls-auth key (<relay-tls-auth>) to allow
for separation of TLS/crypto configuration between
relay and target servers.
(d) The client will reject any PUSH_REPLY messages
from the relay itself to prevent the relay from
trying to establish a tunnel directly with the
client.
Example configuring a client for relay:
# remote addresses point to the relay server
remote ... 1194 udp
remote ... 443 tcp
# include all other directives for connecting
# to the target server
# enable relay mode
relay-mode
# constrain the relay server's cert type
relay-ns-cert-type server
# include extra CAs that validate the relay
# server cert (optional).
<relay-extra-ca>
-----BEGIN CERTIFICATE-----
. . .
-----END CERTIFICATE-----
</relay-extra-ca>
# specify the TLS auth key for the relay server
relay-key-direction 1
<relay-tls-auth>
-----BEGIN OpenVPN Static key V1-----
. . .
-----END OpenVPN Static key V1-----
</relay-tls-auth>
