On Mon, Jan 29, 2018 at 7:14 AM, Michael Tremer michael.tremer@ipfire.org wrote:
First regression! That was a long time, but someone found something:
iPXE does TLS1.2, but no PFS. Doesn't seem to be implemented at all.
https://forum.ipfire.org/viewtopic.php?f=5&t=20232&p=113946#p113946
The problem appears to be iPXE's TLS stack. It is rather anemic... http://ipxe.org/crypto:
The exact list of supported cipher suites is RSA_WITH_AES_256_CBC_SHA256, RSA_WITH_AES_128_CBC_SHA256, RSA_WITH_AES_256_CBC_SHA, and RSA_WITH_AES_128_CBC_SHA
They are all key transport schemes, rather than key exchange schemes. The RSA_WITH_* tells us the key agreement scheme.
I enabled "AES256-SHA256" for the moment to get it working again, but I suppose that is not a permanent solution.
My gut intuition is, OP in the thread should run a squid proxy. The internal proxy allows the RSA transport schemes, and external interface of the proxy uses modern protocols and cipher suites.
Stepping back a bit to what is good for IPFire, then it depends. If the information being protected is public information like free downloads, then there's not much to gain from PFS. The attacker already knows the contents of the communications.
If the information includes user account names and passwords for services or a wiki, then PFS may be desired. If the comms were from a dissident in an oppressive regime, then PFS would probably be a "must have".
What do you guys think about allowing non-PFS cipher suites on downloads.ipfire.org, boot.ipfire.org and mirror1.ipfire.org?
It looks like downloads.ipfire.org is a tad bit tight, and could probably be loosened a bit. However, the loosening probably won't bridge the gap between a modern protocols and cipher suite list and iPXE.
Here is downloads.ipfire.org cipher suite list. It uses an server certificate with an RSA key.
$ sslscan --no-failed download.ipfire.org ...
Testing SSL server download.ipfire.org on port 443
... Supported Server Cipher(s): Accepted TLS12 256 bits ECDHE-RSA-AES256-GCM-SHA384 Accepted TLS12 256 bits ECDHE-RSA-AES256-SHA384 Accepted TLS12 256 bits AES256-SHA256 Accepted TLS12 128 bits ECDHE-RSA-AES128-GCM-SHA256 Accepted TLS12 128 bits ECDHE-RSA-AES128-SHA256
Preferred Server Cipher(s): SSLv3 0 bits (NONE) TLSv1 0 bits (NONE) TLS11 0 bits (NONE) TLS12 256 bits ECDHE-RSA-AES256-GCM-SHA384
You might consider something like the following in your /etc/httpd/conf.d/ssl.conf :
SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2 SSLCipherSuite HIGH:!aNULL:!kRSA:!MD5:!RC4 Header set Strict-Transport-Security "max-age=15552001; includeSubdomains;"
The above is from the cryptopp.com website, which is another free/open source project. It results in server cipher suites like shown below. The site protects public downloads and wiki passwords. The risk assessment tells us we are OK with TLS 1.0 through TLS 1.2 and the list of cipher suites shown below.
The "!kRSA" is the one that ensures PFS (along with non-static DH keys). kRSA allows key *transport*, which is the one where clients encrypt their premaster secret with the server's RSA key and then send it to the server. There is no contributory behavior from the server, and all keys are derived from the one premaster secret. A compromise of the RSA key allows recovery of past conversations.
When kRSA is removed, that leaves key exchange. Key *exchange* is DH and it uses random contributions from both the client and the server. A RSA key compromise does not allow recovery of past conversations because the comms were setup with random parameters. The server's RSA signing key was still used, but it was used to sign the messages and establish authenticity.
Jeff
$ sslscan --no-failed www.cryptopp.com ...
Supported Server Cipher(s): Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA Accepted TLSv1 256 bits DHE-RSA-AES256-SHA Accepted TLSv1 256 bits DHE-RSA-CAMELLIA256-SHA Accepted TLSv1 128 bits ECDHE-RSA-AES128-SHA Accepted TLSv1 128 bits DHE-RSA-AES128-SHA Accepted TLSv1 128 bits DHE-RSA-CAMELLIA128-SHA Accepted TLS11 256 bits ECDHE-RSA-AES256-SHA Accepted TLS11 256 bits DHE-RSA-AES256-SHA Accepted TLS11 256 bits DHE-RSA-CAMELLIA256-SHA Accepted TLS11 128 bits ECDHE-RSA-AES128-SHA Accepted TLS11 128 bits DHE-RSA-AES128-SHA Accepted TLS11 128 bits DHE-RSA-CAMELLIA128-SHA Accepted TLS12 256 bits ECDHE-RSA-AES256-GCM-SHA384 Accepted TLS12 256 bits ECDHE-RSA-AES256-SHA384 Accepted TLS12 256 bits ECDHE-RSA-AES256-SHA Accepted TLS12 256 bits DHE-RSA-AES256-GCM-SHA384 Accepted TLS12 256 bits DHE-RSA-AES256-SHA256 Accepted TLS12 256 bits DHE-RSA-AES256-SHA Accepted TLS12 256 bits DHE-RSA-CAMELLIA256-SHA Accepted TLS12 128 bits ECDHE-RSA-AES128-GCM-SHA256 Accepted TLS12 128 bits ECDHE-RSA-AES128-SHA256 Accepted TLS12 128 bits ECDHE-RSA-AES128-SHA Accepted TLS12 128 bits DHE-RSA-AES128-GCM-SHA256 Accepted TLS12 128 bits DHE-RSA-AES128-SHA256 Accepted TLS12 128 bits DHE-RSA-AES128-SHA Accepted TLS12 128 bits DHE-RSA-CAMELLIA128-SHA