Re: [openssl-users] Appropriate use of SSL_CTX_set_cipher_list()

[Ryan Beethe]

> Offhand, I'm not aware of other OSes that distribute implementations
> of OpenSSL that require platform-specific cipher-list settings.

Ok, that is very helpful to know

> This strikes me as a Really Bad Idea on the part of the Fedora
> developers

While it is a pain to have to have to have a Fedora-specific patch, I am
not sure I understand why this is a bad idea? (Server applications like
Apache do not fall under that guideline.)  As a consumer of applications
that use OpenSSL, I think I would prefer that an up-to-date list of
acceptable ciphers is kept by the same folks who keep my libssl.so
up-to-date, rather than depending on the developer of each individual
application to keep their code in step with current security news.

> I recommend Ivan Ristic's /Bulletproof TLS/ e-book

I have been meaning to buy this book for a long time, so I finally did.
Skimming through it, it looks excellent.

I will also take another look at Mozilla's list (as mentioned by
Daurnimator), and compare it to the suggestions in "Bulletproof TLS".  I
have been using the Mozilla list for server-side things, so I suppose it
make sense to use it on the client side as well.

But I still have one question, which I don't see answered explicitly
anywhere:

For a safe client application, should you explicitly set the cipher list
explicitly, rather than trust the default cipher list that comes from
the package manager's libssl?

(obviously this question would not apply to operating systems which
which don't distribute OpenSSL, or to Fedora)

Thanks,
Ryan
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Appropriate use of SSL_CTX_set_cipher_list()

[Ryan Beethe]

I am writing a cross-platform C application, which I would like to
release for a variety of operating systems (Windows 7+, MacOS
HighSierra, Debian 8+, Ubuntu 14.04+, Fedora 27+, Centos 7+, ArchLinux,
at least for now).

Up to now, I have had a line of code which prepares an SSL_CTX object
like something like this:

SSL_CTX_set_cipher_list(ctx->ctx, CIPHERS);

where `CIPHERS` was set to "HIGH:MED:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4".

However, I realized that Fedora's packaging standards [1] require me to
elminate this line or use the special value "PROFILE=SYSTEM" for
CIPHERS.

So that makes me nervous about whether or not I am using
SSL_CTX_set_cipher_list() wrong.  Should I be calling it at all?  And if
so, where would I find the "right" setting for other operating systems,
since "PROFILE=SYSTEM" appears to be Fedora-specific?

Ryan

[1] https://fedoraproject.org/wiki/Packaging:CryptoPolicies
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] BIO_do_connect memory leak in Arch Linux

[Ryan Beethe]

Hi openssl-users,

I found a memory leak in my program that arises from the use of the
BIO_do_connect() function.  It seems to be related to how openssl is
interacting with other packages on my system.  I observe this behavior
on my Arch Linux machine but not on my Debian Stretch machine.  I wrote
a minimal program that demonstrates the issue and attached the output of
valgrind of the same program.

The leak goes away if I comment out the BIO_do_connect() line, and based
on the output of valgrind the issue seems to have something to do with
the DNS resolving step.  I noticed using strace that on Arch Linux the
same binary running on Arch Linux loads two libraries that don't get
loaded when running on Debian Stretch: "libnss_mymachines.so.2" and
"libnss_resolve.so.2".

Am I doing something wrong or is this a memory leak in openssl?

Thanks,

Ryan


--- leak.c: a minimal example program leak.c

// # compile with gcc 7.2.1:
// gcc -Wall -g -std=c99 -pedantic leak.c -lssl -lcrypto -o leak

#include 
#include 

int main(){
// unencrypted connection
BIO* bio = BIO_new_connect("smtp.gmail.com:587");

// connect BIO
BIO_do_connect(bio);

// read some stuff
char buffer[1024];
int ret = BIO_read(bio, buffer, 1024 - 1);
printf("read %d bytes:\n",ret);
fwrite(buffer, 1, ret, stdout);

BIO_free_all(bio);

printf("exiting\n");
return 0;
}


-- output of: valgrind --show-leak-kinds=all --leak-check=full ./leak

