stunnel 5.46 released

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

stunnel 5.46 released

Michal Trojnara-3
Dear Users,

I have released version 5.46 of stunnel.

Version 5.46, 2018.05.28, urgency: MEDIUM
* New features
  - The default cipher list was updated to a safer value:
    "HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK".
* Bugfixes
  - Default accept address restored to INADDR_ANY.

Home page: https://www.stunnel.org/
Download:  https://www.stunnel.org/downloads.html

SHA-256 hashes:
76aab48c28743d78e4b2f6b2dfe49994b6ca74126046c179444f699fae7a84c7
stunnel-5.46.tar.gz
721cc4d7c385743df767a32a53c11477def2440ae20ad4538d8e685f7b7d6538
stunnel-5.46-win32-installer.exe
d08a3b3598868064db08d6f0e3a97e3c49dedbf6c8d7f348a613b832eca16dd6
stunnel-5.46-android.zip

Best regards,
    Mike


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Viktor Dukhovni


> On May 28, 2018, at 5:27 PM, Michal Trojnara <[hidden email]> wrote:
>
>  - The default cipher list was updated to a safer value:
>    "HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK".

I am rather puzzled as to why you chose to eliminate
not just fixed DH, but also the ephemeral finite-field
DH key exchange.  What's wrong with the DHE ciphers?

I would have chosen:

        HIGH:!aNULL:!kDH:!kECDH:!MD5

which excludes the *fixed* DH/ECDH ciphers and MD5
(and thus also SSLv2).  This does not eliminate
ephemeral finite-field DH, not sure why you're doing
that...

--
--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Michal Trojnara-3
On 05/29/2018 01:48 AM, Viktor Dukhovni wrote:
> I am rather puzzled as to why you chose to eliminate
> not just fixed DH, but also the ephemeral finite-field
> DH key exchange.  What's wrong with the DHE ciphers?
Mostly precomputation attacks: https://weakdh.org/logjam.html
Those parameters are "ephemeral", but not really unique for each TLS
session.
They are also quite slow compared to their EC counterparts...

> I would have chosen:
>
> HIGH:!aNULL:!kDH:!kECDH:!MD5
>
> which excludes the *fixed* DH/ECDH ciphers and MD5
> (and thus also SSLv2).  This does not eliminate
> ephemeral finite-field DH, not sure why you're doing
> that...
Actually the only MD5 vulnerability is collisions.  This may be a threat
for some CAs that use predictable serial numbers, but there are no known
risk for HMACs as used in TLS cipher suites.

Also, excluding kECDH cipher suites sounds like a good idea indeed.

Best regards,
    Mike

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Viktor Dukhovni


> On May 30, 2018, at 12:54 PM, Michał Trojnara <[hidden email]> wrote:
>
>> I am rather puzzled as to why you chose to eliminate
>> not just fixed DH, but also the ephemeral finite-field
>> DH key exchange.  What's wrong with the DHE ciphers?
>
> Mostly precomputation attacks: https://weakdh.org/logjam.html

Which is an issue with *weak* DH parameters, which are no longer
accepted by OpenSSL.  Ephemeral DH is in the majority of server
implementations actually ephemeral.  The group is fixed, but
the server private key is per session, or with old unpatched
code randomly chosen by each server.  It is not clear to me
that EECDH is fundamentally stronger.  Indeed it might prove
weak sooner to QC attacks if/when those become practical.

So I would disable only kDH, but not DHE.  Keep in mind that
some remote systems will not support EECDH, and by disabling
DHE, you get only kRSA, which is worse.  So I think that
'!DH' is unwise.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Michal Trojnara-3
On 30.05.2018 19:12, Viktor Dukhovni wrote:

> So I would disable only kDH, but not DHE.  Keep in mind that
> some remote systems will not support EECDH, and by disabling
> DHE, you get only kRSA, which is worse.  So I think that
> '!DH' is unwise.
I respectfully disagree.  The only practical disadvantage of kRSA is
that it doesn't provide PFS.  Losing PFS is bad, but it's not a huge
price for ensuring secure key exchange.  Actually, there aren't that
many platforms nowadays that support kDHE and not kECDHE.

Best regards,
    Mike


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Viktor Dukhovni


> On May 31, 2018, at 12:09 AM, Michal Trojnara <[hidden email]> wrote:
>
> I respectfully disagree.  The only practical disadvantage of kRSA is
> that it doesn't provide PFS.  Losing PFS is bad, but it's not a huge
> price for ensuring secure key exchange.

There's an assumption here that DHE key exchange is not secure,
while ECDHE is secure.  That assumption is wrong.  Only export
grade DHE was shown weak in logjam.  OpenSSL no longer accepts
weak DHE keys.  There are also weak ECDSA curves that old
implementations would accept, there nothing fundamentally
better (performance aside) about ECDHE vs. DHE.  Indeed
some trust DHE more because the keys are larger and perhaps
more resistant to QC, and the mathematics is better understood
(less bleeding edge than elliptic curves).

I expect there are still plenty of LTS RedHat systems that
ship without EC support, though yes anything reasonably
up to date, will have EC support.

Ultimately of course up to you and your users, I think I've
made my case as well as I could.  Good luck.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Michal Trojnara-3
On 05/31/2018 06:15 AM, Viktor Dukhovni wrote:
> I expect there are still plenty of LTS RedHat systems that
> ship without EC support, though yes anything reasonably
> up to date, will have EC support.
AFAIR EC cipher suites were introduced in OpenSSL 1.0.0, so those LTS
systems must be using OpenSSL 0.9.x.  In 2018 this is asking for
trouble, and a clear evidence that they don't care about security...
> Ultimately of course up to you and your users, I think I've
> made my case as well as I could.  Good luck.
Indeed.  Thank you.  I highly appreciate your input.  Defining an
acceptable security margin for algorithms is tough, especially with QC
predictions in mind...

