Forum Discussion
Prince_165600
Nimbostratus
NimbostratusTLS protocol switching on F5
Hello Experts,
I am looking for documents to understand the behavior of TLS version selection made by F5 in SSL handshake either sides.
I would appreciate if someone can clarify on this :
The scenario is if client connect to F5 using TLSv1.0, will F5 by default try to connect to server using TLSv1.0 as normal behavior ? What if server has TLSv1.0 disabled, only TLSv1.2 enabled. Will F5 retry connection to server by using TLSv1.2? Provided clientssl and serverssl are supporting all versions of TLS.
Moreover, lets say if below are the settings in CLientssl and serverssl profile :
!DEFAULT:!SSLv3:TLSv1:TLSv1_1:TLSv1_2
when i check the list of ciphers supported, i get below list :
`@f5test:LICENSE EXPIRED] config tmm --serverciphers '!DEFAULT:!SSLv3:TLSv1:TLSv1_1:TLSv1_2'
ID SUITE BITS PROT METHOD CIPHER MAC KEYX
0: 5 RC4-SHA 128 TLS1 Native RC4 SHA RSA 1: 5 RC4-SHA 128 TLS1.2 Native RC4 SHA RSA 2: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 3: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 4: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 5: 53 AES256-SHA 256 TLS1 Native AES SHA RSA 6: 53 AES256-SHA 256 TLS1.2 Native AES SHA RSA 7: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA 8: 10 DES-CBC3-SHA 192 TLS1 Native DES SHA RSA 9: 10 DES-CBC3-SHA 192 TLS1.2 Native DES SHA RSA 10: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA 11: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA 12: 61 AES256-SHA256 256 TLS1.2 Native AES SHA256 RSA 13: 9 DES-CBC-SHA 64 TLS1 Native DES SHA RSA 14: 9 DES-CBC-SHA 64 TLS1.2 Native DES SHA RSA `
So along these, what will be selection sequence followed by F5 ?
JGCumulonimbus
If you are talking about SSL bridging, as seems to be the case, F5 will terminate the SSL connection from the client and decrypt its traffic; then it will negotiate and set up another SSL connection with your application server, re-encrypt the client data and pass it to the application server.
There are two distinct network stacks on the F5, one for the client side and the other for the server side. The TLS protocol and cipher used by the connections on the client side and the server side can be the same or different; they depend on the capabilities of the two peers of each connection (client <> F5 and F5 <> application server). So how you configure the SSL profile for each side on the F5 is relevant. The highest/strongest TLS protocol/cipher will be selected by each connection after a sucessful SSL negotiation.
Mathew_86305There will be two negotiations one from client to F5 and then F5 to server. On both cases the destination will be responding for client hello with the Ciphers supported. Based on the destination capability it will be selecting the ciphers supported.
It can view detailed if we try an ssldump in F5.
hari_126827Cirrus
For info on end-user browser's cipher suite being used, we may visit below similar links: https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%208.1
the F5 client-ssl cipher suite should be able negotiate with client-side., vice versa, F5 server-ssl (if default is used) will be negotiating traffic with server-side certificate.
- Kevin_Davies_40
Nacreous
This is the selection sequence. You can reorder them by adding @speed or @strength.
0: 5 RC4-SHA 128 TLS1 Native RC4 SHA RSA 1: 5 RC4-SHA 128 TLS1.2 Native RC4 SHA RSA 2: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 3: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 4: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 5: 53 AES256-SHA 256 TLS1 Native AES SHA RSA 6: 53 AES256-SHA 256 TLS1.2 Native AES SHA RSA 7: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA 8: 10 DES-CBC3-SHA 192 TLS1 Native DES SHA RSA 9: 10 DES-CBC3-SHA 192 TLS1.2 Native DES SHA RSA 10: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA 11: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA 12: 61 AES256-SHA256 256 TLS1.2 Native AES SHA256 RSA 13: 9 DES-CBC-SHA 64 TLS1 Native DES SHA RSA 14: 9 DES-CBC-SHA 64 TLS1.2 Native DES SHA RSA `When it comes to clientssl the F5 controls the order of ciphers. When it comes to serverssl the application server controls it and not the F5. You see from the clients perspective the F5 is the server and from the server perspective the F5 is the client. They don't know anything about each other and there are completely separate network stacks for each of them.
The proxy SSL feature is when the F5 acts as specialised man in the middle. See the knowledge base article on the proxy SSL feature.
Prince_165600Kevin,
By default will F5 follow the cipher selection as per speed or as per strength ?
Will i be correct to say that, even if connection between end client and F5 is TLS 1.0, F5 will initiate connection at TLS1.2 ( being the highest supported by serverssl settings )
or does the above behavior change when i enable "Proxy SSL" feature on both the clientssl and serverssl settings.
- Kevin_Davies_40
By default it will follow the order specified in tmm --serverciphers when you provide it a cipher string. So the order from your output in the original question you posted. You can add @speed or @strength to get it to reorder the ciphers fastest first or strongest first.
Note on the server side as the application server determines what ciphers are available to use and your cipher string just determines what ciphers you will negotiate with the server just like any client would.
Will i be correct to say that, even if connection between end client and F5 is TLS 1.0, F5 will initiate connection at TLS1.2 ( being the highest supported by serverssl settings )
I get the impression you think the two are linked in some way? They are not. The clientside can have strong cipher and the server have weak cipher and vice versa. They are completely independent negotiations.
- JG
Kevin is right: The serverside in either context gets to choose and decide which cipher to use, out of a list of supported ciphers received from the client.
Gabe_Roman_3124Question on this: If the Client can only support TLSv1 and the Server requires TLSv1.2 AND client authentication, how will F5 pass the client cert to the server?