SSL Legacy Renegotiation vs Secure Renegotiation Explained using Wireshark
Related articles: SSL Forward Proxy Explained using Wireshark Quick Intro This is just a quick but in-depth look into SSL/TLS Renegotation and Secure Renegotiation. I'll just quickly show you how legacy and secure negotiation work in TLS/SSL. Renegotiation takes place in the same TCP connection. Do not confuse with Session Resumption/Reuse which takes place in subsequent TCP connections. Here's the topology I used to test this: 1. Legacy Renegotiation First there is a full SSL handshake: Notice that on Frame 6 (Server Hello) BIG-IP offers a Session ID: However, we do not use this session ID in renegotiation. Why? Because renegotiation means we want torenegotiate security parameters again and reusing session ID we would be reusing the same security parameters. Also,renegotiation takes place over the same TCP connection, so if client is the one that starts renegotiation we see a straightClient Hellostill over the same connection aboveand full handshake takes place: If it's BIG-IP (server-side) who is willing to trigger renegotiation then we see aHello Requestmessage still over same TCP connection followed by full handshake: That's it. This is legacy Renegotiation. Note:Do not confuse Renegotiation with Session Reuse/Resumption. In Session Reuse a new TCP connection is open and Client sends a Session ID from a previous session so that same security parameters are reused. 2. Secure Renegotiation - The Add on! Secure renegotiation is exactly the same as above with the addition of SSLrenegotiation_infoextension described inRFC5746. Note:The only reason for this extension is to avoid man-in-the-middle attack where session is hijacked and attacker tries to renegotiate new session using client's handshake information. This extension saves some information from initial handshake that must be provided upon renegotiation which attacker wouldn't have. If we click on first Client Hello we seerenegotiation_infoextension along with other extensions inClient Hellomessage: Note:Instead of renegotiation_info extension there is also the option to add TLS_EMPTY_RENEGOTIATION_INFO_SCSV to Cipher Suites list and that means the same thing, i.e. we (or client/server) support Secure Renegotiation. First message is always blank just to indicate Client supports Secure Renegotiation. Server also signals its support inServer Hello: At the end of every SSL handshake there is aFinishedmessage sent by both Client and BIG-IP: If we click on Finished message from Client, more specifically onVerify Datafield (assuming it is decrypted) we will see a 12 bytes hash in hexadecimal: This client-sidehash(d5 b7 01 35 b3 d2 d7 2a 54 0e 24 f0) is the result of hash of all handshake messages exchanged at this point mixed with previously negotiated master secret and a mathematical function to make it more secure (random). This allows BIG-IP to validate the integrity of the entire handshake. In BIG-IP's Finished message we can also see the sameVerify Datamessage which its own hash which in turn will also allow client to validate the integrity of the entire handshake: But why is it important to know that? Because in the next handshake,renegotiation_info (foundwithinClient Hellosent by Client)containsVerify Dataportion it sent in previousFinishedmessage (from previous handshake). Then BIG-IP sends its hash concatenated with client inVerify Dataportion. Therefore, it is unlikely an attacker could have obtained these values becauseFinishedmessage is always encrypted. Let's confirm values match onrenegotiation_infoon Client Hello sent afterwards in the same TCP connection (frame 1931): On BIG-IP's side it is the concatenation of Client's Verify Data and BIG-IP's Verify data (frame1965): That's it.
F5 and STARTTLS
I am not able to find a way for the F5 (BIG-IP 11.6.0 Build 1.0.403 Hotfix HF1) to essentially proxy an SMTP connection inbound and outbound to/from our email gateway and establishing (or not) a TLS connection. I am looking for the opportunistic conversation to occur between the F5 and the backend email gateway. Going outbound, the email gateway would forward the email to the F5 and the F5 would query the receiving gateway to determine if it could do or responded properly to the STARTTLS conversation. Likewise, an incoming email toward our gateways - the F5 would establish (yes/no) if the sending gateway could do STARTTLS. Thanks very much.
TLS Client Authentication from Server SSL Profile
Hi all We have a requirement to enable an outbound (internet) flow from some internal servers. Sitting near the edge of the network is an LTM that will proxy the connection from the servers, and is required to then do TLS mutual authentication (client authentication) to the target server on the internet. In this setup the LTM is, from the internal server's point of view, the server, so we configure a Client SSL Profile. All good. Next the LTM is, from the target server's point of view, a client so we configure a Server SSL Profile. Unfortunately this is not working for us. In the Server SSL profile we have set the Certificate and Key, which is the identity cert of the LTM itself signed by a 3rd party CA using a Web Server template with Client Authentication Key Usage. The logs from the target server (Apache 2.4.7) show the following: [ssl:info] [pid 5260:tid 2999946048] [client 10.128.2.109:58181] AH02008: SSL library error 1 in handshake (server server.com:443) [ssl:info] [pid 5260:tid 2999946048] SSL Library Error: error:140880AE:SSL routines:SSL3_GET_CERT_VERIFY:missing verify message My limited understanding on TLS MA is that the client should send a Certificate Verify message that proves it owns the private key. It appears the LTM is not sending this message which could explain why it is failing. I've tested a similar setup in my lab but bypassed the LTM and sure enough a Windows client does indeed send the Certificate Verify message and the transaction is successful. Any ideas on this one? Thank you.
Problem FTPS passive
Hello Everyone, For one of our customer, we have to deploy a FTPS server behind the F5. Here is my configuration of the VS : And here is my problem, The FTP behind the F5 is working great, I can connect to it and transfer a file with success. But where I have a problem is when the server has TLS turned on. First I tried to manage the certificate with the F5 (TLS is off on FTP server) so I created a SSL client profiles but it's not working : And when TLS is turned on onto the server but the certificate is not managed by the F5 here is the error message i have: I connect with a real account. 1/Do you think it's a F5 conf problem of a FTP/Certificate problem : Someone already had this kind of problem and how did he manage to resolve it? 2/Do I need to create a irules to limit the range of port to connect? Thanks in advance.
Disable HTTP2 profile from iRule?
Hi! We will implement HTTP2 since it's supported in version 12. There is one iRule assigned to VIP that requires SSL renegotiation. Renegotiation conflicts with HTTP2 and gives SPDY protocol error. This iRule asks for a client certificate from card reader for a specific URL and country. It's easy to select another SSL profile with renegotiation enabled for this specific country, but it would be better to use another SSL profile for this specific URI only. HTTP URI is not allowed within CLIENT_ACCEPTED, but we can live with disabling HTTP2 for a country if there is no way to accomplish this. The most important is to figure out how to disable HTTP2 profile on the VIP for this URL or country. I have not yet found a solution for this. WAM::disable is not working. Any help is highly appreciated because this is a blocker now for enabling HTTP2. iRule: Initialize the variables on new client tcp session. when CLIENT_ACCEPTED { set collecting 0 set renegtried 0 Find out country tag set CountryID "[whereis [IP::client_addr] country]" Use SSL profile with renegotiation enabled if {$CountryID eq "EE"} { SSL::profile with_renegitiation_enabled } } Runs for each new http request when HTTP_REQUEST { /player/identification/eid/start triggers client cert renegotiation if { $renegtried == 0 and [SSL::cert count] == 0 and (([HTTP::uri] starts_with "/player/identification/eid/start") || ([HTTP::uri] starts_with "/player/authentication/authentication/loginEid")) } { Collecting means buffering the request. The collection goes on until SSL::renegotiate occurs, which happens after the HTTP request has been received. The maximum data buffered by collect is 1-4 MB. WAM::disable HTTP::collect set collecting 1 SSL::cert mode request SSL::renegotiate } } After a handshake, we log that we have tried it. This is to prevent constant attempts to renegotiate the SSL session. I'm not sure of this feature; this may in fact be a mistake, but we can change it at any time. It is transparent if we do: the connections only work slower. It would, however, make BigIP detect inserted smartcards immediately. Right answer depends on the way the feature is used by applications. when CLIENTSSL_HANDSHAKE { if { $collecting == 1 } { set renegtried 1 Release allows the request processing to occur normally from this point forwards. The next event to fire is HTTP_REQUEST_SEND. HTTP::release } } Inject headers based on earlier renegotiations, if any. when HTTP_REQUEST_SEND { clientside { Security: reject any user-submitted headers by our magic names. HTTP::header remove "ID-EE-SSL_CLIENT_CERTIFICATE" HTTP::header remove "ID-EE-SSL_CLIENT_CERTIFICATE_FAILED" if certificate is available, send it. Otherwise, send a header indicating a failure, if we have already attempted a renegotiate. if { [SSL::cert count] > 0 } { log local0. "Client Certificate: [X509::subject [SSL::cert 0]]" HTTP::header insert "ID-EE-SSL_CLIENT_CERTIFICATE" [X509::whole [SSL::cert 0]] } elseif { $renegtried == 1 } { This header has some debug value: if the FAILED header is not present, BigIP is probably not configured to do client certs at all. HTTP::header insert "ID-EE-SSL_CLIENT_CERTIFICATE_FAILED" "true" } } }
Question regarding the SSL/TLS cipher and Certificate
Hi Folks, I have two question regarding SSL/TLS cipher and Certificate. We used the same ssl profile with same cipher suite on two different F5 VSs, and we tested SSL/TLS by Qualys SSL Labs. But we saw the different report. One of the website got the A grade, but the other website got the B grade, because the webpage didn't use the forward secrecy cipher suite. Why do we get the discrepancy report ? The other question: There were several WAF or Load balancer on the same network chain to handle the same traffic for the same website. It was like there is a user send the HTTPS request through the several proxy device and final reach the website. Why the user got the certificate problem If one of the proxy which wasn't placed on the first gave the wrong ssl certificate ? Wouldn't the first proxy unit handling client side ssl handshake? Regards, DingSSL client certificate LDAP Authentication Question
Hi all In a bid to try understand some of the lesser documented and possibly implemented features of LTM, I have been testing out the various authentication features LTM has to offer. I am at a point where one them - SSL client certificate LDAP authentication has left me a little stumped. I can get the feature to work at a basic level, that is, the client presents a certificate, the LTM extracts the username from the cert, performs bind to LDAP and authenticates the user successfully. What I wish to do now is ensure that the client is part of a specific AD group before granting permission to resources. I believe the *Group Base DN* and *Valid Groups* settings are what I need to focus on. However, regardless of what I enter here, I cannot get this to work. My thinking is that the Group Base DN should contain a value similar to this: CN=Sales,CN=Users,DC=company,DC=com Where 'Sales' is an AD group the users I wish to authenticate are part of. I then add the keyword 'Sales' to the Valid Groups box, for a final config like so: ltm auth ssl-cc-ldap LAB-SSL-LDAP-CONFIG { admin-dn CN=Administrator,CN=Users,DC=lab,DC=com admin-password group-base CN=Sales,CN=Users,DC=lab,DC=com servers { } user-base CN=Users,DC=lab,DC=com user-key sAMAccountName valid-groups { Sales } Yet, with this config it fails and the Wireshark trace I take doesn't actually provide much clue. In fact I can't even see the LTM attempt to query LDAP for the 'Sales' group. Any idea on where I'm going wrong? Has anyone tried this out successfully? Thanks
Forcing TLSv1_2 in the SSL Server Profile
Is it possible to configure SSL Server Profile so connectins from bigip started with TLSv1_2 ? I tried to put in a ciphers field: TLSv1_2, but connections are still TLSv1, although in the client hello packet the proposed version is TLS1.2. Unfortunately some servers just reset all connections, if are not TLS1.2.