Best regards,
    Mike


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Viktor Dukhovni


> On May 31, 2018, at 3:27 AM, Michał Trojnara <[hidden email]> wrote:
>
> AFAIR EC cipher suites were introduced in OpenSSL 1.0.0, so those LTS
> systems must be using OpenSSL 0.9.x.

Actually, no.  For IP-related reasons, RedHat for a long time
disabled EC support in OpenSSL 1.0.x.  I expect some of those
systems are still deployed.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Viktor Dukhovni
> Sent: Thursday, May 31, 2018 03:40
> To: [hidden email]
> Subject: Re: [openssl-users] stunnel 5.46 released
>
>
> > On May 31, 2018, at 3:27 AM, Michał Trojnara
> <[hidden email]> wrote:
> >
> > AFAIR EC cipher suites were introduced in OpenSSL 1.0.0, so those LTS
> > systems must be using OpenSSL 0.9.x.
>
> Actually, no.  For IP-related reasons, RedHat for a long time
> disabled EC support in OpenSSL 1.0.x.  I expect some of those
> systems are still deployed.

As do some other products that use OpenSSL. There's a great deal of FUD regarding ECC.

For the record, I'm with Viktor on this. WeakDH does not justify disabling finite-field DHE entirely; that's a misinterpretation of the WeakDH discovery. There's no advantage to having !DH in the default cipher string.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Tomas Mraz-2
In reply to this post by Viktor Dukhovni
On Wed, 2018-05-30 at 13:12 -0400, Viktor Dukhovni wrote:

> > On May 30, 2018, at 12:54 PM, Michał Trojnara <Michal.Trojnara@stun
> > nel.org> wrote:
> >
> > > I am rather puzzled as to why you chose to eliminate
> > > not just fixed DH, but also the ephemeral finite-field
> > > DH key exchange.  What's wrong with the DHE ciphers?
> >
> > Mostly precomputation attacks: https://weakdh.org/logjam.html
>
> Which is an issue with *weak* DH parameters, which are no longer
> accepted by OpenSSL.  Ephemeral DH is in the majority of server
> implementations actually ephemeral.  The group is fixed, but
> the server private key is per session, or with old unpatched
> code randomly chosen by each server.  It is not clear to me
> that EECDH is fundamentally stronger.  Indeed it might prove
> weak sooner to QC attacks if/when those become practical.

I would not say that weak DH parameters are fully rejected by OpenSSL.
The 1024 bit DH parameters could be in theory attacked by state
agencies by precomputation of the discrete logarithm table. And openssl
still accepts 1024 bit DH by default if I am not mistaken.

--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Viktor Dukhovni


> On May 31, 2018, at 12:37 PM, Tomas Mraz <[hidden email]> wrote:
>
> I would not say that weak DH parameters are fully rejected by OpenSSL.
> The 1024 bit DH parameters could be in theory attacked by state
> agencies by precomputation of the discrete logarithm table.

That's speculative.  If the idea is to prefer kECDHE over kDHE,
OpenSSL already does that.  In practice ECDHE is negotiated
when available.  The issue at hand is whether kDHE is worse
than kRSA.  Which is more likely later key compromise or
a brute force attack on 1024-bit DHE likely costing 10's to
100's of millions of dollars per key...

> And openssl
> still accepts 1024 bit DH by default if I am not mistaken.

Yes, but unless you're another nation-state with secrets
worth attacking at all costs, it seems rather unlikely
that this is a concern.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Blumenthal, Uri - 0553 - MITLL
FWIW, I'm with Viktor in this argument. From cryptography point of view he's right. I suspect he's right from the practical point of view as well.

P.S. Those concerned that a nation-state would attack them, are advised to change the default config anyway.
--
Regards,
Uri Blumenthal

On 5/31/18, 14:01, "openssl-users on behalf of Viktor Dukhovni" <[hidden email] on behalf of [hidden email]> wrote:

   
   
    > On May 31, 2018, at 12:37 PM, Tomas Mraz <[hidden email]> wrote:
    >
    > I would not say that weak DH parameters are fully rejected by OpenSSL.
    > The 1024 bit DH parameters could be in theory attacked by state
    > agencies by precomputation of the discrete logarithm table.
   
    That's speculative.  If the idea is to prefer kECDHE over kDHE,
    OpenSSL already does that.  In practice ECDHE is negotiated
    when available.  The issue at hand is whether kDHE is worse
    than kRSA.  Which is more likely later key compromise or
    a brute force attack on 1024-bit DHE likely costing 10's to
    100's of millions of dollars per key...
   
    > And openssl
    > still accepts 1024 bit DH by default if I am not mistaken.
   
    Yes, but unless you're another nation-state with secrets
    worth attacking at all costs, it seems rather unlikely
    that this is a concern.
   
    --
    Viktor.
   
    --
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
   

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: stunnel 5.46 released

Viktor Dukhovni


> On May 31, 2018, at 2:43 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
> FWIW, I'm with Viktor in this argument. From cryptography point of view he's right. I suspect he's right from the practical point of view as well.

This is not so much a matter of "right" or "wrong" as arguably
"sensibly pragmatic" vs. "counter-productively cautious", or is
it "negligently careless" vs. "duly conservative"?

So these are judgement calls, but:

  https://tools.ietf.org/html/rfc7525#section-4.2

does recommend both DHE and ECDHE, so I'm on solid
ground viz. the IETF.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users