Openvpn tls-crypt unwrap error

Installing and Using OpenWrt
43

Easy-RSA is a wrapper for OpenSSL designed to make PKI-management easier.
Command build-key is obsolete and replaced with easyrsa build-client-full command in the current version.

44

@AZNBCDDW Do not use Easy-RSA, as it does not create proper certificates and has too many limitations.

  • It is unwise to bounce around to different wikis... please choose one and stick with it. Also, it would likely be more productive to create new threads for new issues.

Easy-RSA has always been a half-baked, poorly implemented, horrendously maintained, half-assed way to handle certificates, consistently, to this day, violating RFC requirements (one violation is from a RFC requirement that's been in effect for over two decades).

If a user wants properly created VPN certificates, utilizing openssl directly, via an openssl.cnf, or utilizing another SSL certificate management system (mbedtls, etc.), is the only way to go.

45

Easy-RSA project is hosted under official OpenVPN account and it's actively developed.
I'm a bit skeptical, so could you explain please, which requirements it violates?

46

I agree completely. But I have not found any documentation I can go for. (multiple clients for TUN, multiple clients for TAP). Especially for TAP there are very few and incomplete descriptions.

47

My idea is to use openssl directly. Other packages usually make maintenance more complicated in the long term. Can you give me the openssl command?

48

I know it's the project of OpenVPN devs, and they've consistently chosen a half-baked, poorly implemented, horrendously maintained, half-assed openssl implementation.

  • Finally, after years, they decided to update it to version 3 and still couldn't manage to properly implement CN requirements or SANs by default (easy-rsa supports them, but they're buried, and last I checked ~a month ago, were still not working correctly)

My philosophy: when doing something, take the time to do it right the first time around, and don't settle for half-assedness simply because it's easier or more convenient...

  • I would have thought OpenVPN devs would have taken the time to properly implement the correct certificate requirements in Easy-RSA v3, which they chose not to do.

I'd have to do some research to dig up the exact RFC number, but ~20 years ago it was stipulated in an RFC the CN must not contain an IP or DNS due to it being actively exploitable via an MITM exploit, and until Easy-RSA v3 was released, it only supported an IP or DNS as the CN, and that was still the default in v3 when I last checked around a month ago.

Easy-RSA was always intended to be half-baked and poorly implemented, put out there as a simple way to create certificates for the devs' main project, regardless if the resultant certificates were properly created or not.

Perhaps in the last month or so Easy-RSA v3 added SANs as the default method, prevented IPs and DNS' from being utilized in the CN, and ensured the correct KUs and EKUs are set, but the fact Easy-RSA either never supported these, or didn't set them to default in v3 (as of around a month ago), means I will never recommend them and will always actively advocate to never utilize Easy-RSA.

  • I, or any user for that matter, should not have to routinely check their GtHub issues page to ensure they've properly implemented the most basic of options for a SSL cert... the fact Easy-RSA has existed for years and has never managed to create a proper certificate (correct KUs & EKUs, utilizing SANs, preventing IP/DNS in CN, etc.) means Easy-RSA should not be trusted by anyone to properly create a certificate, as Easy-RSA has consistently demonstrated it should not be trusted to do so.

On a side note, with respect to OpenWrt, it's more convenient, and efficient, for an OpenWrt user to utilize openssl directly via an openssl.cnf for their certificate management, as it then empowers them to create a main CA for their router, utilize that CA to digitally sign their LuCI cert (as uhttpd's default implementation of generating a self-signed cert is not secure and therefore not acceptable... again, do it right the first time around), digitally sign an ICA for their VPN server, and utilize that ICA to sign their VPN certs.

49

I already have =]


As @vgaetera mentioned previously, provided topology subnet is utilized (Net30 was depreciated years ago), every VPN supports multiple clients by simply ensuring it has a dhcp server config for the VPN interface in /etc/config/dhcp, or if not using a DHCP server, configuring CCD and specifying the ifconfig-push command in the clien'ts config file.

As for TAP, think about TAP vs TUN as:

  • TUN: VPN server is a virtual physical network interface on your router (visualize 3 physical port sections on router: LAN, VPN, WAN)
    • This is what's meant by it being a Layer 3 configuration

  • TAP: VPN server is a virtual physical router that's been virtually connected to the remote router's LAN port.
    • This is what's meant by it being a Layer 2 configuration
    • This allows the remote router to transparently route traffic between the VPN client and the remote router.
      • For example, this could allow your VPN client to be assigned an IP from the remote router's LAN DHCP server and your client would interact with the remote router as if it was directly connected to it.
