SNI Support for unverified SSL

[sammyolo]

Also a relatively simple solution but SNI is also needed (sometimes) for unverified SSL (for example in the case of neon.tech). Or any modern postgres cloud providers.

The solution is relatively simple:

From this:

default_ssl_options(Host, Ssl) ->
  case Ssl of
    ssl_disabled -> {false, []};
    ssl_unverified -> {true, [{verify, verify_none}]};
    ssl_verified -> {true, [
      {verify, verify_peer},
      {cacerts, public_key:cacerts_get()},
      {server_name_indication, binary_to_list(Host)},
      {customize_hostname_check, [
        {match_fun, public_key:pkix_verify_hostname_match_fun(https)}
      ]}
    ]}
  end.

To this:

default_ssl_options(Host, Ssl) ->
  case Ssl of
    ssl_disabled -> {false, []};
    ssl_unverified -> {true, [
      {verify, verify_none},
      {server_name_indication, binary_to_list(Host)}
    ]};
    ssl_verified -> {true, [
      {verify, verify_peer},
      {cacerts, public_key:cacerts_get()},
      {server_name_indication, binary_to_list(Host)},
      {customize_hostname_check, [
        {match_fun, public_key:pkix_verify_hostname_match_fun(https)}
      ]}
    ]}
  end.

I think that's all needed in order to get modern cloud postgres working properly with pog.

If you want me to make a PR im happy to, just relatively new to contributing to open source.

[lpil]

That sounds good! Are there any drawbacks or reasons we would not want to always have that set?

[sammyolo]

There are outdated/older clients that don't support SNI. This may cause issues. I'm not too deep into this technology in all honesty. If you want to be rather safe than sorry, it could be a config argument that you can set to false. However I do recommend the default to be turned on, read below:

Prior to SNI, when making a TLS connection, the client had no way to specify which site it was trying to connect to. Hence, if one server hosts multiple sites on a single listener, the server has no way to know which certificate to use in the TLS protocol. In more detail, when making a TLS connection, the client requests a digital certificate from the web server. Once the server sends the certificate, the client examines it and compares the name it was trying to connect to with the name(s) included in the certificate. If a match occurs, the connection proceeds as normal. If a match is not found, the user may be warned of the discrepancy and the connection may abort as the mismatch may indicate an attempted man-in-the-middle attack. However, some applications allow the user to bypass the warning to proceed with the connection, with the user taking on the responsibility of trusting the certificate and, by extension, the connection.

[lpil]

Sounds good! Please open a PR 🙏