For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

raZorTT's avatar
raZorTT
Icon for Cirrostratus rankCirrostratus
Jul 08, 2016

TCP::Respond as part of HTTP CONNECT request/response

Hi all,

 

I downloaded and deployed the forward proxy iApp on my F5. After pointing my browser at the VIP I could see the requests being handled by the F5.

 

When I started to test the port restrictions, I first tried a site using http, the request was blocked and the browser received a 403 with the HTML message explaining the port was not allowed.

 

However when I tried a https site, it was blocked but the browser didn't display the user friendly error message. Instead it would report a proxy server refused connection error.

 

I jumped in and took a look at the iRule that is genereated by the iApp and noticed it detects if the HTTP method is CONNECT, and if so responds with a TCP::respond instead of HTTP::respond. From what I could see though the iRule was passing HTML content back to the browser.

 

I was wondering if the browser (Firefox in this case) should be able to receieve and render the HTML message from a TCP::respond?

 

Cheers, Simon

 

application delivery
iRules
LTM
proxy

3 Replies

  • boneyard's avatar
    boneyard
    Icon for MVP rankMVP
    Jul 12, 2016

    what exactly is send to the client? can you see that on the browser or via a capture?

     

    do you send http/https both to the same proxy port?

     

  • janholtz's avatar
    janholtz
    Icon for Altostratus rankAltostratus
    Jul 12, 2016

    Hi Simon. You should be able to craft a perfectly valid HTTP (or indeed any other TCP protocol) response with TCP:respond.

     

    Do you have some tcpdumps to stick into wireshark for us to track down the cause of the disparity?

     

  • raZorTT's avatar
    raZorTT
    Icon for Cirrostratus rankCirrostratus
    Jul 13, 2016

    Hi guys,

    boneyard, yes i'm sending both http/https to the same port.

    I created a very simple irule just for testing with the following statements.

    set html_message "Access DeniedAccess Denied"

TCP::respond "HTTP/1.1 403 Not Allowed Mime-Type: text/html\r\nCache-Control: no-cache,no-store\r\nConnection: close\r\nContent-Length: [string length $html_message]\r\n\r\n$html_message\r\n\r\n"

    I'm running wireshark on my client and the responses look the same. Both show "269 HTTP/1.1 403 Not Allowed Mime-Type: text/html" in the summary. And if I look look deeper the HTTP portion looks identical as well.

    If I attempt to access http://google.com I get the access denied message. Here is what wireshark displays if I follow the TCP stream.

    GET http://google.com/ HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 403 Not Allowed Mime-Type: text/html
Cache-Control: no-cache,no-store
Connection: close
Content-Length: 89

Access DeniedAccess Denied

    If I attempt to access https://devcentral.f5.com I get the proxy server is refusing connections message. Here is what wireshark displays if I follow the TCP stream.

    CONNECT devcentral.f5.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: devcentral.f5.com:443

HTTP/1.1 403 Not Allowed Mime-Type: text/html
Cache-Control: no-cache,no-store
Connection: close
Content-Length: 89

Access DeniedAccess Denied

    Not sure why I see different behaviour because from what I can see the response is the same.

    Appreciate any thoughts.

    Simon