50

Let's drop emotional part and try to be impersonal dealing with everything in order.

1. Basic Constraints, Key Usage, Extended Key Usage

Attributes BC, KU and EKU look fine:

# openssl x509 -text -in /etc/easy-rsa/pki/ca.crt | grep -EA1 'Basic Constraints|Key Usage'
            X509v3 Basic Constraints:
                CA:TRUE
            X509v3 Key Usage:
                Certificate Sign, CRL Sign

# openssl x509 -text -in /etc/easy-rsa/pki/issued/vgserver.crt | grep -EA1 'Basic Constraints|Key Usage'
            X509v3 Basic Constraints:
                CA:FALSE
--
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Key Usage:
                Digital Signature, Key Encipherment

# openssl x509 -text -in /etc/easy-rsa/pki/issued/vglaptop.crt | grep -EA1 'Basic Constraints|Key Usage'
            X509v3 Basic Constraints:
                CA:FALSE
--
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Key Usage:
                Digital Signature

2. Subject Alternative Name

Since when has SAN become mandatory attribute?
Please state specific RFC.
Note that RFC 2818 does not refer to OpenVPN protocol and does not take into account KU and EKU attributes.

3. Subject Common Name Field

Please state specific RFC.
Note that in accordance with OpenVPN manual we have remote-cert-tls as an additional EKU verification to prevent MITM.

51

There are, according to my research, two methods of encryption in openvpn:
1. Pre-shared key
2. Certificates

For certificates you need a constant DDNS or DNS name or a consistent IP. Both are not given with me. The IP is assigned dynamically by Internet Providers and I use multiple DDNS domains for security reasons.

Is it correct that for this reason no certificates and no PKI are usable?

52

the documentation is good. But many links do not work anymore.

53

can someone tell me what these IP addresses mean?

54
  1. Basic Constraints, Key Usage, Extended Key Usage
    • EKUs serverAuth and cliethAuth were previously not possible to be set by default until 2017, and while there has been active development on Easy-RSA throughout 2017 and 2018, prior to this, there was no work being done on it, which is why I began pushing the utilization of openssl directly over that of Easy-RSA.
      • With that being said, it does appear I was wrong about some of my assertions yesterday, however, due to the lack of basic features Easy-RSA lacked for so long without active development up until 2017, it's left a bad taste in my mouth.

  2. Subject Alternative Name
    • See RFC2818 (3.1):
      • "Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead."
  • Since when has SAN become mandatory attribute?
    • If an IP or hostname is not to be stored in the CN per the RFC, the only other way of specifying them is via the SAN.
      • As of a month or so ago, it was still not possible to set SANs by default via Easy-RSA, per an issue that was opened on their GitHub, and what was essentially being done was the CN was being copied into a single SAN entry, even though the CN should not contain an IP or domain name...
        (my philosophy: take the time and do things the right way the first time around)
  • Note that RFC 2818 does not refer to OpenVPN protocol and does not take into account KU and EKU attributes.
    • This was one of my assertions that was wrong, as prior to 2017, it was impossible to set EKUs through Easy-RSA as the default behavior.

  1. Subject Common Name Field
    • As mentioned previously, I'll need to do some research to dig up the exact RFC.
  • Note that in accordance with OpenVPN manual we have remote-cert-tls as an additional EKU verification to prevent MITM
    • remote-cert-tls, which expects a KU of keyEnciphernment [a0] OR keyAgreement [88] (not both) [RFC 5280 4.2.1.3], has always been supported, but it does not require an EKU... in fact, if you specify an EKU, or both KUs keyEncipherment & keyAgreement, the connection will fail since the hex values will not match a0 or 88 (this may have been addressed in v2.4)
      • This blog write up explains the technicalities of why this is.
    • Additionally, remote-cert-tls severely restricts what ciphers you're able to utilize, as the available ciphers for utilization are determined by the KU(s) specified.
55

OpenSSL moved their man pages from their main site to their wiki site, and I haven't had the time to update the links.

  • If you need the man page for a command, simply google "< command > man page"
    (i..e "openssl req man page", "openssl x509 man page", etc.)

You would create your SAN with each DDNS host name entered (per the bullet under 1.b.I):

[ alt_vpn_server1 ]
IP.1                = 10.0.0.1
DNS.1               = your.ddns1.com
DNS.2               = your.ddns2.com
DNS.3               = your.ddns3.com
DNS.4               = your.ddns4.com
DNS.5               = your.ddns5.com
57

I understand your point however you can also look from the positive side.
It took a lot of time but the project has finally matured and those features are implemented correctly now.

