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?ssl_error_rx_record_too_long error
Hey guys, Have issue where in our prod environment I get ssl_error_rx_record_too_long when using ff. This works in our staging environment but our in our prod env we get this error. I verified both certs we are using match staging and prod as well the ciphers. I also did a capture from my laptop and did see any issues during the ssl handshakes and or cipher exchange. Has anyone experienced this before ? Thanks
Mitigating sslsqueeze and other no-crypto, brute force SSL handshake attacks
I’ve spent a bunch of cycles lately trying to analyze how resistant we are to a new class of SSL handshake attacks. You see, I have a thing for these weird, asymmetric crypto attacks. To this day, the SSL Renegotiation DDoS piece is still the most popular article of mine, partly because the obsessiveness passion comes through in the writing. The Classic SSL Renegotiation Attack The original SSL renegotiation attack tool, by the French group “The Hacker’s Choice”, repeatedly requested SSL handshakes with a vulnerable server. These handshakes were ten times more CPU-intensive for the server than they were for the attack client. The BIG-IP SSL stack has become increasingly resistant to the tool; the latest versions of BIG-IP automatically reject clients that attempt to send multiple renegotiations in a single connection (no iRule needed). A new class of handshake attack tools There’s a new class of SSL attacks tools - one could call them “No Crypto” attack tools. These new attack tools boost the computational asymmetry between the client and the server to a 2 nd order multiplier by vastly reducing the client workload. Basically, the new attack clients don’t do any crypto at all – they just send pre-canned packets that look like an SSL handshake but aren’t. In his excellent analysis of handshake attacks, Vincent Bernat writes about these much more efficient attack tools. “With such a tool and 2048bit RSA certificate, a server is using 100 times more processing power than the client. Unfortunately, this means that most solutions, except rate limiting, exposed on [in his analysis] may just be ineffective.” One of these tools is called sslsqueeze and is written by none other than Michal Trojnar, the author of stunnel (the original SSL tunnel utility). Thankfully the tool isn’t widely available, but I was able to get a copy of the source. The sslsqueeze code is super tight. It is structured in such a way as to be almost entirely I/O-bound, so it is extremely lean with regard to the CPU. Here it is throwing over a thousand handshakes a second against an Apache server using about 2% of the client CPU. Each "success" means that the Apache server went to all the trouble to try to decrypt a bunch of junk and then returned "bad-record-mac" each time. Frankly, I'm impressed that an Apache server can turn around that many 2048-bit decrypts without hardware offload. That's what four cores will get you; each one doing about 300 decrypts per second (and little else). After letting it run for a minute, the time command shows that sslsqueeze is nearly entirely I/O-bound. Not CPU-bound, which is what we expect since it's not doing any real crypto. sslsqueeze real 1m3.514s user 0m4.264s sys 0m7.904s This is a single client, using almost none of its own CPU, keeping all four cores on a web server busy. Can sslsqueeze overwhelm cryptographic accelerators? Next I ran sslsqueeze against a real, physical BIG-IP with cryptographic offload accelerators. I keep a BIG-IP 3900 at my house for just these kinds of cases where we need to see how the underlying Cavium cryptographic accelerators respond. This platform does not represent state-of-the-art hardware, but the BIG-IP 3900 remains one of the most widely-deployed F5 appliance models to-date. See all those failures? That's because BIG-IP is returning record-overflow instead of bad-record-mac which is what sslsqueeze is expecting. The effect is really the same though. The 3900's crypto card is only rated for about 3000 SSL TPS (with 2K keys). The sslsqueeze program (on a single client!) is basically consuming all of that capacity without even really trying. The modern equivalent of the 3900 is the 4200v, which is rated for 9000 TPS. The attack client computer that I bought for $200 at a used computer store can generate upwards of 20,000 (!!!) fake handshakes per second. That’s not good. Not good at all. If even cryptographic processors can’t absorb the attack, how can you stop sslsqueeze? Disabling SSL Renegotiation doesn’t help During the original SSL renegotiation attack analysis, simply disabling renegotiation was sufficient to foil that attack. In fact, most servers were disabling renegotiation at the time to avoid a completely different vulnerability. However, disabling renegotiation has no effect in this case. The sslsqueeze tool is so efficient that it doesn’t need to multiplex SSL handshakes through a single TCP connection. It simply opens a new TCP connection, sends its junk, waits for a response and then closes the connection. iRules to the rescue once again If disabling renegotiation doesn’t work and cipher selection doesn’t help and virtual server rate-limits don’t apply, what is left? After exhausting all the options available in the BIG-IP 11.5 native SSL implementation, and still unable to effectively mitigate sslsqueeze, I turned to iRules. As a colleague of mine likes to say, iRules make the difficult tasks easy and the impossible tasks merely difficult. In other words, when all else fails, you can always write an iRule. iRule #1 – ssl_hx_rlimit Here’s an iRule I had some fun putting together – ssl_hx_rlimit (SSL handshake rate limit). It’s a nice, clean iRule that has the following benefits: Very small chance of false positives. Minimal performance degradation (not measurable in my setup). Minimal memory requirements (just one state variable per client address). Not signature based – should catch all kinds of handshake monkey business. Probably the biggest issue with this iRule will involve so-called mega-proxies or giant NATs where thousands of individual clients appear to come from the same IP (think AOL or other service provider). If an attacker is hiding behind one of these mega-proxies, then iRule #2 (see below) will have to be used instead. The full iRule and it’s commentary can be found on this DevCentral page:ssl_hx_rlimit iRule iRule #2 – sslsqueeze_rx As stated above, the ssl_hx_rlimit iRule won’t really work if the attacker is mixing their bogus requests in with other valid requests from the same mega-proxy.There may also be other pathological cases as well where the ssl_hx_rlimit fails and you just need a quick fix to throw in place. iRule #2, sslsqueeze_rx, is that quick fix. It has these benefits: Extremely fast. No additional memory requirements. Can handle the mega-proxy cases But also this main drawback: Very easy for an attacker to change the attack signature. sslsqueeze_rx works because the sslsqueeze tool sends the exact same ClientHello every time. Therefore, all a signature-based system has to do is look for this incoming packet and block the connection. If the attacker changes the ClientHello at all then you’d have to modify the static::sxch to represent the new signature. A determined attacker would be including random data in the 32 bytes of random data anyway. You could still key off the three specific ciphers that sslsqueeze is sending if you needed to. The full iRule and it’s commentary can be found on this DevCentral page:sslsqueeze_rx iRule Long Term Fixes in TLS? The IETF TLS working group has taken a look at this problem recently and there is a proposal for a much more elegant fix than dropping or rate limiting. Enter “Client Puzzles”. There is a proposed draft for to ask the client to perform some kind of crypto puzzle to prove that it is a real TLS client and not some hack tool. It reduces the asymmetry by putting an arbitrary load on the client. When I had told a colleague about this problem he said “instead of puzzle, could you have the client perform some Bitcoin block chain verification instead?” We discussed this option at the TLS meeting, but decided that it would lead to too much “gaming” on behalf of malicious servers, heheh. http://tools.ietf.org/html/draft-nir-tls-puzzles-00 The puzzles would very likely be based on this trick. · Server chooses a random number. · Computes SHA hash for it. · Asks client “which number, in this range, hashes to this value?” You can increase the work done by the client by simply increasing the size of the range hint (keyspace). Making it “stateless” like a SYN cookie is a little trickier but could be done. The client puzzle solution remains an interesting idea at this point with no real plans to be included in the handshake for TLS 1.3. Another possible mitigator is the fact that the TLS protocol is slowly switching toward elliptic-curve key exchanges that are more balanced in terms of client versus server CPU load. This proposal is before the IETF committee right now for TLS 1.3. It is my hope that this will reduce the threat scope for these so-called “no crypto” attacks. Conclusion As I write this, attackers are still attacking the applications rather than the TLS servers themselves. Typically the attackers will find a large PDF file or an expensive database query and then they’ll just open TLS connections and request those URIs repeatedly. We stop those attacks with the web application firewall. Internet Engineering Task Force drops RSA from next SSL standard (TLS 1.3) http://t.co/BCw64n4yFY via @kennwhite < wow! @rmhrisk — David Holmes (@dholmesf5) May 4, 2014 As more web application firewalls get deployed and caching gets better and better, the attackers may start switching to TLS protocol attacks. Until TLS 1.3 gets adopted broadly supported you may find your SSL site under assault from one of these new attack tools. And if that happens, hopefully you’ll be able to defend your application with one of these two iRules. Let me know if you see an attack, or if you see ways to improve upon these iRules.
SSL Handshake errors
We are facing intermittent issues in our Exchange connectivity thats loadbalanced in F5 boxes (LTM version is 11.3.0 HF6 ). On observing the LTM logs, I noticed many instances of SSL handshake failures. Will these errors have any impact of the connectivity? Any idea how to resolve these errors. 01060111:3: Open SSL error - error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol. 01060111:3: Open SSL error - error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure. 01060111:3: Open SSL error - error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure. 01060111:3: Open SSL error - error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure. 01260013:6: SSL Handshake failed for TCP from x.x.x.x:62373 to y.y.y.y:443 01260013:6: SSL Handshake failed for TCP from x.x.x.x:45849 to y.y.y.y:443
SSL Handshake error
I have one of my VIP configured to use SSL profile, ssl handshake is failing. I have tried using default ciphers and also tried using All ciphers but still the handshake is failing. Here is the tcp dump. New TCP connection 1: 10.xx.xx.254(3990) <-> xx.xx.xx.131(443) 1 0.2331 (0.2331) C>S TCP RST New TCP connection 2: 10.xx.xx.254(30154) <-> xx.xx.xx.131(443) 2 0.2337 (0.2337) C>S TCP RST New TCP connection 3: 10.xx.xx.253(40997) <-> xx.xx.xx.131(443) 3 1 0.2318 (0.2318) C>S Handshake ClientHello Version 3.3 cipher suites TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_SHA Unknown value 0xc028 Unknown value 0xc014 Unknown value 0xc027 Unknown value 0xc013 Unknown value 0xc012 Unknown value 0xff compression methods NULL 3 2 0.4649 (0.2331) S>C Handshake ServerHello Version 3.1 session_id[32]= f6 2f cf 54 10 74 f3 07 70 88 39 b4 d2 3b af bb f7 bc d3 a4 e1 67 2e 80 60 39 59 43 e9 61 bf 22 cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA compressionMethod NULL 3 3 0.4650 (0.0000) C>S Alert level fatal value handshake_failure 3 0.4651 (0.0000) C>S TCP RST
