4 Replies Latest reply: Mar 28, 2014 7:53 AM by otruniger RSS

    known error with PHP upload function and SSL splitting?

    otruniger

      Hi,

       

      on several occations I got incidents reported when uploading files to a website over SSL when they use some PHP framework. I tried to debug this using rule tracing but there is no usable trace. When sniffing the outside SSL connection I see immediate Resets on the TCP connection probably during SSL handshake. The users receive an error message stating that the proxy could not connect to the remote server within the timeout value, but the error message occurs immediately.

       

      The upload function works fine without ssl scanning.

       

      Is this a known problem with some PHP frameworks (possible AJAX) that they would use some POST request which is not compatible with ssl scanning? Or could this be something else like a TLS version thing?

       

      Any experiences on this topic anyone?

       

      Thanks, Othmar

        • 1. Re: known error with PHP upload function and SSL splitting?
          otruniger

          Hi,

          after investing some more time on the topic I could narrow down the problem an reproduce the problem with a real website and I'm now convinced to have found a nasty bug.

           

          Please have a look at the standard ouput of tcpdump run on the external interface of the MWG. It contains the external SSL communiation for a GET request (time 09:50:43) followed by the failed POST request (time 09:50:58).

           

          09:50:43.706983 IP mwg-out.59644 > webserver.https: Flags [S], seq 1787731547, win 14600, options [mss 1460,sackOK,TS val 1201137536 ecr 0,nop,wscale 2], length 0

          09:50:43.708784 IP webserver.https > mwg-out.59644: Flags [S.], seq 973416950, ack 1787731548, win 14480, options [mss 1460,sackOK,TS val 1399280903 ecr 1201137536,nop,wscale 6], length 0

          09:50:43.708802 IP mwg-out.59644 > webserver.https: Flags [.], ack 1, win 3650, options [nop,nop,TS val 1201137536 ecr 1399280903], length 0

          09:50:43.717590 IP mwg-out.59644 > webserver.https: Flags [P.], seq 1:383, ack 1, win 3650, options [nop,nop,TS val 1201137537 ecr 1399280903], length 382

          09:50:43.719316 IP webserver.https > mwg-out.59644: Flags [.], ack 383, win 243, options [nop,nop,TS val 1399280905 ecr 1201137537], length 0

          09:50:43.719915 IP webserver.https > mwg-out.59644: Flags [P.], seq 1:151, ack 383, win 243, options [nop,nop,TS val 1399280905 ecr 1201137537], length 150

          09:50:43.719924 IP mwg-out.59644 > webserver.https: Flags [.], ack 151, win 3650, options [nop,nop,TS val 1201137537 ecr 1399280905], length 0

          09:50:43.720237 IP mwg-out.59644 > webserver.https: Flags [P.], seq 383:442, ack 151, win 3650, options [nop,nop,TS val 1201137537 ecr 1399280905], length 59

          09:50:43.720372 IP mwg-out.59644 > webserver.https: Flags [P.], seq 442:1087, ack 151, win 3650, options [nop,nop,TS val 1201137537 ecr 1399280905], length 645

          09:50:43.721813 IP webserver.https > mwg-out.59644: Flags [.], ack 1087, win 264, options [nop,nop,TS val 1399280906 ecr 1201137537], length 0

          09:50:43.742234 IP webserver.https > mwg-out.59644: Flags [P.], seq 151:3563, ack 1087, win 264, options [nop,nop,TS val 1399280911 ecr 1201137537], length 3412

          09:50:43.742248 IP mwg-out.59644 > webserver.https: Flags [.], ack 3563, win 5356, options [nop,nop,TS val 1201137540 ecr 1399280911], length 0

          09:50:45.775684 IP webserver.https > mwg-out.59644: Flags [P.], seq 3563:3600, ack 1087, win 264, options [nop,nop,TS val 1399281413 ecr 1201137540], length 37

          09:50:45.776782 IP webserver.https > mwg-out.59644: Flags [F.], seq 3600, ack 1087, win 264, options [nop,nop,TS val 1399281413 ecr 1201137540], length 0

          09:50:45.810704 IP mwg-out.59644 > webserver.https: Flags [.], ack 3601, win 5356, options [nop,nop,TS val 1201137747 ecr 1399281413], length 0

          09:50:58.281688 IP mwg-out.59644 > webserver.https: Flags [P.], seq 1087:1828, ack 3601, win 5356, options [nop,nop,TS val 1201138994 ecr 1399281413], length 741

          09:50:58.281884 IP mwg-out.59644 > webserver.https: Flags [.], seq 1828:9068, ack 3601, win 5356, options [nop,nop,TS val 1201138994 ecr 1399281413], length 7240

          09:50:58.281905 IP mwg-out.59644 > webserver.https: Flags [.], seq 9068:14860, ack 3601, win 5356, options [nop,nop,TS val 1201138994 ecr 1399281413], length 5792

          09:50:58.283766 IP webserver.https > mwg-out.59644: Flags [R], seq 973420551, win 0, length 0

          09:50:58.283783 IP webserver.https > mwg-out.59644: Flags [R], seq 973420551, win 0, length 0

          09:50:58.283786 IP webserver.https > mwg-out.59644: Flags [R], seq 973420551, win 0, length 0

          09:50:58.283788 IP webserver.https > mwg-out.59644: Flags [R], seq 973420551, win 0, length 0

          09:50:58.283790 IP webserver.https > mwg-out.59644: Flags [R], seq 973420551, win 0, length 0

           

          Obviously the webserver closes the TCP connection two seconds after delivering the GET response message, the FIN immediately acknowledged by the MTG. But the MWG does not send FIN but instead continues to send data on the half-open connection 13 seconds later. I consider this clearly as invalid connection handling. Of course the webservers sends back RST for the closed connection which results in a 502 message for the client.

           

          When disabling SSL scanner for this site all looks quite normal. The webserver again terminates the TCP session two seconds after delivering the content and the MTG immediately closes the TCP connection also from his side. Then for the POST request a new TCP connection is opened and all works fine.

           

          I have seen several cases like this for different sites, all for uploads over SSL. And I have the impression that all this worked fine on earlier releases.

          We run 7.3.2.3.0 (16052)

           

          Now, is this a known problem which got fixed in a newer release?

           

          Regards, Othmar

          • 2. Re: known error with PHP upload function and SSL splitting?
            otruniger

            Hi,

             

            I just checked with the newest 7.3 release - 7.3.2.6.0 (16970). The problem is still there.

             

            I also noticed that the basic situation is the same for GET requests but it does not get visible because the MTG just starts a new TCP connection after RST from the webserver on the old, half-closed connection. So only POST requests are affected by this bug.

             

            Regards, Othmar

            • 3. Re: known error with PHP upload function and SSL splitting?
              asabban

              Hello,

               

              I have seen a similar looking issue at a customer which is still being investigated. Did you already file a request with tech support? We need to know if you are seeing the same problem and - if so - ensure you receive a fix in time.

               

              Best,

              Andre

              • 4. Re: known error with PHP upload function and SSL splitting?
                otruniger

                Hi,

                 

                my problem is solved by version 7.3.2.7

                 

                Regards