Xen Orchestra TLS minimum version requirement -- How to set?

kevdog

Hi I'm referencing a part of the XO configuration found in the config.toml file:

# Specify to use at least TLSv1.1.
# See: https:#github.com/certsimple/minimum-tls-version
secureOptions = 117440512

I visited the site referenced however I don't see any numbers that would indicate the secureOptions directive. The site has examples such as the following:
secureOptions: minimumTLSVersion('tlsv11')

On this site there isn't any mention regarding the use of numbers. How did the configuration decide on this setting?? I'd like to use tlsv12 as minimum.

olivierlambert

Ping @julien-f

julien-f

@kevdog We'll remove this setting from future versions.

In the meantime, you should be able to set these:

# Already the default value in Node 12 but you can explicit it
minVersion = 'TLSv1.2'

secureOptions = null

kevdog

@julien-f

Snippet of config.toml file:

# These options are applied to all listen entries.
[http.listenOptions]
# Ciphers to use.
#
# These are the default ciphers in Node 4.2.6, we are setting
# them explicitly for older Node versions.
ciphers = 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA'

# Tell Node to respect the cipher order.
honorCipherOrder = true

# Specify to use at least TLSv1.1.
# See: https:#github.com/certsimple/minimum-tls-version
minVersion = 'TLSv1.2'

secureOptions = null

#secureOptions = 117440512

At least for me including those options didn't work.

Oct 27 14:54:32 ubuntuxo systemd[1]: Started XO Server.
Oct 27 14:54:33 ubuntuxo xo-server[103642]: ✖ Unexpected character, expected "nan" at row 115, col 18, pos 3784:
Oct 27 14:54:33 ubuntuxo xo-server[103642]: 114:
Oct 27 14:54:33 ubuntuxo xo-server[103642]: 115> secureOptions = null
Oct 27 14:54:33 ubuntuxo xo-server[103642]:                       ^
Oct 27 14:54:33 ubuntuxo xo-server[103642]: 116:
Oct 27 14:54:33 ubuntuxo xo-server[103642]: TomlError: Unexpected character, expected "nan" at row 115, col 18, pos 3784:
Oct 27 14:54:33 ubuntuxo xo-server[103642]: 114:
Oct 27 14:54:33 ubuntuxo xo-server[103642]: 115> secureOptions = null
Oct 27 14:54:33 ubuntuxo xo-server[103642]:                       ^
Oct 27 14:54:33 ubuntuxo xo-server[103642]: 116:

If I changed the secureOptions back to prior value with minTLS version the server would at least start, however I have no way to verify if functioning correctly.

julien-f

@kevdog My bad, null is not supported in TOML files.

You can simply rebuild Xen Orchestra from the sources, I have removed these settings: https://github.com/vatesfr/xen-orchestra/commit/8d2e23f4a8c7ce49eeaf57093ff87e98cc787ce9

0

julien-f committed to vatesfr/xen-orchestra

fix(xo-server): remove TLS config to use native settings

See https://xcp-ng.org/forum/topic/3747/xen-orchestra-tls-minimum-version-requirement-how-to-set

kevdog

@julien-f

I reviewed your commit, however I don't understand your heading (remove TLS config to use native settings).

If not specified in the config.toml file, what are the native settings? Where are these specified?

julien-f

These are the default settings built-in Node:

$ node
Welcome to Node.js v12.18.2.
Type ".help" for more information.
> tls.DEFAULT_MIN_VERSION
'TLSv1.2'
> tls.DEFAULT_CIPHERS
'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA'

kevdog

@julien-f

Ahh - very nice -- I guess the point of my post was pointless.

Thanks for help.

julien-f

@kevdog Not at all, it made us aware that our vendor config was no longer relevant

Thank your for your report!