2ndQuadrant is now part of EDB

Bringing together some of the world's top PostgreSQL experts.

2ndQuadrant | PostgreSQL
Mission Critical Databases
  • Contact us
  • EN
    • FR
    • IT
    • ES
    • DE
    • PT
  • Support & Services
    • Support
      • 24/7 PostgreSQL Support
      • Developer Support
    • DBA Services
      • Remote DBA
      • Database Monitoring
    • Consulting Services
      • Health Check
      • Performance Tuning
      • Database Security Audit
      • PostgreSQL Upgrade
    • Migration Services
      • Migrate to PostgreSQL
      • Migration Assessment
  • Products
    • Postgres-BDR ®
    • PostgreSQL High Availability
    • Kubernetes Operators for BDR & PostgreSQL
    • Managed PostgreSQL in the Cloud
    • Installers
      • Postgres Installer
      • 2UDA
    • 2ndQPostgres
    • pglogical
    • Barman
    • repmgr
    • OmniDB
    • SQL Firewall
    • Postgres-XL
  • Downloads
    • Installers
      • Postgres Installer
      • 2UDA – Unified Data Analytics
    • Whitepapers
      • Business Case for PostgreSQL Support
      • Security Best Practices for PostgreSQL
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
  • Postgres Learning Center
    • Webinars
      • Upcoming Webinars
      • Webinar Library
    • Whitepapers
      • Business Case for PostgreSQL Support
      • Security Best Practices for PostgreSQL
    • Blog
    • Training
      • Course Catalogue
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
    • Books
      • PostgreSQL 11 Administration Cookbook
      • PostgreSQL 10 Administration Cookbook
      • PostgreSQL High Availability Cookbook – 2nd Edition
      • PostgreSQL 9 Administration Cookbook – 3rd Edition
      • PostgreSQL Server Programming Cookbook – 2nd Edition
      • PostgreSQL 9 Cookbook – Chinese Edition
    • Videos
    • Events
    • PostgreSQL
      • PostgreSQL – History
      • Who uses PostgreSQL?
      • PostgreSQL FAQ
      • PostgreSQL vs MySQL
      • The Business Case for PostgreSQL
      • Security Information
      • Documentation
  • About Us
    • About 2ndQuadrant
    • 2ndQuadrant’s Passion for PostgreSQL
    • News
    • Careers
    • Team Profile
  • Blog
  • Menu Menu
You are here: Home1 / Blog2 / 2ndQuadrant3 / Setting SSL/TLS protocol versions with PostgreSQL 12

PostgreSQL 12 contains two new server settings::

  • ssl_min_protocol_version
  • ssl_max_protocol_version

As the names indicate, these are used to control the oldest (minimum) and newest (maximum) version of the SSL and TLS protocol family that the server will accept.

(For historical reasons, in PostgreSQL, all settings related to SSL and TLS are named ssl_something, even though TLS is the currently correct term. In this article, I will use both terms and use version numbers were more precision is required.)

Right now, the following versions of the SSL/TLS protocol exist:

  • SSL 1.0 (never publicly released)
  • SSL 2.0 (1995)
  • SSL 3.0 (1996)
  • TLS 1.0 (1999)
  • TLS 1.1 (2006)
  • TLS 1.2 (2008)
  • TLS 1.3 (2018)

SSL support in PostgreSQL first appeared in version 7.0, released in 2000 (commit). (Curiously, this was not mentioned in the release notes at all at the time.) It supported SSL 2.0 and up.

In PostgreSQL 7.4, released in 2003, support for SSL 2.0 was removed from the source code (commit). Support for SSL 3.0 was removed in PostgreSQL 9.4, released in 2014 (commit). (If you check the trail of commit messages carefully, there was some confusion in the intermediate versions where apparently the client side (libpq) would insist on using TLS 1.0 exactly but the server would accept any version, including SSL 3.0 and newer TLS versions. There were also a number of interoperability issues to contend with while introducing the various new TLS versions. If you need yet another reason to get rid of your old PostgreSQL versions, there is one.)

Which TLS versions PostgreSQL supports also depends on what the OpenSSL library in use supports. All releases under the “OpenSSL” label (as opposed to the predecessor “SSLeay”) support at least TLS 1.0. For TLS 1.1 and TLS 1.2, OpenSSL 1.0.1 (2012) is required. For TLS 1.3, OpenSSL 1.1.1 (2018) is required. Many vendors ship patched OpenSSL versions, and there are a number of OpenSSL-compatible libraries (such as LibreSSL) that may have other capabilities. So in general this is quite tricky to track.

By default, PostgreSQL server and client leave the negotiation of the TLS version up to the SSL library. They will negotiate a TLS version between 1.0 and 1.3 transparently and use the latest one that both sides support.

The reason new versions of TLS are developed is, among other reasons, that security issues are found in the older versions. So almost universally, using a later version is better than using a previous
version. The only issue is that all the software needs to be updated to actually support the newer versions.

How can you check what TLS versions you are currently using?

You can use the system view pg_stat_ssl to see the SSL status of all connections:

SELECT * FROM pg_stat_ssl;

  pid  | ssl | version |         cipher         | bits | compression | client_dn | client_serial | issuer_dn
-------+-----+---------+------------------------+------+-------------+-----------+---------------+-----------
 59609 | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           |           |               |

(Join with pg_stat_activity on the pid column to see more details on each connection. Full access to these views may require superuser permissions.)

If you enable log_connections in the server, each connection attempt over TCP/IP will also contain information about the SSL parameters used.

2019-11-23 09:49:23.322 CET [59633] LOG:  connection authorized: user=peter database=postgres application_name=psql SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, compression=off)

Using either of these tools, perhaps combined with log analysis tools or similar, you can analyze the TLS use in your environment and detect clients using suspiciously old versions.

If you are using psql, it will also print the same information on the client side when you connect:

$ psql -h localhost
psql (12.1)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

postgres=#

and you can use the psql command \conninfo to have this information printed at any time.

If you are writing your own client application using libpq, this information can be obtained using the function PQsslAttribute().

For testing, you can also use the openssl command directly, for example

openssl s_client -connect localhost:5432 -starttls postgres

This will print out a lot of low-level protocol information, including the TLS version, cipher, and so on. Note that you must use the option -starttls postgres, or otherwise this command will report that no SSL is in use. This requires at least OpenSSL 1.1.1.

Now, in order to improve security, you may want to disable the use of old versions TLS. That’s what these settings are for. So for example, if you set

ssl_min_protocol_version = 'TLSv1.1'

then connections with TLS 1.0 are rejected. Similarly, you could set it to TLSv1.2 or TLSv1.3. The default right now is TLSv1 (which means TLS 1.0; the naming is inconsistent for historical reasons).

If a client does not support the version of TLS that is the minimum required, they will get a connection error. So this is not a good option to put into production without careful analysis and testing. You should use the above tools to make sure that no client (that you care about) still uses old TLS versions.

So which TLS version is a good one?

As one data point, PCI DSS requires disabling TLS 1.0 as of 30 June 2018. That means, as of this writing, if you are still using, or allowing the use of, TLS 1.0, then you are not satisfying PCI DSS. Of course, PCI DSS technically only applies to applications handling credit card data, but it is a fairly well-regarded security standard that is also followed by many outside of its direct area of applicability. PCI DSS also strongly encourages the use of TLS 1.2, so while TLS 1.1 is not officially disallowed at this point, the writing is on the wall.

So at the very least, I would recommend setting the minimum version to TLSv1.1, as shown above.

Secondly, browser vendors are planning to remove support for TLS 1.0 and TLS 1.1 from browsers in “early 2020”. There is also an IETF draft to officially deprecate these protocol versions.

Note that all OpenSSL versions that support TLS 1.1 also support TLS 1.2, so setting the minimum version to TLS 1.2 instead of TLS 1.1 would have no practical drawback for users of OpenSSL, as far as I can tell. There are PostgreSQL clients that don’t use OpenSSL, such as the JDBC driver, but it seems unlikely that the version of the Java stack you use would not support at least TLS 1.2 at this point.

It is probably too early to require TLS 1.3. The protocol itself and the required OpenSSL release are only about a year old, and so you probably won’t find them in most operating installations that are currently in use.

Perhaps you are wondering, why do we also have a setting for the maximum version? That setting is not required for configuring security, but it serves two other purposes: First, it allows testing the protocol negotiation and SSL configuration settings in PostgreSQL. And second, there are occasionally combinations of software components with broken support for some TLS versions. For example, when TLS 1.3 came onto the scene, some specific combinations of PostgreSQL-related software components failed to support TLS 1.3 and errored out during a connection attempt. Such situations can be worked around by disabling newer protocol versions on the server side. All instances of such situations in the PostgreSQL ecosystem have been fixed, as far as I know, but it’s still good to have this option around.

Popular Articles from EDB

  • Connecting PostgreSQL using psql and pgAdmin
  • How to use PostgreSQL with Django | EDB
  • How to use PostgreSQL with Laravel | EDB
  • 10 Examples of PostgreSQL Stored Procedures
  • How to import and export data using CSV files in PostgreSQL

Featured Articles from EDB

  • PostgreSQL Replication and Automatic Failover Tutorial
  • PostgreSQL vs. SQL Server (MSSQL) - Extremely Detailed ...
  • The Complete Oracle to PostgreSQL Migration Guide ...
  • PostgreSQL vs. MySQL: A 360-degree Comparison ...
  • How to use pg_dump and pg_restore in multi-host ...

Useful Links from EDB

  • EDB Postgres Advanced Server: The Oracle Alternative
  • Backup and Recovery Tool: Disaster Recovery for PostgreSQL
  • Migration Portal: Convert Oracle database schemas to ...
  • Migration Toolkit: Command-line data migration tool
  • Managing Postgres Replication Made Easy

Search

Get in touch with us!

Recent Posts

  • Random Data December 3, 2020
  • Webinar: COMMIT Without Fear – The Beauty of CAMO [Follow Up] November 13, 2020
  • Full-text search since PostgreSQL 8.3 November 5, 2020
  • Random numbers November 3, 2020
  • Webinar: Best Practices for Bulk Data Loading in PostgreSQL [Follow Up] November 2, 2020

Featured External Blogs

Tomas Vondra's Blog

Our Bloggers

  • Simon Riggs
  • Alvaro Herrera
  • Andrew Dunstan
  • Craig Ringer
  • Francesco Canovai
  • Gabriele Bartolini
  • Giulio Calacoci
  • Ian Barwick
  • Marco Nenciarini
  • Mark Wong
  • Pavan Deolasee
  • Petr Jelinek
  • Shaun Thomas
  • Tomas Vondra
  • Umair Shahid

PostgreSQL Cloud

2QLovesPG 2UDA 9.6 backup Barman BDR Business Continuity community conference database DBA development devops disaster recovery greenplum Hot Standby JSON JSONB logical replication monitoring OmniDB open source Orange performance PG12 pgbarman pglogical PG Phriday postgres Postgres-BDR postgres-xl PostgreSQL PostgreSQL 9.6 PostgreSQL10 PostgreSQL11 PostgreSQL 11 PostgreSQL 11 New Features postgresql repmgr Recovery replication security sql wal webinar webinars

Support & Services

24/7 Production Support

Developer Support

Remote DBA for PostgreSQL

PostgreSQL Database Monitoring

PostgreSQL Health Check

PostgreSQL Performance Tuning

Database Security Audit

Upgrade PostgreSQL

PostgreSQL Migration Assessment

Migrate from Oracle to PostgreSQL

Products

HA Postgres Clusters

Postgres-BDR®

2ndQPostgres

pglogical

repmgr

Barman

Postgres Cloud Manager

SQL Firewall

Postgres-XL

OmniDB

Postgres Installer

2UDA

Postgres Learning Center

Introducing Postgres

Blog

Webinars

Books

Videos

Training

Case Studies

Events

About Us

About 2ndQuadrant

What does 2ndQuadrant Mean?

News

Careers 

Team Profile

© 2ndQuadrant Ltd. All rights reserved. | Privacy Policy
  • Twitter
  • LinkedIn
  • Facebook
  • Youtube
  • Mail
Webinar: Using SSL with PostgreSQL and pgbouncer [Follow Up] Barman 2.10 – Recovery of partial WAL files
Scroll to top
×