OpenVPN Support Forum

I have a client (doctor's office) that has an OpenVPN access server (VMware) and they had a PCI compliance scan ran, and it came back with several areas of concern for the doctor and myself. Could someone shed some light on what we could do to remedy the issues listed below.

• SSLv3 Supported
  TLSv1.0 Supported
  SSL version 3 protocol padding-oracle attack (POODLE)
  Block cipher algorithms with block size of 64 bits (like DES and 3DES) birthday attack known as Sweet32
  No X-FRAME-OPTIONS Header

Thanks in advance!!

Matt

I suggest you raise a support ticket on the Access Server Support portal:
https://openvpn.net/index.php/login.html

Likewise, I suggest contacting the support ticket system. However I also have these comments.

First of all, I assume you have Access Server 2.1.4. If you don't; upgrade.

> SSLv3 Supported
> TLSv1.0 Supported
> SSL version 3 protocol padding-oracle attack (POODLE)

You can fix this in the Admin UI under SSL Settings. Set the WEB SERVICES to TLS 1.2 for example. That fixes all those 3 messages. DON'T mess with the OpenVPN daemons SSL Settings unless you enjoy reinstalling some of your client software.

> Block cipher algorithms with block size of 64 bits (like DES and 3DES) birthday attack known as Sweet32

Simple, disable that cipher if you don't want to use it. The Access Server's web services supports a standardized list of ciphers, same as Apache2 and Nginx do, for example. Since this changes all the time, I'd suggest looking up a recommended cipher suite string for Apache2 or Nginx, and then applying that to the Access Server. See here on how to apply it;
https://docs.openvpn.net/docs/access-se ... phersuites

If your test still comes back with problematic ciphers after adjusting the web server cipher suite, then make sure that you disable those ciphers it complains about. You can look up OpenSSL documentation on cipher suite strings to learn which ciphers you need to disable. Probably it's something like adding :!DES to disable DES-based ciphers.

> No X-FRAME-OPTIONS Header

Not sure about this one, I can definitely see the header in there on the admin interface, though.