Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
> From: Michael Wojcik [mailto:michael.woj...@microfocus.com] Thanks for the detailed and thoughtful response. I only want to respond to a few of your points. > One is simply that we're seeing a lot of > OpenSSL roadmap announcements. That's good in the sense that before the > funding boost, progress was of course much slower and communication > much less frequent. On the other hand, it's worrying because those changes > have consequences for developers working with OpenSSL, and so we need > to account for them in our plans. It seems to me that now folks are being told what is coming (or planned, or might, or we want to) a pretty long time in advance. I don't think that's ever happened before. I understand the stress this can cause -- "how will we handle it" -- but at least there's advance notice now, which there never was before. Also, keep in mind that the big flurry of activity is happening in master, which isn't going to be released until, at best, year-end. That's a pretty long time. And we are working pretty hard to keep the community informed and engaged. > And while those announcements are > generally couched as requests for feedback, arguments against them usually > don't seem to carry much weight. I disagree with this. On the platform issue, Netware was kept and nodbody else raised an issue. On the #ifdef issue, Brian Smith raised a concern and Richard reassured him. On the API issue, Jakob is upset; some of that is, supposedly, addressed by overall retaining the crypto API's, and some of it we just disagree. On the cipher strength, the discussion is still ongoing and I haven't seen much support for Viktor's viewpoint. Have I missed any? -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, Feb 11, 2015 at 12:59:22PM +0100, Hubert Kario wrote: > On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote: > > On Tue, Feb 10, 2015 at 09:15:36PM +, Salz, Rich wrote: > > > I would like to make the following changes in the cipher specs, in the > > > master branch, which is planned for the next release after 1.0.2 > > > > > > Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW > > > > Note, that RC4 is already the only commonly used cipher-suite in MEDIUM. > > > > Changing the definitions of EXPOR, LOW, MEDIUM introduces significant > > compatibility issues for opportunistic TLS (e.g. Postfix) where > > RC4 is still required for interop and is better than cleartext. > > Opportunistic TLS is a-typical use of TLS. One that is vulnerable to trivial > MitM attacks by the very definition. Using "ALL", possibly "ALL:!aNULL", > instead of "DEFAULT" doesn't make it much less secure. Yeah, right, 70-90% of the world's email using opportunistic TLS is "atypical". XMPP server-to-server using opportunistic TLS is "atypical", sorry the browser use-case is not the sole use of TLS. As for vulnerable to MiTM, opportunistic TLS is less vulnerable than cleartext. (I'll believe that you actually care that opportunistic TLS is not secure enough when Redhat deploys DNSSEC and DANE TLSA RRs for its MX hosts). -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Salz, Rich > Sent: Wednesday, February 11, 2015 13:26 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] [openssl-dev] Proposed cipher changes for > post-1.0.2 > > > All sorts of things can be done. Clearly, in the Brave New World of well- > > funded OpenSSL, they'll have to be, because it's apparent that we're going > > to > > see a lot of disruptive change made on the flimsiest of pretexts, with > > objections from the user community brushed aside. That's your prerogative, > > of course, and anyone's free to fork OpenSSL. But it's a shame. > > I am surprised by the strength of your reaction. Hmm. Well, let me try to explain. There are two related issues here. One is simply that we're seeing a lot of OpenSSL roadmap announcements. That's good in the sense that before the funding boost, progress was of course much slower and communication much less frequent. On the other hand, it's worrying because those changes have consequences for developers working with OpenSSL, and so we need to account for them in our plans. And while those announcements are generally couched as requests for feedback, arguments against them usually don't seem to carry much weight. Things are changing relatively quickly with OpenSSL and that is a destabilizing circumstance in itself. (The obvious answer would be to delay adopting new OpenSSL releases, and only pick up fixes. Sometimes that's a solution. Sometimes new fix levels change behavior, though; and sometimes, in these post-Heartbleed days, customers demand the latest release for no very good reason. Right now I have a customer insisting we update one product line to OpenSSL 1.0.1m, which obviously is a little difficult.) The second issue is that any user-visible change in behavior that's not solely a fix to a vulnerability is significant work for us, particularly if it involves code changes. We have to make the necessary updates, test, provide documentation, and ensure customers are aware of the change. It's a substantial effort if the change in OpenSSL requires a corresponding change in our code, but at least in that case the integration process catches it. If it's a runtime behavior change, then we have to make sure all the affected development teams are aware of it, because we can't be sure that everyone has tests that will catch it. We have multiple teams in the organization using OpenSSL independently. We're working on a plan to bring all our OpenSSL builds under a single group which can be responsible for tracking changes, but that's a long way off yet. We have product lines that use our other products internally to provide SSL/TLS, and those teams don't know what's happening with OpenSSL - they just expect it to work. (This does raise a rather delicate point: sponsorship. Let's just say that I've suggested it in the past and it hasn't gotten a lot of traction. I keep meaning to donate personally but ... oh, hell, let's just do it now. Done. Coals to Newcastle these days, but every bit helps, I suppose.) So, for the components I personally work on, this change (RC4 into LOW) isn't a big deal. One product line sets ciphers explicitly, either using its own default list or one configured by the user; another might need a change (haven't checked) to maintain existing behavior, but it's time to review that anyway. It's the 20-odd other product lines that I'm more worried about, because i don't even know what all of them are. And I don't know how changes like this in OpenSSL behavior affect, say, the SUSE division - how many updated packages they'll have to integrate and test. Maybe it's not a big deal; maybe it's a lot of work. Maybe they welcome this particular change regardless. (I'll have to ask on our next security call.) Anyway, this has gone on too long already. The basic point is that these changes affect us, the users of OpenSSL, sometimes in quite disruptive ways. And sometimes they leak through to our users, and we have to handle that situation. So yes, some of us will be resistant to changes that we think aren't strongly justified. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, Feb 11, 2015 at 03:46:54PM +, Salz, Rich wrote: > > I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it > > explicitly in DEFAULT) is a good one that maintains important backward > > compatibility while providing the desired removal of RC4 by default. There's > > no advantage to moving RC4 to LOW. > > Sure there is: it's an accurate description of the quality of protection > provided by the algorithm. :) Except that it is not. There are off-the-shelf key recovery attacks on 56-bit DES (essentially the only LOW cipher anyone might actually use, though nobody does anymore). The known attacks on RC4 are only effective when a great many plaintexts includes the same sensitive content at a fixed position in the data stream. While this does mean we should stop using RC4 as soon as practical, it is far from equating the security of RC4 with single-DES. > It's also compatible with our documentation, which as was pointed > out, always uses the word "currently" to describe the magic keywords. Sure, there's some rope there, it does not mean we need to hang ourselves. The basic ciphersuite primitives by now have well understood meanings that should only be changed with great care if at all. > Postfix can work lay the groundwork to be future-compliant by changing its > default configuration to be HIGH:MEDIUM:RC4. Except that "RC4" includes export-grade RC4, so that would be wrong. Also Postfix defines a more usable user-interface of cipher "grades": smtp_tls_cipher_grade = null | export | low | medium | high where "export" is EXPORT and up, "low" is "LOW" and up, "medium" is "MEDIUM" and up, with the underlying definitions also configurable but most users are encouraged to stay well clear of those: tls_null_cipherlist = eNULL:!aNULL tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH instead users choose a grade, and may also specify exclusions: smtp_tls_exclude_ciphers = RC4, PSK, aDSS, ... this provides enough flexibility to allow emergency tweaks to be applied by users to deal with future issues, without requiring users to be experts in OpenSSL cipherlists. It is important to remember that all the moving pieces are part of an ecosystem: * The OpenSSL project provides a foundation library to application developers (like myself with Postfix) AND to O/S release engineering teams that take upstream Postfix and upstream OpenSSL and package these into integrated systems. * The Postfix developers create a Postfix release with sensible backwards-compatible and reasonably future-proof cipherlist settings. * Postfix is built from source by the O/S release engineering team against some OpenSSL library available at the time of the build. * Users deploy systems with some Postfix version and some OpenSSL version. They expect Postfix to be reasonably interoperable and backwards-compatible out of the box. I am not sympathetic to the view that libraries should set application policy because application developers are lazy. I am not lazy, and take the time to give users carefully chosen cipher settings. These setting use documented primitives that avoid being too specific, so that Postfix will take advantage of new ciphers (not block progress) as these become available, and prioritizes these appropriately. If some developers do nothing and just want the library to be magic security pixie-dust, then they benefit or get hurt by the "DEFAULT" ciphersuite. If developers or users do make more fine-grained choices, those ought not change capriciously. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
On 11/02/2015 16:46, Salz, Rich wrote: I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it explicilty in DEFAULT) is a good one that maintains important backward compatibility while providing the desired removal of RC4 by default. There's no advantage to moving RC4 to LOW. Sure there is: it's an accurate description of the quality of protection provided by the algorithm. :) Is the security level (i.e. log2 of the cost of the best known direct attack) 40 bits (historical EXPORT label), 56 bits (historical LOW label), 112 to 127 bits (historical MEDIUM) level, or somewhere in between? This is the real question that should guide its classification, not if it is "lower than what is currently recommended". Given the currenly available ciphers, it may make sense to add new groups: HIGH192, HIGH256 and larger ones still. As time progresses, the default can then move from HIGH to HIGH192, to HIGH256 as the state of the art changes, without redefining semantics. Furthermore, the various attacks on SSL3/TLS1.0 padding and IV logic creates an ongoing need to have a widely supported, TLS1.0 compatible stream-or-otherwise-unpadded cipher choice as an emergency fallback as other protections are being rolled out by all kinds of vendors. For example RC4 is immune to POODLE as well as a previous widelypublicized attack, simply because it uses neither the flawed SSL3padding nor the sometimes problematic TLS1.0 IV selection. No other cipher provides this protection when talking to older peers that cannot or will not upgrade to the latest-and-greatest TLS standards. It's also compatible with our documentation, which as was pointed out, always uses the word "currently" to describe the magic keywords. And it's also planned for the next version which won't be available until near the end of the year. And it's also compliant with the expected publication of the IETF RFC's that talk about TLS configuration and attacks. Postfix can work lay the groundwork to be future-compliant by changing its default configuration to be HIGH:MEDIUM:RC4. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
> All sorts of things can be done. Clearly, in the Brave New World of well- > funded OpenSSL, they'll have to be, because it's apparent that we're going to > see a lot of disruptive change made on the flimsiest of pretexts, with > objections from the user community brushed aside. That's your prerogative, > of course, and anyone's free to fork OpenSSL. But it's a shame. I am surprised by the strength of your reaction. Hmm. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Salz, Rich > Sent: Wednesday, February 11, 2015 10:47 > To: openssl-users@openssl.org; openssl-...@openssl.org > Subject: Re: [openssl-users] [openssl-dev] Proposed cipher changes for > post-1.0.2 > > > I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it > > explicilty in DEFAULT) is a good one that maintains important backward > > compatibility while providing the desired removal of RC4 by default. There's > > no advantage to moving RC4 to LOW. > > Sure there is: it's an accurate description of the quality of protection > provided by the algorithm. :) Hobgoblin consistency. > It's also compatible with our documentation, which as was pointed out, > always uses the word "currently" to describe the magic keywords. Hobgoblins everywhere. And by that argument, any action is equally "compatible" with the documentation. > And it's also planned for the next version which won't be available until near > the end of the year. I'm not sure why that's relevant. > And it's also compliant with the expected publication of the IETF RFC's that > talk about TLS configuration and attacks. Frankly, that's rubbish. OpenSSL cipher lists are not "compliant" with RFCs because RFCs don't specify OpenSSL cipher lists. It's an entirely specious justification. And even if it weren't, explicitly disabling RC4 in the DEFAULT list would "comply" with the RFC. > Postfix can work lay the groundwork to be future-compliant by changing its > default configuration to be HIGH:MEDIUM:RC4. All sorts of things can be done. Clearly, in the Brave New World of well-funded OpenSSL, they'll have to be, because it's apparent that we're going to see a lot of disruptive change made on the flimsiest of pretexts, with objections from the user community brushed aside. That's your prerogative, of course, and anyone's free to fork OpenSSL. But it's a shame. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
> I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it > explicilty in DEFAULT) is a good one that maintains important backward > compatibility while providing the desired removal of RC4 by default. There's > no advantage to moving RC4 to LOW. Sure there is: it's an accurate description of the quality of protection provided by the algorithm. :) It's also compatible with our documentation, which as was pointed out, always uses the word "currently" to describe the magic keywords. And it's also planned for the next version which won't be available until near the end of the year. And it's also compliant with the expected publication of the IETF RFC's that talk about TLS configuration and attacks. Postfix can work lay the groundwork to be future-compliant by changing its default configuration to be HIGH:MEDIUM:RC4. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Viktor Dukhovni > Sent: Tuesday, February 10, 2015 21:01 > To: openssl-...@openssl.org; openssl-users@openssl.org > Subject: Re: [openssl-users] [openssl-dev] Proposed cipher changes for > post-1.0.2 > > On Wed, Feb 11, 2015 at 12:22:44AM +, Salz, Rich wrote: > > > RC4 in LOW has a bit of pushback so far. My cover for it is that > > the IETF says "don't use it." So I think saying "if you want it, > > say so" is the way to go. > > By all means, don't use it, but it is not OpenSSL's choice to make > by breaking the meaning of existing interfaces. > > If you put RC4 in LOW, one can no longer exclude LOW ciphers if > one still needs RC4. Nobody uses single-DES, but enough peers > still use (only) RC4 to make disabling of RC4 a choice best made > by applications. I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it explicilty in DEFAULT) is a good one that maintains important backward compatibility while providing the desired removal of RC4 by default. There's no advantage to moving RC4 to LOW. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, Feb 11, 2015 at 01:50:07AM -0500, Daniel Kahn Gillmor wrote: > > RC4 in LOW has a bit of pushback so far. My cover for it is that the > > IETF says "don't use it." So I think saying "if you want it, say so" is > > the way to go. > > I think that's the correct position. People who want to be able to > negotiate a deprecated cipher should need to explicitly state that > that's their intent. I do: aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH The proposal to now misclassify RC4 as LOW (lumped in with single DES and similar) needlessly breaks this. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, Feb 11, 2015 at 03:30:57AM +, Salz, Rich wrote: > > By all means, don't use it, but it is not OpenSSL's choice to make by > > breaking > > the meaning of existing interfaces. > > Except that we've explicitly stated we're breaking things with this new > release. > > Those magic cipher keywords are point-in-time statements. And time has moved > on. Those categories had and continue to have sensible definitions to which the proposed changes would do unwarranted violence. It is OK to drop EXPORT ciphers entirely. It is OK to drop LOW ciphers entirely. Nobody is using either. The deprecation of RC4 is still aspirational, and reclassifying it as LOW breaks configurations where it is still needed. It is largely sufficient to drop RC4 from the "DEFAULT" cipherlist, leaving applications that make more fine-grained choices to make their own RC4 decisions. The DEFAULT cipherlist is a point-in-time definition, but EXPORT, LOW, MEDIUM and HIGH have more precise expected semantics. Libraries should only break compatibility when there is no choice. Here there are many alternatives. Including the "security level" features already in the master release, which address the issue more systematically. This, plus further work on documenting NCONF, publishing reasonably complete best-practice sample client and server programs will do a lot more good than needlessly breaking non-browser opportunistic TLS applications. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
> By all means, don't use it, but it is not OpenSSL's choice to make by breaking > the meaning of existing interfaces. Except that we've explicitly stated we're breaking things with this new release. Those magic cipher keywords are point-in-time statements. And time has moved on. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, Feb 11, 2015 at 12:22:44AM +, Salz, Rich wrote: > RC4 in LOW has a bit of pushback so far. My cover for it is that > the IETF says "don't use it." So I think saying "if you want it, > say so" is the way to go. By all means, don't use it, but it is not OpenSSL's choice to make by breaking the meaning of existing interfaces. If you put RC4 in LOW, one can no longer exclude LOW ciphers if one still needs RC4. Nobody uses single-DES, but enough peers still use (only) RC4 to make disabling of RC4 a choice best made by applications. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
On Tue, Feb 10, 2015 at 06:17:38PM -0500, Daniel Kahn Gillmor wrote: > On Tue 2015-02-10 16:15:36 -0500, Salz, Rich wrote: > > I would like to make the following changes in the cipher specs, in the > > master branch, which is planned for the next release after 1.0.2 > > > > Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW > > yes, please! There are lots of ways to disable RC4: * You can do that in a browser, or any other application * The NCONF interface allows one to specify this in suitable configuration files. * Security levels can be similarly specified, ... * TLS 1.3 will not support RC4, ... However, OpenSSL MUST NOT force this choice on applications or require them to be explicitly modified to continue to support RC4. It is NOT the library's job to set this policy. > when these are "removed", what will that do to a cipherstring that > specifies them by negation? > > currently, this is an error: > > 0 dkg@alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER > bash: !NO-SUCH-CIPHER: event not found PBKAC: $ openssl ciphers -v 'RC4:!FOOBARXYZZY' ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 ECDH-RSA-RC4-SHASSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 EXP-ADH-RC4-MD5 SSLv3 Kx=DH(512) Au=None Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
> currently, this is an error: > > 0 dkg@alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER > bash: !NO-SUCH-CIPHER: event not found > 0 dkg@alice:~$ Yeah, but that's coming from bash, not openssl :) ; openssl ciphers -v ALL | wc 111 6758403 ; openssl ciphers -v ALL:!FOOBAR | wc 111 6758403 RC4 in LOW has a bit of pushback so far. My cover for it is that the IETF says "don't use it." So I think saying "if you want it, say so" is the way to go. /r$ ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2
On Tue, Feb 10, 2015 at 09:15:36PM +, Salz, Rich wrote: > I would like to make the following changes in the cipher specs, in the master > branch, which is planned for the next release after 1.0.2 > > Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW Note, that RC4 is already the only commonly used cipher-suite in MEDIUM. Changing the definitions of EXPOR, LOW, MEDIUM introduces significant compatibility issues for opportunistic TLS (e.g. Postfix) where RC4 is still required for interop and is better than cleartext. I have no issues with changing "DEFAULT", but would strongly prefer to not see RC4 demoted to LOW. Just define: DEFAULT = ALL:!aNULL:!EXPORT:!LOW:!RC4:!MD5 Which leaves from MEDIUM just SEED and IDEA: $ openssl ciphers -v 'MEDIUM:!aNULL:!MD5:!RC4' DHE-RSA-SEED-SHASSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHASSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 DH-RSA-SEED-SHA SSLv3 Kx=DH/RSA Au=DH Enc=SEED(128) Mac=SHA1 DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS Au=DH Enc=SEED(128) Mac=SHA1 SEED-SHASSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 IDEA-CBC-SHASSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
