Update Openvpn RT-AC56R

[Guidoj]

My stock RT-AC56R uses Openvpn 2.3.2
Is it possible to upgrade the OpenVPN files on the router to 2.3.13?
SHA1 no good anymore?

TLS: Username/Password authentication succeeded for username 'xxxxx'
Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Control Channel: TLSv1, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA

 

[RMerlin]

My stock RT-AC56R uses Openvpn 2.3.2
Is it possible to upgrade the OpenVPN files on the router to 2.3.13?
SHA1 no good anymore?

TLS: Username/Password authentication succeeded for username 'xxxxx'
Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Control Channel: TLSv1, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA

You'd need to move to a third party firmware for that, the OpenVPN software is part of the read-only flash.

Note however that SHA1 is still perfectly fine for use in an HMAC, due to the way HMAC works. I learned about it while researching whether I should disable SHA1 support for SSH - turns out it's not necessary. SHA1 only becomes a weakness when applied against a single, "static" value, where you can break it through collisions. Unfortunately I didn't keep any of the links explaining the technical reasons why SHA1 HMAC was still perfectly fine, you might be able to find some of them on Google.

The performance impact of SHA256 won't bring you any real additional security there in this context.

 

[Guidoj]

Oh thank you,

Is it possible to change the value of rsa to 2048 using ssh....there is no option in gui

 

[RMerlin]

Oh thank you,

Is it possible to change the value of rsa to 2048 using ssh....there is no option in gui

You have to generate your own keys.

 

[Guidoj]

Thanx RMerlin

 

[sfx2000]

Note however that SHA1 is still perfectly fine for use in an HMAC, due to the way HMAC works. I learned about it while researching whether I should disable SHA1 support for SSH - turns out it's not necessary. SHA1 only becomes a weakness when applied against a single, "static" value, where you can break it through collisions. Unfortunately I didn't keep any of the links explaining the technical reasons why SHA1 HMAC was still perfectly fine, you might be able to find some of them on Google.

The performance impact of SHA256 won't bring you any real additional security there in this context.

SHA1 is still relatively safe, esp. when used in conjunction with AES-128 or AES-256... SHA256 can impact performance in some circumstances...

If this helps... this is on ARMv7 - brcm2710 (which is what I have handy at the moment)

$ gnutls-cli --benchmark-ciphers
Checking cipher-MAC combinations, payload size: 16384
     AES-128-CBC-SHA1 18.67 MB/sec
     AES-128-CBC-SHA256 16.36 MB/sec

Checking MAC algorithms, payload size: 16384
            SHA1 83.00 MB/sec
          SHA256 50.68 MB/sec

Checking ciphers, payload size: 16384
     AES-128-CBC 24.03 MB/sec

=========
[B]$[/B] openssl speed sha1 sha256 aes-256-cbc aes-128-cbc
OpenSSL 1.0.1t  3 May 2016
built on: Fri Sep 23 22:38:09 2016
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) 
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1              7570.85k    24090.13k    54026.33k    78959.96k    91346.26k
aes-128 cbc      41474.19k    46773.99k    48613.29k    48958.81k    49179.31k
aes-256 cbc      32435.88k    35587.41k    36631.47k    36900.86k    36965.03k
sha256           10790.52k    26967.64k    48760.32k    61597.35k    66633.73k

 

[john9527]

Here's on a AC68P, overclocked to 1200,800

gnutls-cli --benchmark-ciphers
Checking cipher-MAC combinations, payload size: 16384
             AES-128-GCM 13.56 MB/sec
             AES-128-CCM 12.51 MB/sec
       CHACHA20-POLY1305 43.49 MB/sec
                    NULL 0.64 GB/sec
        SALSA20-256-SHA1 37.87 MB/sec
        AES-128-CBC-SHA1 17.96 MB/sec
        AES-128-CBC-SHA256 15.09 MB/sec

Checking MAC algorithms, payload size: 16384
            SHA1 77.38 MB/sec
          SHA256 40.60 MB/sec
          SHA512 12.25 MB/sec

Checking ciphers, payload size: 16384
                3DES-CBC 6.41 MB/sec
             AES-128-CBC 23.73 MB/sec
             ARCFOUR-128 67.63 MB/sec
             SALSA20-256 70.02 MB/sec

 

[sfx2000]

Here's on a AC68P, overclocked to 1200,800

Interesting - Pi3 stock vs. RT-AC68P (overclocked)

Maybe time to see about some DNS tricks and support both OVPN clients and some adblock activities via DNS - DNSmasq runs on both, redirect VPN traffic via DNS to the Pi, and let the Pi be the primary DNS for the LAN for adblocking..

And the Pi3 having more cores - that's more threads...

cool...

 

[RMerlin]

nteresting - Pi3 stock vs. RT-AC68P (overclocked)

