Re: fe-secure.c and SSL/TLS - Mailing list pgsql-hackers

Hi Marko,

Sorry to go offlist....

>> I believe the "standard" way of achieving TLS1.0 and above is to use
>> the SSLv23_client_method() and then remove the SSL protocols with
>> SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3. I have to use handwaiving around
>> "standard" because I don't believe its documented anywhere (one of the
>> devs told me its the standard way to do it.).
>
> Indeed - Python ssl module seems to achieve TLSv1.1 and it uses
> SSLv23_method().  But still no TLSv1.2.
It sounds like they are using the TLSv1_1_method(). You can check it
with Wireshark. The Client Hello will advertise the highest version of
the protocol supported. See http://postimg.org/image/e4mk3nhhl/.

If Python is not advertising TLS 1.2, then they should use the
SSLv23_method() with SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3 and
SSL_OP_NO_TLSv1. That will get them TLS 1.1 and above. From ssl.h,
around line 605:

#define SSL_OP_NO_SSLv2                    0x01000000L
#define SSL_OP_NO_SSLv3                    0x02000000L
#define SSL_OP_NO_TLSv1                    0x04000000L
#define SSL_OP_NO_TLSv1_2                0x08000000L
#define SSL_OP_NO_TLSv1_1                0x10000000L

If you only want TLS 1.1 and 1.2, you can further trim your preferred
cipher list. TLS 1.1 did not add any ciphers, so your list might look
like (the TLS 1.0 ciphers can be used in TLS 1.1):

const char* PREFERRED_CIPHERS =
   /* TLS 1.2 only */   "ECDHE-ECDSA-AES256-GCM-SHA384:"   "ECDHE-RSA-AES256-GCM-SHA384:"
"ECDHE-ECDSA-AES128-GCM-SHA256:"  "ECDHE-RSA-AES128-GCM-SHA256:"
 
   /* TLS 1.2 only */   "DHE-DSS-AES256-GCM-SHA384:"   "DHE-RSA-AES256-GCM-SHA384:"   "DHE-DSS-AES128-GCM-SHA256:"
"DHE-RSA-AES128-GCM-SHA256";
   /* TLS 1.0 and above */   "DHE-DSS-AES256-SHA:"   "DHE-RSA-AES256-SHA:"   "DHE-DSS-AES128-SHA:"
"DHE-RSA-AES128-SHA:"

Personally, I'd like to drop TLS 1.0 (even though the complaints are
mainly academic). But I think its still needed for interop. I've never
rolled a system without it enabled.

Jeff

On Fri, Nov 29, 2013 at 7:14 PM, Marko Kreen <markokr@gmail.com> wrote:
> On Fri, Nov 29, 2013 at 06:01:01PM -0500, Jeffrey Walton wrote:
>> I know of no other ways to check the result of OpenSSL's chain
>> validation. The open question (for me) is where are
>> SSL_get_verify_result/X509_V_OK checked? Neither show up in the
>> Postgres sources.
>
> According to SSL_set_verify manpage, you are perhaps talking about
> SSL_VERIFY_NONE case?  Which has suggestion that you should call
> SSL_get_verify_result if you want to know if cert was valid.
>
> But if SSL_VERIFY_PEER is used, this is not needed.
>
>> > 3) libpq starts using TLSv1_2_method() by default.
>> > 4) libpq will give switch to users to request TLSv1.2.
>> This might have negative effects on non-TLSv1.2 clients. For example,
>> an Android 2.3 device can only do TLSv1.0 (IIRC). I think there's a
>> similar limitation on a lot of Windows XP clients (depending on the IE
>> version and SChannel version). And OpenSSL-based clients prior to
>> 1.0.0h (released 14 Mar 2012) will have trouble (if I am reading the
>> change log correctly).
>
> Note we are talking about client-side settings here.  So the negative
> effect would be that clients with TLSv1.2+ libpq cannot connect to
> old servers.
>
>> I believe the "standard" way of achieving TLS1.0 and above is to use
>> the SSLv23_client_method() and then remove the SSL protocols with
>> SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3. I have to use handwaiving around
>> "standard" because I don't believe its documented anywhere (one of the
>> devs told me its the standard way to do it.).
>
> Indeed - Python ssl module seems to achieve TLSv1.1 and it uses
> SSLv23_method().  But still no TLSv1.2.
>
> I'll play with it a bit to see whether it can have any negative effects.