Re: [HACKERS] SSL: better default ciphersuite
committed -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On Sat, Feb 22, 2014 at 08:31:14PM -0500, Peter Eisentraut wrote: On 2/2/14, 7:16 AM, Marko Kreen wrote: On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote: Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL and also adds documentation about reasoning for it. This is the last pending SSL cleanup related patch: https://commitfest.postgresql.org/action/patch_view?id=1310 Peter, you have claimed it as committer, do you see any remaining issues with it? I'm OK with this change on the principle of clarifying and refining the existing default. But after inspecting the expanded cipher list with the openssl cipher tool, I noticed that the new default re-enabled MD5 ciphers. Was that intentional? Yes, kind of. First note that only RC4-MD5 is SSLv3+, rest are SSLv2-only suites. There are 2 points relevant about RC4-MD5: * Main reason MEDIUM was added is to get RC4, for compatibility. * ALthough MD5 is broken, TLS protocol uses HMAC-MD5 which is not. So RC4-MD5 is weak suite not because of MD5 but because of RC4. My conclusion is it's unnecessary to add '!MD5' to MEDIUM as that would not actually make things more secure. Instead 'MEDIUM' alone is enough to show that user will not get state-of-the-art-only suites. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On 2/2/14, 7:16 AM, Marko Kreen wrote: On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote: Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL and also adds documentation about reasoning for it. This is the last pending SSL cleanup related patch: https://commitfest.postgresql.org/action/patch_view?id=1310 Peter, you have claimed it as committer, do you see any remaining issues with it? I'm OK with this change on the principle of clarifying and refining the existing default. But after inspecting the expanded cipher list with the openssl cipher tool, I noticed that the new default re-enabled MD5 ciphers. Was that intentional? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote: Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL and also adds documentation about reasoning for it. This is the last pending SSL cleanup related patch: https://commitfest.postgresql.org/action/patch_view?id=1310 Peter, you have claimed it as committer, do you see any remaining issues with it? -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On Sun, Dec 15, 2013 at 5:10 PM, James Cloos cl...@jhcloos.com wrote: For reference, see: https://wiki.mozilla.org/Security/Server_Side_TLS for the currently suggested suite for TLS servers. ... But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful for some. And RC4, perhaps, also should be !ed. And if anyone wants Kerberos tls-authentication, one could add KRB5-DES-CBC3-SHA, but that is ssl3-only. Once salsa20-poly1305 lands in openssl, that should be added to the start of the list. I'm starting to think we should just leave this well enough alone. We can't seem to find two people with the same idea of what would be better than what we have now. And of course the point of making it a setting in the first place is that each person can set it to whatever they deem best. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote: On Sun, Dec 15, 2013 at 5:10 PM, James Cloos cl...@jhcloos.com wrote: For reference, see: https://wiki.mozilla.org/Security/Server_Side_TLS for the currently suggested suite for TLS servers. ... But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful for some. And RC4, perhaps, also should be !ed. And if anyone wants Kerberos tls-authentication, one could add KRB5-DES-CBC3-SHA, but that is ssl3-only. Once salsa20-poly1305 lands in openssl, that should be added to the start of the list. I'm starting to think we should just leave this well enough alone. We can't seem to find two people with the same idea of what would be better than what we have now. And of course the point of making it a setting in the first place is that each person can set it to whatever they deem best. Yes, I am seeing that too. Can we agree on one that is _better_ than what we have now, even if we can't agree on a _best_ one? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On 12/17/2013 08:26 AM, Bruce Momjian wrote: On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote: On Sun, Dec 15, 2013 at 5:10 PM, James Cloos cl...@jhcloos.com wrote: For reference, see: https://wiki.mozilla.org/Security/Server_Side_TLS for the currently suggested suite for TLS servers. ... But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful for some. And RC4, perhaps, also should be !ed. And if anyone wants Kerberos tls-authentication, one could add KRB5-DES-CBC3-SHA, but that is ssl3-only. Once salsa20-poly1305 lands in openssl, that should be added to the start of the list. I'm starting to think we should just leave this well enough alone. We can't seem to find two people with the same idea of what would be better than what we have now. And of course the point of making it a setting in the first place is that each person can set it to whatever they deem best. Yes, I am seeing that too. Can we agree on one that is _better_ than what we have now, even if we can't agree on a _best_ one? Agreed. I would note that what is being proposed is a default that helps those of us (myself included) that do not know ciphers in and out, start with reasonable expectation of protection. This is a GUC so it can be modified to suite personal taste. -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On Tue, Dec 17, 2013 at 11:26:13AM -0500, Bruce Momjian wrote: On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote: I'm starting to think we should just leave this well enough alone. We can't seem to find two people with the same idea of what would be better than what we have now. And of course the point of making it a setting in the first place is that each person can set it to whatever they deem best. Yes, I am seeing that too. Can we agree on one that is _better_ than what we have now, even if we can't agree on a _best_ one? To recap - old settings are: DEFAULT:!LOW:!EXP:!MD5:@STRENGTH prefer-client-order new proposal is: HIGH:MEDIUM:+3DES:!aNULL prefer-server-order This is better than old state in following aspects: - First, it does not remove any ciphers compared to current list. So anything that could connect previously can connect still. - Clearer to people not intimately familiar with OpenSSL and TLS. In particular, the 'MEDIUM' communicates that some less secure ciphers are enabled (RC4). - Fixes the 3DES ordering. OpenSSL default list is ordered roughly by (key-bits, ECDHE, DHE, plain RSA). 3DES has 168-bit key so it appears before 128-bit ciphers, although it offers around 112-bit actual security. This problem exists already with existing Postgres versions: if you set suite to AES128:3DES, then libpq-based clients will use 3DES. When combined with prefer-server-order, it has following benefits: - Clarity: admin can look at configured cipher order and make reasonable guesses what will be used. - Actually activates the 3DES fix. Although non-libpq/OpenSSL based clients did used their own order, OpenSSL-based client did have same order problem in client-side. - Old clients that did prefer RC4 will use it as last resort only, when only alternative is 3DES. - Old clients that did prefer non-DHE ciphers will use DHE ciphers if available. One goal the new settings *do not* try to achieve is to pick the absolutely fastest cipher from the secure ones. Old settings did not it either, when speaking of libpq clients. Java did try from client-side, but as a result old deployed versions use now insecure settings. I think it's best when the default settings prefer security over speed, everyone who is has special requirements speed-wise - AES is slow - can tune list themselves. So, does anyone have reasons not to use proposed new default? -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On 18/12/13 05:26, Bruce Momjian wrote: On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote: On Sun, Dec 15, 2013 at 5:10 PM, James Cloos cl...@jhcloos.com wrote: For reference, see: https://wiki.mozilla.org/Security/Server_Side_TLS for the currently suggested suite for TLS servers. ... But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful for some. And RC4, perhaps, also should be !ed. And if anyone wants Kerberos tls-authentication, one could add KRB5-DES-CBC3-SHA, but that is ssl3-only. Once salsa20-poly1305 lands in openssl, that should be added to the start of the list. I'm starting to think we should just leave this well enough alone. We can't seem to find two people with the same idea of what would be better than what we have now. And of course the point of making it a setting in the first place is that each person can set it to whatever they deem best. Yes, I am seeing that too. Can we agree on one that is _better_ than what we have now, even if we can't agree on a _best_ one? Because various security agencies probably have people trying to confuse the issue, and acting to discourage strong encryption... Possibly choose the one computationally most difficult to crack - but even then, we don't know what algorithms they are using, which are bound to be very sophisticated. I've a horrible feeling, that I'm not paranoid enough! Cheers, Gavin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On Sun, Dec 15, 2013 at 05:10:38PM -0500, James Cloos wrote: MK == Marko Kreen mark...@gmail.com writes: PE == Peter Eisentraut pete...@gmx.net writes: PE Any other opinions on this out there? For reference, see: https://wiki.mozilla.org/Security/Server_Side_TLS for the currently suggested suite for TLS servers. That is: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM: ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA: ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256: DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256: DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256: AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA: AES128:AES256:RC4-SHA:HIGH: !aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK This is example of ciphersuite list for people who have special requirements and care about tracking yearly changes in SSL landscape. And can deploy config changes relatively fast. This discussion is about Postgres default suite which cannot and should not be periodically changed, for people who leave Postgres settings to defaults and expect setup work well. We would like to leave as much as possible to OpenSSL, but not more. Looking at the history of OpenSSL, their default order has been good, except the 3DES vs. AES128 priority. Looking into future, I guess following events are likely: - RC4 gets practially broken and/or removed from TLS (draft-popov-tls-prohibiting-rc4-01). - New ciphersuites: Salsa/Chacha (256-bit key). - New modes: CCM (RFC6655, draft-mcgrew-tls-aes-ccm-ecc-07), other ciphers with GCM, new AEAD constructs. - CBC mode fixes: pad-mac-encrypt, pad-encrypt-mac. Those may be implemented with TLS extensions, so no new ciphersuites. RC4 situation - the 'MEDIUM' in my proposal communicates that not all ciphers are best, and prefer-server-order makes sure it is selected as last resort. So that is solved. New ciphersuites - if we want to select fastest from secure suites we need to change configuration periodically (RC4-AES128-CBC-AES128-GCM-SALSA) and I don't think Postgres should bother we that. So I think it's better to leave ordering new ciphers to OpenSSL, and people who have special requirements can worry about best configuration for specific stack they are running. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
MK == Marko Kreen mark...@gmail.com writes: PE == Peter Eisentraut pete...@gmx.net writes: MK Well, we should - the DEFAULT is clearly a client-side default MK for compatibility only. No server should ever run with it. PE Any other opinions on this out there? For reference, see: https://wiki.mozilla.org/Security/Server_Side_TLS for the currently suggested suite for TLS servers. That is: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM: ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA: ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256: DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256: DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256: AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA: AES128:AES256:RC4-SHA:HIGH: !aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK The page explains why. But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful for some. And RC4, perhaps, also should be !ed. And if anyone wants Kerberos tls-authentication, one could add KRB5-DES-CBC3-SHA, but that is ssl3-only. Once salsa20-poly1305 lands in openssl, that should be added to the start of the list. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On Thu, Dec 12, 2013 at 09:18:03PM -0500, Peter Eisentraut wrote: On Thu, 2013-12-12 at 12:30 +0200, Marko Kreen wrote: First, if there is explicit wish to keep RC4/SEED in play, I'm fine with HIGH:MEDIUM:!aNULL as new default. Clarity-wise, it's still much better than current value. And this value will result *exactly* same list in same order as current value. If we have to make a change, I'd go for that, but I'm not convinced that this is necessarily clearer. Yeah, the clarity argument is getting thinner... And my latest patch was for HIGH:MEDIUM:+3DES:!aNULL. I still think it's better to have positive statements there - gimme this and that - instad badly-named 'DEFAULT' and then lot's of negatives applied to it. But it's not that straightforward anymore - the +3DES breaks the leave everything to OpenSSL angle. But we do need to change default suite list to have one that works well with prefer-server-ciphers option, which means it should contain at least the +3DES workaround. Client that don't want AES256 are reasonable as AES256 does not have any practical advantages over AES128. I don't think just reverting the default is good idea - we should then add documentation to option that if you flip this, add such fixes to cipher list. Which seems silly. And not documenting anything and just leaving matters to admins seems bad idea too - they are not in better position to do such research than we are now. So I think we can pick good default, now, and everybody will benefit. For fun, how to go overboard on the issue - Mozilla recommendations for TLS setup on their infrastructure: https://wiki.mozilla.org/Security/Server_Side_TLS It also discusses various issues with TLS, so it's good read. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On Wed, Dec 11, 2013 at 10:08:44PM -0500, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: Any other opinions on this out there? All instances of other SSL-enabled servers out there, except nginx, default to some variant of DEFAULT:!LOW:... or HIGH:MEDIUM: The proposal here is essentially to disable MEDIUM ciphers by default, which is explicitly advised against in the Postfix and Dovecot documentation, for example. Doesn't seem like a great idea then. First, if there is explicit wish to keep RC4/SEED in play, I'm fine with HIGH:MEDIUM:!aNULL as new default. Clarity-wise, it's still much better than current value. And this value will result *exactly* same list in same order as current value. But please don't look into SMTP/IMAP world for sane defaults, their situation is quite different: * Lot's of old and crap mail clients around (usually named Outlook). * They use aNULL ciphers for opportunistic SSL. * They use aNULL ciphers because CA-less certs. If you need aNULL enabled anyway, there is no point in secure ciphers. I assume that if left to its own devices, PG presently selects some MEDIUM-level cipher by default? If so, it sounds like this change amounts to imposing a performance penalty for SSL connections by fiat. On the other hand, if we select a HIGH cipher by default, then aren't we just refusing to let clients who explicitly ask for a MEDIUM cipher have one? Either way, I'd want to see a pretty darn airtight rationale for that, and there sure isn't one in this thread so far. Performance penalty can happen for clients that support only RC4 and 3DES, and prefer RC4 currently. 3DES is slow cipher, so falling back to it would be noticeable. According to ssllabs.com, Java 6 does prefer RC4, but it would fall back to AES, which is fast cipher. Java 7 prefers AES. OpenSSL has always used AES, so no change there. I know that SChannel SSL library in Windows XP (and earlier) is such RC4+3DES only implementation, but I have not heard about anything using it to connect to Postgres. Also I have not heard about any Postgres clients actually allowing to configure ciphers, so my impression all client libraries use defaults, which usually prefer AES anyway. The part of the patch that removes @STRENGTH seems plausible, though, if Marko is correct that that's effectively overriding a hand-tailored ordering. In the end I wonder why our default isn't just DEFAULT. Anybody who thinks that's an inappropriate default should be lobbying the OpenSSL folk, not us, I should think. It's easy to see why - then every Postgres admin who wants SSL *must* configure the suite. The ALL:!aNULL:!eNULL default is clearly a library default, which does not know in what situation it is used, geared at max compatibility. It's especially bad choice because it will look fine to people unfamiliar with OpenSSL internal nuances. As seen in this thread. My goal is to have default which will be secure by default, and give rough impression what it is about. - Hm, looking at Java suites, I notice a problem that is due to bug in OpenSSL default cipher order - it orders 3DES before AES128. So if we give priority to server cipher order and client does not accept AES256 (like Java 6/7), 3DES will be picked. This is indeed bug that should be fixed on OpenSSL side, but seems we cannot wait for their fix... So my new proposal would be to pick one from following defaults: 1) HIGH:+3DES:!aNULL - disables RC4, orders 3DES last. 2) HIGH:MEDIUM:+3DES:!aNULL - no suite changes from current one, except 3DES is ordered last. +3DES reorders already picked 3DES suites to the end. As my impression is that no clients ever have actually used 3DES, it's fine to use !3DES there. It's clearer too. But if max compatibility is goal, then +3DES is better. It's not as nice and simple as I hoped though. :( -- marko PS. Use openssl ciphers -v 'HIGH:...' file and diff -u on files to see changes in different values. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On Thu, Dec 12, 2013 at 11:30 AM, Marko Kreen mark...@gmail.com wrote: On Wed, Dec 11, 2013 at 10:08:44PM -0500, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: Any other opinions on this out there? All instances of other SSL-enabled servers out there, except nginx, default to some variant of DEFAULT:!LOW:... or HIGH:MEDIUM: The proposal here is essentially to disable MEDIUM ciphers by default, which is explicitly advised against in the Postfix and Dovecot documentation, for example. Doesn't seem like a great idea then. First, if there is explicit wish to keep RC4/SEED in play, I'm fine with HIGH:MEDIUM:!aNULL as new default. Clarity-wise, it's still much better than current value. And this value will result *exactly* same list in same order as current value. But please don't look into SMTP/IMAP world for sane defaults, their situation is quite different: * Lot's of old and crap mail clients around (usually named Outlook). * They use aNULL ciphers for opportunistic SSL. * They use aNULL ciphers because CA-less certs. If you need aNULL enabled anyway, there is no point in secure ciphers. Yeah, aNULL is definitely pointless. I assume that if left to its own devices, PG presently selects some MEDIUM-level cipher by default? If so, it sounds like this change amounts to imposing a performance penalty for SSL connections by fiat. On the other hand, if we select a HIGH cipher by default, then aren't we just refusing to let clients who explicitly ask for a MEDIUM cipher have one? Either way, I'd want to see a pretty darn airtight rationale for that, and there sure isn't one in this thread so far. Performance penalty can happen for clients that support only RC4 and 3DES, and prefer RC4 currently. 3DES is slow cipher, so falling back to it would be noticeable. According to ssllabs.com, Java 6 does prefer RC4, but it would fall back to AES, which is fast cipher. Java 7 prefers AES. OpenSSL has always used AES, so no change there. I know that SChannel SSL library in Windows XP (and earlier) is such RC4+3DES only implementation, but I have not heard about anything using it to connect to Postgres. Also I have not heard about any Postgres clients actually allowing to configure ciphers, so my impression all client libraries use defaults, which usually prefer AES anyway. I don't know, but I would assume that npgsql which sit on top of dotnet, would sit on top of schannel in the end. That said, this is XP and earlier, right? Newer versions of Windows have better defaults? The part of the patch that removes @STRENGTH seems plausible, though, if Marko is correct that that's effectively overriding a hand-tailored ordering. In the end I wonder why our default isn't just DEFAULT. Anybody who thinks that's an inappropriate default should be lobbying the OpenSSL folk, not us, I should think. It's easy to see why - then every Postgres admin who wants SSL *must* configure the suite. The ALL:!aNULL:!eNULL default is clearly a library default, which does not know in what situation it is used, geared at max compatibility. It's especially bad choice because it will look fine to people unfamiliar with OpenSSL internal nuances. As seen in this thread. My goal is to have default which will be secure by default, and give rough impression what it is about. - Hm, looking at Java suites, I notice a problem that is due to bug in OpenSSL default cipher order - it orders 3DES before AES128. So if we give priority to server cipher order and client does not accept AES256 (like Java 6/7), 3DES will be picked. This is indeed bug that should be fixed on OpenSSL side, but seems we cannot wait for their fix... So my new proposal would be to pick one from following defaults: 1) HIGH:+3DES:!aNULL - disables RC4, orders 3DES last. 2) HIGH:MEDIUM:+3DES:!aNULL - no suite changes from current one, except 3DES is ordered last. +3DES reorders already picked 3DES suites to the end. As my impression is that no clients ever have actually used 3DES, it's fine to use !3DES there. It's clearer too. But if max compatibility is goal, then +3DES is better. It's not as nice and simple as I hoped though. :( We definitely want to explain in a comment next to the default value the exact reasoning behind the default value, I think. That doesn't mean people will understand it, but it means they at least have a chance. That said, #2 seems reasonable I think, but I wouldn't object to #1 either :) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Re: [HACKERS] SSL: better default ciphersuite
On Thu, Dec 12, 2013 at 01:33:57PM +0100, Magnus Hagander wrote: On Thu, Dec 12, 2013 at 11:30 AM, Marko Kreen mark...@gmail.com wrote: On Wed, Dec 11, 2013 at 10:08:44PM -0500, Tom Lane wrote: I know that SChannel SSL library in Windows XP (and earlier) is such RC4+3DES only implementation, but I have not heard about anything using it to connect to Postgres. Also I have not heard about any Postgres clients actually allowing to configure ciphers, so my impression all client libraries use defaults, which usually prefer AES anyway. I don't know, but I would assume that npgsql which sit on top of dotnet, would sit on top of schannel in the end. Probably yes. That said, this is XP and earlier, right? Newer versions of Windows have better defaults? Yes, since Vista it supports AES: http://msdn.microsoft.com/en-us/library/windows/desktop/ff468651%28v=vs.85%29.aspx So my new proposal would be to pick one from following defaults: 1) HIGH:+3DES:!aNULL - disables RC4, orders 3DES last. 2) HIGH:MEDIUM:+3DES:!aNULL - no suite changes from current one, except 3DES is ordered last. +3DES reorders already picked 3DES suites to the end. As my impression is that no clients ever have actually used 3DES, it's fine to use !3DES there. It's clearer too. But if max compatibility is goal, then +3DES is better. It's not as nice and simple as I hoped though. :( We definitely want to explain in a comment next to the default value the exact reasoning behind the default value, I think. That doesn't mean people will understand it, but it means they at least have a chance. That said, #2 seems reasonable I think, but I wouldn't object to #1 either :) Although I don't think that making .NET users on XP use 3DES is a big problem, there is also no urgent need to drop RC4, as long as all reasonable alternatives are used first. Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL and also adds documentation about reasoning for it. (I tried to be consistent there about cipher vs. cipher suite, not sure whether I succeeded.) Summary: this default with previous server-order-first patch make sure that MEDIUM ciphers are never picked accidentally (eg. the bad default in Java 6), but only when explicitly requested or when only alternative is 3DES. -- marko diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 8896988..2755f55 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -876,12 +876,62 @@ include 'filename' /indexterm listitem para -Specifies a list of acronymSSL/ ciphers that are allowed to be +Specifies a list of acronymSSL/ cipher suites that are allowed to be used on secure connections. See the citerefentryrefentrytitleciphers//citerefentry manual page in the applicationOpenSSL/ package for the syntax of this setting -and a list of supported values. The default value is usually -reasonable, unless you have specific security requirements. +and a list of supported values. The default value is +literalHIGH:MEDIUM:+3DES:!aNULL/. It is usually reasonable, +unless you have specific security requirements. + /para + para +Explanation for default value: +variablelist + varlistentry + termliteralHIGH/literal/term + listitem + para +Cipher suites that use ciphers from literalHIGH/ section. +(AES, Camellia, 3DES) + /para + /listitem + /varlistentry + varlistentry + termliteralMEDIUM/literal/term + listitem + para +Cipher suites that use ciphers from literalMEDIUM/ section. +(RC4, SEED) + /para + /listitem + /varlistentry + varlistentry + termliteral+3DES/literal/term + listitem + para +OpenSSL default order for literalHIGH/ is problematic as it orders 3DES +higher than AES128. This is wrong as 3DES offers less security than AES128 +and it is also much slower. literal+3DES/ reorders it after all other +literalHIGH/ and literalMEDIUM/ ciphers. + /para + /listitem + /varlistentry + varlistentry + termliteral!aNULL/literal/term + listitem + para +Disables anonymous cipher suites that do no authentication. +Such cipher suites are vulnerable to a man in the middle +attack and so should not be used. + /para + /listitem + /varlistentry +/variablelist +Available cipher suite details will vary across OpenSSL versions, these values +are taken from applicationOpenSSL/ 1.0.1. Use command +literalopenssl ciphers -v 'HIGH:MEDIUM:+3DES:!aNULL'/literal +to see actual details
Re: [HACKERS] SSL: better default ciphersuite
On Thu, 2013-12-12 at 12:30 +0200, Marko Kreen wrote: First, if there is explicit wish to keep RC4/SEED in play, I'm fine with HIGH:MEDIUM:!aNULL as new default. Clarity-wise, it's still much better than current value. And this value will result *exactly* same list in same order as current value. If we have to make a change, I'd go for that, but I'm not convinced that this is necessarily clearer. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
On Fri, 2013-11-29 at 18:43 +0200, Marko Kreen wrote: Well, we should - the DEFAULT is clearly a client-side default for compatibility only. No server should ever run with it. Any other opinions on this out there? All instances of other SSL-enabled servers out there, except nginx, default to some variant of DEFAULT:!LOW:... or HIGH:MEDIUM: The proposal here is essentially to disable MEDIUM ciphers by default, which is explicitly advised against in the Postfix and Dovecot documentation, for example. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
Peter Eisentraut pete...@gmx.net writes: Any other opinions on this out there? All instances of other SSL-enabled servers out there, except nginx, default to some variant of DEFAULT:!LOW:... or HIGH:MEDIUM: The proposal here is essentially to disable MEDIUM ciphers by default, which is explicitly advised against in the Postfix and Dovecot documentation, for example. Doesn't seem like a great idea then. I assume that if left to its own devices, PG presently selects some MEDIUM-level cipher by default? If so, it sounds like this change amounts to imposing a performance penalty for SSL connections by fiat. On the other hand, if we select a HIGH cipher by default, then aren't we just refusing to let clients who explicitly ask for a MEDIUM cipher have one? Either way, I'd want to see a pretty darn airtight rationale for that, and there sure isn't one in this thread so far. The part of the patch that removes @STRENGTH seems plausible, though, if Marko is correct that that's effectively overriding a hand-tailored ordering. In the end I wonder why our default isn't just DEFAULT. Anybody who thinks that's an inappropriate default should be lobbying the OpenSSL folk, not us, I should think. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
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. 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 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?) !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. @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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL: better default ciphersuite
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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers