Re: SSL: better default ciphersuite

Поиск
Список
Период
Сортировка
От Marko Kreen
Тема Re: SSL: better default ciphersuite
Дата
Msg-id 20131129164322.GB26457@gmail.com
обсуждение исходный текст
Ответ на Re: SSL: better default ciphersuite  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: SSL: better default ciphersuite  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
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.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [GENERAL] pg_upgrade ?deficiency
Следующее
От: Marko Kreen
Дата:
Сообщение: Re: [PATCH 1/2] SSL: GUC option to prefer server cipher order