Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

[Mahesh Bhoothapuri]

Thanks for the hint.  The problem is fixed.

Server was setting:

if (SSL_CTX_set1_groups_list(ctx, "X25519:P-256") == 0) {
//
}

The call succeeds.

But the old TLS 1.2 code was setting:

int nid = NID_X9_62_prime256v1;
EC_KEY* ecdh = EC_KEY_new_by_curve_name(nid);
if (ecdh == NULL)
{
   //error
}
SSL_CTX_set_tmp_ecdh(ctx, ecdh);

After disabling this, the server responds with the right group - X25519.

Thanks,
Mahesh
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

[Mahesh Bhoothapuri]

I am attaching a pcap where I set the supported list to contain X25519.
The client extension contains X25519.  However, the server still responds
with keyshare extension secp256r1 in a hello retry request.

This is the case for all the 5 TLS 1.3 ciphers.  Is there another setting
for the server to enable the supported groups?


Thanks,
Mahesh

On Wed, Oct 4, 2017 at 8:02 AM, Dr. Stephen Henson 
wrote:

> On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:
>
> > if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
> >//error
> > }
> >
>
> If you have the above line you're telling the client to advertise support
> for
> P-521:P-384:P-256 in that order and the server to only use them.
>
> > The client and server both use SSL_CTX_set1_groups-list to set the
> > supported group list.  Right now,  the server always
> > has P-256 in the supported groups extension.
> > When the the groups list is changed to add X25519,  the server
> responds
> > with P-256.   Is there a way to have the server support
> > multiple specified groups.
> >
> > Section 9.1 of the rfc states:
> > "
> >
> > A TLS-compliant application MUST support digital signatures with
> >rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
> >CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
> >TLS-compliant application MUST support key exchange with secp256r1
> >(NIST P-256) and SHOULD support key exchange with X25519 [RFC7748
> > ].
> >   "
> >
>
> Yes and OpenSSL does support those but there is nothing stopping a server
> or
> client being configured to support a different set of groups.
>
> >   So, having the server support P-256 satisfies the MUST part.  How
> > can we support X25519 on the server, or
> >
>
> Use X25519 in the supported group list.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>


x25519_trace0.pcap
Description: Binary data
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

[Dr. Stephen Henson]

On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:

> if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
>//error
> }
> 

If you have the above line you're telling the client to advertise support for
P-521:P-384:P-256 in that order and the server to only use them.

> The client and server both use SSL_CTX_set1_groups-list to set the
> supported group list.  Right now,  the server always
> has P-256 in the supported groups extension.
> When the the groups list is changed to add X25519,  the server responds
> with P-256.   Is there a way to have the server support
> multiple specified groups.
> 
> Section 9.1 of the rfc states:
> "
> 
> A TLS-compliant application MUST support digital signatures with
>rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
>CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
>TLS-compliant application MUST support key exchange with secp256r1
>(NIST P-256) and SHOULD support key exchange with X25519 [RFC7748
> ].
>   "
> 

Yes and OpenSSL does support those but there is nothing stopping a server or
client being configured to support a different set of groups.

>   So, having the server support P-256 satisfies the MUST part.  How
> can we support X25519 on the server, or
> 

Use X25519 in the supported group list.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Can I haz TLS 1.3 ?

[Richard Moore]

On 3 October 2017 at 20:45, Hanno Böck  wrote:

> On Tue, 3 Oct 2017 17:36:03 +
> "Salz, Rich via openssl-dev"  wrote:
>
> So I heard chatter about this, but not much details. Which I find
> unfortunate and a bit disturbing. (I'm aware of a single case with
> bluetooth HW, but this sounds like this is much more common.)
>
>
​http://bluecoat.force.com/knowledgebase/articles/Technical_Alert/32878​
​​
Cheers

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

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

[Benjamin Kaduk via openssl-dev]

On 10/04/2017 04:30 AM, Matt Caswell wrote:
>
> Looks like we should have an exception for this case (with a suitable
> comment explaining why). Will you create a PR?
>

Yes, I was planning to.  I was just taking some time to ponder whether
it's worth burning an option bit on, to allow an opt-out (probably not).

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

