Re: CA and HTTPS usage on *.ipfire.org

[Jeffrey Walton <noloader@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5407 bytes --]

On Mon, Jan 29, 2018 at 7:14 AM, Michael Tremer
<michael.tremer(a)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