Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed potential null dereference when record splitting is enabled. #185

Closed
wants to merge 1 commit into from
Closed

Conversation

xdarklight
Copy link

Found by some OpenWrt users that are reporting problems with OpenVPN (in client mode):
https://dev.openwrt.org/ticket/19101

@xdarklight
Copy link
Author

Any comments on this one?
Could this also be caused by a bug in the application (in this case a patched OpenVPN version)?

@mpg
Copy link
Contributor

mpg commented Apr 15, 2015

Hi, I think this is both a problem in the application and a bug in our code :)

(I was mistaken about the problem in the application. Please disregard the next paragraph, which I leave just to void breaking the replies.)
The problem in the application is that ssl_write() is called before the handshake is complete, which should not be the case. The handshake is complete only when ssl_handshake() did return 0 once. You may need to call it in a loop to obtains that result, see programs/ssl/ssl_client1.c for example. (Note that I didn't look at the application code, but that's the only explanation I can see right now for this happening.)

The bug in our code, obviously, is that we should handle that more gracefully than by segfaulting. While your patch indeed avoids the segfault, I'll probably re-arrange things a bit to solve the problem in another way.

Thanks for your report and the proposed patch (even if I'm not using it this time)!

@amq
Copy link

amq commented Apr 15, 2015

I've tried the patch and there were indeed no more segfaults, but OpenVPN still couldn't finish the initialization sequence https://community.openvpn.net/openvpn/ticket/524#comment:3

@mpg
Copy link
Contributor

mpg commented Apr 15, 2015

Please try the following: a2fce21

@amq
Copy link

amq commented Apr 18, 2015

The outcome was the same as with xdarklight's patch: TLS handshake failed.

I've used https://tls.mbed.org/download/mbedtls-1.3.10-gpl.tgz + a2fce21

Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: OpenVPN 2.3.6 mips-openwrt-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Apr 18 2015
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: library versions: PolarSSL 1.3.10, LZO 2.08
Sat Apr 18 10:03:45 2015 daemon.warn openvpn(a)[1665]: WARNING: file '/etc/openvpn/pass.txt' is group or others accessible
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: LZO compression initialized
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: Socket Buffers: R=[393216->131072] S=[393216->131072]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 link local: [undef]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 link remote: [AF_INET]x.x.x.x:1194
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [14] to [AF_INET]x.x.x.x:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: 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
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: TLS: Initial packet from [AF_INET]x.x.x.x:1194, sid=9820ed04 75bd6d6f
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 0 ]
Sat Apr 18 10:03:45 2015 daemon.warn openvpn(a)[1665]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [36] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=22
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [22] from [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 1 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [126] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ 2 ] pid=1 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 1 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 2 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 3 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 4 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 5 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=6 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 6 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 7 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 8 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 9 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=10 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 10 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=11 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 11 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=12 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 12 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=13 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 13 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=14 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 14 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=15 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 15 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=16 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 16 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=17 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 17 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=18 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 18 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=19 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 19 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=20 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 20 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=21 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 21 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=22 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 22 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=23 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 23 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=24 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: CRL CHECK OK: C=US, ST=OH, L=Columbus, O=XYZ, CN=XYZ CA, emailAddress=secure@xyz.com
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: VERIFY OK: depth=1, C=US, ST=OH, L=Columbus, O=XYZ, CN=XYZ CA, emailAddress=secure@xyz.com
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: Validating certificate key usage
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: ++ Certificate has key usage  00a0, expects 00a0
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: VERIFY KU OK
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: Validating certificate extended key usage
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: VERIFY EKU OK
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: CRL CHECK OK: C=US, ST=CA, L=LosAngeles, O=XYZ, OU=XYZ, CN=XYZ, ??=XYZ, emailAddress=secure@xyz.com
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=XYZ, OU=XYZ, CN=XYZ, ??=XYZ, emailAddress=secure@xyz.com
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 24 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=25 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 25 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=26 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 26 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=27 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 27 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=28 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 28 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=29 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 29 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=30 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 30 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=31 DATA len=100
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 31 ]
Sat Apr 18 10:03:45 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [60] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=32 DATA len=46
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [126] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ 32 ] pid=3 DATA len=100
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=100
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=100
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [40] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=6 DATA len=26
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [22] from [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 3 ]
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [22] from [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 4 ]
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [22] from [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 5 ]
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [126] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ 6 ] pid=33 DATA len=100
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 33 ]
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [114] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=34 DATA len=100
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [22] to [AF_INET]x.x.x.x:1194: P_ACK_V1 kid=0 [ 34 ]
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 READ [48] from [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=35 DATA len=34
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [126] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ 35 ] pid=7 DATA len=100
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sat Apr 18 10:03:47 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [80] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=66
Sat Apr 18 10:03:49 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Sat Apr 18 10:03:50 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sat Apr 18 10:03:51 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [80] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=66
Sat Apr 18 10:03:53 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Sat Apr 18 10:03:55 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sat Apr 18 10:03:55 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [80] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=66
Sat Apr 18 10:04:02 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Sat Apr 18 10:04:03 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sat Apr 18 10:04:04 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [80] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=66
Sat Apr 18 10:04:18 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Sat Apr 18 10:04:19 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [114] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Sat Apr 18 10:04:20 2015 daemon.notice openvpn(a)[1665]: UDPv4 WRITE [80] to [AF_INET]x.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=66
Sat Apr 18 10:04:45 2015 daemon.err openvpn(a)[1665]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Apr 18 10:04:45 2015 daemon.err openvpn(a)[1665]: TLS Error: TLS handshake failed
Sat Apr 18 10:04:45 2015 daemon.notice openvpn(a)[1665]: TCP/UDP: Closing socket

