[ale] OpenVPN help

Sun Nov 8 01:48:05 EST 2015

I went ahead and pulled in the jessie repository so I could get a
slightly more updated openvpn version.  Wheezy's verison is 2.2.1 and
jessie has 2.3.4 which supposedly supports TLSv1.2.  However, this is
the most confusing set of status lines in the debug logs:

Sat Nov  7 22:37:55 2015 us=468563 166.170.49.17:12858 Data Channel
Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sat Nov  7 22:37:55 2015 us=469677 166.170.49.17:12858 Data Channel
Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Nov  7 22:37:55 2015 us=470868 166.170.49.17:12858 Data Channel
Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sat Nov  7 22:37:55 2015 us=471834 166.170.49.17:12858 Data Channel
Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Nov  7 22:37:55 2015 us=545726 166.170.49.17:12858 Control Channel:
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

Note the last one.  It says TLSv1.2 then immediately says TLSv1/SSLv3.
So which is it?  A dump from openssl says that the mentioned cipher is
TLSv1.2:

DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256)
Mac=AEAD

So I'm going to hope it really is TLSv1.2 and not TLSv1.

On 2015-11-07 17:55, Alex Carver wrote:
> Working on the encryption now.  It seems to be like throwing darts to
> figure out which digests and ciphers are supported.
> 
> I had to use the AES-256-CBC cipher, DHE-RSA-AES256-SHA for TLS.
> Nothing else seems to work.
> 
> I tried giving it ECDHE-RSA-AES256-GCM-SHA384 and ECDHE-RSA-AES256-SHA
> with no luck.  I get all sorts of TLS handshake errors with those:
> 
> Sat Nov  7 17:49:51 2015 us=878015 166.170.49.84:13522 TLS: Initial
> packet from [AF_INET]166.170.49.84:13522, sid=6dfb2220 b2f2f3fe
> Sat Nov  7 17:49:51 2015 us=951852 166.170.49.84:13522 TLS_ERROR: BIO
> read tls_read_plaintext error: error:1408A0C1:SSL
> routines:SSL3_GET_CLIENT_HELLO:no shared cipher
> Sat Nov  7 17:49:51 2015 us=953457 166.170.49.84:13522 TLS Error: TLS
> object -> incoming plaintext read error
> Sat Nov  7 17:49:51 2015 us=954451 166.170.49.84:13522 TLS Error: TLS
> handshake failed
> 
> 
> I can't figure out what the phone supports for ciphers or I'd use the
> highest one there.
> 
> 
> On 2015-11-07 17:36, Jim Kinney wrote:
>> You'll want to disable tls 1 (1.1 is ok) and ssl 3 (all bad). Looks
>> encrypted.
>> On Nov 7, 2015 4:44 PM, "Alex Carver" <agcarver+ale at acarver.net> wrote:
>>
>>> On 2015-11-07 12:45, Phil Turmel wrote:
>>>> On 11/07/2015 02:58 PM, dev null zero two wrote:
>>>>> did you set up routes and ip forwarding?
>>>>
>>>> You'll probably also need nat in the openvpn server for any external
>>>> traffic originating in the vpn.
>>>
>>> Ok, the NAT worked (I didn't have iptables installed at all on this
>>> particular machine).  Got that installed, masqueraded the VPN subnet
>>> over to the machine's network card and can now reach the internal traffic.
>>>
>>> Next step, trying to verify that the link is encrypted.  I've got
>>> debugging turned up a bit and am watching the logs.  When a connection
>>> is established I see the following:
>>>
>>> Sat Nov  7 16:28:28 2015 us=998372 MULTI: multi_create_instance called
>>> Sat Nov  7 16:28:29 2015 us=1250 166.170.49.84:20242 Re-using SSL/TLS
>>> context
>>> Sat Nov  7 16:28:29 2015 us=3046 166.170.49.84:20242 LZO compression
>>> initialized
>>> Sat Nov  7 16:28:29 2015 us=12627 166.170.49.84:20242 Control Channel
>>> MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
>>> Sat Nov  7 16:28:29 2015 us=15443 166.170.49.84:20242 Data Channel MTU
>>> parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
>>> Sat Nov  7 16:28:29 2015 us=17017 166.170.49.84:20242 Local Options
>>> String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto
>>> UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize
>>> 128,tls-auth,key-method 2,tls-server'
>>> Sat Nov  7 16:28:29 2015 us=21830 166.170.49.84:20242 Expected Remote
>>> Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto
>>> UDPv4,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize
>>> 128,tls-auth,key-method 2,tls-client'
>>> Sat Nov  7 16:28:29 2015 us=24194 166.170.49.84:20242 Local Options hash
>>> (VER=V4): '14168603'
>>> Sat Nov  7 16:28:29 2015 us=25583 166.170.49.84:20242 Expected Remote
>>> Options hash (VER=V4): '504e774e'
>>> Sat Nov  7 16:28:29 2015 us=27203 166.170.49.84:20242 TLS: Initial
>>> packet from [AF_INET]166.170.49.84:20242, sid=53399d05 59f52b6e
>>> Sat Nov  7 16:28:37 2015 us=252588 166.170.49.84:20242
>>> Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #3
>>> / time = (1446942506) Sat Nov  7 16:28:26 2015 ] -- see the man page
>>> entry for --no-replay and --replay-window for more info or silence this
>>> warning with --mute-replay-warnings
>>>
>>>
>>> (This last set of TLS messages gets repeated a few times.)
>>>
>>> After those get repeated I get:
>>>
>>>
>>> Sat Nov  7 16:28:47 2015 us=176814 166.170.49.84:20242 Data Channel
>>> Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
>>> Sat Nov  7 16:28:47 2015 us=178102 166.170.49.84:20242 Data Channel
>>> Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
>>> Sat Nov  7 16:28:47 2015 us=179541 166.170.49.84:20242 Data Channel
>>> Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
>>> Sat Nov  7 16:28:47 2015 us=180685 166.170.49.84:20242 Data Channel
>>> Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
>>> Sat Nov  7 16:28:47 2015 us=253723 166.170.49.84:20242 Control Channel:
>>> TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
>>> Sat Nov  7 16:28:47 2015 us=255138 166.170.49.84:20242 [vpntest2] Peer
>>> Connection Initiated with [AF_INET]166.170.49.84:20242
>>>
>>> Is it encrypted or not?
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
> 