Out of all the suggestions by Coverity I picked
the ones that move non-Ptr objects into variables
or attributes.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com>
This is the result after running 'clang-format -i' on all C++ files and
headers, with the defined formatting rules in .clang-format.
Only the openvpn/common/unicode-impl.hpp has been excluded, as that is
mostly a copy of an external project.
Signed-off-by: David Sommerseth <davids@openvpn.net>
As a first step towards DNS configuration in openvpn and a unified way
to push DNS related settings to clients in v2 and v3, this commit adds
support for parsing the new --dns option. Later commits will add support
for setting up DNS on different platforms.
For now, --dns and DNS related --dhcp-option can be used together for
smoother transition. Settings from --dns will override ones --dhcp-option
where applicable.
Signed-off-by: Heiko Hund <heiko@openvpn.net>
Do not try other auth methods, if a specific method was given
as a third parameter to the --http-proxy config option.
Signed-off-by: Heiko Hund <heiko@openvpn.net>
Introduce new
- ERR_PROFILE_FILE_IS_BINARY
- ERR_PROFILE_OPTION
error codes.
Also use "ERR_PROFILE_FILE_TOO_LARGE"
when generic was erronrously used.
Fixes OVPN3-523.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Prefix error messages with a predefined string of the form:
ERR_PROFILE_xxxxx:
This way a user can parse the prefix and get a better understanding of
the error, without relying on the sole message.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
The client reads the WKc from the key file and appends it to
the HARD_RESET_CLIENT_V3 packet when starting a connection.
The server reads the WKc from the received HARD_RESET_CLIENT_V3 packet,
decrypts and authenticates it (it is encrypted and signed with the
server keys upon generation) and finally extracts the client key.
The client key is then used to initialize the server tls-crypt.
At this point every packet is treated as a standard tls-crypt framed
message (HARD_RESET_CLIENT_V3 included).
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
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>
Added support for "http-proxy" and "http-proxy-option" directives
in the main section of the config file, outside of <connection>
blocks.
Added <http-proxy-user-pass> multiline directive for inlining
proxy creds:
<http-proxy-user-pass>
user
pass
</http-proxy-user-pass>
Merge class now knows how to expand creds file inline.
For example,
http-proxy ntlm.yonan.net 3128 auth.txt
is converted to:
http-proxy ntlm.yonan.net 3128 auto
<http-proxy-user-pass>
user
pass
</http-proxy-user-pass>
unrecognized, ignored, or unused.
This behavior is somewhat different (by design) to 2.x branch, which
will raise a fatal exception if an unrecognized option is
encountered.
Android: 1.1.9 build 31
* Reverted key-direction back to a default of 1.
* Raise fatal error if "fragment" option is used.
* Made TunBuilderCapture more useful as a base class for
tun construction on various platforms.
* Added disableClientCert flag at ovpncli.hpp API.
* Updated help FAQ with more details on how to
properly set key-direction, and notes about
possible network disconnect during voice calls.