@amq
Copy link

amq commented Apr 20, 2015

There are 2 patches being applied when building OpenWRT with libpolarssl:
https://github.com/openwrt-mirror/openwrt/tree/master/package/libs/polarssl/patches

One of them disables POLARSSL_SSL_PROTO_SSL3, for example. Could this cause the issue?

@xdarklight
Copy link
Author

I can confirm @amq's findings (and sorry for the late reply).

With "record splitting" enabled all I get is TLS errors.
Disabling it (either via an API call in OpenVPN or via mbed TLS' build-time configuration) allows connecting to my OpenVPN server again.

Please let us know if you need more information.

@mpg
Copy link
Contributor

mpg commented Apr 29, 2015

The patches applied do not seem to be related to this issue at all. What I would need to get a better grasp of the issue is:

  • If you could kindly point me at the part of OpenVPN's code where the handshake happens
  • A full debug output of a failed handshake with debug level set to 4

Anyway, I'm not sure what your use case is, but disabling record splitting is not an issue if the BEAST attack is not a threat to you. By the way, which version of TLS are you using? Normally record splitting should only happen when TLS 1.0 is used...

Also, this is most probably completely unrelated but I'm just curious: you seem to be doing TLS over UDP?

@syzzer
Copy link

syzzer commented May 3, 2015

@mpg: OpenVPN does not explicitly perform the handshake. It never has since PolarSSL 0.14, and has always worked fine. Your documentation seems to imply it should not be needed. See https://tls.mbed.org/module-level-design-ssl-tls, which says:
"After initializing the SSL/TLS context, the handshake function is called to setup an SSL/TLS communication channel. If the application does not call the handshake function explicitly, it is called automatically based on state."

Currently, this only fails in OpenVPN when record splitting is being used. I.e. when a TLSv1.0 connection is set up.

(And wrt UDP: OpenVPN has its own reliability layer on top of UDP for TLS, which predates DTLS. It uses this to multiplex a TLS connection and its own datagram VPN connection over a single UDP 'connection'.)

Edit:
I forgot to point you to the relevant SSL code in OpenVPN.

The SSL context init is done in key_state_ssl_init():
https://github.com/OpenVPN/openvpn/blob/23b6ba6/src/openvpn/ssl_polarssl.c#L722

Call to ssl_write() are done from key_state_ssl_write_plaintext_const():
https://github.com/OpenVPN/openvpn/blob/23b6ba6/src/openvpn/ssl_polarssl.c#L872

(Edit: I changed openvpn to call ssl_write() from one function only, and updated the links to that commit.)

@syzzer
Copy link

syzzer commented May 3, 2015

Oh, and for the record: commit a2fce21 indeed fixes the polarssl part of this issue for me.

The other part is that openvpn assumes that its TLS payload is sent (and then received) all at once, so enabling record splitting will indeed break openvpn. Disabling record splitting is the quick fix (and should not be a problem for openvpn), but being able to deal with record splitting feels like the better solution to me. But I guess that's openvpn's problem.

@xdarklight
Copy link
Author

@syzzer: So should we simply add this to key_state_ssl_init() in OpenVPN?

#if defined(POLARSSL_SSL_CBC_RECORD_SPLITTING)
ssl_set_cbc_record_splitting( ks_ssl->ctx, 0 )
#endif

That disables record splitting for OpenVPN even though it's enabled in the config.
The only part I'm not sure about is that #if - I will test that later if required.

@syzzer
Copy link

syzzer commented May 3, 2015

@xdarklight: sort of, but '0' actually enables record splitting. Also see my comments in the ticket in the openvpn bugtracker. I posted the code that works for me:
https://community.openvpn.net/openvpn/ticket/524#comment:7

jmccrohan pushed a commit to jmccrohan/openwrt that referenced this pull request May 4, 2015
OpenVPN assumes that its control channel messages are sent and received
unfragmented, this assumption is broken when CBC record splitting is
enabled in mbedTLS.

The record splitting is intended as countermeasure against BEAST attacks
which do not apply to OpenVPN, therefore we simply disable it until
upstream OpenVPN gains the ability to process fragmented control
messages.

Disabling the splitting also works around a (not remotely triggerable)
segmentation fault in mbedTLS.

References:

 * https://dev.openwrt.org/ticket/19101
 * https://community.openvpn.net/openvpn/ticket/524
 * Mbed-TLS/mbedtls#185

Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>

git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45602 3c298f89-4303-0410-b956-a3cf2f4a3e73
@mpg
Copy link
Contributor

mpg commented May 4, 2015

@syzzer: regarding the need to call ssl_handshake(), you're right and I was mistaken. Everyone, please disregard my earlier comment about that.

Regarding the remaining issue, thanks for clarifying that the cause is OpenVPN assumes unfragmented records. I agree with you that disabling record splitting is the way to go here.

(Thanks for the explanation regarding TLS/UDP.)

@xdarklight: please always use the defined constants with ssl_set_xxx() functions :) The #if part may not be necessary if you use a know config.h file for mbed TLS, but it cannot hurt, and is useful in case someone tries to build with a different config.h.

