这些天很是研究了一把NetScaler关于cipher选择的机制。通过抓包进行分析得知一个初步结论为NetScaler针对cipher选择的机制可能是匹配client hello包中的第一个cipher，也就是说按照此包中的cipher list进行顺序匹配。这样的机制很被动，因为客户端的cipher list是我们不可控的。原来以为NetScaler会根据client hello的cipher list和NetScaler所支持（相关virtual server配置的ssl cipher）cipher list进行匹配选择安全强度最高的进行加密。有图有真相：
这是client hello包中的cipher list：
下面是server hello选择的cipher list：
从上面的结论来看，好像是选择的client hello包中的第一个cipher。
为了进一步确认，我想citrix开了一个case。从case中心得出的结论是：NetScaler会根据自身支持的cipher list顺序进行匹配。case中心的答复：
During the handshake, SSL client will announce a list of supported cipher suite. NetScaler will go through the list of ciphers configured on the SSL vserver sequentially, once there is a cipher being matched, that cipher will be used. Let me provide you an example:
sh ssl cipher DEFAULT
1) Cipher Name: SSL3-RC4-MD5
Description: SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
2) Cipher Name: SSL3-RC4-SHA
Description: SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
3) Cipher Name: SSL3-DES-CBC3-SHA
Description: SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
4) Cipher Name: TLS1-AES-256-CBC-SHA
Description: TLSv1 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
If the vserver is using the cipher group DEFAULT, the NetScaler will try match the first cipher, which is SSL3-RC4-MD5. If the client supports it, this one will be used. If not, NetScaler will check the second one which is SSL3-RC4-SHA and this process continue until a cipher is matched with the client’s list. You can use the command “show ssl vserver ***” to check the order of the vserver.
而且我通过进行了测试，确认了case中心的答复无误。而后我查看了上面抓包的vserver的ssl cipher order，如下：
进一步确认了case中心的答复。只是有一点疑问，client使用的是TSL1，而server端使用的是SSL3，据case中心说TSL1和SSL3是可以兼容匹配的。
所以，有了这样的理论和实践测试证明。我们可以通过修改vserver的cipher order来解决SSL数据使用弱cipher的问题。那么cipher list的顺序是怎么确定的呢？通过反复测试得知：在建立cipher list的时候按照选择添加的顺序进行排序。这样我们就可以将高强度的cipher先添加进去，确保cipher的顺序符合我们的要求。
但是有一点需要注意：使用高强度的cipher比低强度的算法要更耗NetScaler的performance一些。
本文转自 chris_lee 51CTO博客，原文链接：http://blog.51cto.com/ipneter/204734，如需转载请自行联系原作者
