On Fri, Nov 29, 2013 at 09:18:49AM -0500, Peter Eisentraut wrote: > On Fri, 2013-11-15 at 01:11 +0200, Marko Kreen wrote: > > Attached patch changes the default ciphersuite to > > > > HIGH:!aNULL > > > > instead of old > > > > DEFAULT:!LOW:!EXP:!MD5:@STRENGTH > > > > where DEFAULT is a shortcut for "ALL:!aNULL:!eNULL". > > > Main goal is to leave low-level ciphersuite details to OpenSSL guys > > and give clear impression to Postgres admins what it is about. > > If we want to leave the details of the ciphers to OpenSSL, I think we > shouldn't be second-guessing their judgement of what a reasonable > default is.
Well, we should - the DEFAULT is clearly a client-side default for compatibility only. No server should ever run with it. OTOH, the whole point of "HIGH:!aNULL" is to leave low-level ciphersuite details to OpenSSL guys - as a Postgres admin is not clear to me that DEFAULT:!LOW:!EXP:!MD5:@STRENGTH is actually good suite. It contains "DEFAULT" plus several fixes which show that DEFAULT is not good enough. Why all that? Admin would need to do lot research to see what it is about. Another aspect is that the "HIGH:!aNULL" is more futureproof as default, current default has needed fixes (!LOW:!EXP:!MD5) and would need more fixes in the future (RC4). Also note that OpenSSL has only one ordered cipher list - ALL. All other tokens simply walk that list while keeping the order. So it's not like not using DEFAULT would somehow lose important details about order. > I checked Apache mod_ssl and Postfix, and even though they are > configuring this slightly differently, I think their defaults end up > being about the same as what PostgreSQL currently has. > > https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite > http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_ciphers My proposal is inspired by nginx default: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers > > HIGH: > > Contains only secure and well-researched algorithms. > > > > !aNULL > > Needed to disable suites that do not authenticate server. > > DEFAULT includes !aNULL by default. > > Wouldn't HIGH exclude aNULL also? (If not, what about eNULL?) HIGH/MEDIUM/LOW/ALL are only about cipher strength so they don't exclude aNULL. HIGH does exclude eNULL because eNULL ciphers are not strong enough... > > !MD5 > > This affects only one suite: DES-CBC3-MD5, which is available only > > for SSL2 connections. So it would only pollute the default value. > > I think this is only there for political correctness. But it's noise so should be removed. > > @STRENGTH > > The OpenSSL cipher list is already sorted by humans, > > it's unlikely that mechanical sort would improve things. > > Also the existence of this value in old list is rather > > dubious, as server cipher order was never respected anyway. > > Aren't you proposing to change that? No, ALL and subsets of it (HIGH) are already ordered by @STRENGTH. @STRENGTH as token is only useful if admin does complex filtering by other parameters then wants to reorder it again by cipher strength. Eg. an other default I've considered is: EECDH+HIGH:EDH+HIGH:@STRENGTH which enforces ephemeral key use. @STRENGTH is actually useful there, as without it ECDHE-AES128 would be preferred to DHE-AES256. But it exposes unnecessary complexity to database admins who are not particularly familiar with TLS and OpenSSL internals. So I think the HIGH:!aNULL is better default as it's simpler. And ephemeral keys are preferred anyway. -- marko PS. @STRENGTH and OpenSSL default order in general has problem that it orders 3DES (168-bit key) before AES128, but 3DES strength is around 112-bit only. So crypto-wise, the "perfect" default, while keeping compatibility, would be: EECDH+HIGH:EDH+HIGH:@STRENGTH:+3DES but it's getting messier and messier... PS2. And more fragile too - admin could change +3DES to -3DES and that would be fine, but plain '3DES' would enable aNULL suite. So keeping '!aNULL' visible might not be bad idea. -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers