Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: dev

GnuTLS status

 

 

exim dev RSS feed   Index | Next | Previous | View Threaded


pdp at exim

May 15, 2012, 8:08 AM

Post #1 of 12 (881 views)
Permalink
GnuTLS status

The GnuTLS revamp is 3/4+ done, I need sleep now though.

I've fixed a number of bugs, unhandled error cases, etc. The SNI
support is ~there.

I'm removing support for gnutls_require_kx, gnutls_require_mac and
gnutls_require_protocols, plus I'm turning tls_require_ciphers in the
GnuTLS case from an Exim list into a GnuTLS priority string.

This lets us get rid of a lot of hardcoding of available algorithm
names, and instead lets folks specify things in the same way they can in
~every other GnuTLS application. Test suite test 2011 removed.

For this release, those removed options will be parsed and silently
ignored.

Relevant documentation updated accordingly.

Current plan: sleep, gym, finish revamp, test a lot, push, cut RC1.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


pdp at exim

May 16, 2012, 9:33 AM

Post #2 of 12 (854 views)
Permalink
Re: GnuTLS status [In reply to]

On 2012-05-15 at 11:08 -0400, Phil Pennock wrote:
> The GnuTLS revamp is 3/4+ done, I need sleep now though.

The GnuTLS revamp is ~done. It's pushed, anyway.

I can send and receive email in at least one configuration, but it
almost certainly needs more bashing about to see how it fares. I
haven't re-run the test-suite yet.

I'm off to bed, only 12 hours late... please do feel free to critique
what was done by providing fixes, if so inclined.

I'll go through the test suite stuff for this, and then see about what
can be done to test the two new authenticators I wrote, and start
cutting 4.78 RC1 at the same time.

Oh, I'll merge the EXPERIMENTAL_OCSP stuff now, before bed.

Anyone got a setup where Exim tried to deliver multiple messages
incorrectly down one channel, in violation of separate source IP address
settings, who can try out the "bug_1141" branch?

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


jgh at wizmail

May 16, 2012, 12:51 PM

Post #3 of 12 (856 views)
Permalink
Re: GnuTLS status [In reply to]

On 2012-05-16 17:33, Phil Pennock wrote:
> On 2012-05-15 at 11:08 -0400, Phil Pennock wrote:
>> The GnuTLS revamp is 3/4+ done, I need sleep now though.
>
> The GnuTLS revamp is ~done. It's pushed, anyway.

Does this require the compile system to have some new GnuTLS
stuff installed? It doesn't build straight off for me:

gcc tls.c
In file included from tls.c:83:
tls-gnu.c: In function ‘init_server_dh’:
tls-gnu.c:392: error: ‘GNUTLS_PK_DH’ undeclared (first use in this function)
tls-gnu.c:392: error: (Each undeclared identifier is reported only once
tls-gnu.c:392: error: for each function it appears in.)
tls-gnu.c:392: error: ‘GNUTLS_SEC_PARAM_NORMAL’ undeclared (first use in this function)
tls-gnu.c: In function ‘tls_server_start’:
tls-gnu.c:1261: warning: cast to pointer from integer of different size
tls-gnu.c:1262: warning: cast to pointer from integer of different size
tls-gnu.c: In function ‘tls_client_start’:
tls-gnu.c:1395: warning: cast to pointer from integer of different size
make[1]: *** [tls.o] Error 1

(Scientific Linux 6)
gnutls-devel-2.8.5-4.el6.x86_64 : Development files for the gnutls package

--
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


pdp at exim

May 16, 2012, 7:23 PM

Post #4 of 12 (853 views)
Permalink
Re: GnuTLS status [In reply to]

On 2012-05-16 at 20:51 +0100, Jeremy Harris wrote:
> On 2012-05-16 17:33, Phil Pennock wrote:
> > On 2012-05-15 at 11:08 -0400, Phil Pennock wrote:
> >> The GnuTLS revamp is 3/4+ done, I need sleep now though.
> >
> > The GnuTLS revamp is ~done. It's pushed, anyway.
>
> Does this require the compile system to have some new GnuTLS
> stuff installed? It doesn't build straight off for me:

CRAP.

So, the current stable release of GnuTLS is 3.0.x; they only distribute
with .xz or .lz compression extensions, which might explain why the OS
packagers seem to still be on GnuTLS 2.

The current 2 branch is GnuTLS 2.12.x.

The old 2 branch is GnuTLS 2.10.x.

GnuTLS 2.8.x is ancient.

The previous Exim code was giving deprecation warnings on GnuTLS 2.12.x,
and hard-codes a bunch of cryptographic information which belongs in the
library but wasn't available when Exim's GnuTLS support was written.

The current code, as I committed, gets rid of those deprecation
warnings; I get one warning, about a file-descriptor int to pointer
cast, but that's the API so we suck up that warning. The code gets rid
of a bunch of crypto algorithm knowledge from Exim and lets GnuTLS do
the right thing, cleanly.

So we have a choice: continue to support ancient GnuTLS and get warnings
and later errors on more current GnuTLS, or accept a new requirement of
a "not too old" GnuTLS for the current Exim releases, if using GnuTLS.

I've been going on the assumption that the only folks really on ancient
GnuTLS are distros like Debian, who also maintain ancient Exim with
patches, so they are not affected by this change until they also update
Exim, when they can just update GnuTLS too.

I think that we might have to say "if you need older libraries, use Exim
with OpenSSL, which has had a more stable API".

Thoughts?
-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


pdp at exim

May 16, 2012, 10:05 PM

Post #5 of 12 (847 views)
Permalink
Re: GnuTLS status [In reply to]

On 2012-05-16 at 22:23 -0400, Phil Pennock wrote:
> So, the current stable release of GnuTLS is 3.0.x; they only distribute
> with .xz or .lz compression extensions, which might explain why the OS
> packagers seem to still be on GnuTLS 2.
>
> The current 2 branch is GnuTLS 2.12.x.
>
> The old 2 branch is GnuTLS 2.10.x.

2.10.x is still in use, and I see that GnuTLS folks are ...
"inconsistent" about identifying which version a new feature was added
in, so I was led astray in thinking the functions were more portable
than they are.

I pulled gnutls.git and checked out the various origin/$release_branches
and the ChangeLog files therein, to get a better idea of what's going
on.

Okay, gnutls_sec_param_to_pk_bits() and gnutls_rnd() appear to both be
new in 2.12.x. So here's my current plan:

* make the gnutls_rnd usage guarded on 2.12.x+, by guarding the
vaguely_random_number() definition better, so we go back to "no better
randomness" for older gnutls.

* Go back to a hard-coded number of bits, the same constant as before,
using the old filename, if the gnutls version is too old; this should
sort out the other _PK_ constant issue too.

* ensure this all builds on 2.10.x and 2.12.x.

* push, get feedback, see if that also solves 2.8.x.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


pdp at exim

May 17, 2012, 6:04 AM

Post #6 of 12 (845 views)
Permalink
Re: GnuTLS status [In reply to]

On 2012-05-16 at 20:51 +0100, Jeremy Harris wrote:
> gcc tls.c
> In file included from tls.c:83:
> tls-gnu.c: In function ‘init_server_dh’:
> tls-gnu.c:392: error: ‘GNUTLS_PK_DH’ undeclared (first use in this function)
> tls-gnu.c:392: error: (Each undeclared identifier is reported only once
> tls-gnu.c:392: error: for each function it appears in.)
> tls-gnu.c:392: error: ‘GNUTLS_SEC_PARAM_NORMAL’ undeclared (first use in this function)

Those are fixed by making them dependent upon a "new enough" version of
GnuTLS. Also for gnutls_rnd(), which did not trigger errors. Hrm.
Perhaps because _gnutls_rnd() existed before then.

> tls-gnu.c: In function ‘tls_server_start’:
> tls-gnu.c:1261: warning: cast to pointer from integer of different size
> tls-gnu.c:1262: warning: cast to pointer from integer of different size
> tls-gnu.c: In function ‘tls_client_start’:
> tls-gnu.c:1395: warning: cast to pointer from integer of different size

Those we have to live with, as the API, for how file-descriptors are
registered as I/O function pointers with a low value, for hooking the
socket I/O into GnuTLS. We're using the correct documented functions,
and were before too.

I'm picking through the test suite and finding more corner cases now.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


pdp at exim

May 17, 2012, 7:36 AM

Post #7 of 12 (851 views)
Permalink
Re: GnuTLS status [In reply to]

On 2012-05-17 at 09:04 -0400, Phil Pennock wrote:
> I'm picking through the test suite and finding more corner cases now.

When I wrote that, I'd fixed one bug.

I've spent a lot of time tracking down why things are still going wrong,
before realising that the test certificate uses md5WithRSAEncryption.

I can generate a new cert, but I also want to make sure *that* still
works if the priority string is set to NORMAL:%VERIFY_ALLOW_SIGN_RSA_MD5
and so far I'm failing. So the basic problem is one of trying to fight
new security requirements of the underlying library, to let admins
continue to shoot themselves in the feet if they so choose.

README.UPDATING will have this extra paragraph in the TLS notes:

Note that by default, GnuTLS will not accept RSA-MD5 signatures in chains.
A tls_require_ciphers value of NORMAL:%VERIFY_ALLOW_SIGN_RSA_MD5 should
re-enable support.

So far, I'm failing to make that true.

EXPORT:%VERIFY_ALLOW_SIGN_RSA_MD5 doesn't help. Still seeing:

10842 GnuTLS<1>: Could not find an appropriate certificate: Insufficient credentials for that request.


For certainty, I've generated two new certs, and indeed that fixes most
of the problems.

The other option is to say "You're using TLS for a reason? Stop using
MD5 then, as the GnuTLS folks recommend", in which case README.UPDATING
would say:

Note that GnuTLS no longer accepts RSA-MD5 signatures in certificate
chains, including in self-signatures. In theory, a
tls_require_ciphers value of NORMAL:%VERIFY_ALLOW_SIGN_RSA_MD5 should
re-enable support, but this does not appear to work. We recommend
following the advice of the experts and not using MD5 signatures in
certificates.


One stance is that it's a case where maintaining backwards compatibility
is bad, because that is being deliberately broken to improve security.

Thoughts?

Am really coming around to the idea of making the next release be 4.80
instead of 4.78, to highlight that there are issues to watch for here.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


nigel at dotdot

May 17, 2012, 7:57 AM

Post #8 of 12 (841 views)
Permalink
Re: GnuTLS status [In reply to]

Phil Pennock wrote:
> Am really coming around to the idea of making the next release be 4.80
> instead of 4.78, to highlight that there are issues to watch for here.

There do seem to be a number of changes that cause upgrade issues,
so probably a good idea.

Nigel.

--
[ Nigel Metheringham ------------------------------ nigel [at] dotdot ]
[ Ellipsis Intangible Technologies ]


--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


pdp at exim

May 17, 2012, 8:26 AM

Post #9 of 12 (843 views)
Permalink
Re: GnuTLS status [In reply to]

On 2012-05-17 at 15:57 +0100, Nigel Metheringham wrote:
> Phil Pennock wrote:
> > Am really coming around to the idea of making the next release be 4.80
> > instead of 4.78, to highlight that there are issues to watch for here.
>
> There do seem to be a number of changes that cause upgrade issues,
> so probably a good idea.

Done.

I really dislike being the originator of backwards incompatible
changes, but both the real ones are security fixes: OpenSSL not
susceptible to BEAST in default config, GnuTLS not supporting MD5.

The accept_8bitmime change, I think everyone's roughly in agreement on.
If anyone disagrees, please do speak up.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


jgh at wizmail

May 17, 2012, 12:36 PM

Post #10 of 12 (835 views)
Permalink
Re: GnuTLS status [In reply to]

On 2012-05-17 15:36, Phil Pennock wrote:
> One stance is that it's a case where maintaining backwards compatibility
> is bad, because that is being deliberately broken to improve security.
>
> Thoughts?

In favour of not maintaining back-compat on this point.
--
Jeremy



--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


A.C.Aitchison at dpmms

May 21, 2012, 1:48 AM

Post #11 of 12 (808 views)
Permalink
Re: GnuTLS status [In reply to]

On Wed, 16 May 2012, Phil Pennock wrote:

> So, the current stable release of GnuTLS is 3.0.x; they only distribute
> with .xz or .lz compression extensions, which might explain why the OS
> packagers seem to still be on GnuTLS 2.
>
> The current 2 branch is GnuTLS 2.12.x.
>
> The old 2 branch is GnuTLS 2.10.x.
>
> GnuTLS 2.8.x is ancient.

... ...

> So we have a choice: continue to support ancient GnuTLS and get warnings
> and later errors on more current GnuTLS, or accept a new requirement of
> a "not too old" GnuTLS for the current Exim releases, if using GnuTLS.
>
> I've been going on the assumption that the only folks really on ancient
> GnuTLS are distros like Debian, who also maintain ancient Exim with
> patches, so they are not affected by this change until they also update
> Exim, when they can just update GnuTLS too.

Hmm. I suppose that Red Hat *is* like Debian.
RHEL 5.8 has gnutls-1.4.1 and RHEL 6.2 has gnutls-2.8.5.

I know sysadmins who still consider RHEL 6.2 a bit experimental
for production servers.

--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
A.C.Aitchison [at] dpmms http://www.dpmms.cam.ac.uk/~werdna

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


pdp at exim

May 21, 2012, 2:38 AM

Post #12 of 12 (809 views)
Permalink
Re: GnuTLS status [In reply to]

On 2012-05-21 at 09:48 +0100, Dr Andrew C Aitchison wrote:
> Hmm. I suppose that Red Hat *is* like Debian.
> RHEL 5.8 has gnutls-1.4.1 and RHEL 6.2 has gnutls-2.8.5.
>
> I know sysadmins who still consider RHEL 6.2 a bit experimental
> for production servers.

If GnuTLS doesn't work, they have OpenSSL. As long as one or the other
works, they should be fine. I suspect that those sysadmins are sticking
with vendor packages, so it's RedHat's problem to manage packaging of
Exim.

If someone is maintaining Exim separately (because it's a mail-server
and they don't use vendor packages for the primary purpose of the
machine, to stay current on that), *and* they have library issues, then
I suspect that they are on an OpenSSL system and installing a different
GnuTLS will only affect Exim.

Failing that, use a differently named pkg-config file for their GnuTLS
install, which sets RPATH and forces Exim to use their install. Or
similarly for OpenSSL.

There are many ways to manage getting current software to run on old
systems and I'm willing to apply reasonable patches to support those
systems. Have done, even as part of this release series.

What we can't do it refuse to ever use a newer version of a library.
And if the library changes APIs, we have to make some choices.

For libraries with a light binding, we can have both APIs. Eg, ClamAV,
where we still have WITH_OLD_CLAMAV_STREAM to support the older API.

For libraries with tighter bindings, I'm likely to again choose to do
what I did with GnuTLS: pick the version which is bundled with a
selection of current OSes, avoid the newest one (GnuTLS 3), and work to
make sure that we can go back a few versions. Exim builds now with 2.8,
2.10, and 2.12. It might build with some older version, and if not, but
it's a *light* patch to do so, I'll probably apply it.

Life is a balance of order and chaos, stasis and change. We can't lock
onto the old API and never update. We have to move forward, carefully,
and make sure we keep putting ourselves in a position where we *can*
move forward. When the vendor of a library starts issuing warnings
about your usage of the API, you're in a dead end and you need to
change. Or look at using a different library, leaving that one as the
historic deprecated choice.

I almost provided both the old and new GnuTLS bindings, but decided it
would add more complexity to configuration than benefit, and it kept me
from cleaning up some internal API work. Also, it would place all the
cost on the volunteer maintainers, and ~none of the benefits.

Which leads to the point that none of the current maintainers are paid
to work on Exim, whereas the commercial OS vendors do pay people to
maintain their packages, so by moving onwards we place the cost burden
on those people being paid for their ability to maintain a stasis. So
ultimately, if this really is a problem and then the cost structures are
already in place to support a solution.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

exim dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.