#4415 Perfect Forward Secrecy does not work

1.660
open
nobody
None
5
2015-05-26
2014-05-21
Sage
No

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

Discussion

1 2 > >> (Page 1 of 2)
  • Jamie Cameron
    Jamie Cameron
    2014-05-21

    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.

     
  • Sage
    Sage
    2014-05-21

    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
  • Sage
    Sage
    2014-05-21

    I'm sorry. I just realized I filed this against 1.660, but I am using 1.680.

     
  • Jamie Cameron
    Jamie Cameron
    2014-05-22

    Ok, it sounds like PFS really isn't being used.

    Which openssl version is your Webmin system running?

     
  • Steven Page
    Steven Page
    2014-05-23

    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

     
  • Jamie Cameron
    Jamie Cameron
    2014-05-23

    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" ?

     
  • Sage
    Sage
    2014-05-24

    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

     
  • Sage
    Sage
    2014-05-24

    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 :

     
  • Jamie Cameron
    Jamie Cameron
    2014-05-24

    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 :-(

     
  • Steven Page
    Steven Page
    2014-05-26

    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:

    openssl dhparam -out dhparam.pem LENGTH

    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

    ssl_parameters_regenerate = HOURS

    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

    kDHE

    cipher suites using ephemeral DH key agreement.

    the entire cipher string I have been using to get an ranking or score of "A" (using the online SSL test), including PFS, is:

    kDHE:DH:HIGH:MEDIUM:!LOW:!SSLv2:!MD5:!aNULL:!eNULL:!NULL:@STRENGTH

    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
  • Steven Page
    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:

    kEECDH - ephemeral ECDH

    therefore, the updated cipher string would look something like..:

    kEECDH:kDHE:DH:HIGH:MEDIUM:!LOW:!SSLv2:!MD5:!aNULL:!eNULL:!NULL:@STRENGTH

    again, I hope this helps

     
  • Jamie Cameron
    Jamie Cameron
    2014-05-26

    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.

     
  • Steven Page
    Steven Page
    2014-05-27

    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:

    kEECDH:kDHE:DH:HIGH:MEDIUM:!LOW:!SSLv2:!MD5:!aNULL:!eNULL:!NULL:@STRENGTH

    and after restarting both Webmin, and my Browser (just for good hygiene) it reports:

    connected using 256 bit encryption (TLS 1.2) with AES 256 CBC, with SHA1 for Auth, and RSA for KEX

    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
    Attachments
  • Jamie Cameron
    Jamie Cameron
    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.

     
  • Steven Page
    Steven Page
    2014-05-28

    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:

    steven@rapidwebs:~$ perl -MNet::SSLeay -e 'print "$Net::SSLeay::VERSION\n"'
    1.42

    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
  • Jamie Cameron
    Jamie Cameron
    2014-05-28

    Having two versions of SSLeay installed could be an issue. Try running :
    find /usr -name "SSLeay"
    and see what it finds.

     
  • Steven Page
    Steven Page
    2014-05-29

    comparing the relevant entries from that command..:

    /usr/lib/perl5/auto/Net/SSLeay
    /usr/lib/perl5/Net/SSLeay

    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.

     
  • Jamie Cameron
    Jamie Cameron
    2014-05-29

    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

     
  • Steven Page
    Steven Page
    2014-07-02

    I checked this file, and this setting already exists, and is set.

     
  • Steven Page
    Steven Page
    2014-07-02

    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

     
  • Jamie Cameron
    Jamie Cameron
    2014-07-03

    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?

     
  • Steven Page
    Steven Page
    2014-07-03

    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!

     
  • Steven Page
    Steven Page
    2014-07-05

    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

     
  • Jamie Cameron
    Jamie Cameron
    2014-07-05

    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 :-(

     
  • James B. Byrne
    James B. Byrne
    2014-09-19

    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.

     
1 2 > >> (Page 1 of 2)