You have to allow the legacy ciphers that are weaker and easier to exploit. You have to allow a handshake method that has at least a half dozen know exploit factors because of how weak RSA key exchange is. Also, in OpenSSL 3.5, you have to go to the lowest policy to make this work so yeah it’s “everything” in that case.
Honestly, FreePBX lowers its security policies across the board to make legacy phones work opens the system to exploits and attack vectors because the legacy TLS isn’t as secure as you really think it is.
Point taken. I was being too general and not specific enough in this instance. It’s even further away from what the clients in this case can apparently offer in this use case.
Yes but not in ways you are thinking. To allows the S-Series phones you must allow entire suite families, just not members of the family. So you need to enable RSA key exchange, AES-CBC and SHA1-HMAC this is all TLS 1.0/1.1 era stuff. Early TLS 1.2 framework relied on these from earlier versions of TLS plus new stuff. Later versions of TLS 1.2 started relaying less (or removing) the old TLS 1.0/1.1 hold overs.
So the customization is enabled TLS 1.0/1.1 legacy ciphers, RSA handshakes, etc while enforcing TLS 1.2 or higher.
IMO, this does not present an exploit possibility to the server. Even if the server supported HTTP, it could only be compromised by an application level vulnerability, e.g., SQL injection.
Now it does result in some (very small) risk to the client, but that was always the case for S series phones and users of an EOL device are willing to accept it. If the connection is from a modern phone but using legacy ciphers, the server could simply return an error.
My final $0.02 about this is that most larger providers started phasing out legacy TLS support around 2020. And the IETF officially moved away from it around 2021, if I am not mistaken. This particular line of phones weren’t EOL at that point. A firmware update being published (around the time most all major providers were keeping up with the curve) could’ve avoided this entire thread I suppose. Then again, armchair quarterbacking which offers little to the discussion.
Which is exactly what happens right now. A failed handshake or mismatched ciphers will throw an error back to the client, in this case the phone. The server will mostly also log such an error. None of which, as the user, you will see. It just doesn’t connect from your point of view.
How would that be known during the TLS handshake? That information wouldn’t be available at that point. It wouldn’t be able to be used until TLS is established.
IMO, there are at least three ways to fix this problem:
Set the server to allow legacy (S series) devices to connect via a lenient handshake, but require TLS 1.2 strict for non-EOL devices.
Analyze the consequences of using a less strict policy for all devices. I believe that due to the single short messages sent in each direction, the vulnerabilities of a weaker cipher do not apply for this case.
Temporarily, e.g., for two weeks, revert to the less secure policy. This will give S series users time to implement DHCP option 66, hard-code the provisioning URL in the phones, or acquire new phones, without any loss of service.
You can’t do this. OpenSSL will not allow for this. Once you open RSA handshake and use the RSA key exchange it’s open for anyone that uses it. You can’t tell what the device is until after the TLS connection is established.
The length of the message isn’t considered in security. The TLS vulnerabilities don’t care about message length. On top of that it could contain important things like your provisioning creds or IPs or cert information that can be used. TLS risk assessment doesn’t count the message length because the length doesn’t matter, what’s inside the packet matters.
It hasn’t worked for two months now. For two months they’ve told people to use Option 66 to redirect the phones to your own provisioning server. And let’s been honest here, that two weeks will be asked to be “another week or two” or people will come back 4 weeks later and say “Oh I missed this, I have 700 phones I really need the fix back in place”
Perhaps @mwhite or @penguinpbx should get off their laurels and send a damn announcement about this to users with S-Series phones or just in general the announcement should have went out two months ago, @mwhite admitted they dropped the ball…so pick it up and do something with it. Sangoma made multiple mistakes with all of this, at least try to show some good will and fix what mistakes you can by at least communicating with the base it’s not that hard, your sales team will do it when they want to make money…so the tech team should be able to do it too to keep people fecking happy.
Right but it came up because there was no announcement and in the two months since Sangoma, being fully aware, did not release an announcement. Sangoma had two months to properly communicate this after 1) the update was done or 2) after that post was made. It’s been crickets. This entire thread we are in right now could have been avoided if Sangoma communicated this
@penguinpbx You need to suck it up and admit Sangoma screwed up multiple times on this. Sangoma did not update firmware in the S-Series in the two years that TLS 1.3 and OpenSSL 3.0 became the standards. That would have avoided all of this. Sangoma failed to communicate security updates that would make EOL devices incompatible with the RS service. And Sangoma failed to communicate a second time after it was actually made public. Sangoma (ie you) offered a solution for a massive problem buried in a reply in a thread.
Please stop making excuses as to why it happened, just accept it happened and make amends.
For example:
There are two virtual hosts on the server, rs.sangoma.net and rss.sangoma.net. In their Apache2 configs, rss has SSLCipherSuite set to the “strict” ciphers, while rs also includes the best cipher available on S series. When the phone connects to rs, the server proceeds normally if it’s an S series phone. Otherwise, it sends a 302 redirect to rss, which will accept a valid request from a non-EOL phone, or bounce it if an attacker is attempting a downgrade.
That doesn’t solve the issue of having everything connect to a weaker TLS profile/policy on rs.sangoma.net. Everyone phone will have to do an insecure handshake with some phones being told “go over here for the secure handshake” which does not solve the issue of having system exposed to the public with weak and vulnerable security profiles.
Additionally, you’re now making all the other phones that support TLS1.2 changes or TLS1.3 to maybe do another DNS lookup but for sure have an additional TCP connection, TLS handshake and HTTP request.
Again, we keep going back to in order to allow S-Series phones Sangoma will have to weaken their security policies and adding a second vhost doesn’t add anything of value at that point either.
The only P-series phones we’ve purchased came out of the box in a boot-loop. OOTB, non-functional. They were replacement for an office full of S-series phones that all suffered premature LCD failure.
It took an enormous effort to get to a competent engineer at Sangoma who, after a LOT of unpaid time on our part, agreed that there was a firmware bug. He committed to look into it. We never heard anything back. I was later told he’d left the company.
We eventually got the phones to work, but what should have been a five-minute setup in EPM ended up being a 10-15 HOUR project with no support from “support”.
We won’t be buying any more P-series phones. Ever.
But I’m curious: Why are S-series phones that Sangoma fully dropped support for three years ago still for sale NEW today? Are you still manufacturing and/or selling hardware that is immediately unsupported?
Also…mods editing titles of posts to make it look like the end user is at fault is exceptionally poor integrity. Really inexcusable.
Changing “… not working on S-Series phones” to “…not working on EOL S-Series phones” is squarely in this category.
WTF, folks, do you really feel okay doing things like this? Good grief.
There is a VERY simple solution for this and your other EOL products.
Publish the source code of the firmware and the information on the toolchain used to build it on github.
Then you can wash your hands of all of this. Customers with hundreds of these phones can then download the source and setup their OWN ZTF servers using their own domain name, update the firmware with the new name of their very own ZTF server, and run their own configs.
Or if you don’t want to do that - you can provide the exact location in the phones firmware binaries where the names rs.sangoma.net or whatever the DNS name of the ZTF server is. Customers can then load up the phone firmware into a binary editor, replace the ZTF dns name with their own DNS server name, flash the modified firmware to the phone, and be off to the races.
Lots of companies do this. For example Microsoft did this with the DOS source code:
