pveproxy - Disable weak SSL ciphers?

[dgp]

Hi all,

Is there any way to customize the list of SSL ciphers or key sizes used in pveproxy? We run some automated tests on our network and Proxmox 2 was fine hiding behind Apache but pveproxy has some 56bit ciphers enabled (EDH-RSA-DES-CBC-SHA, DES-CBC-SHA).

I checked the man page for pveproxy and it doesn't mention anything relevant.

Thank you

 

[Frazze]

I am interested in this too!

 

[dietmar]

I am interested in this too!

see /root/.ssh/config

 

[dietmar]

see /root/.ssh/config

Sorry, ignore my answer. Please can you file a bug for that at bugzilla.proxmox.com?

 

[dietmar]

Oh, I just commited a patch for that a few days ago:

https://git.proxmox.com/?p=pve-mana...;hpb=ef94cfec6c6d069ec69a9bab46f4701a235a23be

I guess that will solve your issue?

 

[mir]

But having it configurable through a config file would be preferable.

 

[dietmar]

But having it configurable through a config file would be preferable.

Sorry, but why do you want to configure that (just curious)?

 

[dgp]

Oh, I just commited a patch for that a few days ago:

https://git.proxmox.com/?p=pve-mana...;hpb=ef94cfec6c6d069ec69a9bab46f4701a235a23be

I guess that will solve your issue?

That's exactly the solution I was after, thank you dietmar

 

[mir]

Hardcoded: HIGH:MEDIUM:!aNULL:!MD5
My preferred standard: ECDHE-RSA-AES256-SHA384:AES256-SHA256:HIGH:!RC4:!MEDIUM:!MD5:!aNULL:!EDH:!AESGCM

Newest research has proved that most of the ciphers belonging to the MEDIUM cipher suit is trivial to brute force. Recently RC4 based ciphers from the HIGH cipher suit is also considered broken: http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html

 

[Frazze]

It should be configurable in some sort of config file so people can move to cipher suites that allow you to have perfect forward secrecy enabled or (even better: enforced) or theoretically broken ciphers like RC4 disabled and to mitigate expoits like BEAST and some more, see here:
https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack

 

[dietmar]

It should be configurable in some sort of config file

done, see:

https://git.proxmox.com/?p=pve-manager.git;a=commitdiff;h=787217cdcae48b21a323f2fda22581e08c715294

 

[Frazze]

Nice nice nice! Thanks, you guys are incredible

 

[Rhongomiant]

Dietmar,

Thanks implementing this update. I do have two issues issue and I have some related requests.

1) When I limit to the following ciphers, I get the following errors in syslog.

Sep 30 10:45:59 <name removed> pveproxy[443957]: problem with client <ip removed>; ssl3_read_bytes: ssl handshake failure
Sep 30 10:45:59 <name removed> pveproxy[443957]: WARNING: Can't call method "timeout_reset" on an undefined value at /usr/share/perl5/PVE/HTTPServer.pm line 170.


ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-DES-CBC3-SHA
ECDHE-ECDSA-DES-CBC3-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-SHA256
DHE-DSS-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
EDH-RSA-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHA
DHE-RSA-AES128-SHA256
DHE-DSS-AES128-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-DSS-AES128-GCM-SHA256
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA


2) If you create the /etc/default/pveproxy file, you have to specify POLICY="<some option>". This was not documented anywhere I could find.


3) I see that you have manually disabled SSL Compression in the latest update. This is not an issue with TLS1.1, TLS1.2 and some forms of TSL1.0, so you may want to make it an option in the the /etc/default/pveproxy file with the default as off. Also, I would like to have the following SSL options. These are from apache, so I am not sure how they translate to the web server you are using now.

SSLHonorCipherOrder [ on ]
SSLProtocol [ all SSLv3 TLSv1 TLSv1.1 TLSv1.2 and in the future TLSv1.3 ]
SSLInsecureRenegotiation [ on off ]
SSLCryptoDevice [ Options can be found via openssl engine ]


4) Consider moving the CA certificate file to the local server along with the key and certificate files in case people have servers that use different CA certificates.


5) One more thing... In an archive thread, link is below, you were talking about adding some options to /etc/pve/datacenter.cfg for cipher control of migrations. Were these options ever added?

http://forum.proxmox.com/archive/index.php/t-7539.html

 

[dietmar]

1) When I limit to the following ciphers, I get the following errors in syslog.

Please can you post your config?

2) If you create the /etc/default/pveproxy file, you have to specify POLICY="<some option>".

Why is that needed (should work without)?

3) I see that you have manually disabled SSL Compression in the latest update. This is not an issue with TLS1.1, TLS1.2 and some forms of TSL1.0, so you may want to make it an option in the the /etc/default/pveproxy file with the default as off.

This is totally unnecessary, because we compress at application level.

Also, I would like to have the following SSL options. These are from apache, so I am not sure how they translate to the web server you are using now.

SSLHonorCipherOrder [ on ]
SSLProtocol [ all SSLv3 TLSv1 TLSv1.1 TLSv1.2 and in the future TLSv1.3 ]
SSLInsecureRenegotiation [ on off ]
SSLCryptoDevice [ Options can be found via openssl engine ]

