Recent changes to 4415: Perfect Forward Secrecy does not workhttps://sourceforge.net/p/webadmin/bugs/4415/2016-10-10T05:09:47Z#4415 Perfect Forward Secrecy does not work2016-10-10T05:09:47Z2016-10-10T05:09:47ZJamie Cameronhttps://sourceforge.net/u/jcameron/https://sourceforge.netd58903c9a7957240b82dee2cb9d49de9cbf7f551<div class="markdown_content"><ul>
<li><strong>status</strong>: open --> closed-fixed</li>
</ul></div>#4415 Perfect Forward Secrecy does not work2016-02-19T02:55:55Z2016-02-19T02:55:55ZCharlese2https://sourceforge.net/u/charlese2/https://sourceforge.net1aca138306c260ce717b32496b9a085cf6afe142<div class="markdown_content"><p>In miniserv.pl i added a bit of code and changed one line, but in my tinkering i had it hardcoded.<br/>
<a href="http://i.imgur.com/BmJ6Fjx.png" rel="nofollow">http://i.imgur.com/BmJ6Fjx.png</a></p></div>#4415 Perfect Forward Secrecy does not work2016-02-19T00:25:25Z2016-02-19T00:25:25Zarpeggio4https://sourceforge.net/u/arpeggio4/https://sourceforge.net0baafb78385756c0e4799bfd445b2fd17b243eab<div class="markdown_content"><p>Charlese2, would you mind sharing details on how you added this?</p></div>#4415 Perfect Forward Secrecy does not work2015-12-05T18:41:07Z2015-12-05T18:41:07ZCharlese2https://sourceforge.net/u/charlese2/https://sourceforge.net22da3fdcf9a333bb8060f91ea1d99e5787b58bd1<div class="markdown_content"><p>With a little bit of tinkering i was able to add Diffie-Hellman parameters and Elliptic curve cryptography <img alt="" rel="nofollow" src="http://i.imgur.com/fbUtIDD.png"/></p></div>#4415 Perfect Forward Secrecy does not work2015-09-03T22:47:26Z2015-09-03T22:47:26ZAaron Roydhousehttps://sourceforge.net/u/aaronroydhouse/https://sourceforge.net818dd97dca1daf154a002416b190c5dc5683dcc2<div class="markdown_content"><p>I used to try for 'future proof' lists that started with 'HIGH' and then excluded undesireable options, but I have come around that it is better to explicitly list some good and supported options. And if a new thing comes out, add it manually. With that in mind a good list for Webmin/Usermin is simply 'AES+RSA' (openssl will order by strength by default).</p>
<p>$ openssl ciphers -v 'AES+RSA'<br/>
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD<br/>
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256<br/>
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1<br/>
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD<br/>
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256<br/>
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1</p>
<p>Later, if PFS support is added to Webmin, add those key exchange options, keeping the 'AES+RSA' on the end, only if you want older Windows+IE browsers to work: 'ECDH+aRSA+AES:DH+aRSA+AES:AES+RSA'</p>
<p>$ openssl ciphers -v 'ECDH+aRSA+AES:DH+aRSA+AES:AES+RSA'<br/>
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD<br/>
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384<br/>
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1<br/>
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD<br/>
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256<br/>
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1<br/>
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD<br/>
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256<br/>
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1<br/>
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD<br/>
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256<br/>
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1<br/>
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD<br/>
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256<br/>
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1<br/>
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD<br/>
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256<br/>
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA</p></div>#4415 Perfect Forward Secrecy does not work2015-09-03T22:06:55Z2015-09-03T22:06:55Z waffles1006 https://sourceforge.net/u/waffles1006/https://sourceforge.net86c125a468439a35019bfcabeb8a6c9a7854e53f<div class="markdown_content"><p>Yeah I saw that it had RSA was going to remove it along with AES256-SHA but when I do that it breaks. What ciphers would you recommend then. Currently I use the following on most webserver but this won't work for webmin for the reasons you specodifed. Is AES256-SHA the best we can get? </p>
<p>EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!Low:!DES:!RC4:!3DES:!MD5:!PSK:!SRP:!DSS</p></div>#4415 Perfect Forward Secrecy does not work2015-09-03T20:27:08Z2015-09-03T20:27:08ZAaron Roydhousehttps://sourceforge.net/u/aaronroydhouse/https://sourceforge.netef3fd557a0431a23ffc6f1fd4aaa88109d6969c2<div class="markdown_content"><p>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 options too.</p>
<p>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'</p>
<p>I suggest you specify your own list and realise that there is no point including PFS key exchange options like DH or ECDH because the 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 doesn't automatically add default parameter values. Until either Webmin for SSLeay changes, no PFS for us.</p></div>#4415 Perfect Forward Secrecy does not work2015-09-03T19:11:26Z2015-09-03T19:11:26Z waffles1006 https://sourceforge.net/u/waffles1006/https://sourceforge.net9f8903b8ec642d7df26832a0fb1eca78d8f3cdec<div class="markdown_content"><p>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. <br/>
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</p>
<p>Its falling back to the weekest option. I'm runing Vitualmin 4.18 / Webmin 1.760 on unutnu 14.04.3.</p>
<p>Thanks for any help.</p></div>#4415 Perfect Forward Secrecy does not work2015-05-26T08:08:15Z2015-05-26T08:08:15ZSteven Pagehttps://sourceforge.net/u/rapidwebs/https://sourceforge.net3128709249f4fadff6a1c1a509eb677ab1272a49<div class="markdown_content"><p>oh yeah, I also noticed this from the first page. forgot all about this! :</p>
<p>the Short & Sweet OpenSSL Cipher String:<br />
<a href="http://pastebin.com/yUB5c7XY" rel="nofollow">http://pastebin.com/yUB5c7XY</a></p>
<p>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. </p>
<p>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.</p>
<p>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.</p></div>#4415 Perfect Forward Secrecy does not work2015-05-26T07:19:17Z2015-05-26T07:19:17ZSteven Pagehttps://sourceforge.net/u/rapidwebs/https://sourceforge.net2bfea884022a9e236499697d2a10aa2824c9adf9<div class="markdown_content"><p>I mentioned this on page 1: <a href="https://sourceforge.net/p/webadmin/bugs/4415/#1d75">https://sourceforge.net/p/webadmin/bugs/4415/#1d75</a> a while back, but I forgot to follow up with Jamie to see if maybe it could be somehow related to the issue.</p>
<p>either way, its a direction to head in for now :)</p>
<p>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.</p>
<p>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..</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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:</p>
<blockquote>
<p>my %DEFAULT_SSL_SERVER_ARGS = (<br />
%DEFAULT_SSL_ARGS,<br />
SSL_verify_mode => SSL_VERIFY_NONE,<br />
SSL_honor_cipher_order => 1, # trust server to know the best cipher<br />
SSL_dh => do {<br />
my $bio = Net::SSLeay::BIO_new(Net::SSLeay::BIO_s_mem());<br />
# generated with: openssl dhparam 2048<br />
Net::SSLeay::BIO_write($bio,<<'DH');<br />
-----BEGIN DH PARAMETERS-----<br />
MIIBCAKCAQEAr8wskArj5+1VCVsnWt/RUR7tXkHJ7mGW7XxrLSPOaFyKyWf8lZht<br />
iSY2Lc4oa4Zw8wibGQ3faeQu/s8fvPq/aqTxYmyHPKCMoze77QJHtrYtJAosB9SY<br />
CN7s5Hexxb5/vQ4qlQuOkVrZDiZO9GC4KaH9mJYnCoAsXDhDft6JT0oRVSgtZQnU<br />
gWFKShIm+JVjN94kGs0TcBEesPTK2g8XVHK9H8AtSUb9BwW2qD/T5RmgNABysApO<br />
Ps2vlkxjAHjJcqc3O+OiImKik/X2rtBTZjpKmzN3WWTB0RJZCOWaLlDO81D01o1E<br />
aZecz3Np9KIYey900f+X7zC2bJxEHp95ywIBAg==<br />
-----END DH PARAMETERS-----<br />
DH<br />
my $dh = Net::SSLeay::PEM_read_bio_DHparams($bio);<br />
Net::SSLeay::BIO_free($bio);<br />
$dh or die "no DH";<br />
$dh;<br />
},<br />
$can_ecdh ? ( SSL_ecdh_curve => 'prime256v1' ):(),</p>
<p>);</p>
</blockquote>
<p>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.</p>
<p>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? </p>
<p>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?</p></div>