1 2 Previous Next 14 Replies Latest reply on Jan 31, 2012 10:19 PM by gardenhead_rules

    ALL:!ADH:+RC4:@STRENGTH

      Can anyone explain what this entry in Cipher Suite list means? I am trying to test a reverse proxy scenario on a win xp system with IE7. My setup works on mozilla firefox and IE8 on Win7 machine.

      It seems that the IE7 is sending a list of Cipher suites that is incompatible with Web gateway. Can anyone comment if Cipher suite incompatibility is actually the case. Additionally none of the Cipher suites from IE7 support AES encryption.

       

      I am attaching TCP dump from IE7. The client IP is 10.6.11.141

        • 1. Re: ALL:!ADH:+RC4:@STRENGTH
          asabban

          Hello,

           

          I think the cipher list is explained here:

           

          http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT

           

          I just had a quick look but from what I understand

           

          ALL:!ADH:+RC4:@STRENGTH

           

          should be read similar to:

           

          - Allow all cipher suites (except enull ciphers, which do not offer encryption)

          - Do not allow ADH (caused by the exclamation mark)

          - Move RC4 to the end of the list of ciphers, e.g. use them as the last option

          - Sort the list of ciphers by their strength

           

          From the packet capture I do not really see a cipher incompatibility. All I can see is that IE tries to setup an SSL connection and MWG denies access by sending a block page back:

           

                Your requested URL has been blocked by the McAfee Web Gateway URL Filter database

                module. The URL is listed in categories that are not allowed by your administrator

                at this time.

           

          I would expect an SSL Alert if there was a cipher incompatibility, but I have to check. Do you maybe have a working tcpdump from your IE8/Firefox environment for comparison?

           

          Best,

          Andre

           

          Nachricht geändert durch asabban on 24.01.12 10:13:49 CST
          • 2. Re: ALL:!ADH:+RC4:@STRENGTH

            Hi Andre,

             

            Attached the packet capture for mozilla, you can use the following query on this TCP Dump: ip.src==10.6.11.141 or ip.dst==10.6.11.141

             

            You can see that the client hello in mozilla has proper server name. Whereas Web gateway is unable to receive any server name from IE7 on Winxp. Are there any browser compatibility issues for Reverse proxy?

             

            Regards,

            Ankit

            • 3. Re: ALL:!ADH:+RC4:@STRENGTH
              asabban

              Hi Ankit,

               

              thank you for the data. The server name is transferred as an TLS extension called "Server Name Indication". This is used to tell Web Gateway the requested server name during the SSL handshake. This is not supported by IE 7, so MWG only knows the IP address of the destination server. I think that you maybe have a rule that looks for the URL and blocks access if the URL does match. Since MWG does not know the server name (as it is not sent by IE 7), the block action is triggered and blocks the request.

               

              You can read more about this at

               

              http://en.wikipedia.org/wiki/Server_Name_Indication

               

              It points out that Internet Explorer on Windows XP is not capable of sending the SNI extension.

               

              Maybe you will be able to access if you also allow the IP address of the server, instead of the URL only. I can´t tell exactly since I do not know the policy. You need to allow access to the destination IP for the Internet Explorer on XP users.

               

              I hope this helps,

              Andre

              • 4. Re: ALL:!ADH:+RC4:@STRENGTH

                Hi Andre,

                 

                The answer was very helpful, but it points a major inadequacy in Web Gateway 7. A reverse proxy should be able to host a number of webservers; and the appliance can't predict the the server name the client wants to connect to, unless client specifies it. As SNI feature is unavailable in Win XP, clients will never mention the server name, and server will be confused about the certificate to send.

                Also since the DNS entries point to Web Gateway's IP instead of web server's, the purpose is still unserved, as Win xp client is effectively sending a CONNECT https://webgateway's_IP_address

                In short, a large win xp user base will be deprived of the Reverse Proxy if we go ahead implementing Reverse proxy in its present state. Is McAfee planning any workaround to circumvent this issue, or Is there any OS identifier info, we could use in order to bypass XP users from using Reverse proxy. i.e.: If User's OS == win xp then Don't use Reverse proxy.

                 

                Regards,

                Ankit

                • 5. Re: ALL:!ADH:+RC4:@STRENGTH
                  jschnell

                  Ankit,

                   

                  did 'I understand you correctly that you want to have one MWG as reverse proxy for different sides? And you modified the DNS entry to point to MWG?

                   

                  Thanks

                  Jan

                  • 6. Re: ALL:!ADH:+RC4:@STRENGTH
                    jschnell

                    Ok, read it again and my assumptions seem to be correct! Is this possible for you to change the DNS entries to point to different IP addresses that  are all hold by MWG?

                     

                    If a client does not send the SNI, then the proxy uses it's *own* IP in the mapping process for the certificate. So you can define in the ssl client context without ca:

                     

                    Server   - Certificte - Comment

                    mydomain.com - cert1 - client sends SNI

                    myotherdomain.com - cert2 - client sends SNI

                    10.20.30.40 - cert1 - client does not send SNI

                    10.20.30.41 - cert2 - client does not send SNI

                     

                    and DNS:

                     

                    mydomain.com -> 10.20.30.40

                    myotherdomain.com -> 10.20.30.41

                     

                    Bye

                    Jan

                    • 7. Re: ALL:!ADH:+RC4:@STRENGTH

                      Can't open the attachment.

                      • 8. Re: ALL:!ADH:+RC4:@STRENGTH

                        Hi Tyomni,

                         

                        You guessed the setup correctly. I already implemented the solution you have suggested. It works, but it won't be helpful as I have to route a large number of internal websites through reverse proxy. Therefore my web-server hosting ability of Webwasher will be limited to the number of LAN interfaces my appliance has. Also, which attachment are you unable to open?

                         

                        Andre/Tyomini: I am going to try configure my appliance in transparent bridge instead of explicit proxy mode as it is now. Do you have any ideas, if it could leverage the Reverse proxy feature to serve my Win XP users.

                        • 9. Re: ALL:!ADH:+RC4:@STRENGTH
                          asabban

                          Hello,

                           

                          you are not limited to the number of LAN interfaces. You can add alias IP addresses for each interface, e.g. eth0 can hold 192.168.1.1, 192.168.1.2, ..., 192.168.1.10. Doing so you can host 10 virtual hosts by IP, you don´t need 10 LAN interfaces. You can use more than 10 IP addresses, of course.

                           

                          I never set up a transparent bridge reverse proxy so far, so I can´t really tell if that is working fine but I believe it could. MWG sees the original Web Server IP address in the request from the client, and should be able to obtain the host name by talking to the IP address, obtain the certificate and use the CN of the certificate for the host name decision. You may need "transparent common name handling" enabled on MWG.

                           

                          As mentioned I don´t know, it´s just how I would expect it to work.

                           

                          Best,

                          Andre

                          1 of 1 people found this helpful
                          1 2 Previous Next