Bug #2258

engine padlock broken in openssl on current master

Added by lentferj about 3 years ago. Updated almost 3 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:-
Target version:-

Description

After Upgrading to v2.13.0.527.g95bf5 openvpn does not work any more
with "engine padlock" enabled in server.conf.

Seems engine padlock in openssl is broken. If I comment out "engine
padlock" from server.conf, handshake works fine.

I X-ed out private info in the certificates.

Dec 11 21:38:10 epia openvpn[99939]: MULTI: multi_create_instance called
Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Re-using
SSL/TLS context
Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 LZO compression
initialized
Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Control Channel
MTU parms [ L:1562 D:138 EF:38 EB:0 ET:0 EL:0 ]
Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Data Channel
MTU parms [ L:1562 D:1300 EF:62 EB:135 ET:0 EL:0 AF:3/1 ]
Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Fragmentation
MTU parms [ L:1562 D:1300 EF:61 EB:135 ET:1 EL:0 AF:3/1 ]
Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Local Options
String: 'V4,dev-type tun,link-mtu 1562,tun-mtu 1500,proto
UDPv4,comp-lzo,mtu-dynamic,cipher AES-128-CBC,auth SHA1,keysize
128,key-method 2,tls-server'
Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Expected Remote
Options String: 'V4,dev-type tun,link-mtu 1562,tun-mtu 1500,proto
UDPv4,comp-lzo,mtu-dynamic,cipher AES-128-CBC,auth SHA1,keysize
128,key-method 2,tls-client'
Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Local Options
hash (VER=V4): 'e11a9f86'
Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Expected Remote
Options hash (VER=V4): '0c7fabe0'
Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 TLS: Initial
packet from 85.214.83.243:38599, sid=caa12d6f 165ba8e5
Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599 VERIFY OK:
depth=1, /C=XX/ST=XXXXX/L=XXXXX/O=XXXXXXXXXXXXXXXXX
Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599 VERIFY OK:
depth=0,
/C=XX/ST=XXXXX/L=XXXX/O=XXXXXXXXXXXXXXXXXXXX/CN=XXXXX/emailAddress=XXXXXXXXXXXX
Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599 TLS_ERROR: BIO
read tls_read_plaintext error: error:1408F119:SSL
routines:SSL3_GET_RECORD:decryption failed or bad record mac
Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599 TLS Error: TLS
object -> incoming plaintext read error
Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599 TLS Error: TLS
handshake failed
Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599
SIGUSR1[soft,tls-error] received, client-instance restarting

History

#1 Updated by alexh about 3 years ago

Try running some standalone tests with openssl itself, and also try
loading or unloading padlock.ko (depending on whether you've loaded it
now or not).

Cheers,
Alex

On 11/12/11 20:45, Jan Lentfer via Redmine wrote:
>
> Issue #2258 has been reported by Jan Lentfer.
>
> ----------------------------------------
> Bug #2258: engine padlock broken in openssl on current master
> http://bugs.dragonflybsd.org/issues/2258
>
> Author: Jan Lentfer
> Status: New
> Priority: Normal
> Assignee:
> Category:
> Target version:
>
>
> After Upgrading to v2.13.0.527.g95bf5 openvpn does not work any more
> with "engine padlock" enabled in server.conf.
>
> Seems engine padlock in openssl is broken. If I comment out "engine
> padlock" from server.conf, handshake works fine.
>
> I X-ed out private info in the certificates.
>
>
>
> Dec 11 21:38:10 epia openvpn[99939]: MULTI: multi_create_instance called
> Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Re-using
> SSL/TLS context
> Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 LZO compression
> initialized
> Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Control Channel
> MTU parms [ L:1562 D:138 EF:38 EB:0 ET:0 EL:0 ]
> Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Data Channel
> MTU parms [ L:1562 D:1300 EF:62 EB:135 ET:0 EL:0 AF:3/1 ]
> Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Fragmentation
> MTU parms [ L:1562 D:1300 EF:61 EB:135 ET:1 EL:0 AF:3/1 ]
> Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Local Options
> String: 'V4,dev-type tun,link-mtu 1562,tun-mtu 1500,proto
> UDPv4,comp-lzo,mtu-dynamic,cipher AES-128-CBC,auth SHA1,keysize
> 128,key-method 2,tls-server'
> Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Expected Remote
> Options String: 'V4,dev-type tun,link-mtu 1562,tun-mtu 1500,proto
> UDPv4,comp-lzo,mtu-dynamic,cipher AES-128-CBC,auth SHA1,keysize
> 128,key-method 2,tls-client'
> Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Local Options
> hash (VER=V4): 'e11a9f86'
> Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 Expected Remote
> Options hash (VER=V4): '0c7fabe0'
> Dec 11 21:38:10 epia openvpn[99939]: 85.214.83.243:38599 TLS: Initial
> packet from 85.214.83.243:38599, sid=caa12d6f 165ba8e5
> Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599 VERIFY OK:
> depth=1, /C=XX/ST=XXXXX/L=XXXXX/O=XXXXXXXXXXXXXXXXX
> Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599 VERIFY OK:
> depth=0,
> /C=XX/ST=XXXXX/L=XXXX/O=XXXXXXXXXXXXXXXXXXXX/CN=XXXXX/emailAddress=XXXXXXXXXXXX
> Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599 TLS_ERROR: BIO
> read tls_read_plaintext error: error:1408F119:SSL
> routines:SSL3_GET_RECORD:decryption failed or bad record mac
> Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599 TLS Error: TLS
> object -> incoming plaintext read error
> Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599 TLS Error: TLS
> handshake failed
> Dec 11 21:38:11 epia openvpn[99939]: 85.214.83.243:38599
> SIGUSR1[soft,tls-error] received, client-instance restarting
>
>

#2 Updated by pavalos about 3 years ago

  • Status changed from New to Feedback

Please do some tests with 'openssl speed' so we know that this isn't an openvpn issue.

#3 Updated by lentferj almost 3 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 0 to 100

yeah, seems to be an OpenVPN issue rather. Padlock works with openssl speed and clearly accelerates stuff. Also I have set "SSLCryptoDevice padlock" in my apache https configuration and that works, too.

epia# openssl speed -engine padlock -evp aes-128-cbc
engine "padlock" set.
Doing aes-128-cbc for 3s on 16 size blocks: 6674327 aes-128-cbc's in 2.21s
Doing aes-128-cbc for 3s on 64 size blocks: 5154907 aes-128-cbc's in 2.10s
Doing aes-128-cbc for 3s on 256 size blocks: 3674965 aes-128-cbc's in 2.53s
Doing aes-128-cbc for 3s on 1024 size blocks: 1357137 aes-128-cbc's in 2.55s
Doing aes-128-cbc for 3s on 8192 size blocks: 198541 aes-128-cbc's in 2.53s
OpenSSL 1.0.0f 4 Jan 2012
built on: Wed Jan 4 04:30:05 CET 2012
options:bn(64,32) rc4(4x,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx)
compiler: cc
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 48300.43k 156985.12k 371670.53k 545652.33k 642547.31k
epia# openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 1068355 aes-128-cbc's in 2.53s
Doing aes-128-cbc for 3s on 64 size blocks: 270100 aes-128-cbc's in 2.39s
Doing aes-128-cbc for 3s on 256 size blocks: 73349 aes-128-cbc's in 2.49s
Doing aes-128-cbc for 3s on 1024 size blocks: 34806 aes-128-cbc's in 2.51s
Doing aes-128-cbc for 3s on 8192 size blocks: 4303 aes-128-cbc's in 2.47s
OpenSSL 1.0.0f 4 Jan 2012
built on: Wed Jan 4 04:30:05 CET 2012
options:bn(64,32) rc4(4x,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx)
compiler: cc
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 6753.06k 7230.91k 7534.48k 14212.12k 14278.55k
epia# grep -r padlock /usr/pkg/etc/httpd/*
/usr/pkg/etc/httpd/httpd-ssl.conf:SSLCryptoDevice padlock

Also available in: Atom PDF