SSLVPN Firebox Webserver Ciphers - PCI Compliance
IN the recent months, while performing PCI DSS scans against the public addresses hosted by our Firebox, it has now been determined that the ciphers used on the Firebox Webserver are unsecure and weak, causing failed reports for PCI.
Anyone else having this issue? After working through multiple tech support engineers at WG, they have told me that the ability to change ciphers in in a future release, and then the next tech told me that there are NO plans for this and basically I am SOL if I am using SSLVNP as they have no plans to update it.
How is this possible coming from a company that has a product designed around security?
Is anyone else using WG and have PCI DSS compliance?
Has anyone else done their quarterly scans and found this issue?
I feel that support at WG is slowly going downhill. Which is very unfortunate as we were planning to role out some larger Firebox appliances, however this might put a halt on that...
Comments
Maybe WG are low on support and Engineering People as many others are combined with many (new) Products.
These now show up as a HIGH finding on a PCI DSS scan. This is going to cause a lot of people with PCI networks anxiety. So far WG is no help on this matter.
CBC seems to be the culprit here.
I do not know much about cipher suites, but i can read GCM is preferred over CBC and have been for years.
But i also see Windows still use these ciphers as default still:
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
Guess Windows has it duo to backwards compability, but one should thing it would be easy to remove the CBC ciphers from the sslvpn implementation?
/Robert
One would think. Basically what WG has now told me, is they have a feature request to allow users to configure the suites they want, but no plans on the road map in the future to implement is. I have opened a new feature request with them to simply remove the weak ciphers, but obviously that will take a long time to get implemented. Anyone who needs that web server running for SSLVPN is going to have this issue with PCI scanning. I am actually surprised this is not already a larger issue. Unless many orgs just don't use WG SSL VPN as standard practice.
Hey Cdubyamn,
Would you mind sharing which vendor is running the PCI scan that identifies something here as a HIGH vulnerability. We've been reviewing this recently and have seen one vendor indicating Medium for this, however the details fail to report a specific issue, but rather reference Mozilla's current recommendations.
Our current implementation follows NIST SP800-52r2 recommendations, which include the CBC ciphers that your scan is complaining about.
We're actively reviewing the status of these, however we're missing information on what vendors are identifying this in their scans, and information that supports these scan results, and appreciate any additional context you may be able to share.
Thank you.
Hello,
I am not the original poster but I am having the same issue with CBC ciphers and PCI scanning, with the exact same looking results screenshot as cdubyamn posted above. The vendor in question is SecurityMetrics. Has there been any other update on this?
Hi @tjordanb
If you can please create a support case, and attach the scan to the case, it would be helpful in identifying what specifically they are identifying as high. As Ben mentioned, we're following current guidelines via NIST SP800-52R2.
If you do create a case, if you can please reply here with the case number, I can make sure it gets sent to the correct team to help with this.
-James Carson
WatchGuard Customer Support