SSL Question

[chico]

Recently, our PCI security scan failed due to the following:

Description: SSL server accepts weak ciphers Severity: Potential Problem Impact: A remote attacker with the ability to sniff network traffic could decrypt an encrypted session. Resolution For Apache mod_ssl web servers, use the [http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite] SSLCipherSuite directive in the configuration file to specify strong ciphers only and disable SSLv2.

Our SSL was setup via the keytool as our server's only purpose is serving up Servoy.

Does anyone know anything about this or how to accomplish this with the Servoy App Server or is this strictly an apache thing?

We are running Linux - CentOS 5

[chico]

For those watching at home, we found this:

http://www.sslshopper.com/article-how-to-disable-weak-ciphers-and-ssl-2-in-tomcat.html

We made the changes and restarted Servoy APP server but we're still getting errors on our PCI scan.

Now, this may be something outside of Servoy, but is anyone aware on a CentOS-flavored Linux server where else we might have to disable weak ciphers?

[chico]

The excitement continues... it appears the warning is on the 1099 port.

Anyone have any ideas?

[chico]

Has anyone else here dealt with PCI certification (for credit card processing) in Servoy?

If our server is now failing the certification because of weak ciphers on port 1099, would it make sense to just use HTTP tunnel connection mode?

And if so:

1. Should we up our server resources with more RAM due to the HTTP Tunnel using more server-side resources?
2. If we change the connection mode, what will happen when all of our users double click their shortcut icon on their desktops? Will it error and require a clearing of the cache AND .servoy folder?

Thanks mucho.

[jcompagner]

What kind of certificate are you really using then for RMI? (so in your servoy keystore)
Is it a real valid signed certificate from a trusted source? So the same as you would use for tomcat/apache https itself (so for the tunnel?)
then it is pretty much the same thing

[chico]

We are using a real, certified crt by a CA. We simply followed the steps found here:

http://wiki.servoy.com/display/public/t ... +Authority

The issue with the PCI test is it feels as if port 1099 is allowing SSLProtocol v2. [SSLv2]

If you read through above, we modified the code in the server.xml to NOT use this protocol.

But the test still fails.

[jcompagner]

So the problem is that that the ssl port send out that it supports SSLv2?
(and you expect SSLv3 or TLS 1.0) ??

http://stackoverflow.com/questions/4682 ... ient-hello

It seems that that is just what Java sends out, but i think in the end it just really talks v3

[jcompagner]

it seems that upgrading to java 7 will disable it by default:

http://docs.oracle.com/javase/7/docs/te ... ents7.html

[chico]

Aha! That looks like the ticket.

NOW, what possible fun could erupt by moving our server to use Java 7? Are there any known issues there?

[sebster]

Hi,

Unfortunately it is not possible to tell Java not to use SSLv2 on port 1099 currently. Server.xml only applies to tomcat connectors, not to the RMI port.

I'm not sure if Java 7 does or does not allow SSLv2 to be negotiated, best way to find out is to try it.

Best regards,
Sebastiaan

[chico]

Thanks Sebastiaan,

We can look at Java 7, but right now, we need the fastest game plan to getting PCI compliant.

It's integral if we want to use our solution in a SaaS environment. It's frustrating that it's not been in an issue for 2 years, but for some reason, the scrutiny of the security scans changed.

So, If our server is now failing the certification because of weak ciphers on port 1099, would it make sense to just use HTTP tunnel connection mode?

And if so:

1. Should we up our server resources with more RAM due to the HTTP Tunnel using more server-side resources?
2. If we change the connection mode, what will happen when all of our users double click their shortcut icon on their desktops? Will it error and require a clearing of the cache AND .servoy folder?

OR is our only option trying Java 7?

[jcompagner]

it will not cost that much more memory to use http tunneling
clients will switch automatically, because network settings will be pushed to the client every time.

[jcompagner]

by the way even in java 6 it is not that it is SSLv2 that you talked to it is just that special SSLv2Hello will be there but that will go to SSLv3 right away (if i read everything correctly)

[chico]

We may have done it!

This is what the security firm has come back with:

I did some testing on this issue and I was unable to connect via SSLv2. See below

shaner@whitebox:~$ openssl s_client -host 75.101.159.30 -port 1099 -ssl2
CONNECTED(00000003)
31231:error:1406D0CB:SSL routines:GET_SERVER_HELLO:peer error no cipher:s2_pkt.c:675:
31231:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

I was also unable to see any ciphers on this port at all. I have submitted your statement along with my testing to management to see if we can lower this issue for you. If you have any other questions, or if there is anything else that I can help you with, feel free to email me back.

Thanks for all your help Servoy guys! You're the best.

[chico]

Aww... so it's not solved.

Supposedly, there are weak ciphers running apparently on port 1099.

Code: Select all

Details: Service: 1099:TCP Supported ciphers: EXP-RC4-MD5:TLSv1/SSLv3:40-bit RC4-MD5:TLSv1/SSLv3:128-bit RC4-SHA:TLSv1/SSLv3:128-bit EXP-DES-CBC-SHA:TLSv1/SSLv3:40-bit DES-CBC-SHA:TLSv1/SSLv3:56-bit DES-CBC3-SHA:TLSv1/SSLv3:168-bit EXP-EDH-RSA-DES-CBC-SHA:TLSv1/SSLv3:40-bit EDH-RSA-DES-CBC-SHA:TLSv1/SSLv3:56-bit EDH-RSA-DES-CBC3-SHA:TLSv1/SSLv3:168-bit AES128-SHA:TLSv1/SSLv3:128-bit DHE-RSA-AES128-SHA:TLSv1/SSLv3:128-bit


So, although SSLv2 is not running, supposedly the 40-bit ciphers are under SSLv3 or TLS. So, is there something somewhere where I can disable those ciphers on these protocols?