SSL Forward Proxy Explained using Wireshark
Related articles:SSL Legacy Renegotiation vs Secure Renegotiation Explained using Wireshark Summary The idea behind this feature is to allow BIG-IP to sniff into SSL connections to any Internet destination that goes through it whilst preserving client's trust of the destination. When this feature is enabled, BIG-IP uses a pre-installed CA set underproxy-ca-cert(CA Certificatein the GUI) that is also trusted by client's browser and BIG-IP pretends to be the Internet destination by re-signing SSL certificates on the fly with the aforementioned CA and using public key from CA configured undercerton BIG-IP. The client trusts the connection and is unaware of BIG-IP's presence. The most common use case isSecure Web Gateway(SWG), although neither APM nor SWG are needed to deploy SSL Forward Proxy functionality.LTM is enough. Lab Scenario Lab test results: Client opens connection with BIG-IP and sendsClient Hello. BIG-IP immediately opens connection with web server and completes SSL handshake. BIG-IP creates unique certificate with following information and sends it over viaServer Hello: Serial number: random Issuer: copied fromdefault.crt Validity: notBefore (copied fromserver1.crt), notAfter: 30 days counting from time it was generated (configurable viacert-lifespanorCertificate Lifespanin the GUI) Subject: copied fromserver1.crt Public Key: copied fromltm2.CA.crt All X.509extensionsallowed incert-extensions-includeare also copied fromserver1.crtto unique custom certificate Client-side handshake completes successfully using above dynamically generated custom certificate just created by BIG-IPand data exchange works as expected. How SSL Forward Proxy works on Wireshark Actual capture used for below explanation is attached to this article below (and heressl-forward-sample-3.pcap ) Upon Client Hello sent by Client BIG-IP rushes to open new connection and completes server-side SSL handshake: Server-side handshake completes on frames 17-18 and and BIG-IP immediately resumes and completes Client-side handshake.Note:The reason why BIG-IP waits for server-side handshake to complete first is because BIG-IP uses server-side certificate information to generate acustomcertificate that will be sent to Client on client-side. The most interesting bit here is BIG-IP'sCertificatemessage sent on frame 20 to Client as it contains the customCertificate generated by BIG-IP: We can see there are 2 Certificates: CA Certificate(proxy-ca-cert) is the Certificate Authority (CA) that signs the newly created custom certificate and is supposed to be trusted by Client to confirm BIG-IP's custom (dynamically generated) certificate can be trusted too. We can immediately work out that the 2nd certificate isdefault.crtjust by matching its serial number which is unique for each issuer: However, the first certificate looked a mystery to me until I found where all the pieces came from. The serial number looks randomly generated to me as it doesn't match (not even close to any of the certificates above): The Issuer field, which shows information about who signed the certificate, shows thatdefault.crtwas the one who signed BIG-IP's custom certificate: Certificate generation date (notBefore) is copied fromserver1.crtbut expiry date (notAfter) is calculated based oncert-lifespan(Certificate Lifespanin the GUI) which by default is 30 days added to time custom certificate was generated: Subject fields, which shows information about the current certificate, is copied and identical to information onserver1.crt: And finally, the public key is copied fromcertfield (ltm2CA.crt). Notice they are the same: That's enough information for now.
Forward explicit SSL proxy server
Dear all, Trying to figure out why HTTPS traffic is not passing the forward proxy. I followed the following article, configured the HTTP and SSL profiles and the two virtual servers accepting HTTP and HTTPS traffic. The only thing that we dont use is the APM part. Result is that when using the explicit IP address configured in HTTP virtual server and the local browser client is that it works just fine when accessing HTTP websites. When I try to access a website with HTTPS using the explicit IP address configured in my browser I can see an HTTP CONNECT and the virtual server replies with service unavailable HTTP 503. This happens with all HTTPS sites. If I change the proxy setting in the browser the HTTPS (port 443) to request is simply being reset. https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-secure-web-gateway-implementations-12-0-0/7.html Does anyone has experience in deploying Big IP LTM as a explicit forward proxy using HTTP and clientSSL profiles only without the use of Irules?
URL redirect/rewrite to external site/header change with internal CA.
Hello everyone! I will start by saying I have scoured this site and found a few instances of what might resemble my issue. I have tried to use different posted solutions, but I am still stuck.I will post down below my needs with examples. 1. I have an external url I am going to be forwarding traffic to and lets call it www.wallyworld.com. I have an internalsite which we will call www.internalworld.com that I need to write the external header to with a specific url after and lets call it /brand/. 2. after step one is accomplished, then I will need a link on the external url to be added after the added /brand/. 3. I still need to use my internal certificate successfully. Can this be accomplished? examples down below! 1. redirect from internal site to external site transparently(maintaining internal url)- www.internalworld.com/brand/ redirected tobut maintaining internal url-> www.wallyworld.com 2. added link - www.internalworld.com/brand-> add any link that is selected on the external site. example would be if they selected a link named dining.-> www.internalworld.com/brand/dining/ 3. certificate - still use my internal certificate successfully after the header change.
SSL Forward Proxy Question
Hello all We have a requirement to allow some servers in a DMZ to talk to a service on the internet. I was looking into the SSL Forward Proxy feature on the LTMs as this appears to provide the service we need. F5s documentation on this is rather weak and rushed. I am following this guide: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-11-6-0/13.html Some (basic) questions I had on this: When I create a pool, presumably the pool members are the server IPs on the internet? The certificate I use on the Client SSL Profile (Certificate B in the link above) - does this certificate need to be signed by our internal CA, and if so, do we need to use a particular certificate template, e.g. Subordinate Certification Authority? In the Client SSL Profile, do we only (at minimum) need to configure the SSL Forward Proxy section? In the Server SSL Profile which certificate and key do we use? We need the LTM to perform MA with the server. Will this be a certificate generated on the LTM itself or do we need to import the cert + keys of the back end server and use those here? Thank you.
SSL Intercept with F5 in L2 mode
I am looking for a deployment where I configure same VLAN to the ports my client and server are connected. I would like to intercept this traffic. Is this possible on F5. The current scenario explained in the F5 doc is to have self-ips for server and client vlans and route the traffic to the F5 using these IPs. Anyone is aware of deployment without these self-ips and having client and server in the same vlan?
