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.
An Irule for Client Ssl Profile that Allows Unassigned TLS Extension Values (17516)
Hello Community, I have a requirement to allow enriched https header enrichment. The SSL negotiation (I'm doing ssl termination on F5) fails because the enriched header from client contains reserved tls extension values. (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtmltls-extensiontype-values-1). The Client Hello request in the SSL Handshake was captured and contained an Extensions list, which included a reserved TLS Extension value (17156), which the F5 isn't presenting in Server Hello. I need an irule that can allow that Extension to be added on the client ssl profile so the ssl handshake doesn't fail.
Certificate Issue : unable to find valid certification path to requested target
Hello, We deployed a staging e-payment application, using a Virtual Server with these properties : port : https protocol profile : mptcp-mobile-optimized HTTP Profile : XFF SSL Profile : 2 certificates - The issued certificate & a second certificate with Default SSL Profile for SNI SNAT Pool : ip in the same subnet as nodes. Pool : 2 pool members with port 7010 I'm using public certificates (signed by CA Verisign G5 & CA Symantec G4) the web page is displayed correctly, & SSL checks says all is ok (tested with "; & ";) the actual issue is that transaction doesn't pass over https (in http it works fine) here's the error message relived from client side : -An exception occured in HTTPProcess sendMessage. Exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. - doPost exception encountered. Exception: java.lang.NullPointerException. can you support us please?
Check where SSL profile is used
Morning :) I've inherited an F5, and the previous admin was a little bit off with his SSL management. I need to do some cleaning up, and one question came up. I've already found a way to figure out which profiles are using particular SSL certificates. Now I need to move a step forward and find a matching VS for my SSL profiles Is there an easy tmsh command which could achieve that (or at least move me one step closer)?
SSL client profile - certificate authentication - multiple CRL files
Hi guys, currently I'm running a tests with certificate-based user authentication, using LTM/APM. In general everything is working fine, except for the fact, that there is no option to check several CRL files in one SSL client profile. As there are multiple CAs, that have issued client certificates, I need to check several CRL files. The documentation is not very specific about this piece of information. There are only statements, that it is not allowed to have multiple CRLs in a single master file. I have tried to use CRLDP, but this does only work in conjunction with LDAP. I can only provide the CRLs via file upload to BIG-IP or via HTTP downloads from an internal server. The only idea I have so far, but which is still not tested, is to use several SSL client profiles, one for each Trusted CA, assign the correct CRL file, stored locally on the BIG-IP, and the assign the SSL client profiles dynamically, based on the requested hostname in the SNI extension. To be honest, I cannot believe that there is no easier way to achieve this. Any ideas on that? Thanks in advance. Greets, svs
BigIP 11.6 HF4 + SSL ciphers
We've recently upgraded to 11.6 to eliminate Chrome's obsolete cryptography message. I have an iRule that is allowing me to perform Strict Transport Security (HSTS), allowing us to obtain an A+ rating from ssllabs. The issue we're having now, is that I cannot find a suitable combination of ciphers to allow Chrome to display the following message: The connection is encrypted and authenticated using AES_128_GCM and uses ECDHE_RSA as the key exchange mechanism. I've been able to find a way to enable ECDHE_RSA as the key exchange, however the encryption that ends up being used is AES_256_CBC, resulting in the obsolete cryptography message to appear. I need to know how to get clients to prefer a GCM cipher, right? Evidently DHE_RSA does not allow for PFS to be enabled. Any recommendations for a cipher string? This is what I've tried so far, with no luck: !SSLv2:!SSLv3:!MD5:!EXPORT:ECDHE+AES:ECDHE+3DES:RSA+AES:RSA+3DES !SSLv2:!SSLv3:!MD5:!EXPORT:!SHA1:ECDHE+AES:ECDHE+3DES:RSA+AES:RSA+3DES !LOW:!SSLv3:!MD5:!RC4-SHA:!EXPORT:DHE+AES-GCM:DHE+AES:DHE+3DES:AES-GCM+RSA:RSA+AES:RSA+3DES:ECDHE+AES-GCM:ECDHE+AES:ECDHE-RSA-DES-CBC3-SHA I was able to obtain an A+ rating on ssllabs using the following ciphers, however now the Obsolete message is back: ECDHE+AES-GCM:NATIVE:!MD5:!EXPORT:!DES:!DHE:!EDH:!RC4:!ADH:!SSLv3 Your connection to domain.com is encrypted with obsolete cryptography. The connection uses TLS 1.2. The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism.
