Server and client O/S? OpenSSL versions?
On 7/16/19 3:27 PM, Andy wrote: > Hey, so now I'm missing the ECDHE-ECDSA-AES256-GCM-SHA384 algorithms > inside of the server and client. > *~/.vnc/Server:3.log* > 16/07/2019 16:15:29 Available cipher suites: > DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:KRB5-DES-CBC3-MD5:KRB5-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:RC2-CBC-MD5:KRB5-RC4-MD5:KRB5-RC4-SHA:RC4-SHA:RC4-MD5:RC4-MD5:KRB5-DES-CBC-MD5:KRB5-DES-CBC-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-KRB5-RC2-CBC-MD5:EXP-KRB5-DES-CBC-MD5:EXP-KRB5-RC2-CBC-SHA:EXP-KRB5-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-KRB5-RC4-MD5:EXP-KRB5-RC4-SHA:EXP-RC4-MD5 > > *Client output with -loglevel 100* > CSecurityTLS: Available cipher suites: TLS_AES_128_GCM_SHA256, > TLS_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256, > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, > TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, > TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, > TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, > TLS_DH_anon_WITH_AES_256_GCM_SHA384, > TLS_DH_anon_WITH_AES_128_GCM_SHA256, > TLS_DH_anon_WITH_AES_256_CBC_SHA256, TLS_DH_anon_WITH_AES_256_CBC_SHA, > TLS_DH_anon_WITH_AES_128_CBC_SHA256, TLS_DH_anon_WITH_AES_128_CBC_SHA > > *However `openssl ciphers` :* > At least has the ECDHE-ECDSA-AES256-GCM-SHA384 that I'm looking for > (don't see the CBC but thats ok) > ECDHE-RSA-AES256-GCM-SHA384:*ECDHE-ECDSA-AES256-GCM-SHA384*:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DH-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DH-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DH-RSA-AES256-SHA256:DH-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DH-RSA-AES256-SHA:DH-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DH-RSA-CAMELLIA256-SHA:DH-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DH-DSS-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DH-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DH-RSA-AES128-SHA256:DH-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DH-RSA-AES128-SHA:DH-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DH-RSA-SEED-SHA:DH-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:DH-RSA-CAMELLIA128-SHA:DH-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DH-RSA-DES-CBC3-SHA:DH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:IDEA-CBC-SHA:PSK-3DES-EDE-CBC-SHA:KRB5-IDEA-CBC-SHA:KRB5-DES-CBC3-SHA:KRB5-IDEA-CBC-MD5:KRB5-DES-CBC3-MD5:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:KRB5-RC4-SHA:KRB5-RC4-MD5 > > > I'm not sure what's up with java not seeing it. > > I installed version 2.2.80 with the RPM > *Server command: * /opt/TurboVNC/bin/vncserver -SecurityTypes X509Vnc > -x509cert /home/user/ca/certs/localhost.cert.pem -x509key > /home/user/ca/certs/localhost.key.pem -rfbauth /home/user/ca/t.file > > *Client Command: *JAVA_TOOL_OPTIONS="" /opt/TurboVNC/bin/vncviewer > -loglevel 100 -x509ca /home/user/ca/certs/CA.cem -passwd > /home/user/ca/t.file localhost:1 > > > On Tuesday, July 16, 2019 at 1:03:13 PM UTC-4, DRC wrote: > > Yeah, or you can use the pre-release builds, which are generated > automatically by Travis and AppVeyor: > > https://turbovnc.org/DeveloperInfo/PreReleases > <https://turbovnc.org/DeveloperInfo/PreReleases> > > > > On 7/16/19 11:57 AM, Andy wrote: >> Wow! Thanks for the quick fix! >> >> I take all I need to try it out is to pull and build the latest >> turbovnc and it should work? >> >> Thanks again! >> >> On Saturday, July 13, 2019 at 1:37:31 AM UTC-4, DRC wrote: >> >> I went ahead and implemented a new security configuration >> file directive (permitted-cipher-suites), as well as a new >> Java TurboVNC Viewer system property. To achieve what you >> want, assuming you're using OpenSSL 1.0.2 or later, you can add: >> >> permitted-cipher-suites = >> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384 >> >> to /etc/turbovncserver-security.conf. That will prevent any >> ciphers other than the two you listed from being used on the >> server end, regardless of which ciphers are supported on the >> client end. It will also effectively disallow any of the >> TLS* security types, irrespective of the >> permitted-security-types directive (because anonymous TLS >> uses different ciphers.) >> >> As a belt-and-suspenders measure, you can also force the >> viewer to use only those ciphers by setting >> >> >> >> JAVA_TOOL_OPTIONS='-Dturbovnc.ciphersuites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384' >> >> in the environment on the client machine. >> >> The Xvnc log file, as well as the debug output from the >> viewer (-loglevel 100) will reveal which ciphers are >> available and which cipher was negotiated between server and >> client. >> >> DRC >> >> On 7/12/19 2:25 PM, Andy wrote: >>> That would be awesome >>> >>> Thanks! >>> >>> On Friday, July 12, 2019 at 2:46:20 PM UTC-4, DRC wrote: >>> >>> I did some digging, and unfortunately there is no way to >>> enable/disable >>> OpenSSL ciphers on a system-wide or per-user basis. >>> They have to be >>> configured on a per-application basis. I will >>> investigate adding a new >>> TurboVNC security configuration file property for this, >>> as it seems like >>> something that would be generally useful. >>> >>> On 7/12/19 10:03 AM, Andy wrote: >>> > Hey so I have some strict requirements on what >>> encryption ciphers we are >>> > allowed to use. >>> > >>> > Basically I need it to use >>> > either TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >>> > or TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384. >>> > >>> > From the viewer side I'm able to restrict the ciphers >>> available to it by >>> > modifying the java argument inside of the vncviewer >>> script: >>> > and adding on the options >>> > >>> -Djava.security.properties=/opt/test/java.security.restictive >>> >>> > -Djavax.net.debug=ssl >>> > >>> > Now I get an SSL Handshake error when I try to connect >>> - I think its >>> > because Xvnc doesn't support the 2 ciphers that I'm >>> trying to use. >>> > >>> > How would I go about enabling the two ciphers from the >>> server (Xvnc) >>> > side? I'd prefer to not have to recompile, but I'm not >>> afraid to. >>> > >>> > >>> > Thanks! >>> >>> -- >>> You received this message because you are subscribed to the >>> Google Groups "TurboVNC User Discussion/Support" group. >>> To unsubscribe from this group and stop receiving emails >>> from it, send an email to [email protected]. >>> To view this discussion on the web visit >>> >>> https://groups.google.com/d/msgid/turbovnc-users/717ffd21-4778-4e1c-a6ef-b4fb50f2bf59%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/turbovnc-users/717ffd21-4778-4e1c-a6ef-b4fb50f2bf59%40googlegroups.com?utm_medium=email&utm_source=footer>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> -- >> You received this message because you are subscribed to the >> Google Groups "TurboVNC User Discussion/Support" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected] <javascript:>. >> To view this discussion on the web visit >> >> https://groups.google.com/d/msgid/turbovnc-users/c82c784a-0fef-4f60-b6a6-dc281532dbee%40googlegroups.com >> >> <https://groups.google.com/d/msgid/turbovnc-users/c82c784a-0fef-4f60-b6a6-dc281532dbee%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > -- > You received this message because you are subscribed to the Google > Groups "TurboVNC User Discussion/Support" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/turbovnc-users/e850a8b0-9ee8-4780-bd53-2aa1d64bc935%40googlegroups.com > <https://groups.google.com/d/msgid/turbovnc-users/e850a8b0-9ee8-4780-bd53-2aa1d64bc935%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/1d28bc7d-9766-dfbb-f17c-e8089e86a943%40virtualgl.org. For more options, visit https://groups.google.com/d/optout.
