Project

General

Profile

Todo #6332

Upgrade encryption options to cover current range of recommendations

Added by Stilez y almost 4 years ago. Updated 7 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
Web Interface
Target version:
-
Start date:
05/07/2016
Due date:
% Done:

0%

Estimated time:

Description

Several packages, as well as base, have GUI where the user can specify a cipher, digest, or other encryption-related standard. The options for these selections seem to have issues:

  1. They are scattered around and often hard-coded, making them harder to review and periodically update as a whole.
  2. They often present an apparently inadequate range which does not cover the current recommendations for use by major bodies.
  3. There is no page which allows easy admin setting of permissible crypto options (beyond a very basic "allow , so the only way to confirm if undesirably weak crypto is permitted in some function is to check every GUI where a crypto method can be specified.
  4. Defaults and options are at times presented which are currently considered to be effectively broken and should really not be suggested any more, or at least not as defaults (DH=1024 in OpenVPN, MD5 as a digest, etc)
  5. In some circumstances such as longer term resistance to retrospective analysis or decryption of sessions and data (>2030 or >2040) NIST refers to FIPS 140-2 (table 2 p.88) and recommends asymmetric keys >7680 bits or >15360 bits. The European Union Agency for Network and Information Security (ENISA) concurred back in 2013 that crypto based on RSA, DLP and pairing and requiring long term resistance should use >15360 bits. But no pfSense setting where asymmetric key size is entered, allows >4096 bits even if this is recommended in some cases.

Some pfSense functions do allow a full range of options, for example openVPN gets its list of digests and ciphers directly from openVPN and therefore supports all.

POSSIBLE IMPROVEMENT?

  1. Move the hard-coded lists and the most important defaults to more obvious locations where they can be maintained more accessibly.
  2. Create static tables of common descriptors for the most common crypto methods, such as "considered broken", "legacy", "current use", "future use", "long term use", "may break compatibility" etc. Then, where the GUI allows a user to select a crypto method (almost always a dropdown selector) note after the crypto method, the groups it's in, so the user can see for each method, its current status. For example, SHA1 might appear as "SHA1 (considered legacy, use stronger if able)" while an 8192-bit key might appear "8192 bits (currently excessive, recommended for >2030 only; may not be compatible with all software)", or similar. This would greatly help people to choose appropriate key sizes rather than guessing at random or using outdated information. As recommendations are only updated every year, or every few years, categorising this way this would not be burdensome or need constant updates, it could be updated annually or 2-yearly with new releases of the firmware, or checked automatically every X days much like bogon tables (nicer?).

It might also be easy to provide a simple usage tracker to identify when a crypto method that has been used, changes category, and warn the user.

History

#1 Updated by Stilez y almost 4 years ago

Also noting
  • captiveportal.inc uses MD5 to generate randomness for the session id (and probably shouldn't?)
  • auth.inc appears to upgrade password storage from md5-hash to bcrypt-hash when a login succeeds but no hint is given otherwise that some users have old passwords still stored (indefinitely) as MD5 hashes which may present an unrealised vulnerability in the system as nothing is done to these if the user doesn't log on.

#2 Updated by Sean McBride over 3 years ago

I was about to file a similar bug, but found this one searching the bugbase for "md5".

I'm new to pfsense and just reading through the book and setting up IPsec VPN. I was rather shocked to see "md5" as an option in various places, since it's been known to be weak since 2004ish.

This bug entry is pretty ambitious IMHO, perhaps a good starting point would be simply purge "md5" and other crud as options in the UI and increase some of the default encryption settings?

#3 Updated by Jim Pingle over 3 years ago

We can't outright purge md5 and other weak options because people are frequently forced to use them for third party vendor interoperability. It would be nice to allow the admin to selectively disable some, but given how they are represented differently based on whichever underlying software is used (openvpn, strongswan, mpd, etc) then it's tougher to do than it seems on the surface.

We do try to offer strong and sensible defaults, but those change over time so there is always room for debate as there could be some area that was overlooked or recently gained a stronger option that's more desirable.

#4 Updated by Sean McBride over 3 years ago

Jim Pingle wrote:

We can't outright purge md5 and other weak options because people are frequently forced to use them for third party vendor interoperability.

Still? :( Speaks volumes on the state of internet security I suppose. :(

How about at least putting warnings in the text under the various popups? I could probably grep the strings and submit a patch...

We do try to offer strong and sensible defaults, but those change over time so there is always room for debate as there could be some area that was overlooked or recently gained a stronger option that's more desirable.

Well, from what I've touched upon so far setting up IPsec:
- phase 1 hash algo defaults to only SHA1
- phase 1 DH group defaults to only 1024 bit

#5 Updated by Jim Thompson over 3 years ago

  • Assignee set to Steve Beaver

In general I agree that we could do a better job here. Beaver can look into that.

Things like md5 have to stay until they are deprecated via RFC or similar. You wouldn't believe the fight that some here (now gone) put up when I removed (single) DES from IPsec.

#6 Updated by Sean McBride over 3 years ago

I believe such an RFC exists already:

https://tools.ietf.org/html/rfc6151

Section 2: "MD5 is no longer acceptable where collision resistance is required such as digital signatures."

#7 Updated by Jim Pingle 7 months ago

  • Category set to Web Interface

Also available in: Atom PDF