pveproxy - Disable weak SSL ciphers?

[Rhongomiant]

Dietmar,

Thanks for the response. See my responses below.

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 ]

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

Looks like IO::Socket::SSL has more options than AnyEvent::TLS, for example, the SSL_version allows TLSv11 and TLSv12 to be specified, SSL_honor_cipher_order is an option, etc. I have never created my own web server or worked with AnyEvent, so I am not sure if IO::Socket::SSL can replace AnyEvent::TLS or if just works with it or if it can even be used with IO::Socket::SSL at this point.

Are you opposed to using IO::Socket::SSL? The options that would be useful are SSLHonorCipherOrder and SSLProtocol. SSLInsecureRenegotiation is off by default with IO::Socket::SSL and the AnyEvent::TLS module docs do not mention this option. Also, I do not see that any of these modules support SSLCryptoDevice, so that is not an an option.

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.

The override option would be great.

 

[dietmar]

Looks like IO::Socket::SSL has more options than AnyEvent::TLS

You can pass a Net::SSLeay::CTX object in tls_ctx, so I thing all options are there.

 

[Frazze]

Has there been any update on the SSLHonorCipherOrder [ on ] part? So one can enforce a certain ciphers order which should be used? This is an important feature IMHO to force "stupid" browsers (which all seem to be, testet with IE, firefox, chrome) to use the best possible cipher the server has to offer.

 

[Frazze]

Sorry for bringing this thread up again, but I think aside from the already requested "SSLHonorCipherOrder" option we need one more option which is even more important as the Proxmox VE Webinterface currently maybe is vulnerable to the "BREACH" attack (similar to the "CRIME" exploit you already patched only using HTTP compression (gzip deflate) instead of TLS compression).

Here is my ./testssl.sh test result:

 BREACH =HTTP Compression, experimental    uses gzip compression  (only "/" tested)

Can someone from the team shed some light on this?
Also the SSLHonorCipherOrder feature would be really cool

 

[dietmar]

Here is my ./testssl.sh test result:

Is there an exploit for that attack, or is it more a theoretical issue? And is there a suggested fix besides turning off gzip?
Or should we add a flag to turn off gzip?

 

[Frazze]

Is there an exploit for that attack, or is it more a theoretical issue? And is there a suggested fix besides turning off gzip?
Or should we add a flag to turn off gzip?

Well, there is PoC Code in the wild, I haven't tested it though, like here from the researchers of the BREACH problem:
https://github.com/nealharris/BREACH

And here the "official" site explaining it a bit:
http://breachattack.com/
There is also a part explaining how praticial it is on the site above, you might want to look at that part as well.


The authers say there is no clean suggested fix but a few things one could do:

The mitigations are ordered by effectiveness (not by their practicality - as this may differ from one application to another).

• Disabling HTTP compression
• Separating secrets from user input
• Randomizing secrets per request
• Masking secrets (effectively randomizing by XORing with a random secret per request)
• Protecting vulnerable pages with CSRF
• Length hiding (by adding random number of bytes to the responses)
• Rate-limiting the request

That beeing said I think that adding the option to disable gzip http compression would be the easiest thing to do and with garanteed results.

 

[dietmar]

That beeing said I think that adding the option to disable gzip http compression would be the easiest thing to do and with garanteed results.

Our API is CSRF protected - how does that help?

 

[Frazze]

Our API CSRF protected - how does that help?

Well, I don't know exactly, that's why I brought this up so you can check for yourself.

BUT I know for sure that if you disable http compression you remove the whole problem with all possible scenario. I also don't see the need fpr gzip http compression, it's mostly useless on the webinterface, why not disable it or give users the option to disable it? Better save then sorry, IMHO

 

[dietmar]

Well, I don't know exactly, that's why I brought this up so you can check for yourself.

Well, I dont' like to change nay code unless I understand why it is required.

BUT I know for sure that if you disable http compression you remove the whole problem with all possible scenario. I also don't see the need fpr gzip http compression, it's mostly useless on the webinterface, why not disable it or give users the option to disable it? Better save then sorry, IMHO

gzip greatly reduced the amount of traffic sent over the network (json compress very well).

 

[Frazze]

We, I dont' like to change nay code unless I understand why it is required.



gzip greatly reduced the amount of traffic sent over the network (json compress very well).

I posted links why it should be required. type "BREACH ssl" into google and see ....


Ye well, its a website, in real day usage no one cares and no one can tell the difference if the page sends 140kb (uncompressed) or 40kb (compressed), there should be an option to torn it on or off, it would be the best solution.

 

[dietmar]

I posted links why it should be required. type "BREACH ssl" into google and see ....

