OpenVPN multithreading

Help on building IPFire & Feature Requests
Post Reply
Saiyato
Posts: 36
Joined: October 9th, 2018, 6:55 pm

OpenVPN multithreading

Post by Saiyato » December 18th, 2018, 9:17 pm

Hi all,

I've been reading into why OpenVPN seems perform so poorly on fairly new devices. As it appears OpenVPN only runs on one thread, meaning higher frequencies are beneficial, but multiple cores aren't.

Some searching did give me this repo, which claims it can run OpenVPN connections over multiple cores: https://github.com/znuh/frivpn

I'm not sure how security is impacted, but this might prove to be of benefit for low frequency, multi-core processors (like the APU and ARM devices).

As said, I'm not sure if this degrades security, but maybe someone more knowledgeable might be able to provide his/her $0.02. Or maybe it won't (ever) build on IPFire, because then it stops as well ;)

Thanks in advance!
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4813
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN multithreading

Post by ummeegge » December 19th, 2018, 8:00 am

Hi Saiyato,
postponed thread into english but also into development section.
Saiyato wrote:
December 18th, 2018, 9:17 pm
I've been reading into why OpenVPN seems perform so poorly on fairly new devices. As it appears OpenVPN only runs on one thread, meaning higher frequencies are beneficial, but multiple cores aren't.
in OpenVPN roadmap --> https://community.openvpn.net/openvpn/w ... #Threading you can find also some informations causing this topic.
Saiyato wrote:
December 18th, 2018, 9:17 pm
Some searching did give me this repo, which claims it can run OpenVPN connections over multiple cores: https://github.com/znuh/frivpn

I'm not sure how security is impacted, but this might prove to be of benefit for low frequency, multi-core processors (like the APU and ARM devices).
Reading through a discussion about Frivpn --> https://news.ycombinator.com/item?id=16416881 some of the concerns in there are also security related.
Saiyato wrote:
December 18th, 2018, 9:17 pm
As said, I'm not sure if this degrades security, but maybe someone more knowledgeable might be able to provide his/her $0.02. Or maybe it won't (ever) build on IPFire, because then it stops as well ;)
Seeing the limitations in here --> https://github.com/znuh/frivpn under "Troubleshooting & Caveats" would be, speaking for myself, currently not acceptable since it requires the server to use really outdated but under specific circumstances exploitable settings like comp-lzo -->viewtopic.php?t=21265 , since GCM is available for OpenVPN, CBC seems to become also a kind of outdated (OpenVPN uses AES-GCM-256|128) as default for the cipher negotiation (with 2.4.x available) see also --> https://blog.cloudflare.com/padding-ora ... hersuites/ , why the usage of TCP with OpenVPN can be a problem can be found in here --> http://sites.inka.de/bigred/devel/tcp-tcp.html and as far as i know this problem is already addressed in the OpenVPN dev community but to my knowledge there has been no solution for this yet. I won´t also use SHA1 aynmore.

Some points of view from here.

Best,

UE
Image
Image

Saiyato
Posts: 36
Joined: October 9th, 2018, 6:55 pm

Re: OpenVPN multithreading

Post by Saiyato » December 19th, 2018, 11:27 am

Hi UE,

Thanks for the response, I did some checking into comp-lzo, which is 'simple' compression (now deprecated, because lz4 was implemented for speed reasons), it it - in certain scenarios - susceptible to attacks. See BEAST and CRIME: https://security.stackexchange.com/ques ... ffect-vpns
But I obviously forgot about VORACLE; if I'm reading this correctly it only affects HTTP traffic, right?

I've also been trying to understand CBC (chaining) and GCM (Galoise counter), but the more I read... the less I understand it ;) I should just accept that I understand it are both ways to make sure the messages arrive in order and in time and untampered with.

As for TCP-over-TCP, I understand that this can be problematic if a package is lost/delayed yes, you would need to rebuild the connection if I understand correctly, which takes time.

SHA-1 is pretty clear to me, it's outdated and more secure ways have been adopted, period :)

I do understand that timing is everything in VPNs and multithreading has been a dread throughout the history of computers. I guess I was just hoping OpenVPN would be able to provide secure multithreaded solutions for the wide spread ARM devices on the globe ::)
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4813
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN multithreading

Post by ummeegge » December 19th, 2018, 3:15 pm

Hi Saiyato,
Saiyato wrote:
December 19th, 2018, 11:27 am
Thanks for the response, I did some checking into comp-lzo, which is 'simple' compression (now deprecated, because lz4 was implemented for speed reasons), it it - in certain scenarios - susceptible to attacks.
LZ4 and LZ4v2 integration has been already made with 80% into IPFire´s WUI but Voracle stops this then.This problem is an older one but the feasibility of Voracle leads sooner or later to disable it in general in the WUI even the compression becomes most effective with clear text streams like HTTP but is also less//not effective with already encrypted ones. The LZ4 lib is already available for IPFire but not implemented into OpenVPN WUI and i think it never will.
Saiyato wrote:
December 19th, 2018, 11:27 am
if I'm reading this correctly it only affects HTTP traffic, right?
Yes, there are some more points which you can read in more depth in the linked topic.
Saiyato wrote:
December 19th, 2018, 11:27 am
I've also been trying to understand CBC (chaining) and GCM (Galoise counter), but the more I read... the less I understand it ;) I should just accept that I understand it are both ways to make sure the messages arrive in order and in time and untampered with.
The main and already noticeable problem is SWEET32 --> https://sweet32.info/ . Even OpenVPN did activated by default "reneg-bytes 64000000" with v2.3.12 (64MB data transfer no more reneg-sec with 3600 sec. {one hour} until a new session key renegotiation) if 64bit clock cipher are in use (BLOWFISH all DES varieties, or in other words 50% percent of IPFire´s available OpenVPN ciphers) for the renewal of the session key (which needs time where no data can goes through the tunnel and the usage of big DH-parameter lenghts needs even longer) the whole CBC structure is a longer time known possible problem which becomes now more present. GCM might also ba a noticeable speed difference to CBC in my opinion (HMAC is already integrated).
Saiyato wrote:
December 19th, 2018, 11:27 am
As for TCP-over-TCP, I understand that this can be problematic if a package is lost/delayed yes, you would need to rebuild the connection if I understand correctly, which takes time.

As some of the above, a possible better performance with multithreading will be shreded with this adjustments in my humble opinion.
Saiyato wrote:
December 19th, 2018, 11:27 am
SHA-1 is pretty clear to me, it's outdated and more secure ways have been adopted, period :)
Yes.
Saiyato wrote:
December 19th, 2018, 11:27 am
I do understand that timing is everything in VPNs and multithreading has been a dread throughout the history of computers. I guess I was just hoping OpenVPN would be able to provide secure multithreaded solutions for the wide spread ARM devices on the globe ::)
Possibly OpenVPN stucks there a little since they would need to rewrite lots of their code... Nevertheless, OpenVPN-2.5 comes with some awesome new stuff, not to mention the already new (v2.4) possibilities which are currently not available via WUI (Cue: ECC) the performance/security can surely be increased.

Best,

UE
Image
Image

Post Reply