==6700== Memcheck, a memory error detector
==6700== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6700== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==6700== Command: ./leak
==6700==
read 52 bytes:
220 smtp.gmail.com ESMTP d26sm175472lja.54 - gsmtp
exiting
==6700==
==6700== HEAP SUMMARY:
==6700== in use at exit: 7,365 bytes in 10 blocks
==6700==   total heap usage: 148 allocs, 138 frees, 118,960 bytes allocated
==6700==
==6700== 48 bytes in 1 blocks are still reachable in loss record 1 of 6
==6700==at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==6700==by 0x4011D85: tls_get_addr_tail (in /usr/lib/ld-2.26.so)
==6700==by 0x4017447: __tls_get_addr (in /usr/lib/ld-2.26.so)
==6700==by 0x65BBD1D: ??? (in /usr/lib/libnss_resolve.so.2)
==6700==by 0x65D7711: ??? (in /usr/lib/libnss_resolve.so.2)
==6700==by 0x65CE60C: _nss_resolve_gethostbyname4_r (in 
/usr/lib/libnss_resolve.so.2)
==6700==by 0x566DFD8: gaih_inet.constprop.7 (in /usr/lib/libc-2.26.so)
==6700==by 0x566EF03: getaddrinfo (in /usr/lib/libc-2.26.so)
==6700==by 0x517160D: BIO_lookup_ex (b_addr.c:691)
==6700==by 0x51716CD: BIO_lookup (b_addr.c:614)
==6700==by 0x517C8BD: conn_state (bss_conn.c:123)
==6700==by 0x517C8BD: conn_ctrl (bss_conn.c:360)
==6700==by 0x5178F73: BIO_ctrl (bio_lib.c:529)
==6700==
==6700== 61 bytes in 2 blocks are still reachable in loss record 2 of 6
==6700==at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==6700==by 0x401AB9A: strdup (in /usr/lib/ld-2.26.so)
==6700==by 0x40162EF: _dl_load_cache_lookup (in /usr/lib/ld-2.26.so)
==6700==by 0x40089D1: _dl_map_object (in /usr/lib/ld-2.26.so)
==6700==by 0x401377D: dl_open_worker (in /usr/lib/ld-2.26.so)
==6700==by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==by 0x4013279: _dl_open (in /usr/lib/ld-2.26.so)
==6700==by 0x56BF10C: do_dlopen (in /usr/lib/libc-2.26.so)
==6700==by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==by 0x56BF1A6: dlerror_run (in /usr/lib/libc-2.26.so)
==6700==by 0x56BF240: __libc_dlopen_mode (in /usr/lib/libc-2.26.so)
==6700==by 0x56A6978: nss_load_library (in /usr/lib/libc-2.26.so)
==6700==
==6700== 61 bytes in 2 blocks are still reachable in loss record 3 of 6
==6700==at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==6700==by 0x400B468: _dl_new_object (in /usr/lib/ld-2.26.so)
==6700==by 0x4005984: _dl_map_object_from_fd (in /usr/lib/ld-2.26.so)
==6700==by 0x40086B0: _dl_map_object (in /usr/lib/ld-2.26.so)
==6700==by 0x401377D: dl_open_worker (in /usr/lib/ld-2.26.so)
==6700==by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==by 0x4013279: _dl_open (in /usr/lib/ld-2.26.so)
==6700==by 0x56BF10C: do_dlopen (in /usr/lib/libc-2.26.so)
==6700==by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==by 0x56BF1A6: dlerror_run (in /usr/lib/libc-2.26.so)
==6700==by 0x56BF240: __libc_dlopen_mode (in /usr/lib/libc-2.26.so)
==6700==by 0x56A6978: nss_load_library (in /usr/lib/libc-2.26.so)
==6700==
==6700== 720 bytes in 2 blocks are still reachable in loss record 4 of 6
==6700==at 0x4C2EEF5: calloc (vg_replace_malloc.c:711)
==6700==by 0x4010F03: _dl_check_map_versions (in /usr/lib/ld-2.26.so)
==6700==by 0x4013822: dl_open_worker (in /usr/lib/ld-2.26.so)
==6700==by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==by 0x4013279: _dl_open (in