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
Downgraded to FF28.4 and restarted the httpd service on one of the hosts. This had no effect whatsoever on the behaviour of Webmin STARTTLS connections. HTTPS connections to Apache 2.2 running on the same host do allow perfect forward security ciphers.
unless you have installed or configured Webmin to use Apache as it's backend, Webmin uses it's own built in server.
what your bug report tells me, however, is that this is not limited to a specific operating system.. which is somewhat helpful.
it also does not seem to be related to a specifc distributions candidate for the Perl module in question.
moreover, this bug seems to surface regardless of the browser (tested with both Chrome and Firefox).
My hypothesis is that at some stage of the SSL Session Setup Process, the cipher string is not being correctly passed to the Perl SSL Module. maybe it's a little bug in Webmins code (variable defined out of scope?).. OR maybe the API has changed. and the accepted input parameters have changed, likewise.
After some back-and-forth with Jamie, it appears he is also stumped as to what the issue is. looks like either we will have to wait for Jamie to dig into the code, or one of us will have to dig into the Webmin code.
I am by no means an expert in Perl, or the modules in question.. but I would think that a good place to start would be to write a test bed application using the Perl SSL Module. afterwards, compare working example code against what has been done in Webmin. if I can ever find the time to do this, i'll be sure to submit a patch.
On Fri, September 19, 2014 13:44, Steven Page wrote:
This problem first appeared following an update to Firefox (FF) from FF24.esr
to FF31esr. However, having surfaced it will not go away. FF31 also exhibits
strange (to me) behaviour with respect to symmetric keys (SK) and Apache-2.2
vice FF24. In FF24 I connect to URL https://X and get a Calomel 0.62 of Very
Strong and a SK cipher type of AES 256. Updating to FF31 on the same
workstation and connecting to the same URL I get a Calomel rating of Very Weak
and a SK cipher type of TLS_DHE_RSA_WITH_AES_256_CBC_SHA.
Not being a dyed-in-the-wool cryptanalyist I cannot say what, if any,
difference exists between these two other than the name. But Calomel seems to
think that there is.
--
E-Mail is NOT a SECURE channel
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
On Fri, September 19, 2014 14:43, James B. Byrne wrote:
I rolled back to FF24 and restarted and now I am getting the behaviour that I
recalled. Camomel reports that I have Very Strong SSL Validation with Webmin
employing AES-256 for the SK cipher.
I suspect that between FF24 and FF31 something respecting SSL handshaking
changed. It would not surprise me if it proved the case that the same thing
happened to Chrome at some point as well, since Google has a hand in both.
What I suggest as a trial is to roll back versions of Chrome and FF one major
release at a time until the problem goes away. As I am on CentOS-6.5 I do not
get the regular releases, only the Extended Support Releases, so I cannot do
this. The indications are that something has changed inside FF for certain
and possibly Chrome that triggers this problem.
Note as well, that in my case, FF31 will not make a strong SSL connection to
my Apache servers either but that FF24 does.
--
E-Mail is NOT a SECURE channel
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
sorry, i was reading your bug report from my cell phone, and I didnt read it over very well.
it does appear that something strange is going on here, and it certainly warrants further inspection. i hope that we can get this working, because PFS is certainly something most people will want on their back end in todays day-and-age.
however, one should note that firefox extended support release does not support the same ciphers as many of the later release candidates do. i have noticed that when using firefox ESR, many websites are reported as using a weak cipher. some versions of Firefox appear to be restricted to certain ciphers... while others fail to support strong MAC specs.
I apologize if you understand these key concepts, but its worth going over none the less. when a client connects to the server, the server suggests a list of ciphers for the client to use. the client can essentially pick from any of the suggested ciphers. the server can request the client to honor the cipher order, but thats about it.
what is strange is that in any modern release candidate of Firefox or Chrome, webmin simply refuses to offer a PFS style ciphers as a selection. or atleast this is what appears to be happening.
within regard to Calomels weak/strong specification... this is not really backed up against any "standard" per say, but a point system. and I noticed that the signature/MAC effects the over all score quite a bit.
your weak/strong issue might very well be an issue with supported ciphers and MAC/Signature specifications, within different Firefox builds. i too have had this issue.
it does however also appear that webmin is not following the input for a desired cipher string. likely a seperate issue entirely. it seems to support standard block ciphers fairly well, but the minute you try to move to DH/ECDH, any sort of ephermeal key exchange, or strong MAC spec... it has a brain fart.
anyways, my point is, using firefox 32.0 (on Ubuntu 12.04 lts), and on Windows 7, I can successfully get apache 2.22 to score A++ on Qualys SSL Labs test. Calomel reports Very Strong. but when browsing to Webmin.. no matter what I do, we are restricted to AES, and weak signatures/MAC Specs.
combined with this very common firefox issue (that unforuntately not alot of people are aware of), this means that webmin is left fairly "insecure". or rather.. fairly weak, within regard to SSL Connections.
AES/128/256 honestly should suffice, and i'm not 100% sure the MAC Spec scoring system in Calomel is very fair. it feels... pooly balanced? but that is neither here nor there. could be wrong.
hope this helps clarify things. however, i have a tendacy to just make things more confusing! :)
Last edit: Steven Page 2014-09-19
On Fri, September 19, 2014 19:35, Steven Page wrote:
I presently work on CentOS-6.5 mainly. The default security.ssl3
configuration settings in about:config for FF31esr shipped with RHEL/CentOS
seems to differ significantly from those found in my MacBook FF31esr
downloaded directly from the Mozilla project. Further, when I disable the
weak keys in FF31 then I cannot get a connection with Webmin at all but FF28
connects just fine.
I have my webmin installations fire-walled to only accept connections from
certain IP addresses originating from inside our LAN. Nothing from the
outside is allowed to directly connect. So the issue is not quite as bad as
it might be. However, I have had to drop back to FF28 on CentOS-6.5 to obtain
a high grade symmetric key (SK) when connecting to webmin internally.
I am depending upon the Calomel-0.62 classifications here but I am fairly
confident that an AES-256 SK provides good security and that an RC4-128 does
not. I get the former when using FF28esr and the latter when using FF31esr
against the same Webmin host, both versions of FF obtained from the CentOS
repository.
--
E-Mail is NOT a SECURE channel
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
On Mon, September 22, 2014 09:35, James B. Byrne wrote:
and
These both should read FF-24.8esr and not FF28
--
E-Mail is NOT a SECURE channel
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
I have discovered that FF-31.2 on CentOS Uses RSA/Server key to establish the key exchange with Webmin. Whereas Apache https connections from the same FF-31 instance to Apache httpd running on the same host and employing exactly the same keys and certificates as Webmin use ECDHE. Calmomel reports that RSA/server key exchange is weak and does not support PFS.
Is the problem in the key exchange?
Further update. FF-31.2 Page Info reports this:
Connection Partially Encrypted
Parts of the page you are viewing were not encrypted . . .
In my testing the 'perfect forward secrecy' option has no effect.
Also I found the 'force cipher order' has no effect either. Worse, if you list your own ciphers, Webmin+SSLeay will use them in reverse order and prefer the last/weakest cipher on your list.
If you only list PFS ciphers, Webmin stops working as it is unable to form an SSL connection.
It would be nice if these option were implemented, but it is terrible that the UI misleads users to think that they are implemented/working :-(
Until recently SSLeay did not support PFS either, and still may not, though work was started last year by Paul Howarth (v1.56):
http://koji.fedoraproject.org/koji/buildinfo?buildID=608072
Last edit: Aaron Roydhouse 2015-03-28
Has anyone tested with 1.56 or higher? If that's what we need, then it'd be a reasonable project to get packages of that available for the most popular distributions.
I've built and manually replaced all the default SSLeay files with the latest version SSLeay 1.68 from http://www.cpan.org/modules/by-module/Net/Net-SSLeay-1.68.tar.gz
I'm running on webmin 1.740
I still get the errors of no match could be found when setting the ciphers to Modern compatibility. Intermediate works but uses "AES128-SHA".
https://wiki.mozilla.org/Security/Server_Side_TLS
Chrome reports the connection is secured with obsolete cryptography.
if i can ever find the time, ill try to whip up a test bed application. that which makes use of the perl ssl module. i have experience with a plethora of languages, but not so much with Perl in particular.
however, it should not be outside the realm of possibility that one of us here in this thread could compose a quick application making use of this library. this way, we can test once and for all if the problem is as a result of the perl ssl module... or if it is a bug within Webmins implementation of the module.
after acquiring a working understanding of how the modules setup, use, and tear-down is performed... it shouldn't be too difficult to peek into Webmins code, in order to seek out any potential problem with its current implementation. some extensive logging and extra debugging tactics should help find and surface the issue, one would think. Webmin's code base isn't entirely all that difficult to navigate after some time spent in dissection.
according to the Net-SSLeay CPAN distribution, it was possible as far back as 2013 to use DH for acquiring PFS support. all though this is slow, it IS forward secrecy. however, if i can remember correctly.. this was not working for me (in the context of Webmin and its integrated server).
furthermore, a bug was filed in 2013 regarding ECDH support. a patch was provided by the maintainer of IO:Socket::SSL to do just that. you can read the bug report and find the provided patch at this address : https://rt.cpan.org/Public/Bug/Display.html?id=89408
according to the aforementioned thread, the patch was added to the SVN on Friday, October 11, 2013. it should have made its way into the into any public repository by now, one would assume. hence, the bug report was closed (being changed from "open" to "resolved").
all this leads me to believe that this is indeed a problem with the implementation of net-SSLeay on-top of Webmin's integrated server.
something to think about: i'm not entirely sure if Webmins integrated server was developed by, or is maintained by Jamie. if Webmins integrated server was developed along side Webmin itself... it shouldn't be too hard to debug or troubleshoot this.
but if it is indeed developed or maintained by a third party... this could be a little more complicated than simply patching Webmin. note im not 100% sure about this scenario. maybe Jamie could chime in on this.. as far as i know, the integrated server is simply a part of Webmins core, and belongs to the Webmin package.
now, im not quite sure if this was attempted... we might have already taken this into consideration, or looked into this... but has anybody tried to use the latest version of the library, acquired from CPAN, rather than what is provided by their operating systems repository?
im sure that by now any such patched version of Net-SSLeay should be included in mainstream repositories.. included or used in any recent and up to date Linux distributions.. but hey, you never know!
Last edit: Steven Page 2015-04-29
Thanks for looking into @Steven. I did some investigation a while back and my understanding was that for DH and especially for ECDH to work, it is not enough for the SSL library to support it. The application has to also be involved with keeping/exchanging some extra parameters with the library.
So to get PFS to work with Webmin, a capable Net-SSLeay and some changes to Webmin are required. I didn't dig further after that, since I didn't have time to go patching Webmin to get it. It was easier to proxy Webmin through a small web server that can already do PFS.
This is consistent with what we saw with Apache. Remember when Apache 2.2 couldn't do PFS but Apache 2.4 could, even if both were using the latest OpenSSL with DH/ECDH? That was this parameter handling issue.
That PFS parameter support has since been back-ported to Apache 2.2, we could probably find that relatively recent patch to get an idea of what Webmin is missing to support PFS.
Last edit: Aaron Roydhouse 2015-04-29
i made a few changed/edits to my above post. if you are reading this from email... please visit sourceforge for an up to date version of my previous post. thanks.
my apologies mentalinc. just noticed your post. ignore my comment about using libraries provided by CPAN, rather than what is in your distributions repository.
but for the sake of completeness however.. (don't take the following personally. it's not meant to undermine your abilities. nor is it meant to negate your wherewithal..)
how did you verify webmin was indeed using your custom built libraries?
just so i dont explode this thread with long winded posts, i have included some directions on how to make sure webmin is using the desired cusom built dependencies. your can find my extrapolation on pastebin: http://pastebin.com/FpWtiwc5
simply ignore this if you have already double checked this... or if this was all obvious to you after building the latest versions from CPAN the first time...
Webmin has been suffering from this issue for a while now, and after a long break.. it appears it has still not been resolved. if the development team cant get this resolved, hopefully we can contribute to the project by patching it our selves.
thank you for your input.
Last edit: Steven Page 2015-04-29
Yes, Webmin's integrated webserver is indeed developed by me. However, it basically delegates all of the SSL functionality to the Net::SSLeay library - and the list of ciphers is just passed to that library as a string. This seems to work OK for selecting PCI-compliant ciphers, but for the life of me I can't figure out why it doesn't seem to work for PFS ciphers.
If there is a code change that can be made to Webmin to get this working, I'd love to know what it is.
Hi Cameron, I gather that to use DH and ECDH which allow PFS there are extra parameters the server needs to provide to the SSL library, beyond the cipher list. For DH the servers to supply a set of DH parameters (pre-computed, see 'openssl dhparam') to match the temporary key length, and for EC the curve name and a temporary runtime key.
For SSLeay it appears you have to provide callback functions to fetch these parameters from the Webmin application. e.g.
http://search.cpan.org/~mikem/Net-SSLeay-1.68/lib/Net/SSLeay.pod:
Net::SSLeay::CTX_set_tmp_dh($ctx, $dh);
Net::SSLeay::CTX_set_tmp_dh_callback($ctx, $tmp_dh_callback);
E.g. here's a patch for Apache 2.2 mod_ssl that adds ECDH support to Apache 2.2, where mod_ssl provides the call-back function needed.
https://github.com/apache/httpd/commit/058a25cdcb42572867d613ec13c68a350b9d57b6.patch
Thanks - that's somewhat useful. Unfortunately the Net::SSLeay docs don't have a lot of into on exactly what the $dh parameter is supposed to contain. And I haven't been able to find any example code that uses these functions..
Maybe this will help:
https://wiki.openssl.org/index.php/Diffie-Hellman_parameters
We use D-H with Postfix-2.11 and need to regenerate the D-H parameters for the ethemeral keys on a regular basis. That will likely be a consideration that Webmin will need to deal with. We use the following in a cron script:
$(which openssl) dhparam -out dh2048.tmp 2048 && mv dh2048.tmp dh2048.pem
The two step process is required to protect the existing D-H pem file from corruption in the event that the regeneration step fails. Some authorities hold that a 512 bit key is sufficient and much-much faster to produce. I figure that for something that is run one a week we can go with the higher key size.
Ok, I'll try that out.
I mentioned this on page 1: https://sourceforge.net/p/webadmin/bugs/4415/#1d75 a while back, but I forgot to follow up with Jamie to see if maybe it could be somehow related to the issue.
either way, its a direction to head in for now :)
I haven't actually used the SSL libraries / Perl SSL module "directly", and have only ever interfaced them through high level programming languages or general purpose networking libraries... but I do have a basic understanding of how this all works.. or fits together.. and so I guess I'll toss in my two cents here.
from what I understand, there IS a "default" DH Parameter which the SSL library can use when no user generated parameters are supplied.. Generating your own DH parameters is basically a method of ensuring your parameters are generated with truly random data (high in entropy). it is also used to ensure that the parameters are not compromised..
from what most documentation on the topic seems to iterate.. and from what I understand about how the DH algorithm works.. there is no problem in using the default DH parameters.. or for reusing the same parameters when signing several key pairs over long periods of time. or even the same parameters as somebody else.
which basically boils down to... do we trust the developers of the library in question? and do we trust the repositories the library was pulled from? i.e. what IS required is that the parameters are TRULY random. and that they are not designed by a malicious party with the intent of making it easy to exploit your service, or decrypt your data.
thus.. if I could suggest something... I would suggest that custom generating DH parameters is an "opt-in" feature? it's common for people to assume that generating their own key for their DH parameters is a required practice.. or that generating a longer / more complex key will result in "more security". but from what I gather.. it simply results in wasted CPU cycles.
ECDH is a very similar algorithm.. replacing DH parameters with "random curves". and in practice, it's simply not realistic to generate your own random curve.
for starters... it can be computationally expensive. and second: it's much more time consuming to write a curve generator than it is to generate DH parameters. but most importantly? the improvements of elliptic curve algorithms (primarily it's speed) come from both the client and server being "optimized" for a specific curve. and generating your own would negate these improvements.
anyways, I took a peek in the source code for /lib/IO/Socket/SSL.pm to see how and where the library defines default DH parameters.. as well as to see if the library defines a default elliptical curve. here is what I found:
it appears to define default DH Parameters within the "default SSL server arguments" class/structure. it also appear to define a default curve for use with ECDH.
one would think the initialization function would just overload these arguments... simply falling back to the default DH Parameters when none are supplied, but is needed. regardless... maybe you could pull the default DH Parameters / ECDH curve from the default SSL server arguments constant?
if not.. maybe just generate your own "default" parameters and ship them with the Webmin package? and define "prime256v1" as the default curve if ECDH is used without a user defined parameter?
oh yeah, I also noticed this from the first page. forgot all about this! :
the Short & Sweet OpenSSL Cipher String:
http://pastebin.com/yUB5c7XY
Enforces PCI Compliance & Perfect Forward Secrecy, with support for algorithms such as DH, ECDH & GCM.. while retaining support for almost any algorithm commonly found employed by web servers and web browsers on the market. includes graceful fallback logic: always uses the most secure and quickest algorithm available.. and attempting to establish this connection using PFS for Key Exchange each and every time.
essentially, this lists utilized the poorly documented tokens defined by the ssl library. using these tokens, along side operator logic, i have eliminated the need for defining any ciphers in the cipher string at all. it provides organization, forward compatibility, and extra security through peace of mind knowing that you have not defined an obsolete/defunct/inherently broken or vulnerable cipher in your list.
i think this was the way cipher string were supposed to be written... but people have been copying and pasting from what they found online for so long.. that cipher strings have turned into a real mess.
Is there any update on this? I'm selecting "Only strong ciphers with perfect forward secrecy" but this includes AES256-SHA and SHA1 is not secuere but is the only option at this time that works for Chrome.
The ssl_cipher_list used by that option is: EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5
Its falling back to the weekest option. I'm runing Vitualmin 4.18 / Webmin 1.760 on ubuntu 14.04.3.
Thanks for any help.
Last edit: waffles1006 2015-09-03
Ciphers don't provide PFS, key exchange algorithms do that. Also if you test that list you'll find it is bogus anyway as it includes non-PFS RSA key exchange options too.
openssl ciphers -v 'EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5'
I suggest you specify your own list and realise that there is no point including PFS key exchange options like DH or ECDH because they won't work with Webmin/Usermin, because Webmin/Usermin don't currently supply the extra init parameters needed for each of those key exchange methods to work (DH needs init vector, ECDH needs a curve name) and nor does SSLeay automatically add default parameter values. Until either Webmin for SSLeay changes, no PFS for us.
Last edit: Aaron Roydhouse 2015-09-03