Again I read those links. But we have CSRF protection, so it is no real problem (at least I read it that way).

Ye well, its a website, in real day usage no one cares and no one can tell the difference if the page sends 140kb (uncompressed) or 40kb (compressed)

It is an application server (not a web site), and it is important to reduce the traffic, especially if there are many VMs.

 

[Frazze]

Well you have know it - that's my I posted it here so you can decide and if needed take proper actions


Any plans regarding the "SSLHonorCipherOrder" idea?

 

[dietmar]

Any plans regarding the "SSLHonorCipherOrder" idea?

Can we set that by default (if all browsers are stupid?), or needs this to be an option?

 

[Frazze]

I think its better as an option, who knows what strange browsers people use. Maybe make it default on, but as an option imho.

 

[Frazze]

here was written crap... sry

 

[dietmar]

Any plans regarding the "SSLHonorCipherOrder" idea?

Thought more about that, and I really think this should be fixed on the client side instead.

 

[Frazze]

Thought more about that, and I really think this should be fixed on the client side instead.

Hehe, the problem with fixing it the client side is, there is no way so far to do it in any of the major browsers .
You would have to limit your Firefox to only allow the same cipher suites you would want to use on your Proxmox site for ALL the sites you will visit with your browser. Which of course will cause mayham while browsing the web.

All big webservers (apache, ngnix, lighttpd) have such an option so the visiting client has to use the cipher suites the server provides in the specific sequence the server want them to be used.

As an example why this should be server side:
I use in my /etc/default/pveproxy this cipher string:

CIPHERS='ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:!aNULL:!MD5:!DSS'

which results in the following cipher suites beeing available for use:

root@proxmox-ve /etc/default # openssl ciphers -v 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:!aNULL:!MD5:!DSS'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1

Now the ideal ciphers I would like ( in a "perfect world" ) to be used by all applications are the first 4:

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD

because they seem to offer the best security at the moment.


But because I also want to be able to use the proxmox android applicantion (Quadprox Mobile) (for example) I had to allow some slightly weaker cipher suites like for example

 DHE-RSA-AES256-SHA

.



Now what happens when I browse the proxmox webinterface with Firefox is this:
Firefox uses the following ciphers suite: (because Firefox is retarded, but I can't change that in an easy manner without breaking the internet, there are already bug report tickets on Mozilla about this, but they don't care or whatever):

 TLS_DHE_RSA_WITH_AES_256_CBC_SHA1

NOW IF I could just set "SSLHonorCiphersOrder=on" in /etc/default/pveproxy Firefox would simply pick my prefered cipher suite first, meaning the best & most secure one; because Firefox _can_ use it but for some odd reason doesn't use it until one forces Firefox to do so.

The same problem happens with other browsers too.

You are right it _should_ be fixed client side in an ideal world, but that's not where we live in (sadly ), and that also is the reason why all major webservers include such an option.



If I have the option to force the client to use the best-available both to the server and client cipher suite we can have the best of both worlds and the maximum flexability & security.



I hope you understand my point

 

[dietmar]

So you think firefox select the wrong cipher? If so, did you already report a bug (please provide a link)? It would be interesting to know why Firefox selects that cipher.

 

[Frazze]

It's not Firefox selecting the wrong cipher, its just that they think they know better then me what ciphers should used, but thats stupid.
If I use Chrome for the same cipher string I posted earlier Chrome goes with the following cipher: AES_128_GCM with DHE_RSA key-exchange & authentification.

That's better then what Firefox does, but still not optimal.


I'll look for that bug report later on.


And even if Firefox would use the correct cipher order they think one should use (don't know why it doesn't do that for me) it would still be

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)

which is Firefoxe's 1st preference, even over the 256 AES ciphers.



EDIT: I can't seem to find the bug report, I am sure though it has been there, I found it a few months back when I was testing all the cipher suites stuff, nearly 1 year ago, I am sorry.

 

[Horloge]

Hey over here,


Sorry for the digging up but the latter subject of this thread is still a concern (the ciphers order honoring on the PVEProxy).

@dietmar, back in the past, you wanted to know why Firefox would select the AES-128 cipher, it's now explained here (sorry for the fake URL, I don't have the rights to post it) :

wiki.
mozilla.
org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29

WEB browsers developers are still looking for performance with the loading time (old battle), and thus would rather use a cipher with a lower time cost, over a more "secure" one.

This behavior could of course be overridden with the `SSL_honor_cipher_order` option, and it would be a good thing to have (at least) the ability to set it to `on` within the PVEProxy configuration file.

Any chance to get to the bottom of this ?


Nevertheless, a big thanks for your stack, it's very great !
Sam