[FOLIO-2406] SSL/TLS, SCRAM-SHA-256, migration to PostgreSQL 10 (or higher) Created: 18/Dec/19  Updated: 15/Jun/20  Resolved: 20/Dec/19

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P2
Reporter: Johannes Drexl Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: postgres, privacy, security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Duplicate
duplicates FOLIO-1438 Upgrade to PostgreSQL 10 Closed
duplicates FOLIO-2410 EOL: PostgreSQL 9.x Closed
duplicates OKAPI-787 Support SSL connections to Postgres Closed
duplicates RMB-546 Support TLS/SSL connections to Postgres Closed
duplicates FOLIO-2145 Upgrade to PostgreSQL 12 Closed
duplicates FOLIO-2144 Upgrade to PostgreSQL 11 Closed
duplicates FOLIO-2411 Use SCRAM-SHA-256 for passwords on Po... Blocked
duplicates FOLIO-2412 Clients should verify PostgreSQL SSL/... Blocked
Sprint:

 Description   

Okapi and probably all modules are using legacy (though still supported) postgres libraries, which have major drawbacks and sometimes seem to be not correctly implemented anyway.

  • Migration to PG10+ will be mandatory in September 2021, because that's when support for 9.x will be dropped after 5 years of maintenance. Pushing that to the back of the queue will be stressful for the community afterwards, when the deadline draws near, especially with more and more modules being build on legacy functions and more libraries using folio in their production environment.
  • SSL not supported
    Okapi 2.36.0 is not able to talk to a PG server that enforces SSL communication. Although a dedicated VLAN can be used for communication of this type, a single error or bug in the network setup can severely impact query privacy in this scenario, including exposure of database (login) information to a sniffing attacker. Defense in depth -> use everything that secures confidentiality and security of communication and hampers a potential adversary, so even crushing 0day exploits are highly unlikely to compromise the setup.
  • MD5 mandatory
    MD5 is the only password storage hashing algorithm that is supported by PG 9.x. And it's legacy, i. e. broken beyond repair and hope. PG 10 introduced SCRAM-SHA-256. Not only is sha256 a stronger and - for the foreseeable future - secure hashing algorithm, it also is salted and bundled with salted challenge response authentication, which doesn't expose passwords to sniffing parties on the network. Even if database breaches are something that seems like a worst case scenario, exposing passwords due to weak hashes during a breach will put a lot of users under fire, since we all know a lot of people recycle their passwords. SCRAM-SHA-256 won't be breakable for quite some time (as of current knowledge), and the salting counters rainbow table attacks too.
    There also is the problem that MD5 hashed passwords are incompatible with SCRAM-SHA-256 authentication, so upgrading and using the better algorithm is only possible by resetting all passwords, which is a nightmare in its own right.

Additional note: Enable SSL server certificate pinning when upgrading
postgresql will by default allow connections to servers with unknown/self-signed certificates and doesn't bother about server verification:
https://www.postgresql.org/docs/current/libpq-ssl.html#LIBQ-SSL-CERTIFICATES
Introduce a parameter to make certificate verification enforceable or better make it mandatory.



 Comments   
Comment by Julian Ladisch [ 19/Dec/19 ]

Thank you for your report.

It seems that you've combined 4 issues into a single report:
1. End-of-Life of PostgreSQL 9.x in September 2021.
2. Okapi has no SSL support for the connection to PostgreSQL.
3. Missing SCRAM-SHA-256 support (only MD5) for PostgreSQL passwords.
4. Missing SSL server certificate pinning for the connection to PostgreSQL.

Can you create a separate Jira issue for each of them so that they can be handled independently?

Can you check whether FOLIO-1438 Closed solves 1. and 3.?

Can you report 2. against OKAPI project? https://folio-org.atlassian.net/projects/OKAPI/issues

When creating the issue for 4. can you be more specific in which part of FOLIO you noticed this problem (for example mod-inventory-storage, or in Okapi)?

After creating the separate Jira issues please link FOLIO-2406 Closed as a duplicate of them and close FOLIO-2406 Closed as duplicate.

Comment by Johannes Drexl [ 20/Dec/19 ]

Split into multiple tickets:

https://folio-org.atlassian.net/browse/FOLIO-2410

https://folio-org.atlassian.net/browse/OKAPI-787

-> https://folio-org.atlassian.net/browse/FOLIO-2412

https://folio-org.atlassian.net/browse/FOLIO-2411

Can't link and close issues, but if Hkaplanian would be so nice to do that for me 😉

As for FOLIO-1438 Closed - I'm only able to test that in about 3 weeks, but I'll try it then.

Comment by Julian Ladisch [ 20/Dec/19 ]

Thank you Johannes, I've linked them!

Generated at Thu Feb 08 23:20:24 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.