Opened 10 years ago

Closed 10 years ago

#524 closed Bug / Defect (fixed)

OpenVPN with PolarSSL: segmentation fault

Reported by: amqamq Owned by:
Priority: major Milestone: release 2.4
Component: Generic / unclassified Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Steffan Karger

Description

Hello, I am running OpenVPN on OpenWRT and there seems to be some problem after the latest PolarSSL version (1.3.10):

Thu Mar  5 08:43:54 2015 OpenVPN 2.3.6 mips-openwrt-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Mar  4 2015
Thu Mar  5 08:43:54 2015 library versions: PolarSSL 1.3.10, LZO 2.08
Thu Mar  5 08:43:54 2015 WARNING: file '/etc/openvpn/pass.txt' is group or others accessible
Thu Mar  5 08:43:54 2015 Socket Buffers: R=[393216->131072] S=[393216->131072]
Thu Mar  5 08:43:54 2015 UDPv4 link local: [undef]
Thu Mar  5 08:43:54 2015 UDPv4 link remote: [AF_INET]109.201.154.193:1194
Thu Mar  5 08:43:54 2015 TLS: Initial packet from [AF_INET]censored:1194, sid=e4c3a780 c84ea8d5
Thu Mar  5 08:43:54 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Segmentation fault

Everything worked with:

Thu Mar  5 08:32:07 2015 OpenVPN 2.3.6 mips-openwrt-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jan 22 2015
Thu Mar  5 08:32:07 2015 library versions: PolarSSL 1.3.9, LZO 2.08

I have also posted a bug report on dev.openwrt.org: ​https://dev.openwrt.org/ticket/19101

Change History (12)

comment:1 Changed 10 years ago by alexander.haensch

I have the same problem on android and ios if the key is 4096bit and password encrypted.

You can use a key without password i guess?

comment:2 Changed 10 years ago by martin.blumenstingl

It seems that this is a bug in PolarSSL (nowadays called mbed TLS) for which I wrote a patch (which is still waiting to be reviewed by the developers):
​https://github.com/ARMmbed/mbedtls/pull/185

comment:3 Changed 10 years ago by amqamq

No more segfaults after applying the patch, but I still couldn't get OpenVPN to complete the initialization sequence.

Sun Apr  5 22:31:59 2015 us=615834 OpenVPN 2.3.6 mips-openwrt-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Apr  5 2015
Sun Apr  5 22:31:59 2015 us=616940 library versions: PolarSSL 1.3.10, LZO 2.08
Sun Apr  5 22:31:59 2015 us=618112 WARNING: file 'auth' is group or others accessible
Sun Apr  5 22:31:59 2015 us=621099 LZO compression initialized
Sun Apr  5 22:31:59 2015 us=623368 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Apr  5 22:31:59 2015 us=624543 Socket Buffers: R=[163840->131072] S=[163840->131072]
Sun Apr  5 22:31:59 2015 us=641174 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sun Apr  5 22:31:59 2015 us=641459 UDPv4 link local: [undef]
Sun Apr  5 22:31:59 2015 us=641677 UDPv4 link remote: [AF_INET]x.x.x.x:1194
Sun Apr  5 22:31:59 2015 us=642060 UDPv4 WRITE [14] to [AF_INET]x.x.x.x:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Sun Apr  5 22:31:59 2015 us=676874 UDPv4 READ [26] from [AF_INET]x.x.x.x:1194: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Sun Apr  5 22:31:59 2015 us=677221 TLS: Initial packet from [AF_INET]x.x.x.x:1194, sid=c85a6fed f8bb3eb7
Sun Apr  5 22:31:59 2015 us=677568 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 0 ]
Sun Apr  5 22:31:59 2015 us=678022 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Apr  5 22:31:59 2015 us=678443 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=100
Sun Apr  5 22:31:59 2015 us=678971 UDPv4 WRITE [36] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=22
Sun Apr  5 22:31:59 2015 us=714841 UDPv4 READ [22] from [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 1 ]
Sun Apr  5 22:31:59 2015 us=721763 UDPv4 READ [126] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ 2 ] pid=1 DATA len=100
Sun Apr  5 22:31:59 2015 us=722375 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 1 ]
Sun Apr  5 22:31:59 2015 us=722950 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=100
Sun Apr  5 22:31:59 2015 us=723356 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 2 ]
Sun Apr  5 22:31:59 2015 us=723883 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=100
Sun Apr  5 22:31:59 2015 us=724293 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 3 ]
Sun Apr  5 22:31:59 2015 us=724821 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=100
Sun Apr  5 22:31:59 2015 us=725226 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 4 ]
Sun Apr  5 22:31:59 2015 us=756590 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=100
Sun Apr  5 22:31:59 2015 us=757044 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 5 ]
Sun Apr  5 22:31:59 2015 us=757745 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=6 DATA len=100
Sun Apr  5 22:31:59 2015 us=758278 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 6 ]
Sun Apr  5 22:31:59 2015 us=758837 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Sun Apr  5 22:31:59 2015 us=759389 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 7 ]
Sun Apr  5 22:31:59 2015 us=759942 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sun Apr  5 22:31:59 2015 us=760348 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 8 ]
Sun Apr  5 22:31:59 2015 us=791491 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=100
Sun Apr  5 22:31:59 2015 us=791960 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 9 ]
Sun Apr  5 22:31:59 2015 us=792625 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=10 DATA len=100
Sun Apr  5 22:31:59 2015 us=793034 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 10 ]
Sun Apr  5 22:31:59 2015 us=794330 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=11 DATA len=100
Sun Apr  5 22:31:59 2015 us=795045 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 11 ]
Sun Apr  5 22:31:59 2015 us=795599 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=12 DATA len=100
Sun Apr  5 22:31:59 2015 us=796004 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 12 ]
Sun Apr  5 22:31:59 2015 us=826407 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=13 DATA len=100
Sun Apr  5 22:31:59 2015 us=826878 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 13 ]
Sun Apr  5 22:31:59 2015 us=827543 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=14 DATA len=100
Sun Apr  5 22:31:59 2015 us=827955 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 14 ]
Sun Apr  5 22:31:59 2015 us=829417 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=15 DATA len=100
Sun Apr  5 22:31:59 2015 us=829887 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 15 ]
Sun Apr  5 22:31:59 2015 us=830578 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=16 DATA len=100
Sun Apr  5 22:31:59 2015 us=841811 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 16 ]
Sun Apr  5 22:31:59 2015 us=861248 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=17 DATA len=100
Sun Apr  5 22:31:59 2015 us=861707 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 17 ]
Sun Apr  5 22:31:59 2015 us=862359 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=18 DATA len=100
Sun Apr  5 22:31:59 2015 us=862771 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 18 ]
Sun Apr  5 22:31:59 2015 us=864334 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=19 DATA len=100
Sun Apr  5 22:31:59 2015 us=864797 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 19 ]
Sun Apr  5 22:31:59 2015 us=876607 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=20 DATA len=100
Sun Apr  5 22:31:59 2015 us=877074 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 20 ]
Sun Apr  5 22:31:59 2015 us=896229 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=21 DATA len=100
Sun Apr  5 22:31:59 2015 us=896693 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 21 ]
Sun Apr  5 22:31:59 2015 us=897348 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=22 DATA len=100
Sun Apr  5 22:31:59 2015 us=897758 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 22 ]
Sun Apr  5 22:31:59 2015 us=899183 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=23 DATA len=100
Sun Apr  5 22:31:59 2015 us=899649 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 23 ]
Sun Apr  5 22:31:59 2015 us=914871 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=24 DATA len=100
Sun Apr  5 22:31:59 2015 us=933321 CRL CHECK OK: C=US, ST=OH, L=Columbus, O=XYZ, CN=XYZ CA, emailAddress=secure@xyz.com
Sun Apr  5 22:31:59 2015 us=934323 VERIFY OK: depth=1, C=US, ST=OH, L=Columbus, O=XYZ, CN=XYZ CA, emailAddress=secure@xyz.com
Sun Apr  5 22:31:59 2015 us=936774 Validating certificate key usage
Sun Apr  5 22:31:59 2015 us=937501 ++ Certificate has key usage  00a0, expects 00a0
Sun Apr  5 22:31:59 2015 us=938326 VERIFY KU OK
Sun Apr  5 22:31:59 2015 us=938996 Validating certificate extended key usage
Sun Apr  5 22:31:59 2015 us=939897 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun Apr  5 22:31:59 2015 us=940790 VERIFY EKU OK
Sun Apr  5 22:31:59 2015 us=952138 CRL CHECK OK: C=US, ST=CA, L=LosAngeles, O=XYZ, OU=XYZ, CN=XYZ, ??=XYZ, emailAddress=secure@xyz.com
Sun Apr  5 22:31:59 2015 us=952946 VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=XYZ, OU=XYZ, CN=XYZ, ??=XYZ, emailAddress=secure@xyz.com
Sun Apr  5 22:31:59 2015 us=954047 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 24 ]
Sun Apr  5 22:31:59 2015 us=955300 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=25 DATA len=100
Sun Apr  5 22:31:59 2015 us=956404 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 25 ]
Sun Apr  5 22:31:59 2015 us=957756 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=26 DATA len=100
Sun Apr  5 22:31:59 2015 us=958736 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 26 ]
Sun Apr  5 22:31:59 2015 us=960085 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=27 DATA len=100
Sun Apr  5 22:31:59 2015 us=961073 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 27 ]
Sun Apr  5 22:31:59 2015 us=988929 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=28 DATA len=100
Sun Apr  5 22:31:59 2015 us=989383 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 28 ]
Sun Apr  5 22:31:59 2015 us=991404 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=29 DATA len=100
Sun Apr  5 22:31:59 2015 us=991866 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 29 ]
Sun Apr  5 22:31:59 2015 us=993719 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=30 DATA len=100
Sun Apr  5 22:31:59 2015 us=994187 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 30 ]
Sun Apr  5 22:31:59 2015 us=995517 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=31 DATA len=100
Sun Apr  5 22:31:59 2015 us=995976 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 31 ]
Sun Apr  5 22:32:00 2015 us=24004 UDPv4 READ [60] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=32 DATA len=46
Sun Apr  5 22:32:01 2015 us=208106 UDPv4 WRITE [126] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ 32 ] pid=3 DATA len=100
Sun Apr  5 22:32:01 2015 us=209348 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=100
Sun Apr  5 22:32:01 2015 us=210435 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=100
Sun Apr  5 22:32:01 2015 us=211827 UDPv4 WRITE [40] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=6 DATA len=26
Sun Apr  5 22:32:01 2015 us=242928 UDPv4 READ [22] from [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 3 ]
Sun Apr  5 22:32:01 2015 us=244461 UDPv4 READ [22] from [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 4 ]
Sun Apr  5 22:32:01 2015 us=251957 UDPv4 READ [22] from [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 5 ]
Sun Apr  5 22:32:01 2015 us=252430 UDPv4 READ [126] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ 6 ] pid=33 DATA len=100
Sun Apr  5 22:32:01 2015 us=252807 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 33 ]
Sun Apr  5 22:32:01 2015 us=253349 UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=34 DATA len=100
Sun Apr  5 22:32:01 2015 us=254227 UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 34 ]
Sun Apr  5 22:32:01 2015 us=255024 UDPv4 READ [48] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=35 DATA len=34
Sun Apr  5 22:32:01 2015 us=255822 UDPv4 WRITE [126] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ 35 ] pid=7 DATA len=100
Sun Apr  5 22:32:01 2015 us=256389 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sun Apr  5 22:32:01 2015 us=256923 UDPv4 WRITE [80] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=66
Sun Apr  5 22:32:03 2015 us=593972 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Sun Apr  5 22:32:04 2015 us=762854 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sun Apr  5 22:32:05 2015 us=931098 UDPv4 WRITE [80] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=66
Sun Apr  5 22:32:07 2015 us=100045 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Sun Apr  5 22:32:08 2015 us=268908 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sun Apr  5 22:32:09 2015 us=437800 UDPv4 WRITE [80] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=66
Sun Apr  5 22:32:15 2015 us=684259 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Sun Apr  5 22:32:16 2015 us=725993 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sun Apr  5 22:32:17 2015 us=767725 UDPv4 WRITE [80] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=66
Sun Apr  5 22:32:31 2015 us=416839 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Sun Apr  5 22:32:32 2015 us=434559 UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sun Apr  5 22:32:33 2015 us=452261 UDPv4 WRITE [80] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=66
Sun Apr  5 22:32:59 2015 us=523636 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Apr  5 22:32:59 2015 us=523875 TLS Error: TLS handshake failed
Sun Apr  5 22:32:59 2015 us=526016 TCP/UDP: Closing socket
Sun Apr  5 22:32:59 2015 us=526382 SIGUSR1[soft,tls-error] received, process restarting
Sun Apr  5 22:32:59 2015 us=526558 Restart pause, 2 second(s)