OpenSSL 1.0.2 had quite a few performance improvements for those ciphers it has ASM support for. Try upgrading your Pi to 1.0.2 (or backport those optimizations - that's what I originally did for my FW before flat out bumping it to 1.0.2). Should provide some nice boosts to SHA and AES.

 

[sfx2000]

OpenSSL 1.0.2 had quite a few performance improvements for those ciphers it has ASM support for. Try upgrading your Pi to 1.0.2 (or backport those optimizations - that's what I originally did for my FW before flat out bumping it to 1.0.2). Should provide some nice boosts to SHA and AES.

That openssl was the stock build in Raspian-Jessie - I've got a private build, and with the A53, it's not that much different, compared to other cortex cores like the A9...

The Cortex-A9 cores do better in many things compared to the A53's in the 2710... just thought it was interesting how the numbers lined up in one use case... the 2710 does do a bit better in some tasks due to vfp4 and neon with arm7 code, and unlike what folks might expect, armv8 code isn't a big step forward on those a53 cores...

 

[RMerlin]

armv8 code isn't a big step forward on those a53 cores

AES-NI and other methods of providing crypto HW acceleration is what makes the armv8 platform potentially interesting in a router/VPN environment - provided the software stack leverages it.

 

[sfx2000]

AES-NI and other methods of providing crypto HW acceleration is what makes the armv8 platform potentially interesting in a router/VPN environment - provided the software stack leverages it.

Indeed - would like to see Cortex-A72 come in, but I think Cortex-A53 is where folks are headed... but even then, it might be a while - didn't QCA just release an IPQ series with Quad A7's?

I'm actually more interested in the changes with OpenSSL 1.1, as I do have a couple of processors that can take advantage of some of the QuickAssist technology that Intel has pushed in... it probably won't mean things run faster in OpenVPN, but it should reduce some of the pressure on the cores themselves, which can only help...

 

[RMerlin]

I'm actually more interested in the changes with OpenSSL 1.1, as I do have a couple of processors that can take advantage of some of the QuickAssist technology that Intel has pushed in... it probably won't mean things run faster in OpenVPN, but it should reduce some of the pressure on the cores themselves, which can only help...

The upgrade from 1.0.0 to 1.0.2 was easy to do for us third party developers since it was 100% backward compatible. 1.1.0 will be a different story, we'll have to push on OEMs to update to that version in their firmware. Or I'll have to backport things like I did initially with the 1.0.2 ASM optimizations.

Kong posted some nice numbers showing how much performance boost he could get out of a Linksys router that had hardware-acceleration once he enabled it (can't remember, might have been the WRT1900AC). There's a lot of performance to be gained there for VPN tunnels.

 

[sfx2000]

The upgrade from 1.0.0 to 1.0.2 was easy to do for us third party developers since it was 100% backward compatible. 1.1.0 will be a different story, we'll have to push on OEMs to update to that version in their firmware. Or I'll have to backport things like I did initially with the 1.0.2 ASM optimizations.

Agree - it's non-trivial moving over to 1.1 from the 1.0.1/1.0.2, as there are enough changes that could break dependencies - in the longer run, it would be good...

Kong posted some nice numbers showing how much performance boost he could get out of a Linksys router that had hardware-acceleration once he enabled it (can't remember, might have been the WRT1900AC). There's a lot of performance to be gained there for VPN tunnels.

I haven't been following that effort too close lately - but there were some issues with the WRT's in how Armada XP handled cyrpto vs. how the 385 does - AXP had some very nice performance improvements, but the 38x series was still a bit unstable due to how Marvell implemented (and not documenting) some items inside their cypto block.

 

[LouisvilleUK]

OpenVPN 2.4 with AEAD (GCM) support is scheduled for release end of the month. I'll be interested to see what performance improvements we get. Taken from github master changes Version 2.4.0 New features, "20 bytes per packet for AES-128-GCM instead of 36 bytes per packet for AES-128-CBC + HMAC-SHA1."

 

[RMerlin]

OpenVPN 2.4 with AEAD (GCM) support is scheduled for release end of the month. I'll be interested to see what performance improvements we get. Taken from github master changes Version 2.4.0 New features, "20 bytes per packet for AES-128-GCM instead of 36 bytes per packet for AES-128-CBC + HMAC-SHA1."

For a low-powered router I wouldn't expect a big change, since the bottleneck is mostly at the CPU level. For an Intel box however, this might provide an interesting performance boost, where your bottleneck is the available bandwidth.

 

[sfx2000]

OpenVPN 2.4 with AEAD (GCM) support is scheduled for release end of the month. I'll be interested to see what performance improvements we get. Taken from github master changes Version 2.4.0 New features, "20 bytes per packet for AES-128-GCM instead of 36 bytes per packet for AES-128-CBC + HMAC-SHA1."

AES-128-GCM is still fairly new - might be a while before we see widespread support for it with commercial providers, but it does perform well when deployed on both ends of the connection.

But as RMerlin mentions - CPU horsepower and memory bandwidth are the bottlenecks with oVPN... but even there, the future does look better as the oVPN team has tried to improve performance there (while still keeping portability as a priority)