Apache and openssl version RAIDiator 4.2.27.

They are mentioned in the GPL

We have some security fixes in 4.2.28 beta: http://www.readynas.com/forum/viewtopic.php?f=51&t=70385

Are the security fixes what you are wondering about?

I want to support TLS 1.2 and I have very outdated openssl.
I want to support Forward Secrecy and for that I need never version of apache and ssl
and finally I want to be able to turn off SSLCompression. That directive is working with apache 2.2.24 afair other sources saying 2.4.x.
Anyway, are you aware of the versions in current latest RAIDiator?

It's 2.2.6 in RAIDiator 4.2.x, I think.

The OS6 beta firmware has 2.2.29

I have some older version of RAIDiator and it is indeed 2.2.6 which is way too old. Why newer versions of apache aren't included? Latest version is 2.4.12.
Now I wound't expect to have latest version with every RAIDiator update but apache 2.2.6 was realease in September 2007!
Can we expect to see apache updated?

We include backported security fixes as required. A major update to apache would require a lot of regression testing and probably some code to be rewritten as well. I don't think we will update it.

Well if the OS beta has 2.2.29 already, so some testing to some extend has been done already. I know it's different platform and hardware etc.
For those who don't have ssh access and apache config is black magic your security fixes are more the welcome but still there is a lot to do.
I can only assume that you have some older nas devices lying around and one could update apache and see what will blow up.
We are running almost 8 years old software and at some point update might be critical. You never know next security flaw gonna be.
What gonna happen if there is a security hole that requires apache upgrade? What if simple fix, will not work?
I can't afford to change hardware at the moment just to have new software when my current nas could support one of the latest apache versions.
I'm still seeking an answer about openssl.

If there is a security fix required and backporting becomes too much work then we would need to reconsider whether to upgrade it to a newer version.

Considering how critical apache is to the NAS functioning properly any major update to it would require extensive testing.

OS6 is a very different OS and with 6.0.0 we had the advantage of not needing to support any updates from older firmware.

I hardly believe that I am the only one who would like to see apache being elevated to decent version.

I have been playing yesterday with https://www.ssllabs.com/ssltest.
With default settings I'm getting grade F!
With only one line of adjustments my grade was bumped to B.

This server does not mitigate the CRIME attack. Grade capped to B. Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2. MORE INFO » The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B. The server does not support Forward Secrecy with the reference browsers. MORE INFO »

The only think I can improve is generate new certificate with SHA2. Rest is limited by software.
Further more I can't use ECDH because it requires at least TLSv1.1.
Therefore a suggestion to improve apache security out of the box (disable NULL, aNULL, eNULL, DES3, MD5 maybe RC4 even) and I hope we can get attention of Jedi and updating Apache and openssl to decent version will be at least discussed.

The concern over SHA-1 certificate hashing is that with sufficient effort someone can find another certificate that has the same hash. If you can find a pki cert that has the same hash as (for instance) paypal, then you can set up a fake paypal site, and https can't detect it. One source suggests that the cost of doing this with cloud computing resources might drop to $100,000 US in 2017. People are prudently starting to phase out SHA-1 cert hashing, so that there will be no massive problems later on.

However, self-signed certficates (used by ReadyNAS) are not verified with the hash function anyway - the cert itself has to be installed in the client browser. It isn't clear yet if chrome/firefox will deprecate SHA-1 hashing for locally generated self-signed certs. Microsoft is apparently not planning to deprecate them.

It would be a good idea to upgrade the self-signed cert to SHA-256 anyway since some browsers in the future might drop SHA-1 cert hashing, but there is no security risk.

But if you are deploying a pki certificate (e.g., provided by a certificate authority), then you should migrate to SHA-256 since they are verified by the hash function.

BTW, there are other uses of SHA-1 that are not vulnerable to this particular attack (called a collision attack). In particular, HMAC-SHA1 is still considered strong, and there are no plans to deprecate it.