Config:

client
dev tun
proto udp
remote ip 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
tls-client
remote-cert-tls server
auth-user-pass auth
comp-lzo
verb 7
reneg-sec 0
crl-verify crl.pem

(works with OpenVPN 2.3.6 + PolarSSL 1.3.9)

comment:4 Changed 10 years ago by Gert Döring

Cc: Steffan Karger added

Steffan, anything we can do here? Or is this purely PolarSSL land?

comment:5 Changed 10 years ago by Steffan Karger

I can confirm what is reported above. This seems to have to do with 1/n-1 splitting, which is a counter measure to the BEAST attack. However, BEAST requires that the attacker can change the TLS record data and that does not apply to OpenVPN. Disabling record splitting should be a fine temporary fix. I just tried that, but connection establishment still failed. So I'll have to dig deeper, but I'm out of time for now.

comment:6 Changed 10 years ago by amqamq

This worked for me:

--- a/include/polarssl/config.h
+++ b/include/polarssl/config.h
@@ -953,7 +953,7 @@
  *
  * Comment this macro to disable 1/n-1 record splitting.
  */
-#define POLARSSL_SSL_CBC_RECORD_SPLITTING
+//#define POLARSSL_SSL_CBC_RECORD_SPLITTING
 
 /**
  * \def POLARSSL_SSL_DISABLE_RENEGOTIATION

comment:7 Changed 10 years ago by Steffan Karger

Yes, I went for runtime limiting at first, then tried that too. It turned out I screwed up something different in ssl_polarssl.c...

Currently, I use the following to resolve it in OpenVPN:

--- a/src/openvpn/ssl_polarssl.c
+++ b/src/openvpn/ssl_polarssl.c
@@ -727,6 +727,11 @@ void key_state_ssl_init(struct key_state_ssl *ks_ssl,
       if (ssl_ctx->allowed_ciphers)
 	ssl_set_ciphersuites (ks_ssl->ctx, ssl_ctx->allowed_ciphers);
 
+      /* Disable record splitting (breaks current ssl handling) */
+#if defined(POLARSSL_SSL_CBC_RECORD_SPLITTING)
+      ssl_set_cbc_record_splitting (ks_ssl->ctx, SSL_CBC_RECORD_SPLITTING_DISABLED);
+#endif /* POLARSSL_SSL_CBC_RECORD_SPLITTING */
+
       /* Initialise authentication information */
       if (is_server)
 	polar_ok(ssl_set_dh_param_ctx(ks_ssl->ctx, ssl_ctx->dhm_ctx));

