ASA cipher issues, take two

[sebastian.moeller]

Hi David,

happy user of openconect under macosx here. Recently I ran into issues with a recently updated ASA. DTLS kept on dropping (and until the first message of the fall back to https the vpn did not work at all) This sounds very similar to theissue tackeld in one of the recent commits. Only in my case the solution was to fix my version of openssl. Version 1.0.0.d has a known issue with a timer that seemed to have caused the problem in my case.

At least using the following:
--- ssl/d1_clnt.c	27 Aug 2010 12:10:11 -0000	1.16.2.15.2.3
+++ ssl/d1_clnt.c	27 Apr 2011 12:27:50 -0000
@@ -407,7 +407,8 @@
 
 		case SSL3_ST_CW_CHANGE_A:
 		case SSL3_ST_CW_CHANGE_B:
-			dtls1_start_timer(s);
+			if (!s->hit)
+				dtls1_start_timer(s);
 			ret=dtls1_send_change_cipher_spec(s,
 				SSL3_ST_CW_CHANGE_A,SSL3_ST_CW_CHANGE_B);
 			if (ret <= 0) goto end;
@@ -442,7 +443,8 @@
 
 		case SSL3_ST_CW_FINISHED_A:
 		case SSL3_ST_CW_FINISHED_B:
-			dtls1_start_timer(s);
+			if (!s->hit)
+				dtls1_start_timer(s);
 			ret=dtls1_send_finished(s,
 				SSL3_ST_CW_FINISHED_A,SSL3_ST_CW_FINISHED_B,
 				s->method->ssl3_enc->client_finished_label,

from the patch cue for openssl1.0.0.e fixed the issue for me. I would not be amazes if I would be completely off track here, as I am no expert in these matters. But I have a hunch that the patch wih the following commit message:
> author	David Woodhouse <David.Woodhouse at intel.com>	
> Thu, 8 Sep 2011 13:05:46 +0000 (14:05 +0100)
> committer	David Woodhouse <David.Woodhouse at intel.com>	
> Thu, 8 Sep 2011 13:13:22 +0000 (14:13 +0100)
> commit	9785d0c0475c6d185c15bb0d63d170cb3c4581d9
> tree	3017cd5bce4a77cd37e68e60e3f57e31e47c9f8b	tree | snapshot
> parent	8c2796ad32618bbf78a82ce9a1deecf6fedded09

> Fix DTLS compatibility with ASA firmware 8.4.1(11) and above.
> 
> It seems to get very upset when we resend our ChangeCipherSpec messages,
> as the RFC says we're supposed to do. Without a periodic resend, if the
> original did get lost in transit, the server wouldn't be able to decrypt
> any of our data packets.
> 
> Perhaps there's something "wrong" with our packets; the ChangeCipherSpec
> messages is is one of the areas in which Cisco's "speshul" version of
> DTLS differs from RFC4347. But the Cisco client doesn't seem to resend it
> at all, ever. Making it hard to tell what Cisco want it to look like,
> unless we wanted to reverse-engineer their code. Which we don't.
> 
> If Cisco get away without resending, I suppose we can, until/unless we
> work it out. DPD should mostly let us get away with it, because if the
> first packet *does* get lost, DPD will soon tell us that the DTLS
> connection is dead and we'll make a new one. Sucks, but that's what you
> get for using crappy not-quite-RFC-compliant kit. Yay Cisco. Why not join
> us in 2006 and start using the proper standard? It's not even as if it'd
> be hard to support both in parallel for a while.
> 
> Thanks to Eric Barkie for the initial diagnosis.
> 
> Signed-off-by: David Woodhouse <David.Woodhouse at intel.com>
> 

might be obsolete once openssl is fixed upstream.


best
	Sebastian