Reviewing default OpenSSL configuration options

As trust in OpenSSL has been questioned in recent months a look on the current default configuration options (which you can also lookup at http://www.freshports.org/security/openssl) might be worthwhile:
Code:
Configuration Options

===> The following configuration options are available for openssl-1.0.2:
     SHARED=on: build of shared libs
     THREADS=on: Threading support
     I386=off: Optimize for i386 (instead of i486+)
     SSE2=on: runtime SSE2 detection
     ASM=on: optimized Assembler code
     PADLOCK=off: VIA Padlock support
     ZLIB=off: zlib compression support
     GMP=off: gmp support (LGPLv3)
     SCTP=on: SCTP protocol support
     [b]SSL2=on[/b]: SSLv2 protocol support
     [b]SSL3=on[/b]: SSLv3 protocol support
     RFC3779=off: RFC3779 support (BGP)
     [b]MD2=on[/b]: MD2 hash (obsolete)
     RC5=off: RC5 cipher (patented)
     EXPCIPHERS=off: Include experimental ciphers
     DOCS=on: Build and/or install documentation
     EC=on: Optimize NIST elliptic curves
===> Use 'make config' to modify these settings
MD2 is noted as obsolete but activated by default. This does not amuse me.
SSL2 is regarded as broken but is still activated. Why is it?
SSL3 is regarded as obsolete but also activated? Who cares?
 
There's still a huge number of workstations in real use (read government offices etc using Windows XP with IE6 and no permit to upgrade) that have no proper support for TLS 1.0 or better and SSLv3 support is still required to support the browsers on those systems.
 
There's still a huge number of workstations in real use (read government offices etc using windows XP with IE6 and no permit to upgrade) that have no proper support for TLS 1.0 or better and SSLv3 support is still required to support the browsers on those systems.
Ehm, ..., do FreeBSD repositories serve for Microsoft products that have reached end of life support long ago?
 
Ehm, ..., do FreeBSD repositories serve for Microsoft products that have reached end of life support long ago?

Nobody likes it because of the implied security problems but try disabling SSLv3 on your busy https site and I bet you will very quickly start to receive some very angry emails and phone calls when your site doesn't work for a quite large part of your users.
 
Also if you disable the SSLv2/v3 options it means you can't use openssl s_client to connect to other servers to test to see if they support those protocols or not. And I can't recall which bit of software it is I found it on now, but something I have installed failed to start when I tried it with those disabled despite me disabling v2/v3 in the configuration of that particular piece of software. It was like it was coded to at least check. Although now I think about it maybe it was because I had !SSLv2 !SSLv3 in the config and these options then become unknown?
 
Hey guys, we talk about DEFAULT settings for our FreeBSD repository. And we all know since 2013 about efforts tempering cryptography.

Do we really need to endanger ALL of those getting OpenSSL package from our FreeBSD repository for some exceptions a few might want to have?

I do want to bring this to attention of those who get packages without caring of the default options used.

Definitively those who build their own packages can choose appropriate measures.

Choosing intentionally unsecure options should be done by those few who want to do that. The big number of users want to trust getting secure settings. Isn't it?
 
I would ask principal. Why are optimized flags set to on? If someone wants it, could set it and will know if problems appears, this could be the reason. (In the rarest case, it will necessarily need for compilation).
 
Nobody likes it because of the implied security problems but try disabling SSLv3 on your busy https site and I bet you will very quickly start to receive some very angry emails and phone calls when your site doesn't work for a quite large part of your users.
Of course it depends on your site. I have 10 clients who are theatre companies who only get about 15% visitors from IE at all, much less IE6 on XP, so we haven't used SSL for them for a year or more. I have a restaurant chain right next door to one of the country's largest financial institution headquarters and they get about 50% IE visitors but, still, none on XP or IE<8.

So you have to view your logs and see who's visiting but, if at all, possible, turn off SSL. There are even some places that are turning off TLSv1
 
I bet you will very quickly start to receive some very angry emails and phone calls when your site doesn't work for a quite large part of your users.
kpa, I know you do have the admirable resources to explain those why this step has been taken :)
You would get tons of mails saying "thank you, we did not know!"

BTW: Could you imagine faking the user-agent string to IE5 XP?
 
Back
Top