Forum Discussion
NimbostratusHow stuff works - what happens in details and behind the scene when you type in your browser http://google.com & https://gmail.com
EmployeeThe BigIP generally doesn't care about google.com or gmail.com unless you're the person hosting google.com and you have a Bigip in front of that website. So I'll assume that you're going to a site you have hosted behind your BigIP. Furthermore I am going to assume that you are following best practices. I also won't go into detail on the non F5 specific aspects of that connection because others have done that far better than I. For the plain text stuff you could do worse than to read the interview page here:
for HTTPS, I would suggest here:
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
There are others, and google is your friend. But you are on devcentral, and presumably you know this but want to know what kind of mojo BigIP brings to the mix. This is not a super simple question, as the BigIP is a pretty complex machine, but we can break it down somewhat.
To begin with, your computer makes a complete handshake with the BigIP. Assuming you aren't using clientSSL or HTTP profiles, that means SYN, SYN/ACK, ACK. At this point the BigIP makes a load balancing decision based on the settings for your virtual server (we will ignore forwarding servers, which route based on the routing tables rather via pools), and initates a new three way handshake with that back end pool member. In the meantime it has likely received data from the client, which it buffers while it completes the handshake. Once it has a new connection established with the pool member, it will take the buffered data and pass it on to the pool member. Once the pool member has responded it will pass that on to the client. This continues until the conversation is over.
If you have configured the Virtual server to take that HTTP request and redirect it to HTTP over SSL, then you will need an HTTP profile on the virtual server (and an irule). In that case, the BigIP finishes the three way handshake and waits. When it receives a valid HTTP method, it then passes that along to the iRule which returns a redirect telling the client that the desired resource is at
https://.tld/https://.tld/If the HTTPS virtual server is also configured with an HTTP profile (and a clientSSL profile), it will need to complete the three way TCP handshake, the SSL Handshake, and get a valid HTTP method before it makes a load balancing decision. The BigIP has it's own list of Ciphers and TLS versions that it supports completely independent of the back end servers. It also has it's own certificates and keys. When you connect to the BigIP, it will present the cipher it wants to use (out of the ciphers offered by the client), and give out the certificate it has been told to use with that virtual server. Assuming that everything is acceptable to the client and the server, a connection will be established (if not, an SSL alert is fired and the conversation is ended). At this point the client should send an HTTPS method (Usually a GET initially), and the BigIP will make a load balancing decision.
If the Virtual Server is configured with a ServerSSL profile, the BigIP will attempt to make a SSL connection to the Pool Members. We don't care about the validity of the certificate, per se, just that there is a certificate and that you are willing to use one of our offered ciphers. Once we have established a connection we will pass on the HTTP request received earlier from the client and everything proceeds as before.
The BigIP is an RFC standards compliant device, so if you understand how HTTPs and SSL are supposed to work in the wild, and you realize that the BigIP is a full proxy carrying on two conversations (one with the client, one with the server), you are 98% of the way to understanding what the BigIP is doing.
Please let me know if you have other specific questions about this.
