Shiny server vulnerability related - Birthday attacks against TLS ciphers

Hi All,

We have received a vulnerability issue with Shiny server reported by internal cyber team.

Birthday attacks against TLS ciphers with 64bit block size vulnerability (Sweet32)
Disable and stop using DES, 3DES, IDEA or RC2 ciphers - how?

Update: From Redhat, I can see this note

Our internal unix/linux support team suggested, it should be fixed by application (shiny support team) and no fix yet from Redhat.

Any suggestion to fix this vulnerability at Shiny server? Appreciate your help on this.

Environment details:
Red Hat Enterprise Linux Server release 6.10
Shiny Server (Commercial) v1.5.1.760
Node.js v6.9.

1 Like

Hi Franco,

First, the version of Shiny Server Pro you're using is extremely old and should be upgraded if you're concerned about things like TLS ciphers. v1.5.1.760 still supports TLSv1, which you don't want to be running these days. Current versions of Shiny Server Pro support TLSv1.2+ only.

That being said, I think even SSP v1.5.1.760 doesn't use DES, 3DES, IDEA or RC2 ciphers, nor 64 bit block sizes. Is it possible that SSP isn't responsible for decrypting TLS traffic in your setup? It's very common for SSP to be deployed behind Nginx or Apache proxies, where the TLS decryption happens in the proxy. If that's the case, you should still upgrade to the newest Shiny Server Pro, but you'll have to solve the cipher problem in the proxy configuration.

For future questions with Shiny Server Pro, especially security-related ones, I suggest you email The support people do a good job of staying on top of cases and will escalate to the appropriate people within RStudio.

Hope that helps!

Thanks @jcheng for the detailed information.
I have reached Rstudio support team now and they too suggested to upgrade the shiny version.

This topic was automatically closed 54 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.