feel free to send patches for that.

4) Consider moving the CA certificate file to the local server along with the key and certificate files in case people have servers that use different CA certificates.

The idea is to have one single CA for the whole cluster.

5) One more thing... In an archive thread, link is below, you were talking about adding some options to /etc/pve/datacenter.cfg for cipher control of migrations. Were these options ever added?

You can set ciphers in /root/.ssh/config

 

[dietmar]

2) If you create the /etc/default/pveproxy file, you have to specify POLICY="<some option>".

Will fix that in next version.

 

[dietmar]

1) When I limit to the following ciphers, I get the following errors in syslog.

I tested this with the latest version, and I do not get those warnings. I assume this is already fixed by a recent patch sent by Stefan.

 

[Rhongomiant]

Dietmar,

Thanks for the response.

3) Also, I would like to have the following SSL options. These are from apache, so I am not sure how they translate to the web server you are using now.

SSLHonorCipherOrder [ on ]
SSLProtocol [ all SSLv3 TLSv1 TLSv1.1 TLSv1.2 and in the future TLSv1.3 ]
SSLInsecureRenegotiation [ on off ]
SSLCryptoDevice [ Options can be found via openssl engine ]

feel free to send patches for that.

I probably could, but I need to know a bit more about the web server you are using. Is it apache or something else and can you point me to a location in the code where the config file for the web server is created?

4) Consider moving the CA certificate file to the local server along with the key and certificate files in case people have servers that use different CA certificates.

The idea is to have one single CA for the whole cluster.

How will this work if I servers with certificates with different intermediate CAs, but the same root CA or different root and intermediate CAs? I do not believe that one file will handle this. A suggestion would be to have a cert manager where all the information for all certificates is stored in the clusterfs and then a server config that can select on of the certificates in the clusterfs which if needed would cause the key, cert and all needed CAs to be populated in the specific servers directory within the clusterfs.


Thank you,

Rhongomiant

 

[dietmar]

I probably could, but I need to know a bit more about the web server you are using. Is it apache or something else and can you point me to a location in the code where the config file for the web server is created?

We wrote our own server, based on AnyEvent:

https://git.proxmox.com/?p=pve-mana...28eb2a9f0a0ded3f03c195ca2fb9e81e02b11;hb=HEAD

https://git.proxmox.com/?p=pve-mana...c308ea6d6601b886b0dec2bada3d4c3da65d0;hb=HEAD

How will this work if I servers with certificates with different intermediate CAs, but the same root CA or different root and intermediate CAs? I do not believe that one file will handle this.

Why do you want such setup? Simple use the same CA (and same intermediate CAs) to issue certificates for all cluster nodes.

 

[Rhongomiant]

We wrote our own server, based on AnyEvent:

https://git.proxmox.com/?p=pve-mana...28eb2a9f0a0ded3f03c195ca2fb9e81e02b11;hb=HEAD

https://git.proxmox.com/?p=pve-mana...c308ea6d6601b886b0dec2bada3d4c3da65d0;hb=HEAD

Thanks for the info, I will take a look.

How will this work if I servers with certificates with different intermediate CAs, but the same root CA or different root and intermediate CAs? I do not believe that one file will handle this. A suggestion would be to have a cert manager where all the information for all certificates is stored in the clusterfs and then a server config that can select on of the certificates in the clusterfs which if needed would cause the key, cert and all needed CAs to be populated in the specific servers directory within the clusterfs.

Why do you want such setup? Simple use the same CA (and same intermediate CAs) to issue certificates for all cluster nodes.

I think you are trying to over simplify the CA file handling and in doing so you could potentially constrain users without a significantly beneficial reason reason to do so as end users do not control what CAs certificate authorities use to issue certificates. While as long as we buy the same product the root CA will not likely change, the intermediate CAs can change. Lets look at a scenario. A user sets up a Proxmox Server and gets an SSL certificate. Three months later the user gets another server and an SSL certificate for this server using the same SSL product. Months later the user gets another server and an SSL certificate for this server using the same SSL product, but this time the certificate uses different intermediate CAs. Is your view that the users should buy new certificates for all the servers if this happens? There are lots of other examples of what can happen. Users should not have to buy new certificates for all servers in a cluster if they want to change the SSL product they are using because the one they were using before is discontinued, the user wants a cheaper certificate, the user wants to do business with a better Certificate Authority, etc.

Constraining users is not the answer. Please consider moving the CA file to the server side so each server can use the correct CA for the certificate on that server. It would be nice to have a certificate management interface even if you have one server, but as a measure of the value of your time, I think 6 to 10 or more servers in a cluster for a number of your paying clients would warrant your consideration of including a certificate management system to the web interface.

 

[dietmar]

Constraining users is not the answer. Please consider moving the CA file to the server side so each server can use the correct CA for the certificate on that server.

The idea of the cluster is that all nodes in a cluster shares some attributes, for example the CA. But I am open for improvements here, for example we can provide a way to override the CA at node level.