Hi Michael,
On Mi, 2019-10-23 at 10:14 +0100, Michael Tremer wrote:
Hi,
Does it support TLSv1.3?
If the new Net-SSLeay is available it should yes.
Debian is shipping a patch because sendEmail is hardcoded to TLSv1.0. Those are the things I find not okay and why such a project needs to be actively maintained.
If you like, please check some other distributions and add the patches. If it is somewhat maintained by a Debian maintainer I am okay with having it in IPFire.
For this, I searched for about 2 minutes and this is a bad bad problem.
Best, -Michael
Description: Fix ssl enabled bug. Bug-Debian: http://bugs.debian.org/679911 Author: Alejandro Garrido Mota alejandro@debian.org --- a/sendEmail +++ b/sendEmail @@ -1903,7 +1903,7 @@ if ($conf{'tls_server'} == 1 and $conf{'tls_client'} == 1 and $opt{'tls'} =~ /^(yes|auto)$/) { printmsg("DEBUG => Starting TLS", 2); if (SMTPchat('STARTTLS')) { quit($conf{'error'}, 1); }
if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version =>'SSLv3 TLSv1')) {
if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version =>'SSLv23:!SSLv2')) { quit("ERROR => TLS setup failed: " . IO::Socket::SSL::errstr(), 1); } printmsg("DEBUG => TLS: Using cipher: ". $SERVER-
get_cipher(), 3);
This patch is already in the IPFire sources from sendEmail integrated and i think it is in first case because of compatibility reasons since it admits SSLv3, TLSv1.0, TLSv1.1+ and forbids only SSLv2. In IO- Socket-SSL documentation it is also explained like that:
" SSL_version
Sets the version of the SSL protocol used to transmit data. 'SSLv23' uses a handshake compatible with SSL2.0, SSL3.0 and TLS1.x, while 'SSLv2', 'SSLv3', 'TLSv1', 'TLSv1_1', 'TLSv1_2', or 'TLSv1_3' restrict handshake and protocol to the specified version. All values are case-insensitive. Instead of 'TLSv1_1', 'TLSv1_2', and 'TLSv1_3' one can also use 'TLSv11', 'TLSv12', and 'TLSv13'. Support for 'TLSv1_1', 'TLSv1_2', and 'TLSv1_3' requires recent versions of Net::SSLeay and openssl.
" <-- From https://metacpan.org/pod/IO::Socket::SSL .
To permit only TLSv1.2 and TLSv1.3 something like this
--- /tmp/sendEmail.orig 2019-10-24 13:32:31.704118956 +0000 +++ /tmp/sendEmail 2019-10-24 13:39:48.855084039 +0000 @@ -1903,7 +1903,7 @@ if ($conf{'tls_server'} == 1 and $conf{'tls_client'} == 1 and $opt{'tls'} =~ /^(yes|auto)$/) { printmsg("DEBUG => Starting TLS", 2); if (SMTPchat('STARTTLS')) { quit($conf{'error'}, 1); } - if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => 'SSLv23:!SSLv2')) { + if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => '!SSLv2:!SSLv3:!TLSv1:!TLSv1_1:TLSv1_2')) { quit("ERROR => TLS setup failed: " . IO::Socket::SSL::errstr(), 1); } printmsg("DEBUG => TLS: Using cipher: ". $SERVER->get_cipher(), 3);
is needed. Have tested both version, the regular source and the above patch and grab the traffic via tshark. Both versions used TLSv1.2 since it is the best one which web.de in that case has offered.
On 22 Oct 2019, at 15:33, ummeegge ummeegge@ipfire.org wrote:
Hi Michael,
On Di, 2019-10-22 at 12:39 +0100, Michael Tremer wrote:
Hi,
On 21 Oct 2019, at 12:14, ummeegge ummeegge@ipfire.org wrote:
Hi Michael,
On Mo, 2019-10-21 at 10:43 +0100, Michael Tremer wrote:
Hi,
Just to clarify this: Do we need it for software to function or is it a nice to have?
I just tested sendEmail with this combination (IO-Socket-SSL and Net- SSLeay) where it was needed while those tests.
The update has already been on the servers, but since we broke so many things we had to revert the patches and build it again. About four times by now. Poor Arne. Therefore I hope that we can avoid building it for a fifth time.
Understandable, am really not sure what else depends on the combination with IO-Socket-SSL and Net-SSLeay, the git send-email problem for example needed only an updated IO-Socket-SSL . The only problem i have encountered without an updated Net-SSLeay was with sendEmail (IPFire addon). There was also the explanaition from Cpan which i´ve posted in the IO-Socket-SSL patch conversation. That´s why i´d send this patch here too.
Didn’t we plan to drop sendEmail because it is no longer supported?
Did some tests with it and it seems that sendEmail uses the current actual Crypto with an updated Net-SSLeay and IO-Socket-SSL and it just works. Spoken from simplicity and functionality, sendEMail is currently a favorit for me. Nevertheless, their is no further development since 2005 and i can understand it if you want to drop it. Since it is only a Perl script, it is easy to add it again fot those which want it to have.
Best, -Michael
Best,
Erik
So i haven´t recognized malfunctioning in the core structure of IPFire until now but am also not using all components. Difficult to say from my side if it is really needed or if it can may wait until the next core update...
Best, -Michael
Best,
Erik
On 20 Oct 2019, at 15:39, ummeegge ummeegge@ipfire.org wrote:
Hi all, it seems that the updated IO-Socket-SSL also needs this updated version of Net-SSLeay. Have tested sendEmail with an updated IO- Socket- SSL only and it did not worked. After Net-SSLeay has also been updated sendEMail worked again. Am not sure which system components depends on an updated of those moduls too.
It might be may an idea to add this update to the core 137 update since the new version of IO-Socket-SSL has been already included with Core 136.
Best,
Erik
On Mi, 2019-09-25 at 14:25 +0100, Michael Tremer wrote: > Reviewed-by: Michael Tremer michael.tremer@ipfire.org > > > On 25 Sep 2019, at 11:05, Erik Kapfer < > > ummeegge@ipfire.org> > > wrote: > > > > Signed-off-by: Erik Kapfer ummeegge@ipfire.org > > --- > > config/rootfiles/common/Net_SSLeay | 1 - > > lfs/Net_SSLeay | 6 +++--- > > 2 files changed, 3 insertions(+), 4 deletions(-) > > > > diff --git a/config/rootfiles/common/Net_SSLeay > > b/config/rootfiles/common/Net_SSLeay > > index 4f14b74a7..bba719b03 100644 > > --- a/config/rootfiles/common/Net_SSLeay > > +++ b/config/rootfiles/common/Net_SSLeay > > @@ -4,7 +4,6 @@ usr/lib/perl5/site_perl/5.30.0/MACHINE- > > linux- > > thread-multi/Net/SSLeay.pm > > usr/lib/perl5/site_perl/5.30.0/MACHINE-linux-thread- > > multi/Net/SSLeay/Handle.pm > > #usr/lib/perl5/site_perl/5.30.0/MACHINE-linux-thread- > > multi/auto/Net/SSLeay > > #usr/lib/perl5/site_perl/5.30.0/MACHINE-linux-thread- > > multi/auto/Net/SSLeay/.packlist > > -#usr/lib/perl5/site_perl/5.30.0/MACHINE-linux-thread- > > multi/auto/Net/SSLeay/SSLeay.bs > > usr/lib/perl5/site_perl/5.30.0/MACHINE-linux-thread- > > multi/auto/Net/SSLeay/SSLeay.so > > usr/lib/perl5/site_perl/5.30.0/MACHINE-linux-thread- > > multi/auto/Net/SSLeay/autosplit.ix > > usr/lib/perl5/site_perl/5.30.0/MACHINE-linux-thread- > > multi/auto/Net/SSLeay/debug_read.al > > diff --git a/lfs/Net_SSLeay b/lfs/Net_SSLeay > > index 90c0a310a..762bf1f4a 100644 > > --- a/lfs/Net_SSLeay > > +++ b/lfs/Net_SSLeay > > @@ -1,7 +1,7 @@ > > ####################################################### > > #### > > #### > > #### > > ############ > > # > > > > > > > > # > > # IPFire.org - A linux based > > firewall # > > -# Copyright (C) 2007-2018 IPFire Team < > > info@ipfire.org> > > > > > > # > > +# Copyright (C) 2007-2019 IPFire Team < > > info@ipfire.org> > > > > > > # > > # > > > > > > > > # > > # This program is free software: you can redistribute > > it > > and/or > > modify # > > # it under the terms of the GNU General Public License > > as > > published > > by # > > @@ -24,7 +24,7 @@ > > > > include Config > > > > -VER = 1.82 > > +VER = 1.88 > > > > THISAPP = Net-SSLeay-$(VER) > > DL_FILE = $(THISAPP).tar.gz > > @@ -40,7 +40,7 @@ objects = $(DL_FILE) > > > > $(DL_FILE) = $(DL_FROM)/$(DL_FILE) > > > > -$(DL_FILE)_MD5 = 2170469d929d5173bacffd0cb2d7fafa > > +$(DL_FILE)_MD5 = fcef4985f5f7e0381e3dddd0ee7878d1 > > > > install : $(TARGET) > > > > -- > > 2.12.2