Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

SSL Orchestrator between client and explicit HTTP proxy

Hi Devcentral,

I am testing SSL orchestrator with Inline mode (L2 / Trasparent) in order to inspect cleartext web browsing traffic using an IPS device, the scenario is the following:

  1. Client that points directly to F5 as a gateway
  2. Client have explicit HTTP forward proxy configured on the browser (Mozilla) for HTTP & HTTPS traffic
  3. SSLO is placed inline with SNAT Automap that points to router connected to the Internet

I did a packet capture and I saw that the SSL handshake occurs between the client and the HTTP/HTTPS Forward proxy (tiny proxy) - using HTTP Connect / Proxy-Connect method but the SSL decryption will not occur if the HTTP Forward proxy is configured on the client. (I am testing this because one of our customer would like to implement SSL Orchestrator but actually the customer have explicit HTTP proxy configured in order to provide web reputation filtering to the clients)

The architecture flow is the following (starting from the source):

  1. Client
  2. F5 SSL Orchestrator
  3. HTTP/HTTPS Forward Proxy (tinyproxy)
  4. Internet

I'll expect to see that the traffic is decrypted correctly also using the HTTP forward proxy in place. (actually it works for outbound decryption but without the HTTP forward proxy --> point 3.)

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Can you confirm you are in this mode ?

Image Text

F5 SSLi Ingress and Egress are the same box, this is just to clarify the logical aspects.

There is an implementation issue in SSL Forward Proxy that prevents it from correctly processing TLS inside a proxy CONNECT tunnel. This issue is documented in BZ597099. You can contact our Support to raise a case and be informed when the issue is fixed.

0
Comments on this Answer
Comment made 04-Sep-2017 by DamP 60

Hi Matthieu,

The scenario is slightly different because the Explicit proxy is placed after the F5 SSLi Egress interface (is not in the service chain).

Image Text

I tried to activate the debugging option on SSLo and I saw the following difference:

WITHOUT HTTP FORWARD PROXY:

Rule /Common/chain.app/chain-in_t <CLIENT_ACCEPTED>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 TCP from 192.168.1.1_39622 to 172.217.23.99_443 L7 1
Rule /Common/chain.app/chain-in_t <SERVER_CONNECTED>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 SERVER_CONNECTED state now=2, 192.168.1.1_39622 to 172.217.23.99_443 (vice 172.217.23.99_443) SNAT 10.6.20.69_25934
Rule /Common/chain.app/chain-in_t <CLIENT_DATA>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 classify: phase=2 ipproto=t src=192.168.1.1 dst=172.217.23.99 port=443 ptcl=1 names=www.google.it
Rule /Common/chain.app/chain-in_t <CLIENT_DATA>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 classify: ruleno2src=
Rule /Common/chain.app/chain-in_t <CLIENT_DATA>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 classify: result= _all; found no source addr match.
Rule /Common/chain.app/chain-in_t <CLIENT_DATA>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 client spoke TLS 31 Client Hello 222 bytes, SNI='www.google.it', L7 guess=1, pre-HS chain= _all Dfl
Rule /Common/chain.app/chain-in_t <CLIENTSSL_SERVERHELLO_SEND>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 CLIENTSSL_SERVERHELLO_SEND state=15
Rule /Common/chain.app/chain-in_t <CLIENTSSL_SERVERHELLO_SEND>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 classify: phase=4 ipproto=t src=192.168.1.1 dst=172.217.23.99 port=443 ptcl=1 names=www.google.it
Rule /Common/chain.app/chain-in_t <CLIENTSSL_SERVERHELLO_SEND>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 classify: ruleno2src=
Rule /Common/chain.app/chain-in_t <CLIENTSSL_SERVERHELLO_SEND>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 classify: result= _all; found no source addr match.
Rule /Common/chain.app/chain-in_t <CLIENTSSL_SERVERHELLO_SEND>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 CLIENTSSL_SERVERHELLO_SEND state=16 chain=_all Dfl
Rule /Common/chain.app/chain-in_t <CLIENTSSL_HANDSHAKE>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 CLIENTSSL_HANDSHAKE state=16 www.google.it-TLSv1.2-ECDHE-RSA-AES128-GCM-SHA256-128
Rule /Common/chain.app/chain-in_t <CLIENTSSL_HANDSHAKE>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 CLIENTSSL_HANDSHAKE link to rc then  70.
Rule /Common/chain.app/chain-rc <CLIENT_ACCEPTED>: /Common/chain.app/chain-rc-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 exit (TLS 31) TCP 192.168.1.1_25947 to 172.217.23.99_443
Rule /Common/chain.app/chain-rc <CLIENT_ACCEPTED>: /Common/chain.app/chain-rc-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 link to 70 then .
Rule /Common/chain.app/chain-rc <CLIENT_DATA>: /Common/chain.app/chain-rc-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 classify: phase=8 ipproto=t src=192.168.1.1 dst=172.217.23.99 port=443 ptcl=1 names=www.google.it
Rule /Common/chain.app/chain-rc <CLIENT_DATA>: /Common/chain.app/chain-rc-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 classify: ruleno2src=
Rule /Common/chain.app/chain-rc <CLIENT_DATA>: /Common/chain.app/chain-rc-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 classify: result= _all; found no source addr match.
Rule /Common/chain.app/chain-rc <CLIENT_DATA>: /Common/chain.app/chain-rc-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 client spoke first, reclassify yields _all Dfl
Rule /Common/chain.app/chain-ilS <SERVER_CONNECTED>: /Common/chain.app/chain-70-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 FTD scanning 192.168.1.1_25947 to 172.217.23.99_443 using 192.168.1.1_55514 to 172.217.23.99_443 via 10.6.16.2
Rule /Common/chain.app/chain-ilD <CLIENT_ACCEPTED>: /Common/chain.app/chain-70-D-0-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 FTD exit (TLS 31) TCP 192.168.1.1_55514 to 172.217.23.99_443
Rule /Common/chain.app/chain-ilD <SERVER_CONNECTED>: /Common/chain.app/chain-70-D-0-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 FTD SERVER_CONNECTED exit (TLS 31) TCP 192.168.1.1_55514 to 172.217.23.99_443 SNAT 10.6.20.69_55514
Rule /Common/chain.app/chain-in_t <CLIENT_CLOSED>: /Common/chain.app/chain-in-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 TCP from 192.168.1.1_39622 to 172.217.23.99_443 (vice 172.217.23.99_443) L7 1 (TLS 31) chain _all duration 130972 msec

WITH HTTP FORWARD PROXY

Rule /Common/chain.app/chain-in_t <CLIENT_ACCEPTED>: /Common/chain.app/chain-in-t-4 01c979cad62a3a089938ffa296ae040c TCP from 192.168.1.1_55730 to 10.6.20.68_8888 L7 -1
Rule /Common/chain.app/chain-in_t <CLIENT_DATA>: /Common/chain.app/chain-in-t-4 01c979cad62a3a089938ffa296ae040c classify: phase=1 ipproto=t src=192.168.1.1 dst=10.6.20.68 port=8888 ptcl=1 names=
Ruleno2src=
Rule /Common/chain.app/chain-in_t <CLIENT_DATA>: /Common/chain.app/chain-in-t-4 01c979cad62a3a089938ffa296ae040c classify: result= _all; found no source addr match.
Rule /Common/chain.app/chain-in_t <CLIENT_DATA>: /Common/chain.app/chain-in-t-4 01c979cad62a3a089938ffa296ae040c client spoke first 327 bytes, not TLS, L7 guess=1, chain=_all Dfl
Rule /Common/chain.app/chain-in_t <CLIENT_DATA>: /Common/chain.app/chain-in-t-4 01c979cad62a3a089938ffa296ae040c CLIENT_DATA link to 70 then .
Rule /Common/chain.app/chain-ilS <SERVER_CONNECTED>: /Common/chain.app/chain-70-t-4 01c979cad62a3a089938ffa296ae040c FTD scanning 192.168.1.1_39957 to 10.6.20.68_8888 using 192.168.1.1_49492 to 10.6.20.68_8888 via 10.6.20.68
Rule /Common/chain.app/chain-ilD <CLIENT_ACCEPTED>: /Common/chain.app/chain-70-D-0-t-4 01c979cad62a3a089938ffa296ae040c FTD exit (cleartext) TCP 192.168.1.1_49492 to 10.6.20.68_8888
Rule /Common/chain.app/chain-ilD <SERVER_CONNECTED>: /Common/chain.app/chain-70-D-0-t-4 01c979cad62a3a089938ffa296ae040c FTD SERVER_CONNECTED exit (cleartext) TCP 192.168.1.1_49492 to 10.6.20.68_8888 SNAT 10.6.20.69_49492
Rule /Common/chain.app/chain-in_t <CLIENT_CLOSED>: /Common/chain.app/chain-in-t-4 01c979cad62a3a089938ffa296ae040c TCP from 192.168.1.1_55730 to 10.6.20.68_8888 (vice 10.6.20.68_8888) L7 1 (cleartext) chain _all duration 87 msec

