SSL/TLS interface default configuration

Software SW tweaks
1

Hello,

I just recently ran a security audit of my network, and got multiple warnings all due to some weak SSL/TLS configuration on the admin interface.

  • 5.0 (Medium) SSL/TLS: Report Vulnerable Cipher Suites for HTTPS

  • 4.3 (Medium) SSL/TLS: Report Weak Cipher Suites

  • 4.3 (Medium) SSL/TLS: Diffie-Hellman Key Exchange Insufficient DH Group Strength Vulnerability

  • 4.3 (Medium) jQuery < 3.4.0 Object Extensions Vulnerability

Unfortunately I was not able to pinpoint the configuration file for the turris administration web interface. So maybe one of you can point me out where it is. Iā€™ll be happy to create a pull request for a hardened configuration.

Here follow the details for all the issues above.

SSL/TLS: Report Vulnerable Cipher Suites for HTTPS
ā€˜Vulnerableā€™ cipher suites accepted by this service (443/tcp)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

Solution: The configuration of this services should be changed so that it does not accept the listed cipher suites anymore.

SSL/TLS: Report Weak Cipher Suites
ā€˜Weakā€™ cipher suites accepted by this service (443/tcp)
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_SEED_CBC_SHA

Solution: The configuration of this services should be changed so that it does not accept the listed weak cipher suites anymore.

SSL/TLS: Diffie-Hellman Key Exchange Insufficient DH Group Strength Vulnerability
The SSL/TLS service uses Diffie-Hellman groups with insufficient strength (key size < 2048).

Solution: Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE) or use a 2048-bit or stronger Diffie-Hellman group

System Information
Device: Turris Omnia
Turris OS version: 3.11.16
Kernel version: 4.4.187-a890a5a94ebb621f8f1720c24d12fef1-0
foris version: 100.3-3.6-1

Cheers,
Hashlog

1 Like
2

Maybe youā€™ll better not expose your router interface on the Internet.

Web interface settings are in /etc/lighttpd

3

You dont have to directly expose it to the internet. Still it is a best practice to disable RC4 and 3DES because it is unsafely. There are some techniques to target the router through browser scanning local network ranges even if remote access is disabled.

4

my router interface is not exposed to the internet. The scans were done internally.

Thank you. I managed to harden the configuration, so that the weak ciphers are not used any more. The following options have to be added to both IPv4 and IPv6 sockets in the /etc/lighttpd/conf.d/ssl-enable.conf:

ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
ssl.cipher-list = "EDH+CAMELLIA:EDH+aECDSA:EECDH+aECDSA+AESGCM:EECDH+aECDSA+SHA384:EECDH+aECDSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA"

I will try to make a pull request, so that this default safe configuration gets into the upstream branch.

5 Likes
5

Pull request submitted.

1 Like
6

To my understanding this can be set in the global directive as opposed to per Socket and then applies to all instance and both ipv4 and ipv6.

Additional hardening

ssl.openssl.ssl-conf-cmd = ("Protocol" => "-TLSv1.1, -TLSv1, -SSLv3")

or if the client supports TLSv1.3 then extend to

ssl.openssl.ssl-conf-cmd = ("Protocol" => "-TLSv1.2, -TLSv1.1, -TLSv1, -SSLv3")

1 Like
7

Good point! I updated the PR accordingly.

SSLv2 and SSLv3 has already been disabled in my PR. I would let TLSv1.2 enabled, since that could potentially lock out a lot of devices and the gain in security is not as big as the probable loss in usability.

About disabling TLSv1.1 and TLSv1: Iā€™m not sure if those should be disabled or not.

1 Like
8

Perhaps not in a LAN but it certainly does on WAN.

Both are less secure than TLSv1.2 which should be supported really by any client (app) nowadays.

9

This SSL conf generator by Mozilla is quite handy to generate configs for different server types/versions

1 Like
10

SSL/TLS versioning can be done with a one line, e.g.

ssl.openssl.ssl-conf-cmd = ("Protocol" => "-ALL, +TLSv1.2")

1 Like
11

I would also vote for TLS 1.2 only.

It was standardized 11 year ago so thatā€™s enought time to spread all over the world. And Turris is secure device so it should be in lead :wink:

Other thign is that TLS 1.0 a 1.1 is planned to be deprecated anyway at 2020 (by Google, Mozilla, Microsoft and Apple at least).

TLS 1.3 support would be fine, it is a final standard already a year. But it requires OpenSSL 1.1 which is not part of TOS.

1 Like
12

It will be though but only onwards with OpenWrt 19.x (TOS5.x)

13

For the TOS5.x on this node the following conf is used

### SSL
ssl.openssl.ssl-conf-cmd = ( "Protocol" => "-ALL, +TLSv1.3" )+( "Curves" => "X25519:X448:P-521:P-384:P-256" )
setenv.add-environment = ( "HTTPS" => "on" )
setenv.add-response-header  = ( "Strict-Transport-Security" => "max-age=63072000" )

### Redirect http -> https
$HTTP["scheme"] == "http" { url.redirect = ("" => "https://${url.authority}${url.path}${qsa}") }

Perhaps for TOS4x it could be useful

### SSL
ssl.openssl.ssl-conf-cmd = ( "Protocol" => "-ALL, +TLSv1.2" )
ssl.disable-client-renegotiation = "enable"
setenv.add-environment = ( "HTTPS" => "on" )
setenv.add-response-header  = ( "Strict-Transport-Security" => "max-age=63072000" )
ssl.cipher-list = "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA25"
ssl.ec-curve = "X25519:prime256v1:secp384r1"

### Redirect http -> https
$HTTP["scheme"] == "http" { url.redirect = ("" => "https://${url.authority}${url.path}${qsa}") }
1 Like
14

Thank you everyone again for your feedback. I added the changes to the pull request (TLSv1.2 only, ssl.openssl.ssl-conf-cmd).

Regarding the cipher suites: itā€™s also subjected to review from cynerd on github. I will wait for the response there before updating the pull request.

Thank you @anon50890781 for the Mozilla config generator link. Thatā€™s a really helpful tool I didnā€™t know.

1 Like