Date: Sun, 8 Mar 2015 00:18:48 -0800 From: Doug Hardie <bc979@lafn.org> To: Doug Hardie <bc979@lafn.org> Cc: FreeBSD - <freebsd-questions@freebsd.org>, owner-freebsd-questions@freebsd.org Subject: Re: OpenSSL Ciphers Message-ID: <E7540E0C-06C2-4C3B-A189-984556CFC7A1@lafn.org> In-Reply-To: <70654C1C-913A-4406-B904-697E153646E0@lafn.org> References: <5347DC2D-AD6C-41A1-AEC7-A81C51F691B3@lafn.org> <B8A83AF6-B354-46E7-A736-64959C53CD66@lafn.org> <DC459F71-D819-4BB9-AC1A-4E1D5EB6D4E8@mac.com> <031A70A3-C348-4E2A-8C30-79F85BA4B4A1@lafn.org> <a579dadbf9688db6e2b257f76a441cc1@dweimer.net> <A0FAE283-534A-4C99-B5A0-43C219AB7065@lafn.org> <4d416c9dfa4e2922174ff469313578a0@dweimer.net> <79CC9795-C5EF-451A-9A49-A2847E7C5974@lafn.org> <70654C1C-913A-4406-B904-697E153646E0@lafn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 7 March 2015, at 17:32, Doug Hardie <bc979@lafn.org> wrote: >=20 >=20 >> On 7 March 2015, at 15:13, Doug Hardie <bc979@lafn.org> wrote: >>=20 >>=20 >>> On 7 March 2015, at 08:49, dweimer <dweimer@dweimer.net> wrote: >>>=20 >>> On 03/07/2015 1:35 am, Doug Hardie wrote: >>>>> On 6 March 2015, at 17:35, dweimer <dweimer@dweimer.net> wrote: >>>>> On 03/06/2015 6:36 pm, Doug Hardie wrote: >>>>>>> On 6 March 2015, at 16:28, Charles Swiger <cswiger@mac.com> = wrote: >>>>>>> Hi-- >>>>>>>> On Mar 6, 2015, at 3:58 PM, Doug Hardie <bc979@lafn.org> wrote: >>>>>>>>> On 3 March 2015, at 23:21, Doug Hardie <bc979@lafn.org> wrote: >>>>>>>>> The default list of ciphers is quite extensive and includes = some that are apparently causing some potential security issues. I have = a number of applications that use OpenSSL and many don=E2=80=99t have = the code to restrict the list. Fixing all that would take quite a bit = of work. However, looking into /usr/include/openssl/ssl.h I find a = definition for the SSL_DEFAULT_CIPHER_LIST. The comments indicate that = that list is the one used when the application doesn=E2=80=99t specify = anything. I changed its definition to: >>>>>>>>> #define SSL_DEFAULT_CIPHER_LIST = "TLSv1+HIGH:!SSLv2:RC4+MEDIUM:!aNULL:!eNULL:!3DES:@STRENGTH: >>>>>>>>> However, s_connect will still create a connection with the = export ciphers. I tried adding !EXPORT to that list and it had no = effect. Is the definition actually used by openssl or is it just there = for documentation? >>>>>>>> Not hearing anything on this, I suspect it=E2=80=99s not very = well understood. I have started updating the various servers/clients = that use SSL/TLS. The one that has me completely stumped is sendmail. = There is a web page which provides instructions = "http://novosial.org/sendmail/cipherlist/index.html=E2=80=9D. However, = when I follow them, I can still establish a connection and deliver mail = using the export ciphers. >>>>>>>> Has anyone successfully restricted the sendmail ciphers? >>>>>>> You can see which ciphers openssl will support via a statement = like: >>>>>>> % openssl ciphers -v = 'TLSv1+HIGH:RC4+MEDIUM:!aNULL:!eNULL:!3DES:@STRENGTH:!EXPORT' >>>>>>> DHE-RSA-AES256-SHA SSLv3 Kx=3DDH Au=3DRSA = Enc=3DAES(256) Mac=3DSHA1 >>>>>>> DHE-DSS-AES256-SHA SSLv3 Kx=3DDH Au=3DDSS = Enc=3DAES(256) Mac=3DSHA1 >>>>>>> AES256-SHA SSLv3 Kx=3DRSA Au=3DRSA = Enc=3DAES(256) Mac=3DSHA1 >>>>>>> DHE-RSA-AES128-SHA SSLv3 Kx=3DDH Au=3DRSA = Enc=3DAES(128) Mac=3DSHA1 >>>>>>> DHE-DSS-AES128-SHA SSLv3 Kx=3DDH Au=3DDSS = Enc=3DAES(128) Mac=3DSHA1 >>>>>>> AES128-SHA SSLv3 Kx=3DRSA Au=3DRSA = Enc=3DAES(128) Mac=3DSHA1 >>>>>>> RC4-SHA SSLv3 Kx=3DRSA Au=3DRSA = Enc=3DRC4(128) Mac=3DSHA1 >>>>>>> RC4-MD5 SSLv3 Kx=3DRSA Au=3DRSA = Enc=3DRC4(128) Mac=3DMD5 >>>>>>> RC4-MD5 SSLv2 Kx=3DRSA Au=3DRSA = Enc=3DRC4(128) Mac=3DMD5 >>>>>>> ...and you can experiment with TLS negotiation results via = something like: >>>>>>> % openssl s_client -cipher 'AES256-SHA:AES128-SHA' -connect = www.google.com:443 >>>>>>> [ ... ] >>>>>>> New, TLSv1/SSLv3, Cipher is AES128-SHA >>>>>>> Server public key is 2048 bit >>>>>>> Secure Renegotiation IS supported >>>>>>> Compression: NONE >>>>>>> Expansion: NONE >>>>>>> SSL-Session: >>>>>>> Protocol : TLSv1 >>>>>>> Cipher : AES128-SHA >>>>>>> Session-ID: [ ... ] >>>>>>> Sendmail normally performs crypto via STARTTLS negotiation = rather than via SMTPS; there's a CipherList option which can be defined = via sendmail.mc / sendmail.cf. You might need to recompile sendmail = with -D_FFR_TLS_1, which I think that novosial page mentions. >>>>>> sendmail has _FFR_TLS_1 compiled in per th tests in the web page >>>>>> mentioned above. The CipherList option doesn=E2=80=99t seem to = work. I can >>>>>> connect and send mail with that in place using the EXPORT = ciphers. >>>>> Doug, >>>>> I have this added to my /etc/mail/{HOSTNAME}.mc file. >>>>> LOCAL_CONFIG >>>>> O CipherList=3DALL:!aNULL:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM >>>>> Of course you can use other options, this has been there for a = while in mine, carried over from some time a few versions back. Probably = should get around to testing it to make sure it actually is still = working. It doesn't take long to add it in and run a quick test. >>>> As I replied earlier, I have done that. I can still use: >>>> openssl s_client -connect localhost:25 -starttls smtp -cipher = EXPORT >>>=20 >>> Strange, it seems to be working on mine. >>>=20 >>> if I use the following, it connects: >>> openssl s_client -connect 192.168.5.2:25 -starttls smtp >>> CONNECTED(00000003) >>> depth=3D1 C =3D US, ST =3D Arizona, L =3D Scottsdale, O =3D = "GoDaddy.com, Inc.", OU =3D http://certs.godaddy.com/repository/, CN =3D = Go Daddy Secure Certificate Authority - G2 >>> [snip] >>> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384 >>> Server public key is 4096 bit >>> Secure Renegotiation IS supported >>> Compression: NONE >>> Expansion: NONE >>> SSL-Session: >>> Protocol : TLSv1.2 >>> Cipher : DHE-RSA-AES256-GCM-SHA384 >>> [snip] >>>=20 >>>=20 >>> if I use the cipher option specify aNULL it fails: >>>=20 >>> openssl s_client -connect 192.168.5.2:25 -starttls smtp -cipher = aNULL >>> CONNECTED(00000003) >>> 34379254472:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 = alert handshake = failure:/jails/devel/ROOT/usr/src/secure/lib/libssl/../../../crypto/openss= l/ssl/s23_clnt.c:770: >>> --- >>> no peer certificate available >>> --- >>> No client certificate CA names sent >>> --- >>> SSL handshake has read 353 bytes and written 234 bytes >>> --- >>> New, (NONE), Cipher is (NONE) >>> Secure Renegotiation IS NOT supported >>> Compression: NONE >>> Expansion: NONE >>=20 >> Interesting. That does seem to work for you. I will have to do some = more digging into the code. For some reason it doesn=E2=80=99t work for = me. Thanks for that assistance. =20 >=20 > After more testing, I think you need to try: >=20 > openssl s_client -connect 192.168.5.2:25 -starttls smtp -cipher EXP >=20 > I suspect it will give: > New, TLSv1/SSLv3, Cipher is EXP-DES-CBC-SHA >=20 >=20 > That is the export cipher which is the problem. >=20 I found the problem. Sendmail was not able to access the pid file. = Hence it would not shutdown. There was no error message about that. As = a result, the existing processes were not terminated. Starting sendmail = again ran into the same issue. That did generate a small error message = that was hidden in a bunch of other messages (this is a production = server). When I ran the tests, it was the original server (without the = CipherList entries that responded. Thus it always accepted mail using = any cipher. Once I managed to terminate the original processes and get the new ones = running, then the CipherList did work properly. Thanks to all for the = assistance. I did encounter one very interesting side effect when building the cf = file from the mc file for one system. Sendmail threw an error when = starting that line 46 was invalid. Line 46 was in the middle of a = string of blank lines. I deleted 3 lines around it (all blank) and then = sendmail is happy and works. I suspect there is some non-printing = character generated in that line, but I haven=E2=80=99t checked that = out.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E7540E0C-06C2-4C3B-A189-984556CFC7A1>