By the way, since you're already patching config.h anyway, why not disable CBC record splitting here?

Also, I'd like to mention, just in case, that we also provide a script scripts/config.pl that allows programmatically adjusting config.h. You could use a simple script consisting of a series of invocation of scripts/config.pl instead of a patch. Depending on your workflow, that may or may not be easier to maintain than a patch.

@mpg mpg closed this May 4, 2015
yarwelp pushed a commit to unofficial-inteno-public-mirror/iopsys-cc-core that referenced this pull request May 23, 2017
OpenVPN assumes that its control channel messages are sent and received
unfragmented, this assumption is broken when CBC record splitting is
enabled in mbedTLS.

The record splitting is intended as countermeasure against BEAST attacks
which do not apply to OpenVPN, therefore we simply disable it until
upstream OpenVPN gains the ability to process fragmented control
messages.

Disabling the splitting also works around a (not remotely triggerable)
segmentation fault in mbedTLS.

References:

 * https://dev.openwrt.org/ticket/19101
 * https://community.openvpn.net/openvpn/ticket/524
 * Mbed-TLS/mbedtls#185

Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>

git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45602 3c298f89-4303-0410-b956-a3cf2f4a3e73
Patater added a commit to Patater/mbedtls that referenced this pull request Feb 10, 2020
iameli pushed a commit to livepeer/mbedtls that referenced this pull request Dec 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants