Increase DH key exchange to 2048
I'm trying to move from cipher lists in the ssl profile to cipher rules and groups in order to support TLS1.3 I would like to only enable strong cipher suites. So far I've found this list TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 So far I've come up with this string to reproduce the list: ECDHE+AES-GCM:DHE+AES-GCM:CHACHA20-POLY1305 Each time I test it the DHE+AES-GCM gets flagged because it is only 1024 bits. Removing it means removing a lot of clients from the compatibility list. After days of reseach I can't find the place to increase my DH group strength. Only a 5 year old article which says that I can't increase it. Does anyone know if it is possible to increase DH group strength in either 13.1.1 or 14.1.2, and where to do it?Solved12KViews0likes16Comments
SSL Handshake failed for TCP
We are seeing a ton of these messages in our logs. Several per minute from legit client IPs. However, the clients are not reporting any issues. SSL Handshake failed for TCP x.x.x.x:11555 -> x.x.x.x:443 These particular messages are NOT followed up a connection error message about an unsupported version as you might expect (for example: Connection error: ssl_hs_rxhello:7699: unsupported version (40)). I am trying to understand what is occurring. I did a pcap but was not able to get much out of it since there was a lot of normal traffic in there as well since these are good source IPs. I did not find any fatal handshake errors. Anything else I could look for in a pcap to see what is occurring? What other instances would you see a message like this? The frequency of the messages increase/decrease with peak and off peak times. The application is a typical IIS web app where the client uses a browser to access.11KViews0likes3Comments
unsupported certificate error with device certificates
Hello All. I'd appreciate some help debugging an issue with new device certificates, and communication between two of our f5s. We replaced the certs under Device Certificate Management, and each server has the full chain for both servers under Device Trust Certificates. The message we see in the logs is: Mar 16 10:34:53 s0711125-mgmt iqmgmt_ssl_connect: SSL error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 alert unsupported certificate (Note that this is the full line. In searching for similar cases on here I found a lot of cases where the log entry was "unsupported certificate purpose", but that is not the case here. I tried turning the SSL logging up to debug, and got no additional information that I can see.) In a packet trace I can see that the response is indeed a TLSv1.2 Alert: Unsupported Certificate response: 2447 0.284021 me partner TLSv1.2 84 OUT s1/tmm3 : Alert (Level: Fatal, Description: Unsupported Certificate) The (redacted) cert that my partner presented looked like: Certificate: signedCertificate version: v3 (2) serialNumber: signature (sha256WithRSAEncryption) Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption) issuer: rdnSequence (0) validity subject: rdnSequence (0) subjectPublicKeyInfo extensions: 9 items Extension (id-ce-subjectAltName) Extension (id-ce-subjectKeyIdentifier) Extension (id-ce-authorityKeyIdentifier) Extension (id-ce-cRLDistributionPoints) Extension (id-pe-authorityInfoAccess) Extension (id-ce-keyUsage) Extension Id: 2.5.29.15 (id-ce-keyUsage) Padding: 5 KeyUsage: a0 1... .... = digitalSignature: True .0.. .... = contentCommitment: False ..1. .... = keyEncipherment: True ...0 .... = dataEncipherment: False .... 0... = keyAgreement: False .... .0.. = keyCertSign: False .... ..0. = cRLSign: False .... ...0 = encipherOnly: False 0... .... = decipherOnly: False Extension (id-ms-certificate-template) Extension Id: 1.3.6.1.4.1.311.21.7 (id-ms-certificate-template) CertificateTemplate templateID: 1.3.6.1.4.1.311.21.8.14764644.7141585.13978757.4163610.14474613.168.14047150.174214 (iso.3.6.1.4.1.311.21.8.14764644.7141585.13978757.4163610.14474613.168.14047150.174214) templateMajorVersion: 100 templateMinorVersion: 14 Extension (id-ce-extKeyUsage) Extension Id: 2.5.29.37 (id-ce-extKeyUsage) KeyPurposeIDs: 1 item KeyPurposeId: 1.3.6.1.5.5.7.3.1 (id-kp-serverAuth) Extension (id-ms-application-certificate-policies) Extension Id: 1.3.6.1.4.1.311.21.10 (id-ms-application-certificate-policies) CertificatePoliciesSyntax: 1 item PolicyInformation policyIdentifier: 1.3.6.1.5.5.7.3.1 (id-kp-serverAuth) algorithmIdentifier (sha256WithRSAEncryption) Padding: 0 Any thoughts on what might be causing this error? Thanks much for any help, - rob.Solved5.1KViews0likes1CommentSSL 3.0.7 - Unsafe legacy renegotiation disabled on client side
We have a client reporting a problem connection to one of our endpoints after they upgraded their appliance that uses SSL 3.0.7. I've read around a little and I believe this is in relation to the recent security issue announced by OpenSSL. Their device I believe uses an IBM APIConnect Gateway. The error they are getting with the connection since the upgrade happened is the following (IP and gtid obfuscated for security): May3014:08:08npe-dp-sac-node1[APIConnect_Gateway][0x8120002f][ssl][error]ssl-client(bsc_dev2_tlsp-tls-client-profile-defaultV1.0.0):trans(4705632)[10.10.10.10]gtid(#################):TLSlibraryerror:error:141E3152:SSLroutines:final_renegotiate:unsafelegacyrenegotiationdisabled I'm concerned after digging around, that our F5 might not be ready or setup to accept traffic from devices that have been updated with this new version of SSL 3.0.7. I am the SME for the F5 support at our company and I don't have a lot of experience on this end of the configuration. Is there something we need to do on the F5 to safely allow this traffic?Solved3.4KViews0likes3CommentsTrouble applying GoDaddy certificate to a virtual server
I have created a few virtual servers and applied certs. They work just fine because they are using our internal CA. I have one now that uses a GoDaddy cert. I was provided a GoDaddy pfx file. I imported the cert and key without issues. I created the SSL profiles. In the CLientSSL profile, I chose the newly imported GoDaddy cert for Certificate, Key and Chain. I added the profile to the virtual server. When I open the virtual server in any browser, I get "The site can't be reached". Using FireFox, I get the error, "Error code: PR_CONNECT_RESET_ERROR". Because it's not an invalid cert error, I can't easily troubleshoot. Am I doing something that is glaringly wrong?Solved3.3KViews0likes18Comments
Can we have multiple Client SSL profile on single VIP?
Hi There, Can we have multiple client SSL profile on single VIP? I am looking for some help on this. We need to have some rules like below. www.mywebsite.rain.com --> SSL Profile SSL_rain www.mywebsite.snow.com --> SSL Profile SSL_snow www.mywebsite.sunny.com --> SSL Profile SSL_sunny This requirement is based on application side as we use same VIP for all three websites and the server is determining which website to present to the user based in urls. Can someone shed some lights on this please??Solved3.3KViews0likes7CommentsBypass certificate check
Is there any way that checking the certificate details could be bypassed in specific cases (e.g. a particular client/IP Address, particular URLs/domains) when using SWG as a Forward Proxy? We are trying to set up a Red Hat Satellite server to download repositories from Red Hat and make them available internally. The documentation states that "Use of an SSL interception proxy interferes with this communication. These hosts must be whitelisted on the proxy." Apparently, the reason an SSL Interception proxy interferes with it is that the server certificates aren't signed with publicly trusted certs. The application trusts these certificates, but obviously the proxy doesn't. We do have an SSL Intercept bypass list in place, but as I understand it, the proxy will still check that the certificate is valid (as this can be checked without decoding the traffic). Is there any way that we can disable or bypass this check for this traffic?Solved3.2KViews0likes2Comments
Certain Cipher suites are not shown in ssl server test
Hi, I am running version 15.1.0. I configured client-ssl profile with cipher group as I need to enable TLSv1.3 The cipher group has a rule which enables certain cipher suites only: TLSv1_3:ECDHE_ECDSA+AES-GCM:ECDHE+AES-GCM:ECDHE+AES:ECDHE_ECDSA+CHACHA20-POLY1305:ECDHE+CHACHA20-POLY1305:!DHE+AES-GCM:!TLSv1:!TLSv1_1:!ECDHE+AES:@STRENGTH With this I am receiving the following into the Rule Audit tab: Cipher Suites TLS13-AES256-GCM-SHA384/TLS1.3 TLS13-CHACHA20-POLY1305-SHA256/TLS1.3 ECDHE-ECDSA-AES256-GCM-SHA384/TLS1.2 ECDHE-RSA-AES256-GCM-SHA384/TLS1.2 ECDHE-ECDSA-CHACHA20-POLY1305-SHA256/TLS1.2 ECDHE-RSA-CHACHA20-POLY1305-SHA256/TLS1.2 TLS13-AES128-GCM-SHA256/TLS1.3 ECDHE-ECDSA-AES128-GCM-SHA256/TLS1.2 ECDHE-RSA-AES128-GCM-SHA256/TLS1.2 DH Groups DEFAULT Signature Algorithms DEFAULT The problem is when I check the site into ssl labs , it gives me only these ciphers : Cipher Suites # TLS 1.3 (suites in server-preferred order) TLS_AES_256_GCM_SHA384 (0x1302)ECDH secp384r1 (eq. 7680 bits RSA) FS256 TLS_CHACHA20_POLY1305_SHA256 (0x1303)ECDH secp384r1 (eq. 7680 bits RSA) FS256 TLS_AES_128_GCM_SHA256 (0x1301)ECDH secp384r1 (eq. 7680 bits RSA) FS128 # TLS 1.2 (suites in server-preferred order) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)ECDH secp384r1 (eq. 7680 bits RSA) FS256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)ECDH secp384r1 (eq. 7680 bits RSA) FS256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)ECDH secp384r1 (eq. 7680 bits RSA) FS128 TLSv1.3 is enabled into the client-ssl profile no-tlsv1.1 no-tlsv1 I also have serverssl profile attached to the VIP. Cannot find a way to see ECDHE-ECDSA into the ssl labs...Solved3.1KViews1like8Comments
warning tmm3[11615]: 01260013:4: SSL Handshake failed for TCP
Hi Team , We have an SSL error message on F5 : warning tmm3[11615]: 01260013:4: SSL Handshake failed for TCP (error from same single source ) We did not find any logs for VIP down or backend server down at the time of above SSL error message . Can you please advice what could be the issue in this case . VIP :433 Backend server listening on port 8040 SSL-client profile applied (only ssl offloading)2.6KViews0likes5Comments
SSL Handshake failed for TCP
We are seeing a ton of these messages in our logs. Several per minute from legit client IPs. However, the clients are not reporting any issues. SSL Handshake failed for TCP x.x.x.x:11555 -> x.x.x.x:443 These particular messages are NOT followed up a connection error message about an unsupported version as you might expect (for example: Connection error: ssl_hs_rxhello:7699: unsupported version (40)). I am trying to understand what is occurring. I did a pcap but was not able to get much out of it since there was a lot of normal traffic in there as well since these are good source IPs. I did not find any fatal handshake errors. Anything else I could look for in a pcap to see what is occurring? What other instances would you see a message like this? The frequency of the messages increase/decrease with peak and off peak times. The application is a typical IIS web app where the client uses a browser to access.warning tmm3[11615]: 01260013:4: SSL Handshake failed for TCP
Hi Team , We have an SSL error message on F5 : warning tmm3[11615]: 01260013:4: SSL Handshake failed for TCP (error from same single source ) We did not find any logs for VIP down or backend server down at the time of above SSL error message . Can you please advice what could be the issue in this case . VIP :433 Backend server listening on port 8040 SSL-client profile applied (only ssl offloading)