I'll dive in further later on to figure out what exactly is the difference in polarssl/mbedtls that changed the visible behaviour for us, and how to resolve it.

comment:8 Changed 10 years ago by Steffan Karger

The polarssl/mbedtls developers have fixed the segfault on their development branch:
​https://github.com/ARMmbed/mbedtls/commit/a2fce21

The remaining connection issues are basically OpenVPN's problem. OpenVPN assumes that its control channel messages are sent and received unfragmented, which is actually not conforming to the TLS spec. See RFC5246, section 6.2.1:

Client message boundaries are not preserved in the record layer (i.e.,
multiple client messages of the same ContentType? MAY be coalesced
into a single TLSPlaintext record, or a single message MAY be
fragmented across several records).

In practice, this assumption only becomes invalid if 1/n-1 record splitting is enabled.

The quick fix is to disable 1/n-1 record splitting. That should be fine for openvpn. Record splitting is a counter measure against the BEAST attack, which requires an attacker to influence the data in the records to obtain other data in the same record. But unlike browsers, openvpn does not give an attacker control over the transmitted data.

Still I think the right fix is to change openvpn to be able to deal with record splitting. The down side of this approach is that it will result in more intrusive changes, and will require more extensive testing.

comment:9 Changed 10 years ago by Gert Döring

So I'd suggest:

  • turn record splitting off now, in 2.3 and master, to workaround the issue
  • in master, rework the control protocol handling (if possible) to handle fragmented control packets

comment:10 Changed 10 years ago by Steffan Karger

Yep, I also think that's the way to go. Except that 2.3 won't need it, because we don't support polarssl/mbedtls 1.3 in release/2.3, and I seriously doubt record splitting will ever be backported to polarssl 1.2.

I'll send a patch to disable record splitting to the list soon.

comment:11 Changed 10 years ago by Steffan Karger

Milestone: → release 2.4
Version: 2.3.6 → git master branch

comment:12 Changed 10 years ago by Steffan Karger

Resolution: → fixed
Status: new → closed

The quick fix (disable record splitting) has been applied to the master branch:
​https://github.com/OpenVPN/openvpn/commit/d0f26fb

This resolves the issue at hand. I created #554 to keep track of the wish to add support for record splitting.

Note: See TracTickets for help on using tickets.