#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 2 of 2)
  • James B. Byrne
    James B. Byrne
    2014-09-19

    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.

     
  • Steven Page
    Steven Page
    2014-09-19

    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.

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

      On Fri, September 19, 2014 13:44, Steven Page wrote:

      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.

      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

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

        On Fri, September 19, 2014 14:43, James B. Byrne 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.

        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

         
  • Steven Page
    Steven Page
    2014-09-19

    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! :)

    • Steve
     
    Last edit: Steven Page 2014-09-19
    • James B. Byrne
      James B. Byrne
      2014-09-22

      On Fri, September 19, 2014 19:35, Steven Page wrote:

      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.

      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

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

        On Mon, September 22, 2014 09:35, James B. Byrne wrote:

        . . . 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. . .

        and

        . . . I get the former when using FF28esr . . .

        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

         
  • James B. Byrne
    James B. Byrne
    2014-11-25

    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?

     
  • James B. Byrne
    James B. Byrne
    2014-11-25

    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
  • Joe Cooper
    Joe Cooper
    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.

     
  • Steven Page
    Steven Page
    2015-04-29

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

     
  • Steven Page
    Steven Page
    2015-04-29

    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
  • Jamie Cameron
    Jamie Cameron
    2015-04-30

    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

       
  • Jamie Cameron
    Jamie Cameron
    2015-05-02

    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..

     
  • James B. Byrne
    James B. Byrne
    2015-05-02

    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.

     
  • Jamie Cameron
    Jamie Cameron
    2015-05-04

    Ok, I'll try that out.

     
  • Steven Page
    Steven Page
    2015-05-26

    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:

    my %DEFAULT_SSL_SERVER_ARGS = (
    %DEFAULT_SSL_ARGS,
    SSL_verify_mode => SSL_VERIFY_NONE,
    SSL_honor_cipher_order => 1, # trust server to know the best cipher
    SSL_dh => do {
    my $bio = Net::SSLeay::BIO_new(Net::SSLeay::BIO_s_mem());
    # generated with: openssl dhparam 2048
    Net::SSLeay::BIO_write($bio,<<'DH');
    -----BEGIN DH PARAMETERS-----
    MIIBCAKCAQEAr8wskArj5+1VCVsnWt/RUR7tXkHJ7mGW7XxrLSPOaFyKyWf8lZht
    iSY2Lc4oa4Zw8wibGQ3faeQu/s8fvPq/aqTxYmyHPKCMoze77QJHtrYtJAosB9SY
    CN7s5Hexxb5/vQ4qlQuOkVrZDiZO9GC4KaH9mJYnCoAsXDhDft6JT0oRVSgtZQnU
    gWFKShIm+JVjN94kGs0TcBEesPTK2g8XVHK9H8AtSUb9BwW2qD/T5RmgNABysApO
    Ps2vlkxjAHjJcqc3O+OiImKik/X2rtBTZjpKmzN3WWTB0RJZCOWaLlDO81D01o1E
    aZecz3Np9KIYey900f+X7zC2bJxEHp95ywIBAg==
    -----END DH PARAMETERS-----
    DH
    my $dh = Net::SSLeay::PEM_read_bio_DHparams($bio);
    Net::SSLeay::BIO_free($bio);
    $dh or die "no DH";
    $dh;
    },
    $can_ecdh ? ( SSL_ecdh_curve => 'prime256v1' ):(),

    );

    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?

     
  • Steven Page
    Steven Page
    2015-05-26

    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.

     
<< < 1 2 (Page 2 of 2)