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.
I believe following defect matches your symptoms. This is not fixed in ACE20 but you can disable SSL rehandshake.
|SSL rehandshake does not follow RFC 5746|
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
Do not use rehandshake.
The same defect has been carried over and got fixed in ACE30. ( CSCtq48352 )
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.
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.
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
rserver host web-web2
ip address a.b.c.e
serverfarm host FARM-web2
sticky ip-netmask 255.255.255.255 address source FARM-web2-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
policy-map multi-match L4POLICY
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.
Can you get a Tengig capture of the ACE module and replicate this
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!).
18.104.22.168 - My PC.
22.214.171.124 - The VIP.
126.96.36.199 - The rserver that was chosen in the serverfarm.
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
this should work if vip are accessible via https.
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.
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.