Re: [FFmpeg-devel] [PATCH 5/5] lavf/tls: enable server verification by default when not on mbedtls
On Fri, Jan 18, 2019 at 02:50:29PM -0600, Rodger Combs wrote: > > > > On Jan 18, 2019, at 05:41, Carl Eugen Hoyos wrote: > > > > 2019-01-18 9:46 GMT+01:00, Rodger Combs : > >> All other TLS wrappers now have a mechanism to load a system trust store > >> by default, without setting the cafile option. For Secure Transport and > >> Secure Channel, it's the OS. For OpenSSL and libtls, it's a path set at > >> compile-time. For GNUTLS, it's either a path set at compile-time, or the > >> OS trust store (if on macOS, iOS, or Windows). It's possible to configure > >> OpenSSL, GNUTLS, and libtls without a working trust store, but these are > >> broken configurations and I don't have a problem with requiring users with > >> that kind of install to either fix it, or explicitly opt in to insecure > >> behavior. mbedtls doesn't have a default trust store (it's assumed that the > >> application will provide one), so it continues to require the user to pass > >> in a path and enable verification manually. > > > > I believe the current behaviour is more desirable as default for a > > multimedia > > library. > > That's patent nonsense. Requests for media are as likely to contain > authentication tokens as anything else today, and users have as much of a > right to privacy in the specific media they consume as in anything else they > use online. Without any verification of peer certificates, our current > defaults are little better than using plaintext. Iam in favor of security by default too. But there may be issues iam unaware of of course ... thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavf/tls: enable server verification by default when not on mbedtls
> On Jan 18, 2019, at 05:41, Carl Eugen Hoyos wrote: > > 2019-01-18 9:46 GMT+01:00, Rodger Combs : >> All other TLS wrappers now have a mechanism to load a system trust store >> by default, without setting the cafile option. For Secure Transport and >> Secure Channel, it's the OS. For OpenSSL and libtls, it's a path set at >> compile-time. For GNUTLS, it's either a path set at compile-time, or the >> OS trust store (if on macOS, iOS, or Windows). It's possible to configure >> OpenSSL, GNUTLS, and libtls without a working trust store, but these are >> broken configurations and I don't have a problem with requiring users with >> that kind of install to either fix it, or explicitly opt in to insecure >> behavior. mbedtls doesn't have a default trust store (it's assumed that the >> application will provide one), so it continues to require the user to pass >> in a path and enable verification manually. > > I believe the current behaviour is more desirable as default for a multimedia > library. That's patent nonsense. Requests for media are as likely to contain authentication tokens as anything else today, and users have as much of a right to privacy in the specific media they consume as in anything else they use online. Without any verification of peer certificates, our current defaults are little better than using plaintext. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavf/tls: enable server verification by default when not on mbedtls
2019-01-18 9:46 GMT+01:00, Rodger Combs : > All other TLS wrappers now have a mechanism to load a system trust store > by default, without setting the cafile option. For Secure Transport and > Secure Channel, it's the OS. For OpenSSL and libtls, it's a path set at > compile-time. For GNUTLS, it's either a path set at compile-time, or the > OS trust store (if on macOS, iOS, or Windows). It's possible to configure > OpenSSL, GNUTLS, and libtls without a working trust store, but these are > broken configurations and I don't have a problem with requiring users with > that kind of install to either fix it, or explicitly opt in to insecure > behavior. mbedtls doesn't have a default trust store (it's assumed that the > application will provide one), so it continues to require the user to pass > in a path and enable verification manually. I believe the current behaviour is more desirable as default for a multimedia library. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
