Skip Menu |
 

This queue is for tickets about the IO-Socket-SSL CPAN distribution.

Report information
The Basics
Id: 97816
Status: rejected
Priority: 0/
Queue: IO-Socket-SSL

People
Owner: Nobody in particular
Requestors: ppisar [...] redhat.com
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 1.997
Fixed in: (no value)



Subject: Do not override protocols and ciphers by default
Download (untitled) / with headers
text/plain 1.9k
Current IO::Socket::SSL documentations reads: * Set 'SSL_version' or 'SSL_cipher_list' to a "better" value. IO::Socket::SSL tries to set these values to reasonable secure values, which are compatible with the rest of the world. But, there are some scripts or modules out there, which tried to be smart and get more secure or compatible settings. Unfortunatly, they did this years ago and never updated these values, so they are still forced to do only 'TLSv1' (instead of also using TLSv12 or TLSv11). Or they set 'HIGH' as the cipher list and thought they are secure, but did not notice that 'HIGH' includes anonymous ciphers, e.g. without identification of the peer. So it is recommended to leave the settings at the secure defaults which IO::Socket::SSL sets and which get updated from time to time to better fit the real world. Looking at IO::Socket::SSL history, one can see a lot changes in the default protocol and cipher list varying from "ALL:!LOW" to "ciphers with forward secrecy, disables anonymous authentication and disables known insecure ciphers like MD5, DES etc.". I believe that the last quoted paragraph applies not only to IO::Socket::SSL users, but to IO::Socket::SSL as an OpenSSL user too. There are many other OpenSSL users next to IO::Socket::SSL/Net::SSLeay and from point of system administrator's view, tuning the default settings at one place, e.g. in the OpenSSL, is the only sane option. (Actually there is aim to make the configuration common for all cryptographic libraries like OpenSSL, GnuTLS, NSS, JDK. See <https://fedoraproject.org/wiki/Changes/CryptoPolicy> and <http://lwn.net/Articles/589197/> for more details.) Therefore I propose to drop or allow to inhibit at build-time all the policy hackery implemented in the IO:Socket::SSL and leave it up to underlying cryptographic library (OpenSSL in this case).
Download (untitled) / with headers
text/plain 1.3k
Show quoted text
> There are many other OpenSSL users next to IO::Socket::SSL/Net::SSLeay > and from point of system administrator's view, tuning the default > settings at one place, e.g. in the OpenSSL, is the only sane option. > > (Actually there is aim to make the configuration common for all > cryptographic libraries like OpenSSL, GnuTLS, NSS, JDK. See > <https://fedoraproject.org/wiki/Changes/CryptoPolicy> and > <http://lwn.net/Articles/589197/> for more details.) > > Therefore I propose to drop or allow to inhibit at build-time all the > policy hackery implemented in the IO:Socket::SSL and leave it up to > underlying cryptographic library (OpenSSL in this case).
I would agree with your proposal if there would be an easy way for an administrator to apply a cipher policy for the whole system and if the default settings where sane. But, as far as I understand, the only option to change the default ciphers for openssl is to recompile it and even then you cannot have different default ciphers for client and server side. And the current set of default ciphers on the latest Ubuntu contains insecure ciphers like EXP-RC2-CBC-MD5 which no sane users wants to have in its default configuration. As long as this situation does not change I think its better to have secure defaults inside IO::Socket::SSL for all perl programs using this module.
Download (untitled) / with headers
text/plain 588b
Show quoted text
> As long as this situation does not change I think its better to have > secure defaults inside IO::Socket::SSL for all perl programs using > this module.
If the changes proposed in https://fedoraproject.org/wiki/Changes/CryptoPolicy to have a cipher string of PROFILE=SYSTEM for openssl are implemented, I might use this setting instead of the current default. But I would prefer if there were different defaults for client and server, because clients might need to connect to a variety of servers with sometimes poor ciphers, while a server should not offer poor ciphers by default.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.