Re: [openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

[Dr. Stephen Henson]

On Wed, Oct 04, 2017, Matt Caswell wrote:

> 
> As Tomas said - that ship has sailed. In my mind that change was a
> mistake. It could have been done in a non-breaking way by introducing a
> new header format at that time.
> 

As regards a new header format. In the case of some of the structures we use
there is an appropriate password based encryption ASN.1 AlgorithmIdentifier.
The code to encode and decode that format is already in OpenSSL and it
is documented in various standards. It is currently used for private key
encryption (via PKCS#8) and PKCS#7 EncryptedData format (used by PKCS#12).
One of several advantages of using that form is that any new forms we want to
support just need to be a new password based encryption algorithm and "enc"
handles it automatically. So we'd get scrypt, PBKDF2 and all the older PKCS#12
algorithms automatically. We wouldn't be able to use the current non-standard
password based encrytion algorithm without defining our own OID but I can't
see why we'd want to use that when much better alternatives are available.

In fact if we were feeling particularly adventurous we could output a CMS or
PKCS#7 EncryptedData ContentInfo in the enc utility.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Can I haz TLS 1.3 ?

[Richard Levitte]

It's not specific to devops. Here, a quick history lesson:

https://english.stackexchange.com/questions/20356/origin-of-i-can-haz

Cheers
Richard 

Ted Marynicz  skrev: (4 oktober 2017 10:53:35 CEST)
>Haz?
>
>Is that some kind of devops-speak I am not (yet) aware of?
>
>Ted
>(a grand-father)
>
>On 3 October 2017 at 18:36, Salz, Rich via openssl-dev <
>openssl-dev@openssl.org> wrote:
>
>> Some people have asked why TLS 1.3 isn’t available yet.  This might
>help;
>> it’s a draft of a posting for my company’s blog.
>>
>>
>>
>>
>>
>> Can I Haz TLS 1.3 ?
>>
>>
>>
>> Everybody wants to be able to use TLS 1.3. Among the reasons are:
>>
>> It’s faster – being able to reconnect to a server
>you’ve
>> previously used, and saving a full round-trip latency is impressive.
>>
>> It’s more reliable – the protocol has been cleaned up
>and
>> simplified. For example, the related concepts of sessions, tickets,
>and
>> pre-shared keys are merged and treated consistently. To a protocol
>> designer, it is much more elegant, and therefore much easier to
>implement
>>
>> It’s more secure – Many world-class cryptographers
>have
>> been involved in the protocol design, analyzed it, and tried to break
>it.
>>
>>
>>
>> TLS has been in the “last call” for several weeks now.  What does
>that
>> mean, and what’s holding it up?
>>
>>
>>
>> The IETF is the organization that defines most of the standards that
>> define how the Internet works. They cover everything from naming
>(DNS) to
>> routing around firewalls, up to and including HTTP. The documents,
>known as
>> RFCs, are created by working groups, passed to a steering committee
>for
>> review, and then published as “Internet Standards.”
>>
>>
>>
>> Participation in a working group (WG) is, by design, very easy and
>not a
>> lot of overhead.  You just have to join a mailing list.  Every WG has
>a
>> mailing list and there are currently more than 110 working groups
>hosted at
>> the IETF. Each one has a status page, that shows their charter (what
>they
>> are working on), the current sent of documents, and pointers to the
>mailing
>> lists.  For the TLS working group, that page is at
>> https://datatracker.ietf.org/wg/tls/documents/.
>>
>>
>>
>> Future RFC’s start as Internet-Drafts. Each draft usually goes
>through
>> multiple revisions, as the working group members comment on it, other
>> feedback is addressed, and so on.  At some point, the authors or
>editors
>> will post a new draft.  By convention, every working group draft is
>named
>> “draft-ietf-{WGNAME}-{subject}-{nn}” where {WGNAME} is the name of
>the
>> working group, {subject} is the name of the document, and {nn} is the
>> revision number.  For example, “draft-ietf-tls-tls13-21” is the 21st
>> draft of the TLS 1.3 specification from the TLS working group.
>>
>>
>>
>> When the working group thinks a document is done, it enters WGLC,
>working
>> group last call.  This period, usually lasting a couple of weeks, is
>the
>> last chance to make editorial or serious factual fixes.  Since most
>people
>> are deadline-driven, this is usually when many on the WG wake up and
>read
>> the drafts. After WGLC, it goes to the IESG (technical leadership
>> basically) for review.  As I said, TLS 1.3 has been in WGLC for
>weeks.  So
>> why can’t we use it yet?
>>
>>
>>
>> First, the different drafts don’t interoperate. Each represents a
>> different milestone on the way to the full specification, and a flag
>in the
>> header identifies which draft is being used. OpenSSL, used by most of
>the
>> servers on the Internet, is currently at draft-21. Chrome and
>Firefox, two
>> of the most popular browsers on the Internet, are staying at
>draft-18; they
>> don’t want to upgrade until we have the final version. (I think
>that’s
>> silly, but I don’t work for either browser.)
>>
>>
>>
>> Tests run by various companies, including Google, Mozilla, and
>Facebook,
>> indicate that the “failure rate” of TLS 1.3 is disturbingly high. It
>> appears that network hardware such as routers, gateways, load
>balancers and
>> the like, are blocking TLS 1.3 packets because they don’t recognize
>the
>> protocol. They are doing “fail closed” and block the connections
>because
>> they don’t understand it, rather than assuming it’s safe to forward.
>The
>> IETF often uses the term “middlebox” to describe such hardware that
>> operates between endpoints, and this type of behavior that blocks new
>> protocols as “ossificiation.”  The various companies, and no doubt
>others,
>> are trying experiments to tweak the protocol to lower the failure
>rate. For
>> example, in some circumstances it might be acceptable to make a TLS
>1.3
>> message look like a TLS 1.2 message (after you’ve already committed
>to
>> doing TLS 1.3).
>>
>>
>>
>> So far nobody has released any details. When it happens, it will be
>on the
>> TLS-WG mailing list, which you can find at the page I referenced
>above.
>> Until then, 

Re: [openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

[Matt Caswell]

On 03/10/17 18:51, Robin H. Johnson wrote:
> On Tue, Oct 03, 2017 at 09:45:43AM +0200, Tomas Mraz wrote:
>> On Tue, 2017-10-03 at 08:23 +0100, Matt Caswell wrote:
>>>
 1.2. This also opens the path to stronger key derivation (PBKDF2)
 2. During decryption, if no header block is present, and no message
    digest was specified, the default digest SHOULD be MD5.
>>>
>>> Should it? What about compatibility with OpenSSL 1.1.0? We cannot
>>> make
>>> breaking changes in 1.1.1, so it has to be compatible with 1.1.0.
>> Yeah, the ship has sailed. SHA-256 should be used by default as in
>> 1.1.0.
> It's a breaking change from 1.0.

As Tomas said - that ship has sailed. In my mind that change was a
mistake. It could have been done in a non-breaking way by introducing a
new header format at that time. That way if the header was not present
then we would have known to use MD5 - otherwise use the hash as
specified in the header. But its too late now. Breaking it again back to
what it was before is the wrong answer.

> At the very least, it should be added to the big notes:
> https://www.openssl.org/news/openssl-1.1.0-notes.html
> (this was in fact the first place I looked when my data was broken,
> there was nothing about the enc tool here).

Well in fact it is there:

  *) Changed default digest for the dgst and enc commands from MD5 to
 sha256
 [Rich Salz]

Perhaps that is a little brief - it doesn't really explain the
implications of the change.

Matt



signature.asc
Description: OpenPGP digital signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

[Matt Caswell]

On 03/10/17 16:15, Benjamin Kaduk via openssl-dev wrote:
> Hi all,
> 
> Doing some testing with a snapshot of master (s_client with -tls1_2 and
> optionally a cipherspec that prefers ECDHE ciphers), we're running into
> a sizeable number of servers that are sending extension 0xa (formerly
> "elliptic_curves", now "supported_groups") in the ServerHello.  This is
> not supported by RFC 7919 or RFC 4492 (the server is supposed to
> indicate it's selected curve/group in the ServerKeyExchange message
> instead), or by the TLS 1.3 draft spec (which permits "supported_groups"
> in EncryptedExtensions, so the client can update a cache of groups
> supported by the server).
> 
> In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension
> in a ServerHello as an extension unknown to the library code and passed
> it off to the custom extension handler.  With the extension processing
> rework in master done to support TLS 1.3, which admits extensions in
> many more contexts than previously, we now check that a received
> extension is allowable in the context at hand.  In the table of
> extensions, supported_groups is marked only as allowable in the
> ClientHello and TLS 1.3 EncryptedExtensions, per the spec.  However,
> this new strict behavior causes connection failures when talking to
> these buggy servers.  So far we've seen this behavior from servers that
> send a Server: header indicating Microsoft-IIS/7.5 and just "Apache".
> 
> This raises some question of what behavioral compatibility is desired
> between 1.1.0 and 1.1.1 -- do we need to disable the "extension context"
> verification for ServerHello processing entirely, or maybe just for the
> one extension known to cause trouble in practice?  Or should we have an
> SSL/SSL_CTX option to control the behavior (and which behavior should be
> the default)?
> 
> Also, I'd be interested in hearing whether anyone else has observed this
> sort of behavior.

Looks like we should have an exception for this case (with a suitable
comment explaining why). Will you create a PR?

Matt

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