OpenVPN Hackathon 2023
Table of Contents
This year's hackathon is organized by Lev Stipakov. For the most part.
Dates
October 6-8, 2023
Venue
The venue for the hackathon is a Scandinavian School Costa Blanca, which is in Orihuela Costa, Alicante province, Valencian Community, Spain.
C. Pablo Picasso, 5 Bloque 6, 3ª Planta 03189 Orihuela, Alicante
The closest airport is Alicante Elche. From there it takes 50min by taxi to arrive to Orihuela Costa. Note that the venue located about 8km from Torrevieja center, so you probably don't want to book a hotel there.
Hotels close-by:
Who is coming?
| Name | Topics | Arrival | Departure | Hotel | T-shirt size |
| Lev Stipakov | DCO, new TAP driver | already there | 08.10 late evening | TBD | M |
| Gert Döring | triage open issues, Tunnelcrack | Thu. Oct. 5 16:20 at ALC | Sun Oct. 8 flight at 12:30 | Servigroup | XL |
| Arne Schwabe | things | Tur late (19:00 at ALC) | Sun afternoon (flight at 18:50) | TBD | XXL |
| Johan Draaisma | gerrit | Thu. Oct. 5. 16:30 | Sa. Oct. 14. 17:20 | una casa cerca de la escuela | XL |
| Frank Lichtenheld | gerrit | Thu. Oct. 5. 16:45 | So. Oct. 8. 18:10 | Servigroup | XL |
| Heiko Hund | future of --dhcp-options | Thu. Oct. 5. 16:25 | Sa. Oct. 14. 15:00 | una casa cerca de la escuela | XXL |
| Max Fillinger | TBD | Thu. 16:30 at ALC | Mon. 13:00 | Orihuela Costa Resort | XL |
| Antonio Quartulli | i just want a shirt kthxbye | not attending | not attending | not attending | M |
| James Yonan | unable to attend | not attending | not attending | not attending | XL |
| Samuli Seppänen | not attending | not attending | not attending |
Meeting summary
- TunnelCrack vulnerabilities
Published a statement on the community wiki regarding TunnelCrack. A security advisory on the main site is to follow a bit later.
The statement regarding TunnelCrack is here: https://community.openvpn.net/openvpn/wiki/TunnelCrack
Planned future mitigation steps to counter these vulnerabilities. Out of necessity the mitigations will be different per platform.
Windows: we can rework --redirect-gateway block-local to use Windows Filtering Platform - we already have a precedent for using WFP in --block-outside-dns.
macOS: we need to look at the VPN API and maybe PF for a solution to block the unwanted traffic paths.
Linux: we can have OpenVPN implement a separate routing table and set up a routing policy. We'll need to add some options to give some control over this.
We want to avoid using a firewall solution on Linux because of the multitude of firewall solutions and configurations out there, or even lack of one.
We want to ensure each OpenVPN process has its own routing table, and base its ID number off of interface ID with some offset.
Have an option to allow to specify what routing table ID number OpenVPN should use (but not 0).
Details to be worked out.
BSD OSes: we can provide an --up script example and documentation to show how to block the unwanted traffic paths.
Android: has traffic isolation out of the box and is not affected by these vulnerabilities.
iOS: currently only implementation is in OpenVPN Connect, so OpenVPN Inc. will look into a fix there.
- Change default for topology directive
Currently the default for topology is still net30. However we want to change it to subnet topology.
This change will mean a more sane and simpler to understand default setup of OpenVPN.
To prepare for this change we will update sample configurations and documentation to use subnet topology.
This change of the default from net30 topology to subnet topology is planned for OpenVPN 2.7.
- DNS implementation on Windows
Currently the automatic service runs with elevated privileges which is not ideal from a security perspective.
Currently the OpenVPN binary contains DNS and route handling code that is also duplicated in the interactive service.
We would like to implement new split-DNS functionality using the new --dns directive.
Because we then have to touch the DNS code anyway we would rather not maintain it in duplicate.
We can update the DNS handling functionality in the privileged interactive service.
And then alter the automatic service to use the interactive service for setting routes and DNS.
We can then deduplicate the route and DNS code, but we do need a way to keep debugging feasible.
- DNS implementation on Linux
We want an out-of-the-box working DNS implementation on Linux. OpenVPN2 currently needs an --up script.
Currently an immediately working DNS implemented on Linux only exists in the OpenVPN3 Linux client.
We want to provide a script with OpenVPN 2.7 on Linux that supports resolved and resolvconf out-of-the-box.
OpenVPN will then use that provided script automatically when the new --dns directive options are used.
Existing setups with an --up DNS script that use dhcp-option dns etcetera options will continue to work as before.
For dnsmasq and network-manager setups we add a --dns-script parameter to specify a custom script for DNS handling.
Technically the provided script could also be altered but it is better to provide your own script.
Eventually in the future we may want to deprecate the dhcp-option dns options, but that's far in the future.
- Windows GUI update mechanism
A suggestion was made to consider adding a software update mechanism.
It was mentioned to consider to use Sparkle or some other existing solution to implement the update mechanism.
- Future of dhcp-option directive
Some of the options for this directive are not in the most logical place.
An example of a case where it is more logical to have a separate directive is the set of DNS related dhcp-options.
The functions behind: dns, domain, domain-search, and adapter_domain_suffix, more logically belong with the new --dns directive.
We want to evaluate all the dhcp-option directive options and see if any of it can be separated out into its own directive.
If an option has a replacement directive, then plan to eventually deprecate the original dhcp-option.
- Planned deprecation of NTLM proxy authentication methods
The reason for deprecating this is the very poor security of this feature.
NTLMv1 is already deprecated, but will be removed from OpenVPN 2.7.
NTLMv2 will become marked as deprecated but still work in OpenVPN 2.7.
In the future we can then decide to remove NTLMv2 as well eventually.
It would be nice if OpenVPN GUI could have a single sign-on experience via Kerberos for proxy auth.
- Planned deprecation of --secret static key directive
The --secret directive allows for a simple static key setup in OpenVPN without having to deal with a certificate PKI setup.
The --peer-fingerprint directive allows to do similar, but unlike --secret, it does employ Perfect Forward Secrecy.
Not having PFS means that if the static key is ever compromised, all the previous encrypted data can all be decrypted.
For this and other reasons the --secret directive is now considered unsafe to use and --peer-fingerprint is a good replacement.
Deprecation of the --secret directive will begin in OpenVPN 2.7, and removal will be done in OpenVPN 2.8.
- Multiple authentication plugins support
In the past multiple authentication plugins was supported but had a known issue with tracking the authentication states.
To resolve the immediate security problem now only 1 authentication plugin at a time is allowed.
We have patches in waiting that need attention to get multiple authentication plugin support back in a safe way.
This is planned for OpenVPN 2.7.
- Improve OpenVPN2 and network-manager integration
A known issue is the handling of full-tunnel vs split-tunnel between OpenVPN2 and network-manager.
The network-manager program wants to be in control of the routing, whereas normally OpenVPN2 is assumed to be.
We can indicate to network-manager somehow whether split-tunnel or full-tunnel is required, so it can handle the needed routing.
We can implement this in master intended for 2.7 and if the change is non-disruptive backport it to 2.6.
- Multi-socket support
We want OpenVPN2 to be able to listen on multiple sockets at the same time, for example TCP and UDP at the same time.
We are expecting a patchset to come in that will implement this, and we intend to get this into OpenVPN 2.7.
- Live route updates
This idea started out as a way to updates routes live on the client side without having to force a reconnect.
We agreed that this feature should support also updating other settings.
This is currently planned for OpenVPN 2.7.
- Custom control channel packets
For client-side features not part of OpenVPN protocol itself, having a reliable messaging channel would be good.
Instead of doing out-of-band communication for this, reusing the existing control channel is preferable.
This requires a new control channel message that can transport arbitrary messages.
The changes should not affect existing OpenVPN clients as unrecognized control channel message tend to be ignored.
This is currently planned for OpenVPN 2.7.
- mbedTLS updates
Currently the change in licensing for mbedTLS has held back updates for it in OpenVPN2.
We are currently in the final stages of updating the licensing of OpenVPN2 slightly to resolve this.
This unblocks the mbedTLS maintainer to provide a set of patches to update to newer mbedTLS.
We already have confirmation that a patchset is being worked on and is on the way.
We can implement this in master intended for 2.7 and if the change is non-disruptive backport it to 2.6.
- Remove OpenSSL 1.0.2 support
This is an older version of OpenSSL that we remove support for. Newer versions will remain supported for now.
This is currently planned for OpenVPN 2.7.
- 2.6 client with DCO connecting to 2.4 server silent failure
We looked at this case and turns out that versions 2.4.0 - 2.4.4 are affected. Newer versions are fine.
We will add a notification for this particular issue so that it is not some silent failure. People can upgrade to newer versions to solve it.
- Incoming patchset for DCO-win
Lev will offer to help with splitting the huge patchset into manageable related pieces and work on merging it.
Last modified 7 months ago
Last modified on 10/08/23 13:38:53
