ACE20 and TLSv1.0 extensions problem

[ciscocsoc]

Hi,

I have a problem with an ACE20 running software version A2(2.3) [build 3.0(0)A2(2.3)].

We have a simple load-balancing arrangement for two Apache webservers. All we do is pass HTTP and HTTPS traffic through to one of two servers. we don't do SSL termination or initiation on the ACE - just passthrough.

We now have a requirement to support connections that only use TLSv1.0 with no fallback to SSLv3. If I use IE8 the connection works. If I use IE9 or FF19 then the connection fails. I've traced this to the use of TLS extensions in the ClientHello packet - which came after the TLSv1.0 RFC. IE8 doesn't send extensions whereas the other browsers do.  I can replicate the problem with the OpenSSL s_client application. What surprises me is that the ACE checks the structure of the TLS negotiation even though I'm not asking it to make decisions about it. I can see why this would be done as a security feature if the ACE implemented a strict RFC2246-compliant server - the extensions having bee added post-RFC.

Is there any way to tell the ACE to forward SSL packets and not worry too much about the contents? I've checked all the Release notes and can't find any relevant caveats.

Thank you

Cathy

[ajayku2]

Hi,

I believe following defect matches your symptoms. This is not fixed in ACE20 but you can disable SSL rehandshake.

CSCtn00305            Bug Details

SSL rehandshake does not follow RFC 5746

Symptom: ACE does not send server hello extensions for Secure Rehandshake.Conditions: The SSL proxy has the following parameter map applied.parameter-map type ssl rehand rehandshake enabledWorkaround: Do not use rehandshake.

The same defect has been carried over and got fixed in ACE30. ( CSCtq48352 )

regards,

Ajay Kumar

[ciscocsoc]

Hi Ajay,

Thank you.  I don't think that is the problem as I'm not using the SSL proxy feature - just forwarding packets to the server. As far as I can tell, the ClientHello packet never reaches the server.

Kind Regards

Cathy

[ajayku2]

Hi,

Sorry I missed that part and you are right. Just for testing can you disable Normalization and check if that fix the issue.

Also share the config.

regards,

Ajay Kumar

[ciscocsoc]

Hi Ajay,

Disabling normalization made no difference. I thought it might help, but I think it only looks at the gross structure of the packets and doesn't worry about RFC2246 compliance.

The relevant parts of the configuration are shown below:

rserver host web-web1

  ip address a.b.c.d

  inservice

rserver host web-web2

  ip address a.b.c.e

  inservice

serverfarm host FARM-web2

  rserver web-web1

    inservice

  rserver web-web2

    inservice

sticky ip-netmask 255.255.255.255 address source FARM-web2-Sticky

  timeout 99

  replicate sticky

  serverfarm FARM-web2 backup FARM-sorry

class-map match-any L4VIPCLASS

  2 match virtual-address x.y.z.t tcp eq www

  3 match virtual-address x.y.z.t tcp eq https

  6 match virtual-address x.y.z.t tcp eq 81

policy-map type loadbalance first-match LB-POLICY

  class class-default

    sticky-serverfarm FARM-web2-Sticky

policy-map multi-match L4POLICY

  class L4VIPCLASS

    loadbalance vip inservice

    loadbalance policy LB-POLICY

    loadbalance vip icmp-reply active

    loadbalance vip advertise

service-policy input L4POLICY

As you see, the configuration is about as simple as it can be.

Kind Regards

Cathy

[Cesar Roque]

Hi Cathy,

Can you get a Tengig capture of the ACE module and replicate this

---------------------
Cesar R
ANS Team

[ciscocsoc]

Hi Cesar,

I didn't get a 10Gig capture - but I did a cpature from the context on both interfaces. I hope that is sufficient. There is a bit of chaff at the start of CAP-SSLv3.pcap when I fumbled the URL (htttps - Doh!).

IP Addresses:

128.243.101.53 - My PC.

128.243.80.167 - The VIP.

128.243.80.182 - The rserver that was chosen in the serverfarm.

Kind Regards

Cathy

[Jorge Bejarano]

Cathy,

You took the capture from the ACE itself?

I agree with César it would have been better with a TenGig capture instead.

Jorge

[ciscocsoc]

Hi Jorge, César,

I've attached a capture of an attempted TLSv1-only session from the ACE 10Gig interface as requested.

Thank you

Cathy

[samir ahmed]

Hi Cathy,

You must be use action-list type modify command to achive the desired Result.

action-list type modify http Rewrite_Redirects

    ssl url rewrite location ".*"

policy-map type loadbalance first-match bsm-ssl-back

  class class-default

    serverfarm

    action Rewrite_Redirects

this should work if vip are accessible via https.

[ciscocsoc]

Thanks for looking at this.

I can' t see why this would work. I'm not doing SSL termination and we are failing in the SSL handshake before we even start to worry about web traffic. There isn't a redirection that we need to rewrite as far as I can see. Maybe I'm being a bit dense here - could you clarify why the change should work.

Thank you

Cathy

[ajayku2]

Hi Cathy,

If you look at the packet capture I see that the server is not replying with server certificate instead it is sending FIN

Look at the screenshot:

That is what ACE forward to client. To me it looks like server does not support TLS.

Also look at the below screenshot it shows ACE forward the communication properly to server.

regards,

Ajay Kumar

[ciscocsoc]

Hi Ajay,

Odd. This is now starting to look like a server-side issue. I'll investigate further at this end.

Thank you

Cathy