That statement contains no key words described in RFC 2119 which refers to requirement levels.
So strictly speaking, missing of SAN attributes can't be considered as violation of requirement.

Let's make sure we are talking about the same:

58

Have you considered OpenVPN threat model?
https://en.wikipedia.org/wiki/Threat_model

60

The CN should not contain an IP or DNS... this is why Chrome lists all certs with an IP or DNS in the CN as non-trusted since ~v51.

  • I do understand the point you're making in regards to the definitions in RFC 2119, however if something is depreciated due to a security concern, shouldn't we air on the side of caution?

It's not as simple as that, as each KU option a cert is issued with has a specific hex value attached, and if the sum of the hex values does not match what remote-cert-tls expects (a0 or 88], the VPN connection will be refused. The blog write up I linked to explains in detail why this is, and the hex value for each KU option can be seen in the RFC 5280 4.2.1.3 link I linked to.

  • src/openvpn/options.c
    if (streq (p[1], ā€œserverā€)) {
  options->emote_cert_ku[0] = 0xa0;
  options->remote_cert_ku[1] = 0x88;
  options->remote_cert_eku = ā€œTLS Web Server Authenticationā€;
}
    • Both the following will work:
      keyUsage = digitalSignature, keyAgreement
      keyUsage = digitalSignature, keyEncipherment

    • And all other combinations will not work:
      keyUsage = digitalSignature, keyAgreement, decipherOnly
      keyUsage = digitalSignature, keyAgreement, encipherOnly
      keyUsage = digitalSignature, keyEncipherment, keyAgreement

      keyUsage = nonRepudiation, digitalSignature, keyAgreement
      keyUsage = nonRepudiation, digitalSignature, keyAgreement, decipherOnly
      keyUsage = nonRepudiation, digitalSignature, keyAgreement, encipherOnly
      keyUsage = nonRepudiation, digitalSignature, keyEncipherment
      keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement

With that being said, Easy-RSA did implement the EKUs clientAuth and serverAuth in late 2016, as certs used to be issued with no EKUs. I wasn't aware of this since I stopped using Easy-RSA in late 2015/early 2016 due to it's limitations, and due to the lack of development on the project, I eventually stopped checking if it had seen any commits.

61

Strictly speaking, Google Chrome violates RFC 2818:

RFC 2818 actively uses terms defined in RFC 2119 and word "encouraged" is not one of those terms.
Security concern should utilize more strict terminology, shouldn't it?

However that's not the point.
The point is security is not absolute, but relative.
Security does not exist without context which is defined by threat modeling.
And OpenVPN threat model differs from HTTPS threat model, so RFC 2818 "HTTP Over TLS" is not completely relevant to OpenVPN protocol.

It works fine together with certificates issued by Easy-RSA and it's aslo possible to use other options:

1 Like
62

I'm doubtful Google's in violation of it, as I'm assuming they would have reached out to the IETF prior to, else the risk of a backlash from corporations and CAs alike would have caused a reversion. They provided corporations with around a year to have their certificates reissued with the hostname and/or IPs in the SAN, not the CN. In order to determine which of our interpretations of RFC2818 3.1 are correct, the IETF would have to be contacted for verification..

1 Like
63

I hope so.
In an ideal world IETF releases updated RFC revision to the public in a clear and transparent way, and then everyone can safely implement new features and drop deprecated ones.
I understand Google acts from the point of greater good, certificate structure unification, code optimization, etc.
However it's still a bit alarming that corporation can push its own view of standard using almost monopoly status.
Another example: https://bugs.chromium.org/p/chromium/issues/detail?id=881410

1 Like
64

Hi,
I use this how to from openwrt "line by line".
Server seem to be ok on the router because I got the initialisation sequence blabla in log.
But when I try openvpn --config client1.ovpn on a remote ubuntu pc I got the error:

Sun May 16 15:57:37 2021 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 27 2021
Sun May 16 15:57:37 2021 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Sun May 16 15:57:37 2021 TCP/UDP: Preserving recently used remote address: [AF_INET MypublicIPaddress:1194]
Sun May 16 15:57:37 2021 UDP link local: (not bound)
Sun May 16 15:57:37 2021 UDP link remote: [AF_INET]MypublicIPaddress:1194
Sun May 16 15:57:37 2021 tls-crypt unwrap error: packet too short
Sun May 16 15:57:37 2021 TLS Error: tls-crypt unwrapping failed from [AF_INET]MypublicIPaddress:1194

Couldn't find the way to manage that. Keep trying.
Thanks