Menu
▾
▴
#4415 Perfect Forward Secrecy does not work
Enabling the: "Only strong ciphers with perfect forward secrecy" option in the Webmin Configuration->SSL Encryption module appears to have no effect. Also, manually specifying "Listed Ciphers" appears to have no effect. Regardless of the settings, I have been unable to force PFS. I am connecting with both Firefox 29.0.1, and Safari 7.0.3. Firefox reports the following Cipher: TLS_RSA_WITH_AES_128_CBC_SHA, 128 bit keys
How are you determining that this has no effect exactly? Does the setting in Webmin not get saved, or does Firefox not show that PFS ciphers are being used.
Hi Jamie,
The setting appears to be taken, since I can return to the config page, and the correct setting is there, but it is not effective.
As noted above, Firefox reports: TLS_RSA_WITH_AES_128_CBC_SHA
I am expecting it to report a cipher with ECDHE, or DHE. See this list: https://wiki.mozilla.org/Security/Server_Side_TLS
Also, I'm using the SSleuth add-on for Firefox, which has a friendly display that clearly states: "Perfect Forward Secrecy: No"
Regards,
Sage
Last edit: Sage 2014-05-21
I'm sorry. I just realized I filed this against 1.660, but I am using 1.680.
Ok, it sounds like PFS really isn't being used.
Which openssl version is your Webmin system running?
i have also filed a ticket within regard to this issue, and someone else also confirmed it. it appears that using your own cipher list also has no effect. i have only been able to get a lower level of security (i.e. upgrading to new ciphers or PFS does not work).
could a library of some sort be built against an older version of openssl? I am using the latest avaiable version that comes with Ubuntu 12.04 LTS. i think this is 1.0.1e
If you check the log file /var/webmin/miniserv.error on your system after changing the cipher list, do you see any error like "SSL cipher .... failed" ?
Here's what's in my miniserv.log after changing the cipher and pressing "Save":
Pre-loaded WebminCore
[23/May/2014:20:25:27 -0400] miniserv.pl started
[23/May/2014:20:25:27 -0400] Using MD5 module Digest::MD5
[23/May/2014:20:25:27 -0400] PAM authentication enabled
Failed to initialize SSL connection
Failed to initialize SSL connection
FYI, I am running on Centos 6.5, using system Net::SSLeay:
[root@tango ~]# rpm -qi perl-Net-SSLeay
Name : perl-Net-SSLeay Relocations: (not relocatable)
Version : 1.35 Vendor: CentOS
Release : 9.el6 Build Date: Fri 20 Aug 2010 02:11:15 PM EDT
Install Date: Wed 21 May 2014 12:11:53 PM EDT Build Host: c6b3.bsys.dev.centos.org
Group : Development/Libraries Source RPM: perl-Net-SSLeay-1.35-9.el6.src.rpm
Size : 603530 License: OpenSSL
Signature : RSA/8, Sun 03 Jul 2011 12:56:03 AM EDT, Key ID 0946fca2c105b9de
Packager : CentOS BuildSystem http://bugs.centos.org
URL : http://search.cpan.org/dist/Net-SSLeay/
Summary : Perl extension for using OpenSSL
Description :
That looks pretty recent, so it should support PFS. I've been doing some searching, but haven't yet found a reliable source of info on which are the ciphers required for PFS or how to verify if it is being used or not other than looking at the cipher currently in use by Firefox :-(
hmm... well, im certainly not an expert in the area, but ill chime in my two cents.
I am fairly certain that you need to generate a session parameter file, once every few days. either that, or using a stronger/longer keg length, using:
some nginx SSL tutorials reccomend using 4096, but this can take quite a long time (and is very CPU intensive). this is why it seems to make more sense to use a shorter one (2048), that regenerates it's self every X days. the standards has a generic 1024 bit length key for use (see my following post). for example, Dovecot has a parameter called
anyways... the whole idea, to my understanding, is that the key exchange uses this ephemeral key. from what I have gathered using the official documentation @ https://www.openssl.org/docs/apps/ciphers.html
the cipher string needed to specify the ephemeral key exchange is
the entire cipher string I have been using to get an ranking or score of "A" (using the online SSL test), including PFS, is:
where @STRENGTH sorts the resulting list by strength. this may not be necessary on some machines, considering some people prefer 128 over 256, for example.
all though I have not yet looked into the Elliptical Curved format, this will achieve basic perfect forward secrecy.
hopefully this helps. i expect that you already understand most of this, but i figured that it couldn't hurt to elaborate on at-least my understanding.
Last edit: Steven Page 2014-05-26
it looks like that there is a standards based 1024 bit key for DH parameters (as specified in RFC 2409). it may not be necessary to generate your own..
however, I'm not sure how "secure" this is. but, it IS included in the standards... thus, understanding its exact use case scenario still eludes me XD
also, i have came across the certificate string for using Ephemeral Elliptical Curves... it appears to be:
therefore, the updated cipher string would look something like..:
again, I hope this helps
You can actually test these cipher strings yourself with Webmin, to see how they perform with your browser and OS. At Webmin -> Webmin Configuration -> SSL Encryption, you can enter an arbitrary list of allowed ciphers.
Webmin does not seem to use, or at the very least, support, most changes to the cipher string text on the SSL page.
after changing the cipher string to:
and after restarting both Webmin, and my Browser (just for good hygiene) it reports:
I made these tests using the latest versions of both Chrome and Firefox.
I have attached a screen shot with all relevant findings, including the SSL page from Webmin.
note: TLS 1.2 should support all new ciphers... also, firefox reports that parts of the connection have not been encrypted.
sorry about my ugly ass attempt at a screen shot! :P im no graphics artists, only a programmer ^_^
Last edit: Steven Page 2014-05-27
Webmin actually just passes that cipher string down to the openssl library via the Net::SSLeay perl module - it is up to openssl to interpret the list and decide which ciphers an SSL connection will use.
strange. using this cipher in Apache, NGinx, or any other application, results in the expected cipher being used (ECDHE first, DHE second, and sorted by Strength).
my NET::SSLeay version is reported as:
and it looks like NET::SSLeay has had ECDHE integrated as of 2011, judging by a bug report I have dug up.
I will look to see if there is a conflicting installation of the library somewhere... if i recall correctly, Webmin installed some Perl modules using CPAN, and not the package manager.
however, I would think that this would result in a new version of the library (not an older one)
Last edit: Steven Page 2014-05-28
Having two versions of SSLeay installed could be an issue. Try running :
find /usr -name "SSLeay"
and see what it finds.
comparing the relevant entries from that command..:
against this: https://packages.debian.org/sid/i386/libnet-ssleay-perl/filelist
leads me to believe that everything looks OK
I'll have a few more looks around online to see if there could be an issue with this version of the Perl module, but im not so sure.
the unfortunate side effect is that it likely breaks PCI compliance. I can't run a test against port 10000 using the online test though, so I can't say this for sure.
When I get free time I'll look at the code in the server's executable and might poke around at Net::SSLeay::set_cipher_list to see if I can't come to some sort a resolution
if you have any more suggestions, let me know. I will try them right away.
What's odd is that the cipher list does do something, as there have been many requests in the past for a PCI-compliant list of ciphers. But I'm not sure why a list that enabled PFS when used with Apache isn't working with Webmin.
One more thing you could try is disabling SSLv2 separately. This can be done by adding the line no_ssl2=1 to /etc/webmin/miniserv.conf , and then running /etc/webmin/restart
I checked this file, and this setting already exists, and is set.
Also: I noticed that I was loading my company logo without HTTPS, so ignore the error which stated that some elements were not sent over a secure channel.
I spent some time working on a cipher string, which prefers PFS, using the most modern ciphers. but its second priority is to safely fall back in order to support almost all devices. On the Qualys SSL test, this will get you an A, supports almost all platforms without breaking anything, and is PCI ready.
I plan add it to my GitHub, or my Website's GIT Repository at some point... but until then; You can find the Cipher String, and the Full Description on PasteBin.
http://pastebin.com/yUB5c7XY
Thanks for doing this research! I also found it hard to identify the perfect list of ciphers..
Did you check if using that cipher list in Webmin enforces PFS?
i just noticed that pastbin cut off part of the cipher string. just make sure you highlight it and scroll as far to the right as possible ^_^
I'll check to see if it works with Webmin when i get back later tonight!
doesn't seem to change anything. after switching to this cipher string, it seems to be using TLS_RSA_WITH_AES_CBC_128_SHA.
by virtue of this cipher string, it tells me that it is falling back, all the way to one of the most weak supported ciphers. the only thing weaker, is plain RC4..
Calomel SSL validation gives is a score of 34% (Very Weak).
I really am stumped here. I wonder what the OP operating system is. I am having this problem on all my Ubuntu 12.04 LTS systems.
I wish I had the time to help, by playing around with SSLeay Perl Module... but I've been so busy with work, and my small business.. I'm not sure I could find any time to do so.
Lemme know if you make any headway on this, or if you get any more ideas that I might be able to try
That is annoying - I can't see why using the cipher string in Webmin wouldn't work, when it just gets passed down to the same underlying OpenSSL library :-(
OS= CentOS-65.
WB=Firefox-31.1.0
SSL packages:
mod_ssl.x86_64 1:2.2.15-31.el6.centos @updates
openssl.x86_64 1.0.1e-16.el6_5.15 @updates
openssl-devel.x86_64 1.0.1e-16.el6_5.15 @updates
perl-Net-SSLeay.x86_64 1.35-9.el6 @base
This morning I have run into this exact problem. Calomel reports using TLS_RSA_WITH_AES_CBC_128_SHA or sometimes TLS_RSA_WITH_AES_CBC_356_SHA. If I enable all ciphers on Firefox and block only these:
security.ssl3.rsa_aes_128_sha:false
security.ssl3.rsa_aes_256_sha;false
security.ssl3.rsa_camellia_128_sha;false
security.ssl3.rsa_camellia_256_sha;false
security.ssl3.rsa_des_ede3_sha;false
security.ssl3.rsa_rc4_128_md5;false
security.ssl3.rsa_rc4_128_sha;false
then I see this in Firefox-31.1.0ESR:
Cannot communicate securely with peer: no common encryption algorithm(s).
I am certain that I had established a better level of encryption between my browser and Webmin in the recent past. Yesterday there was an update to Firefox and my spidy-sense tells me that this has something to do with what I am observing.