Bug#802658: libesmtp: Should support TLS 1.1+

[Sebastian Andrzej Siewior]

On 2017-08-07 21:00:05 [+0200], Salvatore Bonaccorso wrote:
> Hi Sebastian
Hi Salvatore,

> Thanks for review. The reason I did that is indeed, to have a patch
> which is most acceptable for upstream to include, independent on
> Debian, although upstream since I initially pinged never replied to my
> queries :-(. Thus as well the explicit version checking, since AFAIU
> the use of the SSLv23_client_method is deprecated in favour of
> TLS_client_method. 
…
> Did I missunderstood something here?
no, you are absolutely right. I just though SSLv23_client_method is
something that currently works for everybody and is the smallest change
given that old-stable Stretch won't be able to connect stable-Buster in
approx. two years (so it coul be a candidate for s-p-u).

However, yes, future proof, this is what the openssl project currently
suggests.

> Regards,
> Salvatore

Sebastian

Bug#802658: libesmtp: Should support TLS 1.1+

[Kurt Roeckx]

On Mon, Aug 07, 2017 at 09:00:05PM +0200, Salvatore Bonaccorso wrote:
> Hi Sebastian
> 
> On Mon, Aug 07, 2017 at 07:15:19PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2017-08-07 14:26:07 [+0200], Salvatore Bonaccorso wrote:
> > > Control: severity important
> > 
> > as in SSL not working anymore in unstable for libesmtp.
> > 
> > > Hi Jeremy,
> > Hi Salvatore,
> > 
> > > Please find attached a (refreshed) patch which is still valid to add
> > > the proper support for TLSv1.1+
> > 
> > Description: Add TLSv1.1 and TLSv1.2 support
> > Origin: vendor
> > Bug-Debian: https://bugs.debian.org/802658
> > Author: Salvatore Bonaccorso 
> > Last-Update: 2015-11-07
> > 
> > --- a/smtp-tls.c
> > +++ b/smtp-tls.c
> > @@ -197,11 +197,24 @@ starttls_create_ctx (smtp_session_t sess
> >ckf_t status;
> >  
> >/* The decision not to support SSL v2 and v3 but instead to use only
> > - TLSv1 is deliberate.  This is in line with the intentions of RFC
> > + TLSv1.X is deliberate.  This is in line with the intentions of RFC
> >   3207.  Servers typically support SSL as well as TLS because some
> >   versions of Netscape do not support TLS.  I am assuming that all
> >   currently deployed servers correctly support TLS.  */
> > -  ctx = SSL_CTX_new (TLSv1_client_method ());
> > +#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
> > +!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
> > +ctx = SSL_CTX_new (TLS_client_method ());
> > +#else
> > +ctx = SSL_CTX_new (SSLv23_client_method ());
> > +#endif
> > +
> > +#ifdef OPENSSL_NO_SSL3
> > +SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
> > +#endif
> > +
> > +#ifdef OPENSSL_NO_SSL2
> > +SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
> > +#endif
> >  
> >/* Load our keys and certificates.  To avoid messing with configuration
> >   variables etc, use fixed paths for the certificate store.  These are
> > 
> > This looks good. I would however just replace TLSv1_client_method() with
> > SSLv23_client_method() (without the version check) and be done with it.
> > Setting the NO_SSLvX thingy is a nop in Debian but upstream might be
> > happy to see it.
> 
> Thanks for review. The reason I did that is indeed, to have a patch
> which is most acceptable for upstream to include, independent on
> Debian, although upstream since I initially pinged never replied to my
> queries :-(. Thus as well the explicit version checking, since AFAIU
> the use of the SSLv23_client_method is deprecated in favour of
> TLS_client_method. 
> 
> The POD for SSL_CTX_new states this explicitly:
> 
> SSLv23_method(), SSLv23_server_method() and SSLv23_client_method()
> were deprecated and the preferred TLS_method(), TLS_server_method()
> and TLS_client_method() functions were introduced in OpenSSL 1.1.0.
> 
> Did I missunderstood something here?

Even tought it's deprecated, it's unlikely we'll remove the
compatiblity define any time soon. So either way really works for
me.


Kurt

Bug#802658: libesmtp: Should support TLS 1.1+

[Salvatore Bonaccorso]

Hi Sebastian

On Mon, Aug 07, 2017 at 07:15:19PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-08-07 14:26:07 [+0200], Salvatore Bonaccorso wrote:
> > Control: severity important
> 
> as in SSL not working anymore in unstable for libesmtp.
> 
> > Hi Jeremy,
> Hi Salvatore,
> 
> > Please find attached a (refreshed) patch which is still valid to add
> > the proper support for TLSv1.1+
> 
> Description: Add TLSv1.1 and TLSv1.2 support
> Origin: vendor
> Bug-Debian: https://bugs.debian.org/802658
> Author: Salvatore Bonaccorso 
> Last-Update: 2015-11-07
> 
> --- a/smtp-tls.c
> +++ b/smtp-tls.c
> @@ -197,11 +197,24 @@ starttls_create_ctx (smtp_session_t sess
>ckf_t status;
>  
>/* The decision not to support SSL v2 and v3 but instead to use only
> - TLSv1 is deliberate.  This is in line with the intentions of RFC
> + TLSv1.X is deliberate.  This is in line with the intentions of RFC
>   3207.  Servers typically support SSL as well as TLS because some
>   versions of Netscape do not support TLS.  I am assuming that all
>   currently deployed servers correctly support TLS.  */
> -  ctx = SSL_CTX_new (TLSv1_client_method ());
> +#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
> +!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
> +ctx = SSL_CTX_new (TLS_client_method ());
> +#else
> +ctx = SSL_CTX_new (SSLv23_client_method ());
> +#endif
> +
> +#ifdef OPENSSL_NO_SSL3
> +SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
> +#endif
> +
> +#ifdef OPENSSL_NO_SSL2
> +SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
> +#endif
>  
>/* Load our keys and certificates.  To avoid messing with configuration
>   variables etc, use fixed paths for the certificate store.  These are
> 
> This looks good. I would however just replace TLSv1_client_method() with
> SSLv23_client_method() (without the version check) and be done with it.
> Setting the NO_SSLvX thingy is a nop in Debian but upstream might be
> happy to see it.

Thanks for review. The reason I did that is indeed, to have a patch
which is most acceptable for upstream to include, independent on
Debian, although upstream since I initially pinged never replied to my
queries :-(. Thus as well the explicit version checking, since AFAIU
the use of the SSLv23_client_method is deprecated in favour of
TLS_client_method. 

The POD for SSL_CTX_new states this explicitly:

SSLv23_method(), SSLv23_server_method() and SSLv23_client_method()
were deprecated and the preferred TLS_method(), TLS_server_method()
and TLS_client_method() functions were introduced in OpenSSL 1.1.0.

Did I missunderstood something here?

So ok I will again do some testing now that the new version is in
unstable.

Regards,
Salvatore

Bug#802658: libesmtp: Should support TLS 1.1+

[Sebastian Andrzej Siewior]

On 2017-08-07 14:26:07 [+0200], Salvatore Bonaccorso wrote:
> Control: severity important

as in SSL not working anymore in unstable for libesmtp.

> Hi Jeremy,
Hi Salvatore,

> Please find attached a (refreshed) patch which is still valid to add
> the proper support for TLSv1.1+

Description: Add TLSv1.1 and TLSv1.2 support
Origin: vendor
Bug-Debian: https://bugs.debian.org/802658
Author: Salvatore Bonaccorso 
Last-Update: 2015-11-07

--- a/smtp-tls.c
+++ b/smtp-tls.c
@@ -197,11 +197,24 @@ starttls_create_ctx (smtp_session_t sess
   ckf_t status;
 
   /* The decision not to support SSL v2 and v3 but instead to use only
- TLSv1 is deliberate.  This is in line with the intentions of RFC
+ TLSv1.X is deliberate.  This is in line with the intentions of RFC
  3207.  Servers typically support SSL as well as TLS because some
  versions of Netscape do not support TLS.  I am assuming that all
  currently deployed servers correctly support TLS.  */
-  ctx = SSL_CTX_new (TLSv1_client_method ());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif
+
+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif
 
   /* Load our keys and certificates.  To avoid messing with configuration
  variables etc, use fixed paths for the certificate store.  These are

This looks good. I would however just replace TLSv1_client_method() with
SSLv23_client_method() (without the version check) and be done with it.
Setting the NO_SSLvX thingy is a nop in Debian but upstream might be
happy to see it.

> Regards,
> Salvatore

Sebastian

Bug#802658: libesmtp: Should support TLS 1.1+

[Salvatore Bonaccorso]

Control: severity important

Hi Jeremy,

Cc'ing the OpenSSL maintainers.

On Mon, Nov 21, 2016 at 07:42:17AM +0100, Salvatore Bonaccorso wrote:
> Hi Jeremy,
>
> On Thu, Oct 13, 2016 at 06:20:49PM -0400, Jeremy T. Bouse wrote:
> > Upstream has been completely MIA for several years now. I've not really
> > checked to determine if there's actually anything dependent on libesmtp
> > and have contemplated archive removal as I am not taking over as
> > upstream and the project itself has appeared to be lifeless and I've
> > merely been keeping the packaging updated.
>
> Some time ago you wrote the above. In case you are interested, I might
> happy to help maintaining it until someone steps up who as well will
> take it over from upstream development point of view.
>
> popcon is increasing for libesmtp actually, it is not dead, and some
> packages depend on it.
>
> And from my personal point of view, I have the additional patch to
> support TSL 1.1+ running since several months now.
>
> Let me know, and regards. Thanks a lot for maintaining it for Debian.

I guess now we need to take action. OpenSSL changed as follows with
the upload of openssl today, the "should support" might now be
rewritten to "needs to support":

https://lists.debian.org/debian-devel-announce/2017/08/msg4.html

[...]
When building it will now already show the deprecation:

/bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.   
-Wdate-time -D_FORTIFY_SOURCE=2 -pthread -std=c99 -pedantic -g -O2 
-fdebug-prefix-map=/build/libesmtp-1.0.6=. -fstack-protector-strong -Wformat 
-Werror=format-security  -Wall -Wchar-subscripts -Wmis
sing-declarations -Wmissing-prototypes -Wstrict-prototypes 
-Wnested-externs -Wpointer-arith -Wbad-function-cast -Wcast-align 
-pthread -std=c99 -pedantic -g -O2 -fdebug-prefix-map=/build/libesmtp-1.0.6=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o
smtp-tls.lo smtp-tls.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-pthread -std=c99 -pedantic -g -O2 -fdebug-prefix-map=/build/libesmtp-1.0.6=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes
-Wstrict-prototypes -Wnested-externs -Wpointer-arith -Wbad-function-cast 
-Wcast-align -pthread -std=c99 -pedantic -g -O2 
-fdebug-prefix-map=/build/libesmtp-1.0.6=. -fstack-protector-strong -Wformat 
-Werror=format-security -c smtp-tls.c  -fPIC -DPIC -o .libs/smtp-tls.o
smtp-tls.c: In function 'starttls_create_ctx':
smtp-tls.c:204:3: warning: 'TLSv1_client_method' is deprecated 
[-Wdeprecated-declarations]
   ctx = SSL_CTX_new (TLSv1_client_method ());
   ^~~
In file included from /usr/include/openssl/ct.h:13:0,
 from /usr/include/openssl/ssl.h:61,
 from libesmtp-private.h:28,
 from smtp-tls.c:46:
/usr/include/openssl/ssl.h:1614:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_client_method(void)) /* 
TLSv1.0 */
 ^
[...]

Please find attached a (refreshed) patch which is still valid to add
the proper support for TLSv1.1+

Regards,
Salvatore
Description: Add TLSv1.1 and TLSv1.2 support
Origin: vendor
Bug-Debian: https://bugs.debian.org/802658
Author: Salvatore Bonaccorso 
Last-Update: 2015-11-07

--- a/smtp-tls.c
+++ b/smtp-tls.c
@@ -197,11 +197,24 @@ starttls_create_ctx (smtp_session_t sess
   ckf_t status;
 
   /* The decision not to support SSL v2 and v3 but instead to use only
- TLSv1 is deliberate.  This is in line with the intentions of RFC
+ TLSv1.X is deliberate.  This is in line with the intentions of RFC
  3207.  Servers typically support SSL as well as TLS because some
  versions of Netscape do not support TLS.  I am assuming that all
  currently deployed servers correctly support TLS.  */
-  ctx = SSL_CTX_new (TLSv1_client_method ());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif
+
+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif
 
   /* Load our keys and certificates.  To avoid messing with configuration
  variables etc, use fixed paths for the certificate store.  These are

Bug#802658: libesmtp: Should support TLS 1.1+

[Salvatore Bonaccorso]

Hi Jeremy,

On Thu, Oct 13, 2016 at 06:20:49PM -0400, Jeremy T. Bouse wrote:
> Upstream has been completely MIA for several years now. I've not really
> checked to determine if there's actually anything dependent on libesmtp
> and have contemplated archive removal as I am not taking over as
> upstream and the project itself has appeared to be lifeless and I've
> merely been keeping the packaging updated.

Some time ago you wrote the above. In case you are interested, I might
happy to help maintaining it until someone steps up who as well will
take it over from upstream development point of view. 

popcon is increasing for libesmtp actually, it is not dead, and some
packages depend on it.

And from my personal point of view, I have the additional patch to
support TSL 1.1+ running since several months now.

Let me know, and regards. Thanks a lot for maintaining it for Debian.

Salvatore

Bug#802658: libesmtp: Should support TLS 1.1+

[Jeremy T. Bouse]

Upstream has been completely MIA for several years now. I've not really
checked to determine if there's actually anything dependent on libesmtp
and have contemplated archive removal as I am not taking over as
upstream and the project itself has appeared to be lifeless and I've
merely been keeping the packaging updated.


On 10/10/2016 12:30 AM, Salvatore Bonaccorso wrote:
> Hi Jememy,
>
> Since almost now a year I try to get that patch forwarded and I have
> it locally running without problems. I do not get a reply from
> upstream author.
>
> Are you in contact with upstream/have an alternative contact address?
>
> The freeze for Debian stretch is approaching in meanwhile really fast.
>
> Regards,
> Salvatore

Bug#802658: libesmtp: Should support TLS 1.1+

[Salvatore Bonaccorso]

Hi Jememy,

Since almost now a year I try to get that patch forwarded and I have
it locally running without problems. I do not get a reply from
upstream author.

Are you in contact with upstream/have an alternative contact address?

The freeze for Debian stretch is approaching in meanwhile really fast.

Regards,
Salvatore

Bug#802658: libesmtp: Should support TLS 1.1+

[Salvatore Bonaccorso]

Control: tags -1 + patch

Hi,

Okay I understand the wontfix reasoning, though I would still want to
point out that it will be become more and more important in future to
not only support TLSv1. I have put a tentative patch together and am
CC'ing upstream author as well.

The patch adds as well a check for libressl and boringssl, this maybe
can be left out though.

For OpenSSL 1.1.x and newer there is TLS_client_method were
SSLv23_client_method is beeing deprecated, so this is as well to
prepare for this case.

How that does look? Comments?

Regards,
Salvatore
Description: Add TLSv1.1 and TLSv1.2 support
Origin: vendor
Bug-Debian: https://bugs.debian.org/802658
Author: Salvatore Bonaccorso 
Last-Update: 2015-11-07

--- a/smtp-tls.c
+++ b/smtp-tls.c
@@ -201,7 +201,20 @@ starttls_create_ctx (smtp_session_t sess
  3207.  Servers typically support SSL as well as TLS because some
  versions of Netscape do not support TLS.  I am assuming that all
  currently deployed servers correctly support TLS.  */
-  ctx = SSL_CTX_new (TLSv1_client_method ());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif
+
+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif
 
   /* Load our keys and certificates.  To avoid messing with configuration
  variables etc, use fixed paths for the certificate store.  These are


signature.asc
Description: PGP signature

Bug#802658: libesmtp: Should support TLS 1.1+

[Salvatore Bonaccorso]

Source: libesmtp
Version: 1.0.6-1
Severity: normal

Hi

libesmtp currently only supports TLSv1:

smtp-tls.c:
199   /* The decision not to support SSL v2 and v3 but instead to use only
200  TLSv1 is deliberate.  This is in line with the intentions of RFC   

  
201  3207.  Servers typically support SSL as well as TLS because some
202  versions of Netscape do not support TLS.  I am assuming that all
203  currently deployed servers correctly support TLS.  */
204   ctx = SSL_CTX_new (TLSv1_client_method ());

Could you please make LibESMTP as well support TLSv1.1 and TLSv1.2.

Regards,
Salvatore

Bug#802658: libesmtp: Should support TLS 1.1+

[Salvatore Bonaccorso]

Hi Jeremy,

On Thu, Oct 22, 2015 at 09:25:29AM -0400, Jeremy T. Bouse wrote:
> severity 802658 wishlist
> tags 802658 + wontfix

I'm interested in the reasoning about the "wontfix". Do you think
Upstream will not take a patch approaching this? Or are there other
reasons/am I missing something?

Thanks for your quick look!

Regards,
Salvatore