2

I have installed PostgreSQL 12.1 on a Windows 10 machine. I am attempting to connect to the server using PostgreSQL JDBC 42.2.10, running in AdoptOpenJDK 11.0.7 created with jlink. The self-signed certificate used on the server uses 2048-bit RSA with a SHA256 signature. I have verified this by opening the certificate, which shows the "Signature algorithm" as sha256RSA, the "Signature hash algorithm" as sha256, and the "Public key" as RSA (2048 Bits).

I am attempting to connect using PostgreSQL JDBC 42.2.10. If I disable TLS 1.3 by adding ssl_max_protocol_version = 'TLSv1.2' to postgresql.conf, then everything works just fine. However, without this line, the TLS handshake fails with a handshake_failure exception. When I look at the PostgreSQL log, I see a line that says:

could not accept SSL connection: no suitable key share

I'm assuming this means there was no overlap between the acceptable cipher suites and those supported by the PostgreSQL server. Does anyone know how to configure either the Java client or the PostgreSQL server to enable such communication using TLS 1.3?

In case it helps, here is my TLS ClientHello message, as output by running Java with the -Djavax.net.debug=all command-line parameter. My hunch is that the issue is the single option available in the psk_key_exchange_modes section:

"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "<HEX DATA>",
  "session id"          : "<HEX DATA>",
  "cipher suites"       : "[TLS_AES_128_GCM_SHA256(0x1301),
                            TLS_AES_256_GCM_SHA384(0x1302),
                            TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D),
                            TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F),
                            TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3),
                            TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C),
                            TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E),
                            TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2),
                            TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D),
                            TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B),
                            TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A),
                            TLS_RSA_WITH_AES_256_CBC_SHA(0x0035),
                            TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039),
                            TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038),
                            TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
                            TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067),
                            TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040),
                            TLS_RSA_WITH_AES_128_CBC_SHA(0x002F),
                            TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033),
                            TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032),
                            TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
  "compression methods" : "00",
  "extensions"          : [
    "status_request (5)": {
      "certificate status type": ocsp
      "OCSP status request": {
        "responder_id": <empty>
        "request extensions": {
          <empty>
        }
      }
    },
    "supported_groups (10)": {
      "versions": [ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]
    },
    "ec_point_formats (11)": {
      "formats": [uncompressed]
    },
    "signature_algorithms (13)": {
      "signature schemes": [rsa_pss_rsae_sha256,
                            rsa_pss_rsae_sha384,
                            rsa_pss_rsae_sha512,
                            rsa_pss_pss_sha256,
                            rsa_pss_pss_sha384,
                            rsa_pss_pss_sha512,
                            rsa_pkcs1_sha256,
                            rsa_pkcs1_sha384,
                            rsa_pkcs1_sha512,
                            dsa_sha256,
                            rsa_sha224,
                            dsa_sha224,
                            rsa_pkcs1_sha1,
                            dsa_sha1]
    },
    "signature_algorithms_cert (50)": {
      "signature schemes": [rsa_pss_rsae_sha256,
                            rsa_pss_rsae_sha384,
                            rsa_pss_rsae_sha512,
                            rsa_pss_pss_sha256,
                            rsa_pss_pss_sha384,
                            rsa_pss_pss_sha512,
                            rsa_pkcs1_sha256,
                            rsa_pkcs1_sha384,
                            rsa_pkcs1_sha512,
                            dsa_sha256,
                            rsa_sha224,
                            dsa_sha224,
                            rsa_pkcs1_sha1,
                            dsa_sha1]
    },
    "status_request_v2 (17)": {
      "cert status request": {
        "certificate status type": ocsp_multi
        "OCSP status request": {
          "responder_id": <empty>
          "request extensions": {
            <empty>
          }
        }
      }
    },
    "extended_master_secret (23)": {
      <empty>
    },
    "supported_versions (43)": {
      "versions": [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1]
    },
    "psk_key_exchange_modes (45)": {
      "ke_modes": [psk_dhe_ke]
    },
    "key_share (51)": {
      "client_shares": [  
        {
          "named group": ffdhe2048
          "key_exchange": { <Hex Data> }
        },
      ]
    }
  ]
}
Jeff G
  • 4,470
  • 2
  • 41
  • 76
  • 1
    Check what version of TLS supported by your installation. Command is here: `SELECT * FROM pg_stat_ssl;` – Steephen Jun 12 '20 at 01:55
  • 1
    That command appears to be showing only active connections, but when run with a PGAdmin 4 connection has two `ssl=true` rows with `version=TLSv1.3` and `cipher=TLS_AES_256_GCM_SHA384`. – Jeff G Jun 12 '20 at 02:08
  • 1
    Possibly this already existing Q/A may help resolve your issue? [SSLHandshakeException with jlink created runtime](https://stackoverflow.com/questions/55439599/sslhandshakeexception-with-jlink-created-runtime). – Ivo Mori Jun 12 '20 at 02:10
  • 1
    @IvoMori Nailed it. Adding that dependency to jlink added three (that matter) additional entries to the `supported_groups` (secp256r1, secp384r1, and secp521r1), and `signature_algorithms*` (ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512). PostgreSQL selected the first in the list. – Jeff G Jun 12 '20 at 02:33
  • 1
    Does this answer your question? [SSLHandshakeException with jlink created runtime](https://stackoverflow.com/questions/55439599/sslhandshakeexception-with-jlink-created-runtime) – Ivo Mori Jun 12 '20 at 04:00
  • Great, that it was the same problem and could be solved in the same way :D This wasn't at all obvious. Anyhow I flagged your question as a duplicate of the already exsting Q/A. Thx for adding the additional details in your last comment. – Ivo Mori Jun 12 '20 at 04:04

0 Answers0