WITH HTTP FORWARD PROXY -->

FTD exit (cleartext) TCP 192.168.1.1_49492 to 10.6.20.68_8888 Rule /Common/chain.app/chain-ilD : /Common/chain.app/chain-70-D-0-t-4 01c979cad62a3a089938ffa296ae040c FTD SERVER_CONNECTED exit (cleartext)

NO HTTP FORWARD PROXY -->

FTD exit (TLS 31) TCP 192.168.1.1_55514 to 172.217.23.99_443 Rule /Common/chain.app/chain-ilD : /Common/chain.app/chain-70-D-0-t-4 4add7b5bd3a8ebc63be73c36d4e651b1 FTD SERVER_CONNECTED exit (TLS 31)

It seems that traffic that is passing through the HTTP Forward proxy is not recognized as encrypted but looking at the packet capture(taken on BIG-IP) the BIG-IP should see the SSL handshake correctly.

Image Text

Matthieu, do you think that is behaviour could be linked to the implementation issue id that you posted?

Thanks in advance.

Matteo

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

This one so :

Image Text

Unfortunately, same issue with BUGID : 597099

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

This use case is expected to be available in BIG-IP 13.1 and SSLO 3.0 (arriving at about the same time).

0
Comments on this Answer
Comment made 05-Sep-2017 by DamP 60

Thank you Kevin! Do you have any ETA of BIG-IP 13.1 and SSL 3.0 ?

0
Comment made 05-Sep-2017 by Kevin Stewart

Nothing definitive, but I believe before the end of the calendar year.

0
Comment made 05-Sep-2017 by Kevin Stewart

By the way, is the explicit proxy there as an external exit point to the Internet, or do you use it as a security device, authenticate users to it, etc?

0
Comment made 05-Sep-2017 by DamP 60

In my lab, the explicit proxy is in place just to replicate the customer scenario. The explicit forward proxy provide user authentication/web reputation filtering on the customer infrastructure.

0
Comment made 05-Sep-2017 by Kevin Stewart

So, if SSLO could offload the client side explicit proxy function, authenticate the users, and pass decrypted data and identity information down to this proxy inside the SSLO inspection zone, would that be useful to you? This functionality is also coming to the SSLO product.

0
Comment made 06-Sep-2017 by DamP 60

Yes of course, its another deployment option that we can provide to customers. It's interesting. I look forward to see soon BIG-IP 13.1 and SSLO 3.0! Do you know if the user authentication part could be done through APM ?

Thanks.

0
Comment made 06-Sep-2017 by Kevin Stewart

Yes, user auth would be handled by SSLO/APM.

0
Comment made 14-Sep-2017 by Piotr Lewandowski 1162

Hi Kevin,

Is simultaneous usage of SSLi and SWG already working solution? I did some research/lab and it was quite problematic to make it work in 13.0.

Piotr

0
Comment made 14-Sep-2017 by Kevin Stewart

It's coming very soon.

0
Comment made 21-Sep-2017 by Morten Marstrander 250

@Piotr, I worked with one of the F5 SE's and we made it work in 12.1.2, with SSLi and SWG running on the same BIG-IP.

You have to do some custom work though, and there is no readily available iApp you can use for it.

Morten

1
Comment made 21-Sep-2017 by Piotr Lewandowski 1162

Hi, Thanks for info. Can you by chance shared configuration used to make it work?

Piotr

0
Comment made 22-Sep-2017 by Morten Marstrander 250

I can post an article about it, but I don't have time to do it before next week.

Morten

0
Comment made 25-Sep-2017 by Piotr Lewandowski 1162

Hi,

Thanks a lot. Would be great, time is not so critical.

Piotr

0
Comment made 21-Nov-2017 by DamP 60

Hi, any news about BIG-IP 13.1 release date ? Thanks.

M.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Thanks for info, planed for 13.1.x?

Piotr

0
Comments on this Answer
Comment made 14-Sep-2017 by Kevin Stewart

Not in 13.1, no. But shortly after I believe.

0
Comment made 21-Sep-2017 by Piotr Lewandowski 1162

Hi Kevin,

Thanks for info.

Piotr

0