From matt at openssl.org  Mon Jul  3 09:11:52 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 3 Jul 2017 10:11:52 +0100
Subject: [openssl-users] PSK generation for TLS 1.3
In-Reply-To: <CANWFjKDtUYJ=2cia-F2BTHP5VG_pUTFswe1k03mdi7YJzWWShw@mail.gmail.com>
References: <CANWFjKDtUYJ=2cia-F2BTHP5VG_pUTFswe1k03mdi7YJzWWShw@mail.gmail.com>
Message-ID: <72cf97f2-f052-49c2-5969-750869d1b59e@openssl.org>



On 30/06/17 22:18, Neetish Pathak wrote:
> Hi All,
> Can anyone provide me pointers on how can we generate external PSK to be
> used inTLS 1.3.
> 
> When I save a a session using SSL_CTX_sess_set_new_cb(), it provides an
> in-band PSK for next resumption connection. 
> I use PEM_write_bio_SSL_SESSION to save the session.
> 
> 
> How do we use PSK externally. Can I use the same session file which was
> saved during in-band connection. I believe in case of an external PSK,
> both client and server should have a copy in advance.

Yes, you can do if you want - like you said you just need to make sure
that the session file is used on both the client and the server.
Alternatively you can "create" a new session file, e.g.
s_server/s_client do it like this:

        usesess = SSL_SESSION_new();
        if (usesess == NULL
                || !SSL_SESSION_set1_master_key(usesess, key, key_len)
                || !SSL_SESSION_set_cipher(usesess, cipher)
                || !SSL_SESSION_set_protocol_version(usesess,
TLS1_3_VERSION)) {
            OPENSSL_free(key);
            goto err;
        }


Matt



From npathak2 at ncsu.edu  Mon Jul  3 21:24:49 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Mon, 3 Jul 2017 14:24:49 -0700
Subject: [openssl-users] PSK generation for TLS 1.3
In-Reply-To: <72cf97f2-f052-49c2-5969-750869d1b59e@openssl.org>
References: <CANWFjKDtUYJ=2cia-F2BTHP5VG_pUTFswe1k03mdi7YJzWWShw@mail.gmail.com>
 <72cf97f2-f052-49c2-5969-750869d1b59e@openssl.org>
Message-ID: <CANWFjKCs6F_n6+7wRobCAvQQYzkaW9oOr6OyvebmhD0LFDNBOw@mail.gmail.com>

On Mon, Jul 3, 2017 at 2:11 AM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 30/06/17 22:18, Neetish Pathak wrote:
> > Hi All,
> > Can anyone provide me pointers on how can we generate external PSK to be
> > used inTLS 1.3.
> >
> > When I save a a session using SSL_CTX_sess_set_new_cb(), it provides an
> > in-band PSK for next resumption connection.
> > I use PEM_write_bio_SSL_SESSION to save the session.
> >
> >
> > How do we use PSK externally. Can I use the same session file which was
> > saved during in-band connection. I believe in case of an external PSK,
> > both client and server should have a copy in advance.
>
> Yes, you can do if you want - like you said you just need to make sure
> that the session file is used on both the client and the server.
> Alternatively you can "create" a new session file, e.g.
> s_server/s_client do it like this:
>
>         usesess = SSL_SESSION_new();
>         if (usesess == NULL
>                 || !SSL_SESSION_set1_master_key(usesess, key, key_len)
>                 || !SSL_SESSION_set_cipher(usesess, cipher)
>                 || !SSL_SESSION_set_protocol_version(usesess,
> TLS1_3_VERSION)) {
>             OPENSSL_free(key);
>             goto err;
>         }
>
>
> Thanks Matt. This is quite useful.
Just to clarify my understanding based on your comments, OpenSSL code  and
Draft for TLS 1.3/RFC for TLS1.2, please help me with following queries

1) So, when using external PSK (by creating the new session file), client
should mandatorily use SSL_CTX_set_psk_use_session_callback while server
should mandatorily use SSL_CTX_set_psk_find_session_callback.
They both should use a common key (psk_key) to generate the new session
file and this common key is the one shared in advance to both client and
server. From the OpenSSL code, this key is used as char * type. So does it
mean that any pre-decided string can be used as a key and it does not need
any format etc. Both client and server create sessions based on the key and
connect based on the created session?
In one of the examples, *strspn*(psk_key, "abcdefABCDEF1234567890") is
used. So, I believe I can use any hex value string of my choice as psk_key.


2) Also, from the man page , I found that PSK are used in TLS1.2 and lower
versions too and SSL_CTX_set_psk_server_callback and
SSL_CTX_set_psk_client_callback
are used to set callback there. PSK  identity and Pre shared key is set
there which can be used during the connection. It is also written that
these values are required when using PSK cipher-suites. So, is my
understanding correct that the role of PSK in version <= TLS1.2 is only for
using PSK ciphersuites (e.g: ECDHE-PSK-AES256-CBC-SHA384) and do not have
anything to do with session resumption and thereby do not provide any
performance enhancement.
Also, this PSK type ciphersuites are no longer valid for TLS 1.3.


Thanks
BR,
Neetish




> Matt
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170703/5f8729c0/attachment.html>

From matt at openssl.org  Tue Jul  4 08:51:43 2017
From: matt at openssl.org (Matt Caswell)
Date: Tue, 4 Jul 2017 09:51:43 +0100
Subject: [openssl-users] PSK generation for TLS 1.3
In-Reply-To: <CANWFjKCs6F_n6+7wRobCAvQQYzkaW9oOr6OyvebmhD0LFDNBOw@mail.gmail.com>
References: <CANWFjKDtUYJ=2cia-F2BTHP5VG_pUTFswe1k03mdi7YJzWWShw@mail.gmail.com>
 <72cf97f2-f052-49c2-5969-750869d1b59e@openssl.org>
 <CANWFjKCs6F_n6+7wRobCAvQQYzkaW9oOr6OyvebmhD0LFDNBOw@mail.gmail.com>
Message-ID: <88cfca68-2058-39a1-8ee1-aa4d104bf454@openssl.org>



On 03/07/17 22:24, Neetish Pathak wrote:

> Thanks Matt. This is quite useful.
> Just to clarify my understanding based on your comments, OpenSSL code
>  and Draft for TLS 1.3/RFC for TLS1.2, please help me with following queries
> 
> 1) So, when using external PSK (by creating the new session file),
> client should mandatorily use SSL_CTX_set_psk_use_session_callback while
> server should mandatorily use SSL_CTX_set_psk_find_session_casllback.
> They both should use a common key (psk_key) to generate the new session
> file and this common key is the one shared in advance to both client and
> server.

Yes, that is correct. If both client and server are OpenSSL then,
optionally, they can just share a session file (which contains the key)
if that is easier.

> From the OpenSSL code, this key is used as char * type. So does
> it mean that any pre-decided string can be used as a key and it does not
> need any format etc.

To me "string" implies NUL terminated printable string. Maybe that's not
what you meant. Anyway in that sense "string" is not quite correct. The
key is binary data which should be the same length as the hash used for
the ciphersuite.


> Both client and server create sessions based on the
> key and connect based on the created session?
> In one of the examples, *strspn*(psk_key, "abcdefABCDEF1234567890") is
> used. So, I believe I can use any hex value string of my choice as psk_key.

Like I said above - the key is *binary* data. It does not have to be a
printable string.


> 2) Also, from the man page , I found that PSK are used in TLS1.2 and
> lower versions too and SSL_CTX_set_psk_server_callback
> and SSL_CTX_set_psk_client_callback are used to set callback there. PSK
>  identity and Pre shared key is set there which can be used during the
> connection. It is also written that these values are required when using
> PSK cipher-suites. So, is my understanding correct that the role of PSK
> in version <= TLS1.2 is only for using PSK ciphersuites
> (e.g: ECDHE-PSK-AES256-CBC-SHA384)

Correct.

> and do not have anything to do with
> session resumption and thereby do not provide any performance enhancement.

They do not have anything to do with session resumption, so you don't
see the reduced number of message flights that you get with a resumed
handshake. However, PSK ciphersuites in <= TLS1.2 avoid the need to send
(and therefore process/validate) Certificate messages which may have
performance benefits. If the ciphersuite in use just uses "plain" PSK
(i.e. no (EC)DHE or RSA) then a connection can be established without
using public-key operations which may also have performance benefits (at
the expense of forward secrecy).

> Also, this PSK type ciphersuites are no longer valid for TLS 1.3.

Correct.


Matt

From devang.kubavat at in.abb.com  Wed Jul  5 04:47:24 2017
From: devang.kubavat at in.abb.com (Devang Kubavat)
Date: Wed, 5 Jul 2017 04:47:24 +0000
Subject: [openssl-users] OpenSSL Engine for TPM
Message-ID: <DB5PR06MB1767BE68A400BC209BF8B2C3B2D40@DB5PR06MB1767.eurprd06.prod.outlook.com>

Hi All,

  1.  Is there any built-in OpenSSL Engine to access the TPM ?
  2.  Is there any other OpenSSL Engine to access the TPM ? If Yes, How can we configure in OpenSSL libraries to use that engine ?

Please guide me. Thanks.

Best Regards,
Devang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170705/03a5e095/attachment.html>

From rsalz at akamai.com  Wed Jul  5 23:27:20 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 5 Jul 2017 23:27:20 +0000
Subject: [openssl-users] OpenSSL Engine for TPM
In-Reply-To: <DB5PR06MB1767BE68A400BC209BF8B2C3B2D40@DB5PR06MB1767.eurprd06.prod.outlook.com>
References: <DB5PR06MB1767BE68A400BC209BF8B2C3B2D40@DB5PR06MB1767.eurprd06.prod.outlook.com>
Message-ID: <1eae8dcd617944c99f72ce33e449bcc2@usma1ex-dag1mb1.msg.corp.akamai.com>

>? 1.? Is there any built-in OpenSSL Engine to access the TPM ?

No.

>? 2.? Is there any other OpenSSL Engine to access the TPM ? If Yes, How can we configure in OpenSSL libraries to use that engine ?

If someone has written one, and can make it available, they should post here.  I don't know of any, but there may be.

From christian at hohnstaedt.de  Thu Jul  6 04:39:44 2017
From: christian at hohnstaedt.de (=?ISO-8859-1?Q?Christian_Hohnst=E4dt?=)
Date: Thu, 06 Jul 2017 06:39:44 +0200
Subject: [openssl-users] OpenSSL Engine for TPM
In-Reply-To: <DB5PR06MB1767BE68A400BC209BF8B2C3B2D40@DB5PR06MB1767.eurprd06.prod.outlook.com>
References: <DB5PR06MB1767BE68A400BC209BF8B2C3B2D40@DB5PR06MB1767.eurprd06.prod.outlook.com>
Message-ID: <700500B3-FCD8-40D6-9656-C8A9145E9108@hohnstaedt.de>

The trousers project has one.
https://sourceforge.net/projects/trousers/files/OpenSSL%20TPM%20Engine/


Christian 

Am 5. Juli 2017 06:47:24 MESZ schrieb Devang Kubavat <devang.kubavat at in.abb.com>:
>Hi All,
>
>  1.  Is there any built-in OpenSSL Engine to access the TPM ?
>2.  Is there any other OpenSSL Engine to access the TPM ? If Yes, How
>can we configure in OpenSSL libraries to use that engine ?
>
>Please guide me. Thanks.
>
>Best Regards,
>Devang

-- 
Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170706/cd8af14d/attachment.html>

From steve at openssl.org  Thu Jul  6 19:38:27 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 6 Jul 2017 19:38:27 +0000
Subject: [openssl-users] Loading multiple private keys a certificates on
 server program
In-Reply-To: <CANWFjKBZR3EvUJ+2y-Xe4YbVfn7WO6sATHW5FqE_bfZgqzeNjg@mail.gmail.com>
References: <CANWFjKBZR3EvUJ+2y-Xe4YbVfn7WO6sATHW5FqE_bfZgqzeNjg@mail.gmail.com>
Message-ID: <20170706193827.GA30828@openssl.org>

On Tue, Jun 27, 2017, Neetish Pathak wrote:

> 
> SSL_CTX_use_certificate_file to load the certificate but the server always
> picks just the first certificate mentioned in the file and fails for one of
> the cases with no cipher shared message
> 
> What should we do to store multiple certificates and private keys at the
> server side so that it picks the right one corresponding to the requested
> cipher.
> 

You call SSL_CTX_use_certificate_file multiple times: once for each
certificate type. Similary for private keys.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From janjust at nikhef.nl  Fri Jul  7 14:39:53 2017
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Fri, 7 Jul 2017 16:39:53 +0200
Subject: [openssl-users] OpenSSL Engine for TPM
In-Reply-To: <700500B3-FCD8-40D6-9656-C8A9145E9108@hohnstaedt.de>
References: <DB5PR06MB1767BE68A400BC209BF8B2C3B2D40@DB5PR06MB1767.eurprd06.prod.outlook.com>
 <700500B3-FCD8-40D6-9656-C8A9145E9108@hohnstaedt.de>
Message-ID: <50c99063-6f4f-45fb-480d-0cac6c92610a@nikhef.nl>

Hi,

On 06/07/17 06:39, Christian Hohnst?dt wrote:
> The trousers project has one.
> https://sourceforge.net/projects/trousers/files/OpenSSL%20TPM%20Engine/
>
>
agreed, but this engine  does not really put the keys inside the TPM - instead it sets up a local repository that is encrypted 
using a key from the TPM. If you look at the way it is designed, it is not really secure (as it's not impossible to find the 
password that was used to encrypt the keys with).


> Am 5. Juli 2017 06:47:24 MESZ schrieb Devang Kubavat <devang.kubavat at in.abb.com>:
>
>     Hi All,
>
>       1.  Is there any built-in OpenSSL Engine to access the TPM ?
>       2.  Is there any other OpenSSL Engine to access the TPM ? If Yes, How can we configure in OpenSSL libraries to use that
>     engine ?
>
>     Please guide me. Thanks.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170707/1f3deb59/attachment-0001.html>

From Michael.Wojcik at microfocus.com  Fri Jul  7 15:53:44 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 7 Jul 2017 15:53:44 +0000
Subject: [openssl-users] OpenSSL Engine for TPM
In-Reply-To: <50c99063-6f4f-45fb-480d-0cac6c92610a@nikhef.nl>
References: <DB5PR06MB1767BE68A400BC209BF8B2C3B2D40@DB5PR06MB1767.eurprd06.prod.outlook.com>
 <700500B3-FCD8-40D6-9656-C8A9145E9108@hohnstaedt.de>
 <50c99063-6f4f-45fb-480d-0cac6c92610a@nikhef.nl>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9A8EBF3@prvxmb03.microfocus.com>

> agreed, but this engine? does not really put the keys inside the TPM - instead it sets up a local repository that is encrypted
> using a key from the TPM. If you look at the way it is designed, it is not really secure (as it's not impossible to find the 
> password that was used to encrypt the keys with).

"really secure" is not a useful phrase. Security is a set of asymptotic trade-offs between attacker and defender work-factors under a threat model. Nothing ever achieves "really secure".

Even a hypothetical OpenSSL engine that performed all cryptographic operations on the TPM wouldn't achieve specified security under the TPM threat model unless the engine, all of OpenSSL, and whatever is invoking it were part of the TCB.

That said, there is certainly a case to be made that an OpenSSL engine which performed at least some crypto operations on the TPM is of at least academic interest. Someone might want to start with the Trousers engine and try extending it. (Enhancing an existing engine generally isn't particularly difficult, in my experience, though of course it depends on what you're trying to do and what APIs are available.) Or try writing a fresh TPM engine using, say, the Windows TPM API.

It might help to know what your use case is.

Michael Wojcik 
Distinguished Engineer, Micro Focus 



From freemonj at gmail.com  Fri Jul  7 16:17:43 2017
From: freemonj at gmail.com (Freemon Johnson)
Date: Fri, 7 Jul 2017 12:17:43 -0400
Subject: [openssl-users] OpenSSL Engine for TPM
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9A8EBF3@prvxmb03.microfocus.com>
References: <DB5PR06MB1767BE68A400BC209BF8B2C3B2D40@DB5PR06MB1767.eurprd06.prod.outlook.com>
 <700500B3-FCD8-40D6-9656-C8A9145E9108@hohnstaedt.de>
 <50c99063-6f4f-45fb-480d-0cac6c92610a@nikhef.nl>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9A8EBF3@prvxmb03.microfocus.com>
Message-ID: <CALD4PSmT+YnFxpffM775fJAjtt=9RpN_eBNQkiHuwObCc7TfMg@mail.gmail.com>

I would personally love to see an implementation of this as well for
OpenSSL. However in the interim you can see how these libraries were
referenced to insert keys into the TPM for OpenSSH. Our team here has also
verified this works nicely. Perhaps this can be extended if you do not wish
to work with Trousers.

https://github.com/ThomasHabets/simple-tpm-pk11



On Fri, Jul 7, 2017 at 11:53 AM, Michael Wojcik <
Michael.Wojcik at microfocus.com> wrote:

> > agreed, but this engine  does not really put the keys inside the TPM -
> instead it sets up a local repository that is encrypted
> > using a key from the TPM. If you look at the way it is designed, it is
> not really secure (as it's not impossible to find the
> > password that was used to encrypt the keys with).
>
> "really secure" is not a useful phrase. Security is a set of asymptotic
> trade-offs between attacker and defender work-factors under a threat model.
> Nothing ever achieves "really secure".
>
> Even a hypothetical OpenSSL engine that performed all cryptographic
> operations on the TPM wouldn't achieve specified security under the TPM
> threat model unless the engine, all of OpenSSL, and whatever is invoking it
> were part of the TCB.
>
> That said, there is certainly a case to be made that an OpenSSL engine
> which performed at least some crypto operations on the TPM is of at least
> academic interest. Someone might want to start with the Trousers engine and
> try extending it. (Enhancing an existing engine generally isn't
> particularly difficult, in my experience, though of course it depends on
> what you're trying to do and what APIs are available.) Or try writing a
> fresh TPM engine using, say, the Windows TPM API.
>
> It might help to know what your use case is.
>
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170707/b2378cd7/attachment.html>

From uri at ll.mit.edu  Fri Jul  7 16:03:24 2017
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Fri, 7 Jul 2017 16:03:24 +0000
Subject: [openssl-users] OpenSSL Engine for TPM
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9A8EBF3@prvxmb03.microfocus.com>
References: <DB5PR06MB1767BE68A400BC209BF8B2C3B2D40@DB5PR06MB1767.eurprd06.prod.outlook.com>
 <700500B3-FCD8-40D6-9656-C8A9145E9108@hohnstaedt.de>
 <50c99063-6f4f-45fb-480d-0cac6c92610a@nikhef.nl>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9A8EBF3@prvxmb03.microfocus.com>
Message-ID: <5223499D-6236-4118-BB94-95EBEE46780F@ll.mit.edu>

And in most cases (except those involving TPM-based platform attestation, which I don?t think has anything to do with OpenSSL use cases),  a separate hardware token (like a smartcard, or an HSM) would IMHO be a much better and more usable choice. PKCS#11 engine (libp11) to access those is quite popular and work well.

--
Regards,
Uri Blumenthal

On 7/7/17, 11:53, "openssl-users on behalf of Michael Wojcik" <openssl-users-bounces at openssl.org on behalf of Michael.Wojcik at microfocus.com> wrote:

    > agreed, but this engine  does not really put the keys inside the TPM - instead it sets up a local repository that is encrypted
    > using a key from the TPM. If you look at the way it is designed, it is not really secure (as it's not impossible to find the 
    > password that was used to encrypt the keys with).
    
    "really secure" is not a useful phrase. Security is a set of asymptotic trade-offs between attacker and defender work-factors under a threat model. Nothing ever achieves "really secure".
    
    Even a hypothetical OpenSSL engine that performed all cryptographic operations on the TPM wouldn't achieve specified security under the TPM threat model unless the engine, all of OpenSSL, and whatever is invoking it were part of the TCB.
    
    That said, there is certainly a case to be made that an OpenSSL engine which performed at least some crypto operations on the TPM is of at least academic interest. Someone might want to start with the Trousers engine and try extending it. (Enhancing an existing engine generally isn't particularly difficult, in my experience, though of course it depends on what you're trying to do and what APIs are available.) Or try writing a fresh TPM engine using, say, the Windows TPM API.
    
    It might help to know what your use case is.
    
    Michael Wojcik 
    Distinguished Engineer, Micro Focus 
    
    
    -- 
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170707/fe3a226c/attachment.bin>

From Michael.Wojcik at microfocus.com  Fri Jul  7 16:42:28 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 7 Jul 2017 16:42:28 +0000
Subject: [openssl-users] OpenSSL Engine for TPM
In-Reply-To: <5223499D-6236-4118-BB94-95EBEE46780F@ll.mit.edu>
References: <DB5PR06MB1767BE68A400BC209BF8B2C3B2D40@DB5PR06MB1767.eurprd06.prod.outlook.com>
 <700500B3-FCD8-40D6-9656-C8A9145E9108@hohnstaedt.de>
 <50c99063-6f4f-45fb-480d-0cac6c92610a@nikhef.nl>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9A8EBF3@prvxmb03.microfocus.com>
 <5223499D-6236-4118-BB94-95EBEE46780F@ll.mit.edu>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9A8EC82@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Blumenthal, Uri - 0553 - MITLL
> Sent: Friday, July 07, 2017 10:03
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] OpenSSL Engine for TPM
> 
> And in most cases (except those involving TPM-based platform attestation,
> which I don?t think has anything to do with OpenSSL use cases),  a separate
> hardware token (like a smartcard, or an HSM) would IMHO be a much better
> and more usable choice. PKCS#11 engine (libp11) to access those is quite
> popular and work well.

Agreed. I've had good results with OpenSC-based devices such as the NitroKey HSM using the OpenSSL PKCS#11 engine. Requires installing the various prereqs and a bit of setup and experimentation, but it all works.

On Windows, the CAPI engine can also generally be used to drive HSMs, if they don't have a suitable PKCS#11 driver.

Michael Wojcik 
Distinguished Engineer, Micro Focus 

 

From freemonj at gmail.com  Fri Jul  7 17:00:39 2017
From: freemonj at gmail.com (Freemon Johnson)
Date: Fri, 7 Jul 2017 13:00:39 -0400
Subject: [openssl-users] OpenSSL Engine for TPM
In-Reply-To: <5223499D-6236-4118-BB94-95EBEE46780F@ll.mit.edu>
References: <DB5PR06MB1767BE68A400BC209BF8B2C3B2D40@DB5PR06MB1767.eurprd06.prod.outlook.com>
 <700500B3-FCD8-40D6-9656-C8A9145E9108@hohnstaedt.de>
 <50c99063-6f4f-45fb-480d-0cac6c92610a@nikhef.nl>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9A8EBF3@prvxmb03.microfocus.com>
 <5223499D-6236-4118-BB94-95EBEE46780F@ll.mit.edu>
Message-ID: <CALD4PSnk2EuY5LydZHM9+q4r9UwSu=TyBQeoWAYdBhyHrHWNRw@mail.gmail.com>

Agreed. I can't speak for the gentleman that originated this thread but in
my context the use case would be to store the keys/certs within the TPM
that's all.

Regards,
Freemon

On Fri, Jul 7, 2017 at 12:03 PM, Blumenthal, Uri - 0553 - MITLL <
uri at ll.mit.edu> wrote:

> And in most cases (except those involving TPM-based platform attestation,
> which I don?t think has anything to do with OpenSSL use cases),  a separate
> hardware token (like a smartcard, or an HSM) would IMHO be a much better
> and more usable choice. PKCS#11 engine (libp11) to access those is quite
> popular and work well.
>
> --
> Regards,
> Uri Blumenthal
>
> On 7/7/17, 11:53, "openssl-users on behalf of Michael Wojcik" <
> openssl-users-bounces at openssl.org on behalf of
> Michael.Wojcik at microfocus.com> wrote:
>
>     > agreed, but this engine  does not really put the keys inside the TPM
> - instead it sets up a local repository that is encrypted
>     > using a key from the TPM. If you look at the way it is designed, it
> is not really secure (as it's not impossible to find the
>     > password that was used to encrypt the keys with).
>
>     "really secure" is not a useful phrase. Security is a set of
> asymptotic trade-offs between attacker and defender work-factors under a
> threat model. Nothing ever achieves "really secure".
>
>     Even a hypothetical OpenSSL engine that performed all cryptographic
> operations on the TPM wouldn't achieve specified security under the TPM
> threat model unless the engine, all of OpenSSL, and whatever is invoking it
> were part of the TCB.
>
>     That said, there is certainly a case to be made that an OpenSSL engine
> which performed at least some crypto operations on the TPM is of at least
> academic interest. Someone might want to start with the Trousers engine and
> try extending it. (Enhancing an existing engine generally isn't
> particularly difficult, in my experience, though of course it depends on
> what you're trying to do and what APIs are available.) Or try writing a
> fresh TPM engine using, say, the Windows TPM API.
>
>     It might help to know what your use case is.
>
>     Michael Wojcik
>     Distinguished Engineer, Micro Focus
>
>
>     --
>     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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170707/8723baf6/attachment-0001.html>

From npathak2 at ncsu.edu  Fri Jul  7 19:38:06 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Fri, 7 Jul 2017 12:38:06 -0700
Subject: [openssl-users] Fwd:  PSK generation for TLS 1.3
In-Reply-To: <CANWFjKBcix-XDR7HfLyqGuWPx5DaF9SFx1hCS5f-OUyQuQ=1=g@mail.gmail.com>
References: <CANWFjKDtUYJ=2cia-F2BTHP5VG_pUTFswe1k03mdi7YJzWWShw@mail.gmail.com>
 <72cf97f2-f052-49c2-5969-750869d1b59e@openssl.org>
 <CANWFjKCs6F_n6+7wRobCAvQQYzkaW9oOr6OyvebmhD0LFDNBOw@mail.gmail.com>
 <88cfca68-2058-39a1-8ee1-aa4d104bf454@openssl.org>
 <CANWFjKCY1K75Z1vuQSB646iZAL5SYvZEHtQFKgBU8HMOYNjWqQ@mail.gmail.com>
 <CANWFjKBcix-XDR7HfLyqGuWPx5DaF9SFx1hCS5f-OUyQuQ=1=g@mail.gmail.com>
Message-ID: <CANWFjKDmr6jpq9V2Z9Lp20_xjXougcDiUZAK5gSeuL=vWFcGjA@mail.gmail.com>

I have a query regarding the TLS 1.3 handshake message exchange. Please
provide your comments.


With TLS 1.3, I see that Application Data Protocol message is sent from the
server side and client side (using wireshark) during the handshake. I am
only performing handshake and not doing any read write operations. I see
that servers and clients send application data protocol when doing just
SSL_connect and SSL_accept .

I also know that all the messages post server hello are encrypted in TLS
1.3. So, I am not sure what data gets exchanged
When checking logs for TLS 1.2, I do not see any exchange of Application
Data Protocol which is as expected.



Basically, connection sequence for TLS 1.2 is

*Client Hello*
*Server Hello, Certificate, Server Key Exchange, Certificate Request,
Server Hello Done*
*Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec,
Encrypted Handshake Message (Finished)*
*Change Cipher Spec, Encrypted Handshake Message (Finished)*



but for TLS 1.3, it is
The same is the sequence of messages exchanged when doing a connection
using resumption. I am not sure what application data gets exchanged when
doing TLS 1.3 when I am not doing any read/writes.
>From RFC, I can see that Application Data can be optionally sent at the end
of server Hello but I am not sure what data it is. How can I decrypt the
exchanged data ?
*Client Hello*
*Server Hello, Application Data Protocol from Server*
*Application Data Protocol from Client*
*Application Data Protocol from Server*
*Application Data Protocol from Client*


Also, I observe that resumption connection time for TLS 1.3 using PSK  is
more than resumption time for TLS 1.2 (by 700-800 microseconds). I am
suspecting the exchange of application data and its processing etc
(encryption) is causing the added delay. Could someone please provide any
explanation or point me in the right direction. It is not very clear to me
right now even after seeing the RFC

Thanks




On Thu, Jul 6, 2017 at 11:40 AM, Neetish Pathak <npathak2 at ncsu.edu> wrote:

> Thanks for the detailed explanation Matt
>
> On Tue, Jul 4, 2017 at 1:51 AM, Matt Caswell <matt at openssl.org> wrote:
>
>>
>>
>> On 03/07/17 22:24, Neetish Pathak wrote:
>>
>> > Thanks Matt. This is quite useful.
>> > Just to clarify my understanding based on your comments, OpenSSL code
>> >  and Draft for TLS 1.3/RFC for TLS1.2, please help me with following
>> queries
>> >
>> > 1) So, when using external PSK (by creating the new session file),
>> > client should mandatorily use SSL_CTX_set_psk_use_session_callback
>> while
>> > server should mandatorily use SSL_CTX_set_psk_find_session_casllback.
>> > They both should use a common key (psk_key) to generate the new session
>> > file and this common key is the one shared in advance to both client and
>> > server.
>>
>> Yes, that is correct. If both client and server are OpenSSL then,
>> optionally, they can just share a session file (which contains the key)
>> if that is easier.
>>
>> > From the OpenSSL code, this key is used as char * type. So does
>> > it mean that any pre-decided string can be used as a key and it does not
>> > need any format etc.
>>
>> To me "string" implies NUL terminated printable string. Maybe that's not
>> what you meant. Anyway in that sense "string" is not quite correct. The
>> key is binary data which should be the same length as the hash used for
>> the ciphersuite.
>>
>>
>> > Both client and server create sessions based on the
>> > key and connect based on the created session?
>> > In one of the examples, *strspn*(psk_key, "abcdefABCDEF1234567890") is
>> > used. So, I believe I can use any hex value string of my choice as
>> psk_key.
>>
>> Like I said above - the key is *binary* data. It does not have to be a
>> printable string.
>>
>>
>> > 2) Also, from the man page , I found that PSK are used in TLS1.2 and
>> > lower versions too and SSL_CTX_set_psk_server_callback
>> > and SSL_CTX_set_psk_client_callback are used to set callback there. PSK
>> >  identity and Pre shared key is set there which can be used during the
>> > connection. It is also written that these values are required when using
>> > PSK cipher-suites. So, is my understanding correct that the role of PSK
>> > in version <= TLS1.2 is only for using PSK ciphersuites
>> > (e.g: ECDHE-PSK-AES256-CBC-SHA384)
>>
>> Correct.
>>
>> > and do not have anything to do with
>> > session resumption and thereby do not provide any performance
>> enhancement.
>>
>> They do not have anything to do with session resumption, so you don't
>> see the reduced number of message flights that you get with a resumed
>> handshake. However, PSK ciphersuites in <= TLS1.2 avoid the need to send
>> (and therefore process/validate) Certificate messages which may have
>> performance benefits. If the ciphersuite in use just uses "plain" PSK
>> (i.e. no (EC)DHE or RSA) then a connection can be established without
>> using public-key operations which may also have performance benefits (at
>> the expense of forward secrecy).
>>
>> > Also, this PSK type ciphersuites are no longer valid for TLS 1.3.
>>
>> Correct.
>>
>>
>> Matt
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170707/8e8d83e5/attachment.html>

From raymi.coevan at gmail.com  Sat Jul  8 09:19:57 2017
From: raymi.coevan at gmail.com (Raymi Coevan)
Date: Sat, 8 Jul 2017 11:19:57 +0200
Subject: [openssl-users] MSVC Compiling OpenSSL on Windows 64 issues with
	missing libs
Message-ID: <CANFqjkLsqy_2z7TvZhap+8xBvx8VKBnmkNuq0KY6iJ8m3f+DPw@mail.gmail.com>

Dear OpenSSL experts,

I'm a junior developer so please forgive me if this is a stupid question.

I'm trying to port an existing application, currently running on MacOSX and
Linux, to Windows 64 bits platform which is not my favorite environment.

I have dependencies on Poco and OpenSSL (1.1.0e is currently used on MacOSX
and Linux), and when trying to compile using MSVC2015, I get and link error
telling that libeaymt64.lib and ssleaymt64.lib are missing. I tried to find
where these dependencies are defined (pragma or linkage definitions) but
did not find. These libraries do not look to exist since I cannot find them
on MacOSX and Linux either.

I have installed OpenSSL environment and tried using precompiled libs and
headers from http://slproweb.com/download/Win64OpenSSL-1_1_0f.exe

Googling on these libs, I find they might be included in OpenSSL 1.0.2g,
however I'm not able able to find them in application's required OpenSSL
release (1.1.x).

I'm sure I'm missing some points but cannot figure out what after hours of
search.

Can someone please help me?

Thanks in advance

KR

Raymi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170708/71739c4b/attachment-0001.html>

From levitte at openssl.org  Sat Jul  8 10:01:31 2017
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 08 Jul 2017 12:01:31 +0200 (CEST)
Subject: [openssl-users] MSVC Compiling OpenSSL on Windows 64 issues
 with missing libs
In-Reply-To: <CANFqjkLsqy_2z7TvZhap+8xBvx8VKBnmkNuq0KY6iJ8m3f+DPw@mail.gmail.com>
References: <CANFqjkLsqy_2z7TvZhap+8xBvx8VKBnmkNuq0KY6iJ8m3f+DPw@mail.gmail.com>
Message-ID: <20170708.120131.951807487781691574.levitte@openssl.org>

Hi,

In message <CANFqjkLsqy_2z7TvZhap+8xBvx8VKBnmkNuq0KY6iJ8m3f+DPw at mail.gmail.com> on Sat, 8 Jul 2017 11:19:57 +0200, Raymi Coevan <raymi.coevan at gmail.com> said:

...
raymi.coevan> I have dependencies on Poco and OpenSSL (1.1.0e is currently used on
raymi.coevan> MacOSX and Linux), and when trying to compile using MSVC2015, I get
raymi.coevan> and link error telling that libeaymt64.lib and ssleaymt64.lib are
raymi.coevan> missing. I tried to find where these dependencies are defined (pragma
raymi.coevan> or linkage definitions) but did not find. These libraries do not look
raymi.coevan> to exist since I cannot find them on MacOSX and Linux either.

Yes, the libraries have changed name for 1.1.0, with names that are
more in line with the Linux / MacOS X names.

raymi.coevan> I have installed OpenSSL environment and tried using precompiled libs
raymi.coevan> and headers from http://slproweb.com/download/Win64OpenSSL-1_1_0f.exe

I tried that one with standard installation location
(c:/OpenSSL-Win64), and here's what I found (looking for *.lib) that's
relevant:

    c:/OpenSSL-Win64/lib/VC/libcrypto64MDd.lib
    c:/OpenSSL-Win64/lib/VC/libssl64MDd.lib
    c:/OpenSSL-Win64/lib/VC/libcrypto64MD.lib
    c:/OpenSSL-Win64/lib/VC/libssl64MD.lib
    c:/OpenSSL-Win64/lib/VC/libcrypto64MTd.lib
    c:/OpenSSL-Win64/lib/VC/libcrypto64MT.lib
    c:/OpenSSL-Win64/lib/VC/libssl64MTd.lib
    c:/OpenSSL-Win64/lib/VC/libssl64MT.lib
    c:/OpenSSL-Win64/lib/VC/static/libcrypto64MDd.lib
    c:/OpenSSL-Win64/lib/VC/static/libssl64MDd.lib
    c:/OpenSSL-Win64/lib/VC/static/libcrypto64MD.lib
    c:/OpenSSL-Win64/lib/VC/static/libssl64MD.lib
    c:/OpenSSL-Win64/lib/VC/static/libcrypto64MTd.lib
    c:/OpenSSL-Win64/lib/VC/static/libcrypto64MT.lib
    c:/OpenSSL-Win64/lib/VC/static/libssl64MTd.lib
    c:/OpenSSL-Win64/lib/VC/static/libssl64MT.lib

>From those, I guess you need to change your dependencies to be
libcrypto64MT.lib instead of libeaymt64.lib, and libssl64MT.lib
instead of ssleaymt64.lib.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From raymi.coevan at gmail.com  Sat Jul  8 10:20:40 2017
From: raymi.coevan at gmail.com (Raymi Coevan)
Date: Sat, 8 Jul 2017 12:20:40 +0200
Subject: [openssl-users] MSVC Compiling OpenSSL on Windows 64 issues
 with missing libs
In-Reply-To: <20170708.120131.951807487781691574.levitte@openssl.org>
References: <CANFqjkLsqy_2z7TvZhap+8xBvx8VKBnmkNuq0KY6iJ8m3f+DPw@mail.gmail.com>
 <20170708.120131.951807487781691574.levitte@openssl.org>
Message-ID: <CANFqjkL_Gwc5cFrwHK_5e4bR9kTBQcJqfodh47W_3XJEZNpLaQ@mail.gmail.com>

Hi,

Indeed, the list you mentioned is exactly the one I have in my environment.
In my MSVC project, I only statically link with libcrypto64MT.lib and
libssl64MT.lib. No reference is made to libeaymt64.lib or libssl64MT.lib,
from what I know at least. So I don't understand why I got these link
errors...

KR
Raymi



On Sat, Jul 8, 2017 at 12:01 PM, Richard Levitte <levitte at openssl.org>
wrote:

> Hi,
>
> In message <CANFqjkLsqy_2z7TvZhap+8xBvx8VKBnmkNuq0KY6iJ8m3f+DPw@
> mail.gmail.com> on Sat, 8 Jul 2017 11:19:57 +0200, Raymi Coevan <
> raymi.coevan at gmail.com> said:
>
> ...
> raymi.coevan> I have dependencies on Poco and OpenSSL (1.1.0e is currently
> used on
> raymi.coevan> MacOSX and Linux), and when trying to compile using
> MSVC2015, I get
> raymi.coevan> and link error telling that libeaymt64.lib and
> ssleaymt64.lib are
> raymi.coevan> missing. I tried to find where these dependencies are
> defined (pragma
> raymi.coevan> or linkage definitions) but did not find. These libraries do
> not look
> raymi.coevan> to exist since I cannot find them on MacOSX and Linux either.
>
> Yes, the libraries have changed name for 1.1.0, with names that are
> more in line with the Linux / MacOS X names.
>
> raymi.coevan> I have installed OpenSSL environment and tried using
> precompiled libs
> raymi.coevan> and headers from http://slproweb.com/download/
> Win64OpenSSL-1_1_0f.exe
>
> I tried that one with standard installation location
> (c:/OpenSSL-Win64), and here's what I found (looking for *.lib) that's
> relevant:
>
>     c:/OpenSSL-Win64/lib/VC/libcrypto64MDd.lib
>     c:/OpenSSL-Win64/lib/VC/libssl64MDd.lib
>     c:/OpenSSL-Win64/lib/VC/libcrypto64MD.lib
>     c:/OpenSSL-Win64/lib/VC/libssl64MD.lib
>     c:/OpenSSL-Win64/lib/VC/libcrypto64MTd.lib
>     c:/OpenSSL-Win64/lib/VC/libcrypto64MT.lib
>     c:/OpenSSL-Win64/lib/VC/libssl64MTd.lib
>     c:/OpenSSL-Win64/lib/VC/libssl64MT.lib
>     c:/OpenSSL-Win64/lib/VC/static/libcrypto64MDd.lib
>     c:/OpenSSL-Win64/lib/VC/static/libssl64MDd.lib
>     c:/OpenSSL-Win64/lib/VC/static/libcrypto64MD.lib
>     c:/OpenSSL-Win64/lib/VC/static/libssl64MD.lib
>     c:/OpenSSL-Win64/lib/VC/static/libcrypto64MTd.lib
>     c:/OpenSSL-Win64/lib/VC/static/libcrypto64MT.lib
>     c:/OpenSSL-Win64/lib/VC/static/libssl64MTd.lib
>     c:/OpenSSL-Win64/lib/VC/static/libssl64MT.lib
>
> From those, I guess you need to change your dependencies to be
> libcrypto64MT.lib instead of libeaymt64.lib, and libssl64MT.lib
> instead of ssleaymt64.lib.
>
> Cheers,
> Richard
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170708/bb4380e8/attachment.html>

From matt at openssl.org  Sat Jul  8 10:28:18 2017
From: matt at openssl.org (Matt Caswell)
Date: Sat, 8 Jul 2017 11:28:18 +0100
Subject: [openssl-users] PSK generation for TLS 1.3
In-Reply-To: <CANWFjKBcix-XDR7HfLyqGuWPx5DaF9SFx1hCS5f-OUyQuQ=1=g@mail.gmail.com>
References: <CANWFjKDtUYJ=2cia-F2BTHP5VG_pUTFswe1k03mdi7YJzWWShw@mail.gmail.com>
 <72cf97f2-f052-49c2-5969-750869d1b59e@openssl.org>
 <CANWFjKCs6F_n6+7wRobCAvQQYzkaW9oOr6OyvebmhD0LFDNBOw@mail.gmail.com>
 <88cfca68-2058-39a1-8ee1-aa4d104bf454@openssl.org>
 <CANWFjKCY1K75Z1vuQSB646iZAL5SYvZEHtQFKgBU8HMOYNjWqQ@mail.gmail.com>
 <CANWFjKBcix-XDR7HfLyqGuWPx5DaF9SFx1hCS5f-OUyQuQ=1=g@mail.gmail.com>
Message-ID: <2c2c71e1-dd7c-7079-f7cd-ee079b201d87@openssl.org>



On 07/07/17 20:14, Neetish Pathak wrote:
> I have a query regarding the TLS 1.3 handshake message exchange. Please
> provide your comments.
> 
> 
> With TLS 1.3, I see that Application Data Protocol message is sent from
> the server side and client side (using wireshark) during the handshake.
> I am only performing handshake and not doing any read write operations.
> I see that servers and clients send application data protocol when doing
> just SSL_connect and SSL_accept .
> 
> I also know that all the messages post server hello are encrypted in TLS
> 1.3. So, I am not sure what data gets exchanged
> When checking logs for TLS 1.2, I do not see any exchange of Application
> Data Protocol which is as expected.

You would probably benefit from reading the TLSv1.3 draft to give you a
better picture of how TLSv1.3 is implemented.

As you say everything in TLSv1.3 after the ServerHello is encrypted.
Additionally the "real" content type of the record is held "inside" the
encrypted payload. The "outer" content type that TLSv1.2 and below used
is still present but is always set to "Application Data" regardless of
what the real inner content type is. What you are seeing as application
data being exchanged is really just handshake messages.

Matt



> 
> I am also attaching wireshark logs for TLS 1.2 and TLS 1.3 connections.
> 
> Basically, connection sequence for TLS 1.2 is 
> 
> *Client Hello*
> *Server Hello, Certificate, Server Key Exchange, Certificate Request,
> Server Hello Done*
> *Certificate, Client Key Exchange, Certificate Verify, Change Cipher
> Spec, Encrypted Handshake Message (Finished)*
> *Change Cipher Spec, Encrypted Handshake Message (Finished)*
> 
> 
> 
> but for TLS 1.3, it is 
> The same is the sequence of messages exchanged when doing a connection
> using resumption. I am not sure what application data gets exchanged
> when doing TLS 1.3 when I am not doing any read/writes.
> From RFC, I can see that Application Data can be optionally sent at the
> end of server Hello but I am not sure what data it is. How can I decrypt
> the exchanged data ?
> *Client Hello*
> *Server Hello, Application Data Protocol from Server*
> *Application Data Protocol from Client*
> *Application Data Protocol from Server*
> *Application Data Protocol from Client*
> 
> 
> Also, I observe that resumption connection time for TLS 1.3 using PSK
>  is more than resumption time for TLS 1.2 (by 700-800 microseconds). I
> am suspecting the exchange of application data and its processing etc
> (encryption) is causing the added delay. Could someone please provide
> any explanation or point me in the right direction. It is not very clear
> to me right now even after seeing the RFC
> 
> Thanks
> 
> 
> 
> 
> On Thu, Jul 6, 2017 at 11:40 AM, Neetish Pathak <npathak2 at ncsu.edu
> <mailto:npathak2 at ncsu.edu>> wrote:
> 
>     Thanks for the detailed explanation Matt
> 
>     On Tue, Jul 4, 2017 at 1:51 AM, Matt Caswell <matt at openssl.org
>     <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>         On 03/07/17 22:24, Neetish Pathak wrote:
> 
>         > Thanks Matt. This is quite useful.
>         > Just to clarify my understanding based on your comments, OpenSSL code
>         >  and Draft for TLS 1.3/RFC for TLS1.2, please help me with following queries
>         >
>         > 1) So, when using external PSK (by creating the new session file),
>         > client should mandatorily use SSL_CTX_set_psk_use_session_callback while
>         > server should mandatorily use
>         SSL_CTX_set_psk_find_session_casllback.
>         > They both should use a common key (psk_key) to generate the new session
>         > file and this common key is the one shared in advance to both client and
>         > server.
> 
>         Yes, that is correct. If both client and server are OpenSSL then,
>         optionally, they can just share a session file (which contains
>         the key)
>         if that is easier.
> 
>         > From the OpenSSL code, this key is used as char * type. So does
>         > it mean that any pre-decided string can be used as a key and it does not
>         > need any format etc.
> 
>         To me "string" implies NUL terminated printable string. Maybe
>         that's not
>         what you meant. Anyway in that sense "string" is not quite
>         correct. The
>         key is binary data which should be the same length as the hash
>         used for
>         the ciphersuite.
> 
> 
>         > Both client and server create sessions based on the
>         > key and connect based on the created session?
>         > In one of the examples, *strspn*(psk_key,
>         "abcdefABCDEF1234567890") is
>         > used. So, I believe I can use any hex value string of my choice as psk_key.
> 
>         Like I said above - the key is *binary* data. It does not have
>         to be a
>         printable string.
> 
> 
>         > 2) Also, from the man page , I found that PSK are used in TLS1.2 and
>         > lower versions too and SSL_CTX_set_psk_server_callback
>         > and SSL_CTX_set_psk_client_callback are used to set callback there. PSK
>         >  identity and Pre shared key is set there which can be used during the
>         > connection. It is also written that these values are required when using
>         > PSK cipher-suites. So, is my understanding correct that the role of PSK
>         > in version <= TLS1.2 is only for using PSK ciphersuites
>         > (e.g: ECDHE-PSK-AES256-CBC-SHA384)
> 
>         Correct.
> 
>         > and do not have anything to do with
>         > session resumption and thereby do not provide any performance enhancement.
> 
>         They do not have anything to do with session resumption, so you
>         don't
>         see the reduced number of message flights that you get with a
>         resumed
>         handshake. However, PSK ciphersuites in <= TLS1.2 avoid the need
>         to send
>         (and therefore process/validate) Certificate messages which may have
>         performance benefits. If the ciphersuite in use just uses
>         "plain" PSK
>         (i.e. no (EC)DHE or RSA) then a connection can be established
>         without
>         using public-key operations which may also have performance
>         benefits (at
>         the expense of forward secrecy).
> 
>         > Also, this PSK type ciphersuites are no longer valid for TLS 1.3.
> 
>         Correct.
> 
> 
>         Matt
>         --
>         openssl-users mailing list
>         To unsubscribe:
>         https://mta.openssl.org/mailman/listinfo/openssl-users
>         <https://mta.openssl.org/mailman/listinfo/openssl-users>
> 
> 
> 

From raymi.coevan at gmail.com  Sat Jul  8 10:29:31 2017
From: raymi.coevan at gmail.com (Raymi Coevan)
Date: Sat, 8 Jul 2017 12:29:31 +0200
Subject: [openssl-users] MSVC Compiling OpenSSL on Windows 64 issues
 with missing libs
In-Reply-To: <CANFqjkL_Gwc5cFrwHK_5e4bR9kTBQcJqfodh47W_3XJEZNpLaQ@mail.gmail.com>
References: <CANFqjkLsqy_2z7TvZhap+8xBvx8VKBnmkNuq0KY6iJ8m3f+DPw@mail.gmail.com>
 <20170708.120131.951807487781691574.levitte@openssl.org>
 <CANFqjkL_Gwc5cFrwHK_5e4bR9kTBQcJqfodh47W_3XJEZNpLaQ@mail.gmail.com>
Message-ID: <CANFqjkLN5DHq7uOTuxYgCCVLv9==WQLO=3j8JJM9QW2p41012Q@mail.gmail.com>

Sorry, I meant no reference to libeaymt64.lib or ssleaymt64.lib

On Sat, Jul 8, 2017 at 12:20 PM, Raymi Coevan <raymi.coevan at gmail.com>
wrote:

> Hi,
>
> Indeed, the list you mentioned is exactly the one I have in my
> environment. In my MSVC project, I only statically link with
> libcrypto64MT.lib and libssl64MT.lib. No reference is made to
> libeaymt64.lib or libssl64MT.lib, from what I know at least. So I don't
> understand why I got these link errors...
>
> KR
> Raymi
>
>
>
> On Sat, Jul 8, 2017 at 12:01 PM, Richard Levitte <levitte at openssl.org>
> wrote:
>
>> Hi,
>>
>> In message <CANFqjkLsqy_2z7TvZhap+8xBvx8VKBnmkNuq0KY6iJ8m3f+DPw at mail.
>> gmail.com> on Sat, 8 Jul 2017 11:19:57 +0200, Raymi Coevan <
>> raymi.coevan at gmail.com> said:
>>
>> ...
>> raymi.coevan> I have dependencies on Poco and OpenSSL (1.1.0e is
>> currently used on
>> raymi.coevan> MacOSX and Linux), and when trying to compile using
>> MSVC2015, I get
>> raymi.coevan> and link error telling that libeaymt64.lib and
>> ssleaymt64.lib are
>> raymi.coevan> missing. I tried to find where these dependencies are
>> defined (pragma
>> raymi.coevan> or linkage definitions) but did not find. These libraries
>> do not look
>> raymi.coevan> to exist since I cannot find them on MacOSX and Linux
>> either.
>>
>> Yes, the libraries have changed name for 1.1.0, with names that are
>> more in line with the Linux / MacOS X names.
>>
>> raymi.coevan> I have installed OpenSSL environment and tried using
>> precompiled libs
>> raymi.coevan> and headers from http://slproweb.com/download/W
>> in64OpenSSL-1_1_0f.exe
>>
>> I tried that one with standard installation location
>> (c:/OpenSSL-Win64), and here's what I found (looking for *.lib) that's
>> relevant:
>>
>>     c:/OpenSSL-Win64/lib/VC/libcrypto64MDd.lib
>>     c:/OpenSSL-Win64/lib/VC/libssl64MDd.lib
>>     c:/OpenSSL-Win64/lib/VC/libcrypto64MD.lib
>>     c:/OpenSSL-Win64/lib/VC/libssl64MD.lib
>>     c:/OpenSSL-Win64/lib/VC/libcrypto64MTd.lib
>>     c:/OpenSSL-Win64/lib/VC/libcrypto64MT.lib
>>     c:/OpenSSL-Win64/lib/VC/libssl64MTd.lib
>>     c:/OpenSSL-Win64/lib/VC/libssl64MT.lib
>>     c:/OpenSSL-Win64/lib/VC/static/libcrypto64MDd.lib
>>     c:/OpenSSL-Win64/lib/VC/static/libssl64MDd.lib
>>     c:/OpenSSL-Win64/lib/VC/static/libcrypto64MD.lib
>>     c:/OpenSSL-Win64/lib/VC/static/libssl64MD.lib
>>     c:/OpenSSL-Win64/lib/VC/static/libcrypto64MTd.lib
>>     c:/OpenSSL-Win64/lib/VC/static/libcrypto64MT.lib
>>     c:/OpenSSL-Win64/lib/VC/static/libssl64MTd.lib
>>     c:/OpenSSL-Win64/lib/VC/static/libssl64MT.lib
>>
>> From those, I guess you need to change your dependencies to be
>> libcrypto64MT.lib instead of libeaymt64.lib, and libssl64MT.lib
>> instead of ssleaymt64.lib.
>>
>> Cheers,
>> Richard
>>
>> --
>> Richard Levitte         levitte at openssl.org
>> OpenSSL Project         http://www.openssl.org/~levitte/
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170708/c41ec8e0/attachment-0001.html>

From levitte at openssl.org  Sat Jul  8 10:34:48 2017
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 08 Jul 2017 12:34:48 +0200 (CEST)
Subject: [openssl-users] MSVC Compiling OpenSSL on Windows 64 issues
 with missing libs
In-Reply-To: <CANFqjkLN5DHq7uOTuxYgCCVLv9==WQLO=3j8JJM9QW2p41012Q@mail.gmail.com>
References: <20170708.120131.951807487781691574.levitte@openssl.org>
 <CANFqjkL_Gwc5cFrwHK_5e4bR9kTBQcJqfodh47W_3XJEZNpLaQ@mail.gmail.com>
 <CANFqjkLN5DHq7uOTuxYgCCVLv9==WQLO=3j8JJM9QW2p41012Q@mail.gmail.com>
Message-ID: <20170708.123448.2057989853453036308.levitte@openssl.org>

In message <CANFqjkLN5DHq7uOTuxYgCCVLv9==WQLO=3j8JJM9QW2p41012Q at mail.gmail.com> on Sat, 8 Jul 2017 12:29:31 +0200, Raymi Coevan <raymi.coevan at gmail.com> said:

raymi.coevan> Sorry, I meant no reference to libeaymt64.lib or ssleaymt64.lib
raymi.coevan> 
raymi.coevan> On Sat, Jul 8, 2017 at 12:20 PM, Raymi Coevan <raymi.coevan at gmail.com>
raymi.coevan> wrote:
...
raymi.coevan> 
raymi.coevan>     Indeed, the list you mentioned is exactly the one I have in my
raymi.coevan>     environment. In my MSVC project, I only statically link with
raymi.coevan>     libcrypto64MT.lib and libssl64MT.lib. No reference is made to
raymi.coevan>     libeaymt64.lib or libssl64MT.lib, from what I know at least. So I
raymi.coevan>     don't understand why I got these link errors...

Can't help you there, sorry.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From matthias.ballreich at outlook.de  Sat Jul  8 23:31:00 2017
From: matthias.ballreich at outlook.de (Matthias Ballreich)
Date: Sat, 8 Jul 2017 23:31:00 +0000
Subject: [openssl-users] OpenSSL 1.1.0 providing new OIDs to source code
Message-ID: <AM5P195MB018008B87ACD89D37B629CF3FBAB0@AM5P195MB0180.EURP195.PROD.OUTLOOK.COM>

Hi there,

i want to contribute some more OIDs. Therefore i added the OIDs inside the ?Objects.txt? inside /crypto/objects

Then i run these commands:
perl objects.pl objects.txt obj_mac.num ../../include/openssl/obj_mac.h
perl obj_dat.pl ../../include/openssl/obj_mac.h obj_dat.h
perl objxref.pl obj_mac.num obj_xref.txt > obj_xref.h

The files are generated / updated. Then i build the source which builds fine without any exceptions. Then i tried to use the generated NIDs in my Code. For test purposes i tried to print out the short and Long Name of my new oid with OBJ_nid2sn(MY_NID) and OBJ_nid2(MY_NID). But here it prints out an empty string.

When o try to use my NID with X509_get_ext_by_NID(cert, MY_NID, -1) the Output is -2.

So where is the Problem or what i?m doing wrong here? Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170708/701ac3dc/attachment.html>

From bbrumley at gmail.com  Sun Jul  9 06:39:34 2017
From: bbrumley at gmail.com (Billy Brumley)
Date: Sun, 9 Jul 2017 09:39:34 +0300
Subject: [openssl-users] OpenSSL 1.1.0 providing new OIDs to source code
In-Reply-To: <AM5P195MB018008B87ACD89D37B629CF3FBAB0@AM5P195MB0180.EURP195.PROD.OUTLOOK.COM>
References: <AM5P195MB018008B87ACD89D37B629CF3FBAB0@AM5P195MB0180.EURP195.PROD.OUTLOOK.COM>
Message-ID: <CAFeDd5ZU8FXYtDcVZGcCsP+G0pwNG9TbQyqEu18M6pEcuUOtfA@mail.gmail.com>

> i want to contribute some more OIDs. Therefore i added the OIDs inside the
> ?Objects.txt? inside /crypto/objects
>
>
>
> Then i run these commands:
>
> perl objects.pl objects.txt obj_mac.num ../../include/openssl/obj_mac.h
>
> perl obj_dat.pl ../../include/openssl/obj_mac.h obj_dat.h
>
> perl objxref.pl obj_mac.num obj_xref.txt > obj_xref.h

Try 'make update' instead.

BBB

From Matthias.Ballreich at outlook.de  Sun Jul  9 09:15:47 2017
From: Matthias.Ballreich at outlook.de (Matthias Ballreich)
Date: Sun, 9 Jul 2017 09:15:47 +0000
Subject: [openssl-users] OpenSSL 1.1.0 providing new OIDs to source code
In-Reply-To: <CAFeDd5ZU8FXYtDcVZGcCsP+G0pwNG9TbQyqEu18M6pEcuUOtfA@mail.gmail.com>
References: <AM5P195MB018008B87ACD89D37B629CF3FBAB0@AM5P195MB0180.EURP195.PROD.OUTLOOK.COM>,
 <CAFeDd5ZU8FXYtDcVZGcCsP+G0pwNG9TbQyqEu18M6pEcuUOtfA@mail.gmail.com>
Message-ID: <DB6P195MB018278A38A28FE88A9319A28FBA80@DB6P195MB0182.EURP195.PROD.OUTLOOK.COM>

Thanks. I tried it but i got the error Message that make update is not available.

I am Building it on windows with nmake under the visual Studio Developer Shell. Why is nmake Update Not working there?

Am 09.07.2017 um 08:40 schrieb Billy Brumley <bbrumley at gmail.com>:

>> i want to contribute some more OIDs. Therefore i added the OIDs inside the
>> ?Objects.txt? inside /crypto/objects
>> 
>> 
>> 
>> Then i run these commands:
>> 
>> perl objects.pl objects.txt obj_mac.num ../../include/openssl/obj_mac.h
>> 
>> perl obj_dat.pl ../../include/openssl/obj_mac.h obj_dat.h
>> 
>> perl objxref.pl obj_mac.num obj_xref.txt > obj_xref.h
> 
> Try 'make update' instead.
> 
> BBB
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From sravani.maddukuri at broadcom.com  Mon Jul 10 03:31:08 2017
From: sravani.maddukuri at broadcom.com (Sravani Maddukuri)
Date: Mon, 10 Jul 2017 09:01:08 +0530
Subject: [openssl-users] Openssl 1.1.0f support for building
	Openssh7.2p2 and above
In-Reply-To: <CADhPa=zkitZZN42gxn9RnrkLjZYozMxaSCbgUFDvt46exjqAww@mail.gmail.com>
References: <CADhPa=zkitZZN42gxn9RnrkLjZYozMxaSCbgUFDvt46exjqAww@mail.gmail.com>
Message-ID: <CADhPa=ywtnLGOEbO4uD_6HtVjXoVVcKJKWeoHyixxtx80zjFvQ@mail.gmail.com>

Dear Concern,

Can you please update me on my below query?

Does openssl 1.1.0f version support building Openssh7.2p2 and
above versions?

Regards,
Sravani

On Fri, Jul 7, 2017 at 2:33 PM, Sravani Maddukuri <
sravani.maddukuri at broadcom.com> wrote:

> Dear Concern,
>
> I am using openssh 7.2p2 version ported to use along with my software.
> After upgrading openssl to 1.1.0f, I am getting compilation errors in the
> openssh code.
>
> Does openssl 1.1.0f version support building Openssh7.2p2 and
> above versions?
>
> Regards,
> Sravani
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170710/5431dc7d/attachment-0001.html>

From noloader at gmail.com  Mon Jul 10 03:48:41 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 9 Jul 2017 23:48:41 -0400
Subject: [openssl-users] Openssl 1.1.0f support for building
 Openssh7.2p2 and above
In-Reply-To: <CADhPa=ywtnLGOEbO4uD_6HtVjXoVVcKJKWeoHyixxtx80zjFvQ@mail.gmail.com>
References: <CADhPa=zkitZZN42gxn9RnrkLjZYozMxaSCbgUFDvt46exjqAww@mail.gmail.com>
 <CADhPa=ywtnLGOEbO4uD_6HtVjXoVVcKJKWeoHyixxtx80zjFvQ@mail.gmail.com>
Message-ID: <CAH8yC8mGy035WPK952fzJ0y4Lv9FBDnCMwJAcOjCqugZDEv8UA@mail.gmail.com>

On Sun, Jul 9, 2017 at 11:31 PM, Sravani Maddukuri via openssl-users
<openssl-users at openssl.org> wrote:
> Dear Concern,
>
> Can you please update me on my below query?
>
> Does openssl 1.1.0f version support building Openssh7.2p2 and above
> versions?

As far as I know, OpenSSH does not support OpenSSL 1.1.0. Kurt Roeckx
provided the initial port and offered the patches to OpenSSH, but they
were never merged.

Also see http://github.com/openssh/openssh-portable/pull/48 and
https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#OpenSSH.

Jeff

From levitte at openssl.org  Mon Jul 10 04:13:30 2017
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 10 Jul 2017 06:13:30 +0200 (CEST)
Subject: [openssl-users] OpenSSL 1.1.0 providing new OIDs to source code
In-Reply-To: <AM5P195MB018008B87ACD89D37B629CF3FBAB0@AM5P195MB0180.EURP195.PROD.OUTLOOK.COM>
References: <AM5P195MB018008B87ACD89D37B629CF3FBAB0@AM5P195MB0180.EURP195.PROD.OUTLOOK.COM>
Message-ID: <20170710.061330.1471247083034095972.levitte@openssl.org>

In message <AM5P195MB018008B87ACD89D37B629CF3FBAB0 at AM5P195MB0180.EURP195.PROD.OUTLOOK.COM> on Sat, 8 Jul 2017 23:31:00 +0000, Matthias Ballreich <matthias.ballreich at outlook.de> said:

matthias.ballreich> Hi there,
matthias.ballreich> 
matthias.ballreich> i want to contribute some more OIDs. Therefore i added the OIDs inside
matthias.ballreich> the ?Objects.txt? inside /crypto/objects
matthias.ballreich> 
matthias.ballreich> Then i run these commands:
matthias.ballreich> 
matthias.ballreich> perl objects.pl objects.txt obj_mac.num .
matthias.ballreich> ./../include/openssl/obj_mac.h
matthias.ballreich> 
matthias.ballreich> perl obj_dat.pl ../../include/openssl/obj_mac.h obj_dat.h
matthias.ballreich> 
matthias.ballreich> perl objxref.pl obj_mac.num obj_xref.txt > obj_xref.h

Sure, that looks fine to me

matthias.ballreich> The files are generated / updated. Then i build the source which
matthias.ballreich> builds fine without any exceptions. Then i tried to use the generated
matthias.ballreich> NIDs in my Code. For test purposes i tried to print out the short and
matthias.ballreich> Long Name of my new oid with OBJ_nid2sn(MY_NID) and OBJ_nid2(MY_NID).
matthias.ballreich> But here it prints out an empty string.
matthias.ballreich> 
matthias.ballreich> When o try to use my NID with X509_get_ext_by_NID(cert, MY_NID, -1)
matthias.ballreich> the Output is -2.
matthias.ballreich> 
matthias.ballreich> So where is the Problem or what i?m doing wrong here? Thanks!

If you've come that far, MY_NID (which I assume is really
NID_whatever) obviously exists, or your code wouldn't even have
compiled.  One possibility remains, that for some reason, libcrypto
hasn't been initialised like it should.  This can happen if you only
call a very select set of OpenSSL functions.  What happens if you add
this at the start of your main()?

    OPENSSL_init_crypto(0, NULL);

(note, that should be seen as a temporary measure, as this is called
internally in quite a number of spots, so for larger uses of OpenSSL
functionality, you shouldn't need that)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From sravani.maddukuri at broadcom.com  Mon Jul 10 06:01:56 2017
From: sravani.maddukuri at broadcom.com (Sravani Maddukuri)
Date: Mon, 10 Jul 2017 11:31:56 +0530
Subject: [openssl-users] Openssl 1.1.0f support for building
 Openssh7.2p2 and above
In-Reply-To: <CAH8yC8mGy035WPK952fzJ0y4Lv9FBDnCMwJAcOjCqugZDEv8UA@mail.gmail.com>
References: <CADhPa=zkitZZN42gxn9RnrkLjZYozMxaSCbgUFDvt46exjqAww@mail.gmail.com>
 <CADhPa=ywtnLGOEbO4uD_6HtVjXoVVcKJKWeoHyixxtx80zjFvQ@mail.gmail.com>
 <CAH8yC8mGy035WPK952fzJ0y4Lv9FBDnCMwJAcOjCqugZDEv8UA@mail.gmail.com>
Message-ID: <CADhPa=wUBc7AJYw0hu1_u8Xazn-UGu_J2=78bVBRAXTAPshvRA@mail.gmail.com>

Thanks for the update Jeff.

Is there any plans in the future to get the support of OpenSSL 1.1.0 for
OpenSSH?

Regards,
Sravani

On Mon, Jul 10, 2017 at 9:18 AM, Jeffrey Walton <noloader at gmail.com> wrote:

> On Sun, Jul 9, 2017 at 11:31 PM, Sravani Maddukuri via openssl-users
> <openssl-users at openssl.org> wrote:
> > Dear Concern,
> >
> > Can you please update me on my below query?
> >
> > Does openssl 1.1.0f version support building Openssh7.2p2 and above
> > versions?
>
> As far as I know, OpenSSH does not support OpenSSL 1.1.0. Kurt Roeckx
> provided the initial port and offered the patches to OpenSSH, but they
> were never merged.
>
> Also see http://github.com/openssh/openssh-portable/pull/48 and
> https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#OpenSSH.
>
> Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170710/47a2a03d/attachment.html>

From noloader at gmail.com  Mon Jul 10 06:35:51 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 10 Jul 2017 02:35:51 -0400
Subject: [openssl-users] Openssl 1.1.0f support for building
 Openssh7.2p2 and above
In-Reply-To: <CADhPa=wUBc7AJYw0hu1_u8Xazn-UGu_J2=78bVBRAXTAPshvRA@mail.gmail.com>
References: <CADhPa=zkitZZN42gxn9RnrkLjZYozMxaSCbgUFDvt46exjqAww@mail.gmail.com>
 <CADhPa=ywtnLGOEbO4uD_6HtVjXoVVcKJKWeoHyixxtx80zjFvQ@mail.gmail.com>
 <CAH8yC8mGy035WPK952fzJ0y4Lv9FBDnCMwJAcOjCqugZDEv8UA@mail.gmail.com>
 <CADhPa=wUBc7AJYw0hu1_u8Xazn-UGu_J2=78bVBRAXTAPshvRA@mail.gmail.com>
Message-ID: <CAH8yC8n8EQAqXO=TGUjR1RW15w5V4sU-VXfT+mxXrdi88X8ATw@mail.gmail.com>

On Mon, Jul 10, 2017 at 2:01 AM, Sravani Maddukuri via openssl-users
<openssl-users at openssl.org> wrote:
>
> Is there any plans in the future to get the support of OpenSSL 1.1.0 for
> OpenSSH?

You should ask the OpenSSH folks.

Jeff

From me at kelunik.com  Mon Jul 10 07:45:35 2017
From: me at kelunik.com (Niklas Keller)
Date: Mon, 10 Jul 2017 09:45:35 +0200
Subject: [openssl-users] Rejecting SHA-1 certificates
Message-ID: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>

Morning,

I'm currently trying to reject certificate chains which rely on MD5 and
SHA-1 for signatures. I found SSL_get0_verified_chain which could be used
to walk the chain and reject if there's any MD5 / SHA-1 certificate in
there, except for the last one, which is trusted because of the public key
instead of based on the signature, so a weak signature algorithm doesn't
have any impact there.

Unfortunately, SSL_get0_verified_chain is only available in OpenSSL 1.1,
but not in OpenSSL 1.0.1 or 1.0.2, which both have to be supported. With
OpenSSL 1.1, we could also just use "auth_level" and be done.

What's the best way / a working way to reject weak signature schemes in
OpenSSL 1.0.{1,2}?

Regards, Niklas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170710/f0c97b22/attachment.html>

From npathak2 at ncsu.edu  Mon Jul 10 08:14:06 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Mon, 10 Jul 2017 01:14:06 -0700
Subject: [openssl-users] Default Diffie Hellman Parameters
Message-ID: <CANWFjKBvycyFyt5Av9s4RBQqrBsKPH5HDJH38xb2WdpCPWgjGw@mail.gmail.com>

Hi All,
In case no dh params are set and ECDHE-ECDSA type cipher is used, what is
the default size of DH params  (what modulus) used on TLS handshake. I see
that X25519 EC is getting used but I am not sure about DH parameters in
that case
Thanks
Best Regards,
Neetish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170710/935dd2fb/attachment.html>

From rsalz at akamai.com  Mon Jul 10 08:16:30 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 10 Jul 2017 08:16:30 +0000
Subject: [openssl-users] Default Diffie Hellman Parameters
In-Reply-To: <CANWFjKBvycyFyt5Av9s4RBQqrBsKPH5HDJH38xb2WdpCPWgjGw@mail.gmail.com>
References: <CANWFjKBvycyFyt5Av9s4RBQqrBsKPH5HDJH38xb2WdpCPWgjGw@mail.gmail.com>
Message-ID: <0545572d7d8943cfb861ddc15059b5ca@usma1ex-dag1mb1.msg.corp.akamai.com>

X25519 does not use DH parameters.

If you don?t set the parameters with a callback, or generate them and tell openssl to use them, then EDH will not be used.  Not that EDH is *not* the same as ECDHE.

Don?t use DH, use X25519, for a number of reasons.  Search ?25519? to find more.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170710/235344dc/attachment-0001.html>

From raymi.coevan at gmail.com  Mon Jul 10 14:00:50 2017
From: raymi.coevan at gmail.com (Raymi Coevan)
Date: Mon, 10 Jul 2017 16:00:50 +0200
Subject: [openssl-users] MSVC Compiling OpenSSL on Windows 64 issues
 with missing libs
In-Reply-To: <20170708.123448.2057989853453036308.levitte@openssl.org>
References: <20170708.120131.951807487781691574.levitte@openssl.org>
 <CANFqjkL_Gwc5cFrwHK_5e4bR9kTBQcJqfodh47W_3XJEZNpLaQ@mail.gmail.com>
 <CANFqjkLN5DHq7uOTuxYgCCVLv9==WQLO=3j8JJM9QW2p41012Q@mail.gmail.com>
 <20170708.123448.2057989853453036308.levitte@openssl.org>
Message-ID: <CANFqjk+F07fbML+kFq2kANNTGUoksvfJO0oxKuUnWZBnmVPxbA@mail.gmail.com>

Ok, found what happened.

For a reason that remains gloomy to me (I think this is undocumented from
POCO), POCO adds the following dependencies to the vcxproj file:
<AdditionalDependencies>ws2_32.lib;iphlpapi.lib;libeay32.lib;ssleay32.lib;%(AdditionalDependencies)</AdditionalDependencies>

I have removed those dependencies and it looks to be ok now. So not an
OpenSSL issue, I just leave the comment for anyone who could face the issue
too.

Sorry for having disturb.

KR
Raymi


On Sat, Jul 8, 2017 at 12:34 PM, Richard Levitte <levitte at openssl.org>
wrote:

> In message <CANFqjkLN5DHq7uOTuxYgCCVLv9==WQLO=3j8JJM9QW2p41012Q at mail.
> gmail.com> on Sat, 8 Jul 2017 12:29:31 +0200, Raymi Coevan <
> raymi.coevan at gmail.com> said:
>
> raymi.coevan> Sorry, I meant no reference to libeaymt64.lib or
> ssleaymt64.lib
> raymi.coevan>
> raymi.coevan> On Sat, Jul 8, 2017 at 12:20 PM, Raymi Coevan <
> raymi.coevan at gmail.com>
> raymi.coevan> wrote:
> ...
> raymi.coevan>
> raymi.coevan>     Indeed, the list you mentioned is exactly the one I have
> in my
> raymi.coevan>     environment. In my MSVC project, I only statically link
> with
> raymi.coevan>     libcrypto64MT.lib and libssl64MT.lib. No reference is
> made to
> raymi.coevan>     libeaymt64.lib or libssl64MT.lib, from what I know at
> least. So I
> raymi.coevan>     don't understand why I got these link errors...
>
> Can't help you there, sorry.
>
> Cheers,
> Richard
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170710/aca4e8eb/attachment.html>

From openssl-users at dukhovni.org  Mon Jul 10 16:52:26 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Jul 2017 12:52:26 -0400
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
Message-ID: <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>


> On Jul 10, 2017, at 3:45 AM, Niklas Keller <me at kelunik.com> wrote:
> 
> 
> What's the best way / a working way to reject weak signature schemes in OpenSSL 1.0.{1,2}?

Most CAs have stopped issuing SHA-1 certificates.  Any old ones will expire over the
next year or two.  While Google has demonstrated a SHA-1 collision, that proof of
concept is far from a practical attack.

The simplest solution is to let the CAs solve the problem as SHA-1 certificates fade
out of the picture.  You can if you wish leave out from the set of trusted roots any
CAs that have not yet stopped issuing SHA-1 certificates.

You can of course implement a verify callback that inspects each certificate in the
chain, and triggers an error when its signature is SHA-1 and it is not the last one
in the chain.  This requires keeping some state attached to the X509 store context,
and I don't think is worth the effort.

See code involving "TLScontext_index" in:

https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L318
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L942
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_verify.c#L163

With such a context, you can keep track of the maximum depth seen by the callback,
and reject SHA-1 at lower depths.  I do not recommend doing this.

-- 
	Viktor.


From me at kelunik.com  Mon Jul 10 17:12:08 2017
From: me at kelunik.com (Niklas Keller)
Date: Mon, 10 Jul 2017 19:12:08 +0200
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
Message-ID: <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>

>
> > On Jul 10, 2017, at 3:45 AM, Niklas Keller <me at kelunik.com> wrote:
> >
> >
> > What's the best way / a working way to reject weak signature schemes in
> OpenSSL 1.0.{1,2}?
>
> Most CAs have stopped issuing SHA-1 certificates.  Any old ones will
> expire over the
> next year or two.  While Google has demonstrated a SHA-1 collision, that
> proof of
> concept is far from a practical attack.
>

Actually they should already be expired, all major browsers will reject
them already, even Edge.


> The simplest solution is to let the CAs solve the problem as SHA-1
> certificates fade
> out of the picture.  You can if you wish leave out from the set of trusted
> roots any
> CAs that have not yet stopped issuing SHA-1 certificates.
>

CAs can't solve the problem that we accept certificates with weak
signatures.


> You can of course implement a verify callback that inspects each
> certificate in the
> chain, and triggers an error when its signature is SHA-1 and it is not the
> last one
> in the chain.  This requires keeping some state attached to the X509 store
> context,
> and I don't think is worth the effort.
>

It's very well worth the effort, otherwise there's a security issue,
because certificates can be forged.

Regards, Niklas


> See code involving "TLScontext_index" in:
>
> https://github.com/vdukhovni/postfix/blob/master/postfix/
> src/tls/tls_client.c#L318
> https://github.com/vdukhovni/postfix/blob/master/postfix/
> src/tls/tls_client.c#L942
> https://github.com/vdukhovni/postfix/blob/master/postfix/
> src/tls/tls_verify.c#L163
>
> With such a context, you can keep track of the maximum depth seen by the
> callback,
> and reject SHA-1 at lower depths.  I do not recommend doing this.
>
> --
>         Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170710/ad356e9a/attachment.html>

From openssl-users at dukhovni.org  Mon Jul 10 17:22:56 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Jul 2017 13:22:56 -0400
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
 <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>
Message-ID: <FF104B55-B9C3-4C49-926E-8B9647382756@dukhovni.org>


> On Jul 10, 2017, at 1:12 PM, Niklas Keller <me at kelunik.com> wrote:
> 
> It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.

Collision attacks don't directly lead to certificate forgery.  There are
no known 2nd-preimage attacks on SHA-1.

The previous MD5 attack required CAs to issue certificates with predictable
content (serial numbers and the like) so that the requested certificate
collides with a rogue certificate with basicConstraints CA:true.  Unpredictable
serial numbers defeat that attack.

If trusted CAs are no longer issuing SHA-1 certificates, then soon you won't need
to detect SHA-1 certificates in trusted chains, as there won't be any such
certificates issued by trusted CAs.

Anyway, if you must, you can inspect the chain as it is being verified via the
verify callback, keep track of the maximum depth (the final set of callbacks
when all goes well start with the topmost CA certificate and goes down towards
the leaf) and reject SHA-1 at depths below any depth seen before.

That's a bunch of code, to address an issue that is solving itself naturally
through attrition.

-- 
-- 
	Viktor.


From Michael.Wojcik at microfocus.com  Mon Jul 10 17:30:25 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Mon, 10 Jul 2017 17:30:25 +0000
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
 <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9A8FC6A@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Niklas Keller
> Sent: Monday, July 10, 2017 11:12
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Rejecting SHA-1 certificates


> It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.

Care to demonstrate that?

The SHAttered attack demonstrated an SHA1 collision using 1) an enormous amount of resources and 2) a file format with plenty of scope for manipulating the preimages. I'm not aware of any public demonstration showing anything close to a practical way of forging an X.509 certificate with an SHA1-based signature. Certificates have far less scope for manipulating the preimage.

It's always been possible to forge certificates. Generally that's been done by stealing the signing key from  a poorly-secured CA. The new marginal feasibility of producing SHA1 collisions does not significantly increase the forgery risk for X.509 certificates at present, since it's probably still too difficult - perhaps not even possible for any useful forgery (if the forged certificate had to carry a suspect amount of unexpected data, for example) - and certainly far too expensive to justify the vast majority of potential attacks.

A security vulnerability is meaningless outside the context of a threat model. Forging certificates with SHA1-based signatures is a very minor branch of the attack tree for nearly all certificate holders. CAs and browser vendors are getting rid of SHA1-based signatures now because the cost of being proactive is very small, and attacks only get better. That doesn't mean immediately screening out all SHA1-based certificates is justified under sensible threat models.

What's your threat model, and how does it justify this effort?

Michael Wojcik 
Distinguished Engineer, Micro Focus 



From me at kelunik.com  Mon Jul 10 18:19:11 2017
From: me at kelunik.com (Niklas Keller)
Date: Mon, 10 Jul 2017 20:19:11 +0200
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9A8FC6A@prvxmb03.microfocus.com>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
 <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9A8FC6A@prvxmb03.microfocus.com>
Message-ID: <CANUQDChWqar8zTf7kL=RgbhtO6BiMmGOr8yvqQK09f25nxYr=w@mail.gmail.com>

2017-07-10 19:30 GMT+02:00 Michael Wojcik <Michael.Wojcik at microfocus.com>:

> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Niklas Keller
> > Sent: Monday, July 10, 2017 11:12
> > To: openssl-users at openssl.org
> > Subject: Re: [openssl-users] Rejecting SHA-1 certificates
>
>
> > It's very well worth the effort, otherwise there's a security issue,
> because certificates can be forged.
>
> Care to demonstrate that?
>

I'm not sure how feasible that is for either SHA1 or MD5.


> The SHAttered attack demonstrated an SHA1 collision using 1) an enormous
> amount of resources and 2) a file format with plenty of scope for
> manipulating the preimages. I'm not aware of any public demonstration
> showing anything close to a practical way of forging an X.509 certificate
> with an SHA1-based signature. Certificates have far less scope for
> manipulating the preimage.
>
> It's always been possible to forge certificates. Generally that's been
> done by stealing the signing key from  a poorly-secured CA. The new
> marginal feasibility of producing SHA1 collisions does not significantly
> increase the forgery risk for X.509 certificates at present, since it's
> probably still too difficult - perhaps not even possible for any useful
> forgery (if the forged certificate had to carry a suspect amount of
> unexpected data, for example) - and certainly far too expensive to justify
> the vast majority of potential attacks.
>

Probably true, yes.


> A security vulnerability is meaningless outside the context of a threat
> model. Forging certificates with SHA1-based signatures is a very minor
> branch of the attack tree for nearly all certificate holders. CAs and
> browser vendors are getting rid of SHA1-based signatures now because the
> cost of being proactive is very small, and attacks only get better. That
> doesn't mean immediately screening out all SHA1-based certificates is
> justified under sensible threat models.
>
> What's your threat model, and how does it justify this effort?
>

The same as for browsers I guess. Could you explain why browsers and Java
disable SHA1, but it's not worth for me doing so?

Regards, Niklas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170710/330ed93b/attachment-0001.html>

From kudzu at tenebras.com  Mon Jul 10 19:07:42 2017
From: kudzu at tenebras.com (Michael Sierchio)
Date: Mon, 10 Jul 2017 12:07:42 -0700
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <FF104B55-B9C3-4C49-926E-8B9647382756@dukhovni.org>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
 <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>
 <FF104B55-B9C3-4C49-926E-8B9647382756@dukhovni.org>
Message-ID: <CAHu1Y718bSQwWUJKp+uisLEZPMSYjnMcP=ArRjB_-uKT1yc9Pg@mail.gmail.com>

On Mon, Jul 10, 2017 at 10:22 AM, Viktor Dukhovni <
openssl-users at dukhovni.org> wrote:

>
> > On Jul 10, 2017, at 1:12 PM, Niklas Keller <me at kelunik.com> wrote:
> >
> > It's very well worth the effort, otherwise there's a security issue,
> because certificates can be forged.
>
> Collision attacks don't directly lead to certificate forgery.  There are
> no known 2nd-preimage attacks on SHA-1.


I'm pretty sure, but are you saying you would rather wait for a
demonstration of the weakness being turned into a practical attack?

Second pre-image attacks against reduced SHA-1 have been demonstrated. It's
only a matter of time before second pre-image resistance for full SHA-1 is
dead and buried.

-- 
"Well," Brahma said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."

- The Mah?bh?rata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170710/04b7d433/attachment.html>

From openssl-users at dukhovni.org  Mon Jul 10 19:23:56 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Jul 2017 19:23:56 +0000
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <CAHu1Y718bSQwWUJKp+uisLEZPMSYjnMcP=ArRjB_-uKT1yc9Pg@mail.gmail.com>
 <CANUQDChWqar8zTf7kL=RgbhtO6BiMmGOr8yvqQK09f25nxYr=w@mail.gmail.com>
Message-ID: <20170710192356.GE1755@mournblade.imrryr.org>

On Mon, Jul 10, 2017 at 08:19:11PM +0200, Niklas Keller wrote:

> > What's your threat model, and how does it justify this effort?
> 
> The same as for browsers I guess. Could you explain why browsers and Java
> disable SHA1, but it's not worth for me doing so?

The browsers and Java do this because they can (they control the
underlying libraries) and in order to prod the CAs into action,
and to force server operators to move to SHA2.

There is no immediate threat, but the goal is to move the ecosystem
away from SHA-1.  Now that they've done that, you don't need to
refuse SHA-1 in every piece of legacy software (e.g. OpenSSL 1.0.x).
Your contribution to purging SHA-1 from the public Internet would be
negligible.


On Mon, Jul 10, 2017 at 12:07:42PM -0700, Michael Sierchio wrote:

> > Collision attacks don't directly lead to certificate forgery.  There are
> > no known 2nd-preimage attacks on SHA-1.
> 
> I'm pretty sure, but are you saying you would rather wait for a
> demonstration of the weakness being turned into a practical attack?

Making your code more complex is a far higher risk than a practical
certificate forgery based on a collision attack on SHA-1.

> Second pre-image attacks against reduced SHA-1 have been demonstrated. It's
> only a matter of time before second pre-image resistance for full SHA-1 is
> dead and buried.

We don't even have 2nd-preimage attacks on MD5 yet.  I'm not holding my
breath for 2nd-preimage attacks on full SHA-1.

Anyway, you can, if you wish, implement a verification callback
that makes the appropriate checks for OpenSSL 1.0.x, but my advice
is to just let the CAs get rid of SHA-1 under pressure from the
browsers, Java, ...

In OpenSSL 1.2.0 (not sure about 1.1.1) we can designate SHA-1 as too
weak for security level 1, and at that time, OpenSSL applications
linked with OpenSSL will by default refuse to validate certificate
signatures based on SHA-1.

-- 
	Viktor.

From Matthias.Ballreich at outlook.de  Mon Jul 10 16:47:28 2017
From: Matthias.Ballreich at outlook.de (Matthias Ballreich)
Date: Mon, 10 Jul 2017 16:47:28 +0000
Subject: [openssl-users] OpenSSL 1.1.0 providing new OIDs to source code
In-Reply-To: <20170710.061330.1471247083034095972.levitte@openssl.org>
References: <AM5P195MB018008B87ACD89D37B629CF3FBAB0@AM5P195MB0180.EURP195.PROD.OUTLOOK.COM>,
 <20170710.061330.1471247083034095972.levitte@openssl.org>
Message-ID: <DB6P195MB0182A9C918B5D06CF9A12FD8FBA90@DB6P195MB0182.EURP195.PROD.OUTLOOK.COM>

Yes, MY_NID is really NID_whatever. I tried it with putting OPENSSL_init_crypto(0, NULL); at start of my main().
Did not make any difference?

The Integer value of MY_NID will be printed out and is the correct integer value.

And i tried another thing. I replaced the two dll-libraries with the new created ones and then i run my Code and there all will be printed out correctly. BUT the whole time i used some older dll-libraries of openssl, (1.1.0f) and for development i used the latest 1.1.1-dev and then i build this, which has added a new x509 extension (Admission), which has a new OID (NID_extX509Admission, etc.) and there the short and long name will be printed out correctly after Building the Code. So this is a Little bit strange.

Or must i replace the dll-libraries every time i build the Code? But when, why has it worked with the old ones and the 1.1.1-dev (master branch)?

Best regards
Matthias


Von: Richard Levitte<mailto:levitte at openssl.org>
Gesendet: Montag, 10. Juli 2017 06:14
An: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Betreff: Re: [openssl-users] OpenSSL 1.1.0 providing new OIDs to source code

In message <AM5P195MB018008B87ACD89D37B629CF3FBAB0 at AM5P195MB0180.EURP195.PROD.OUTLOOK.COM> on Sat, 8 Jul 2017 23:31:00 +0000, Matthias Ballreich <matthias.ballreich at outlook.de> said:

matthias.ballreich> Hi there,
matthias.ballreich>
matthias.ballreich> i want to contribute some more OIDs. Therefore i added the OIDs inside
matthias.ballreich> the ?Objects.txt? inside /crypto/objects
matthias.ballreich>
matthias.ballreich> Then i run these commands:
matthias.ballreich>
matthias.ballreich> perl objects.pl objects.txt obj_mac.num .
matthias.ballreich> ./../include/openssl/obj_mac.h
matthias.ballreich>
matthias.ballreich> perl obj_dat.pl ../../include/openssl/obj_mac.h obj_dat.h
matthias.ballreich>
matthias.ballreich> perl objxref.pl obj_mac.num obj_xref.txt > obj_xref.h

Sure, that looks fine to me

matthias.ballreich> The files are generated / updated. Then i build the source which
matthias.ballreich> builds fine without any exceptions. Then i tried to use the generated
matthias.ballreich> NIDs in my Code. For test purposes i tried to print out the short and
matthias.ballreich> Long Name of my new oid with OBJ_nid2sn(MY_NID) and OBJ_nid2(MY_NID).
matthias.ballreich> But here it prints out an empty string.
matthias.ballreich>
matthias.ballreich> When o try to use my NID with X509_get_ext_by_NID(cert, MY_NID, -1)
matthias.ballreich> the Output is -2.
matthias.ballreich>
matthias.ballreich> So where is the Problem or what i?m doing wrong here? Thanks!

If you've come that far, MY_NID (which I assume is really
NID_whatever) obviously exists, or your code wouldn't even have
compiled.  One possibility remains, that for some reason, libcrypto
hasn't been initialised like it should.  This can happen if you only
call a very select set of OpenSSL functions.  What happens if you add
this at the start of your main()?

    OPENSSL_init_crypto(0, NULL);

(note, that should be seen as a temporary measure, as this is called
internally in quite a number of spots, so for larger uses of OpenSSL
functionality, you shouldn't need that)

Cheers,
Richard

--
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170710/42cdf575/attachment.html>

From Michael.Wojcik at microfocus.com  Mon Jul 10 23:37:41 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Mon, 10 Jul 2017 23:37:41 +0000
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <20170710192356.GE1755@mournblade.imrryr.org>
References: <CAHu1Y718bSQwWUJKp+uisLEZPMSYjnMcP=ArRjB_-uKT1yc9Pg@mail.gmail.com>
 <CANUQDChWqar8zTf7kL=RgbhtO6BiMmGOr8yvqQK09f25nxYr=w@mail.gmail.com>
 <20170710192356.GE1755@mournblade.imrryr.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9A8FE94@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Monday, July 10, 2017 13:24
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Rejecting SHA-1 certificates
> 
> On Mon, Jul 10, 2017 at 08:19:11PM +0200, Niklas Keller wrote:
> 
> > > What's your threat model, and how does it justify this effort?
> >
> > The same as for browsers I guess. Could you explain why browsers and
> Java
> > disable SHA1, but it's not worth for me doing so?
> 
> The browsers and Java do this because they can (they control the
> underlying libraries) and in order to prod the CAs into action,
> and to force server operators to move to SHA2.

That, and PR. Google has Chrome deprecate SHA-1, so they can wave the security flag. Then everyone else has to follow suit to prove they're equally concerned with security.

Security is always about economics. Deprecating SHA-1 is cheap for the major browsers; there's a small development cost and some irritation to users, but if all the major browsers do it, then the latter becomes an externality - it's not going to cost the browsers any market share. And while it doesn't have a lot of value, as Viktor pointed out, it does prod CAs and server owners to update now, before there's any real threat. So there's some return - enough to justify their investment.

For the vast majority of OpenSSL-based applications, the higher cost is not justified by the lower return. We've already noted why the cost is higher. The return is lower because most OpenSSL-based applications are much less prominent than browsers, so fewer people will notice (thus there's less PR and industry-prodding benefit) and less risk of some wildly well-resourced attacker trying to forge a certificate (assuming that's even feasible, given the constraints of the format).

More generally, making security decisions without understanding your threat model and at least estimating the cost/benefit ratio is a Bad Thing. It's stabbing in the dark. And it's critical to include the opportunity cost - could those resources be put to better use, such as finding and fixing more realistic vulnerabilities?

Michael Wojcik 
Distinguished Engineer, Micro Focus 


From sravani.maddukuri at broadcom.com  Tue Jul 11 05:46:02 2017
From: sravani.maddukuri at broadcom.com (Sravani Maddukuri)
Date: Tue, 11 Jul 2017 11:16:02 +0530
Subject: [openssl-users] Openssl 1.1.0f support for building
 Openssh7.2p2 and above
In-Reply-To: <CAH8yC8n8EQAqXO=TGUjR1RW15w5V4sU-VXfT+mxXrdi88X8ATw@mail.gmail.com>
References: <CADhPa=zkitZZN42gxn9RnrkLjZYozMxaSCbgUFDvt46exjqAww@mail.gmail.com>
 <CADhPa=ywtnLGOEbO4uD_6HtVjXoVVcKJKWeoHyixxtx80zjFvQ@mail.gmail.com>
 <CAH8yC8mGy035WPK952fzJ0y4Lv9FBDnCMwJAcOjCqugZDEv8UA@mail.gmail.com>
 <CADhPa=wUBc7AJYw0hu1_u8Xazn-UGu_J2=78bVBRAXTAPshvRA@mail.gmail.com>
 <CAH8yC8n8EQAqXO=TGUjR1RW15w5V4sU-VXfT+mxXrdi88X8ATw@mail.gmail.com>
Message-ID: <CADhPa=yTe=w97P_tNNd9mA_a-F3BWjvxAusRD7A9ZjRNyA0xDg@mail.gmail.com>

I will check with OpenSSH team on this. Thanks for the info.

Regards,
Sravani

On Mon, Jul 10, 2017 at 12:05 PM, Jeffrey Walton <noloader at gmail.com> wrote:

> On Mon, Jul 10, 2017 at 2:01 AM, Sravani Maddukuri via openssl-users
> <openssl-users at openssl.org> wrote:
> >
> > Is there any plans in the future to get the support of OpenSSL 1.1.0 for
> > OpenSSH?
>
> You should ask the OpenSSH folks.
>
> Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170711/4eebd74d/attachment.html>

From levitte at openssl.org  Tue Jul 11 07:19:04 2017
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 11 Jul 2017 09:19:04 +0200 (CEST)
Subject: [openssl-users] OpenSSL 1.1.0 providing new OIDs to source code
In-Reply-To: <DB6P195MB0182A9C918B5D06CF9A12FD8FBA90@DB6P195MB0182.EURP195.PROD.OUTLOOK.COM>
References: <AM5P195MB018008B87ACD89D37B629CF3FBAB0@AM5P195MB0180.EURP195.PROD.OUTLOOK.COM>
 <20170710.061330.1471247083034095972.levitte@openssl.org>
 <DB6P195MB0182A9C918B5D06CF9A12FD8FBA90@DB6P195MB0182.EURP195.PROD.OUTLOOK.COM>
Message-ID: <20170711.091904.1692039280094796130.levitte@openssl.org>

This all sounds a bit mysterious...

would you mind sharing a test program that shows the problem, with
detailed step by step instructions (among others what libraries you're
running against each time)?  Preferably as a github issue, but here is
fine as well...

Cheers,
Richard

In message <DB6P195MB0182A9C918B5D06CF9A12FD8FBA90 at DB6P195MB0182.EURP195.PROD.OUTLOOK.COM> on Mon, 10 Jul 2017 16:47:28 +0000, Matthias Ballreich <Matthias.Ballreich at outlook.de> said:

Matthias.Ballreich> Yes, MY_NID is really NID_whatever. I tried it with putting
Matthias.Ballreich> OPENSSL_init_crypto(0, NULL); at start of my main().
Matthias.Ballreich> 
Matthias.Ballreich> Did not make any difference?
Matthias.Ballreich> 
Matthias.Ballreich> The Integer value of MY_NID will be printed out and is the correct
Matthias.Ballreich> integer value.
Matthias.Ballreich> 
Matthias.Ballreich> And i tried another thing. I replaced the two dll-libraries with the
Matthias.Ballreich> new created ones and then i run my Code and there all will be printed
Matthias.Ballreich> out correctly. BUT the whole time i used some older dll-libraries of
Matthias.Ballreich> openssl, (1.1.0f) and for development i used the latest 1.1.1-dev and
Matthias.Ballreich> then i build this, which has added a new x509 extension (Admission),
Matthias.Ballreich> which has a new OID (NID_extX509Admission, etc.) and there the short
Matthias.Ballreich> and long name will be printed out correctly after Building the Code.
Matthias.Ballreich> So this is a Little bit strange.
Matthias.Ballreich> 
Matthias.Ballreich> Or must i replace the dll-libraries every time i build the Code? But
Matthias.Ballreich> when, why has it worked with the old ones and the 1.1.1-dev (master
Matthias.Ballreich> branch)?
Matthias.Ballreich> 
Matthias.Ballreich> Best regards
Matthias.Ballreich> 
Matthias.Ballreich> Matthias
Matthias.Ballreich> 
Matthias.Ballreich> Von: Richard Levitte
Matthias.Ballreich> Gesendet: Montag, 10. Juli 2017 06:14
Matthias.Ballreich> An: openssl-users at openssl.org
Matthias.Ballreich> Betreff: Re: [openssl-users] OpenSSL 1.1.0 providing new OIDs to
Matthias.Ballreich> source code
Matthias.Ballreich> 
Matthias.Ballreich> In message
Matthias.Ballreich> <AM5P195MB018008B87ACD89D37B629CF3FBAB0 at AM5P195MB0180.EURP195.PROD.OUTLOOK.COM>
Matthias.Ballreich> on Sat, 8 Jul 2017 23:31:00 +0000, Matthias Ballreich
Matthias.Ballreich> <matthias.ballreich at outlook.de> said:
Matthias.Ballreich> 
Matthias.Ballreich> matthias.ballreich> Hi there,
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> i want to contribute some more OIDs. Therefore i
Matthias.Ballreich> added the OIDs inside
Matthias.Ballreich> matthias.ballreich> the ?Objects.txt? inside /crypto/objects
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> Then i run these commands:
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> perl objects.pl objects.txt obj_mac.num .
Matthias.Ballreich> matthias.ballreich> ./../include/openssl/obj_mac.h
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> perl obj_dat.pl ../../include/openssl/obj_mac.h
Matthias.Ballreich> obj_dat.h
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> perl objxref.pl obj_mac.num obj_xref.txt >
Matthias.Ballreich> obj_xref.h
Matthias.Ballreich> 
Matthias.Ballreich> Sure, that looks fine to me
Matthias.Ballreich> 
Matthias.Ballreich> matthias.ballreich> The files are generated / updated. Then i build
Matthias.Ballreich> the source which
Matthias.Ballreich> matthias.ballreich> builds fine without any exceptions. Then i tried
Matthias.Ballreich> to use the generated
Matthias.Ballreich> matthias.ballreich> NIDs in my Code. For test purposes i tried to
Matthias.Ballreich> print out the short and
Matthias.Ballreich> matthias.ballreich> Long Name of my new oid with OBJ_nid2sn(MY_NID)
Matthias.Ballreich> and OBJ_nid2(MY_NID).
Matthias.Ballreich> matthias.ballreich> But here it prints out an empty string.
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> When o try to use my NID with X509_get_ext_by_NID
Matthias.Ballreich> (cert, MY_NID, -1)
Matthias.Ballreich> matthias.ballreich> the Output is -2.
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> So where is the Problem or what i?m doing wrong
Matthias.Ballreich> here? Thanks!
Matthias.Ballreich> 
Matthias.Ballreich> If you've come that far, MY_NID (which I assume is really
Matthias.Ballreich> NID_whatever) obviously exists, or your code wouldn't even have
Matthias.Ballreich> compiled. One possibility remains, that for some reason, libcrypto
Matthias.Ballreich> hasn't been initialised like it should. This can happen if you only
Matthias.Ballreich> call a very select set of OpenSSL functions. What happens if you add
Matthias.Ballreich> this at the start of your main()?
Matthias.Ballreich> 
Matthias.Ballreich> OPENSSL_init_crypto(0, NULL);
Matthias.Ballreich> 
Matthias.Ballreich> (note, that should be seen as a temporary measure, as this is called
Matthias.Ballreich> internally in quite a number of spots, so for larger uses of OpenSSL
Matthias.Ballreich> functionality, you shouldn't need that)
Matthias.Ballreich> 
Matthias.Ballreich> Cheers,
Matthias.Ballreich> Richard
Matthias.Ballreich> 
Matthias.Ballreich> --
Matthias.Ballreich> Richard Levitte levitte at openssl.org
Matthias.Ballreich> OpenSSL Project http://www.openssl.org/~levitte/
Matthias.Ballreich> --
Matthias.Ballreich> openssl-users mailing list
Matthias.Ballreich> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Matthias.Ballreich> 

From Matthias.Ballreich at outlook.de  Tue Jul 11 07:26:51 2017
From: Matthias.Ballreich at outlook.de (Matthias Ballreich)
Date: Tue, 11 Jul 2017 07:26:51 +0000
Subject: [openssl-users] OpenSSL 1.1.0 providing new OIDs to source code
In-Reply-To: <20170711.091904.1692039280094796130.levitte@openssl.org>
References: <AM5P195MB018008B87ACD89D37B629CF3FBAB0@AM5P195MB0180.EURP195.PROD.OUTLOOK.COM>
 <20170710.061330.1471247083034095972.levitte@openssl.org>
 <DB6P195MB0182A9C918B5D06CF9A12FD8FBA90@DB6P195MB0182.EURP195.PROD.OUTLOOK.COM>,
 <20170711.091904.1692039280094796130.levitte@openssl.org>
Message-ID: <DB6P195MB0182BA1096D93DABD958A649FBAE0@DB6P195MB0182.EURP195.PROD.OUTLOOK.COM>

yes i can do this. I do it as github issue then. I hope i find time this evening to do this otherwise tomorrow.

________________________________
Von: openssl-users <openssl-users-bounces at openssl.org> im Auftrag von Richard Levitte <levitte at openssl.org>
Gesendet: Dienstag, 11. Juli 2017 09:19:04
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] OpenSSL 1.1.0 providing new OIDs to source code

This all sounds a bit mysterious...

would you mind sharing a test program that shows the problem, with
detailed step by step instructions (among others what libraries you're
running against each time)?  Preferably as a github issue, but here is
fine as well...

Cheers,
Richard

In message <DB6P195MB0182A9C918B5D06CF9A12FD8FBA90 at DB6P195MB0182.EURP195.PROD.OUTLOOK.COM> on Mon, 10 Jul 2017 16:47:28 +0000, Matthias Ballreich <Matthias.Ballreich at outlook.de> said:

Matthias.Ballreich> Yes, MY_NID is really NID_whatever. I tried it with putting
Matthias.Ballreich> OPENSSL_init_crypto(0, NULL); at start of my main().
Matthias.Ballreich>
Matthias.Ballreich> Did not make any difference?
Matthias.Ballreich>
Matthias.Ballreich> The Integer value of MY_NID will be printed out and is the correct
Matthias.Ballreich> integer value.
Matthias.Ballreich>
Matthias.Ballreich> And i tried another thing. I replaced the two dll-libraries with the
Matthias.Ballreich> new created ones and then i run my Code and there all will be printed
Matthias.Ballreich> out correctly. BUT the whole time i used some older dll-libraries of
Matthias.Ballreich> openssl, (1.1.0f) and for development i used the latest 1.1.1-dev and
Matthias.Ballreich> then i build this, which has added a new x509 extension (Admission),
Matthias.Ballreich> which has a new OID (NID_extX509Admission, etc.) and there the short
Matthias.Ballreich> and long name will be printed out correctly after Building the Code.
Matthias.Ballreich> So this is a Little bit strange.
Matthias.Ballreich>
Matthias.Ballreich> Or must i replace the dll-libraries every time i build the Code? But
Matthias.Ballreich> when, why has it worked with the old ones and the 1.1.1-dev (master
Matthias.Ballreich> branch)?
Matthias.Ballreich>
Matthias.Ballreich> Best regards
Matthias.Ballreich>
Matthias.Ballreich> Matthias
Matthias.Ballreich>
Matthias.Ballreich> Von: Richard Levitte
Matthias.Ballreich> Gesendet: Montag, 10. Juli 2017 06:14
Matthias.Ballreich> An: openssl-users at openssl.org
Matthias.Ballreich> Betreff: Re: [openssl-users] OpenSSL 1.1.0 providing new OIDs to
Matthias.Ballreich> source code
Matthias.Ballreich>
Matthias.Ballreich> In message
Matthias.Ballreich> <AM5P195MB018008B87ACD89D37B629CF3FBAB0 at AM5P195MB0180.EURP195.PROD.OUTLOOK.COM>
Matthias.Ballreich> on Sat, 8 Jul 2017 23:31:00 +0000, Matthias Ballreich
Matthias.Ballreich> <matthias.ballreich at outlook.de> said:
Matthias.Ballreich>
Matthias.Ballreich> matthias.ballreich> Hi there,
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> i want to contribute some more OIDs. Therefore i
Matthias.Ballreich> added the OIDs inside
Matthias.Ballreich> matthias.ballreich> the ?Objects.txt? inside /crypto/objects
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> Then i run these commands:
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> perl objects.pl objects.txt obj_mac.num .
Matthias.Ballreich> matthias.ballreich> ./../include/openssl/obj_mac.h
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> perl obj_dat.pl ../../include/openssl/obj_mac.h
Matthias.Ballreich> obj_dat.h
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> perl objxref.pl obj_mac.num obj_xref.txt >
Matthias.Ballreich> obj_xref.h
Matthias.Ballreich>
Matthias.Ballreich> Sure, that looks fine to me
Matthias.Ballreich>
Matthias.Ballreich> matthias.ballreich> The files are generated / updated. Then i build
Matthias.Ballreich> the source which
Matthias.Ballreich> matthias.ballreich> builds fine without any exceptions. Then i tried
Matthias.Ballreich> to use the generated
Matthias.Ballreich> matthias.ballreich> NIDs in my Code. For test purposes i tried to
Matthias.Ballreich> print out the short and
Matthias.Ballreich> matthias.ballreich> Long Name of my new oid with OBJ_nid2sn(MY_NID)
Matthias.Ballreich> and OBJ_nid2(MY_NID).
Matthias.Ballreich> matthias.ballreich> But here it prints out an empty string.
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> When o try to use my NID with X509_get_ext_by_NID
Matthias.Ballreich> (cert, MY_NID, -1)
Matthias.Ballreich> matthias.ballreich> the Output is -2.
Matthias.Ballreich> matthias.ballreich>
Matthias.Ballreich> matthias.ballreich> So where is the Problem or what i?m doing wrong
Matthias.Ballreich> here? Thanks!
Matthias.Ballreich>
Matthias.Ballreich> If you've come that far, MY_NID (which I assume is really
Matthias.Ballreich> NID_whatever) obviously exists, or your code wouldn't even have
Matthias.Ballreich> compiled. One possibility remains, that for some reason, libcrypto
Matthias.Ballreich> hasn't been initialised like it should. This can happen if you only
Matthias.Ballreich> call a very select set of OpenSSL functions. What happens if you add
Matthias.Ballreich> this at the start of your main()?
Matthias.Ballreich>
Matthias.Ballreich> OPENSSL_init_crypto(0, NULL);
Matthias.Ballreich>
Matthias.Ballreich> (note, that should be seen as a temporary measure, as this is called
Matthias.Ballreich> internally in quite a number of spots, so for larger uses of OpenSSL
Matthias.Ballreich> functionality, you shouldn't need that)
Matthias.Ballreich>
Matthias.Ballreich> Cheers,
Matthias.Ballreich> Richard
Matthias.Ballreich>
Matthias.Ballreich> --
Matthias.Ballreich> Richard Levitte levitte at openssl.org
Matthias.Ballreich> OpenSSL Project http://www.openssl.org/~levitte/
Matthias.Ballreich> --
Matthias.Ballreich> openssl-users mailing list
Matthias.Ballreich> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Matthias.Ballreich>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170711/8292a86f/attachment-0001.html>

From Raj_Jain at symantec.com  Tue Jul 11 18:45:50 2017
From: Raj_Jain at symantec.com (Raj Jain)
Date: Tue, 11 Jul 2017 18:45:50 +0000
Subject: [openssl-users] Issue with TLS1.3 and s_time
Message-ID: <DM3PR16MB0540BFCD9A74DF5299D892F385AE0@DM3PR16MB0540.namprd16.prod.outlook.com>

I'm having an issue with s_time and s_server using the latest OpenSSL (1.1.1-dev) and tls1_3.

When I use tls1_2 connections are established and data is transferred.  However, when I use tls1_3 data is not transferred (connections are established).

Below are the commands I use for s_time and s_server.    I provided the output when I used -tls1_2 vs. -tls1_3 on the server.  Notice "bytes read 0" for TLS 1.3.    (I tried this on the loopback as well as 2 separate boxes)

Is this a known issue with s_time?



This is the client:
s_time -new -connect localhost:44330 -www /1M.txt -cipher ECDHE-RSA-AES256-GCM-SHA384:TLS13-AES-256-GCM-SHA384

This is the server:
openssl s_server -key key.pem -cert cert.pem -accept 44330 -WWW -tls1_3

This is what I see with tls1_2:
1086 connections in 0.46s; 2360.87 connections/user sec, bytes read 51042
1086 connections in 2 real seconds, 47 bytes read per connection

This is what I see with tls1_3:
17663 connections in 7.67s; 2302.87 connections/user sec, bytes read 0
17663 connections in 31 real seconds, 0 bytes read per connection
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170711/07038bae/attachment.html>

From rsalz at akamai.com  Tue Jul 11 21:44:31 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 11 Jul 2017 21:44:31 +0000
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
 <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>
Message-ID: <5229530d0c794f0c9eeccd4dce9aad4b@usma1ex-dag1mb1.msg.corp.akamai.com>

> It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.

No they cannot.

What *has* been done is a document was created with "weak spots" and another document was created that  changed those weak spots, but the digest was the same.

This is a long long long way from creating two certificates with the same digest (and therefore the same signature).


From jb-openssl at wisemo.com  Wed Jul 12 00:02:31 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 12 Jul 2017 02:02:31 +0200
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
Message-ID: <54d82899-4841-8da2-48ba-f9cd729a5995@wisemo.com>

On 10/07/2017 18:52, Viktor Dukhovni wrote:
>> On Jul 10, 2017, at 3:45 AM, Niklas Keller <me at kelunik.com> wrote:
>>
>>
>> What's the best way / a working way to reject weak signature schemes in OpenSSL 1.0.{1,2}?
> Most CAs have stopped issuing SHA-1 certificates.  Any old ones will expire over the
> next year or two.  While Google has demonstrated a SHA-1 collision, that proof of
> concept is far from a practical attack.
>
> The simplest solution is to let the CAs solve the problem as SHA-1 certificates fade
> out of the picture.  You can if you wish leave out from the set of trusted roots any
> CAs that have not yet stopped issuing SHA-1 certificates.
>
> You can of course implement a verify callback that inspects each certificate in the
> chain, and triggers an error when its signature is SHA-1 and it is not the last one
> in the chain.  This requires keeping some state attached to the X509 store context,
> and I don't think is worth the effort.
>
> See code involving "TLScontext_index" in:
>
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L318
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L942
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_verify.c#L163
>
> With such a context, you can keep track of the maximum depth seen by the callback,
> and reject SHA-1 at lower depths.  I do not recommend doing this.
>
I don't think a state is really needed for this, if the callback
simply checks if the certificate is in the loaded trust collection,
and/or if it is self-signed (depending on the application's chosen
root CA trust model).


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From openssl-users at dukhovni.org  Wed Jul 12 05:23:10 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 12 Jul 2017 05:23:10 +0000
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <54d82899-4841-8da2-48ba-f9cd729a5995@wisemo.com>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
 <54d82899-4841-8da2-48ba-f9cd729a5995@wisemo.com>
Message-ID: <20170712052310.GH8146@mournblade.imrryr.org>

On Wed, Jul 12, 2017 at 02:02:31AM +0200, Jakob Bohm wrote:

> I don't think a state is really needed for this, if the callback
> simply checks if the certificate is in the loaded trust collection,
> and/or if it is self-signed (depending on the application's chosen
> root CA trust model).

Yes, though that too is complicated, e.g. DANE-TA(2) validation
often produces chains where none of the certs are in the local
store or self-signed.  And checking the trust stores for an
exact match takes some care...

The stateful approach is in some ways more elementary.

-- 
	Viktor.

From jb-openssl at wisemo.com  Wed Jul 12 05:44:09 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 12 Jul 2017 07:44:09 +0200
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <20170712052310.GH8146@mournblade.imrryr.org>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
 <54d82899-4841-8da2-48ba-f9cd729a5995@wisemo.com>
 <20170712052310.GH8146@mournblade.imrryr.org>
Message-ID: <cdfc0af3-3da8-0893-36f2-47fdb7417c71@wisemo.com>

On 12/07/2017 07:23, Viktor Dukhovni wrote:
> On Wed, Jul 12, 2017 at 02:02:31AM +0200, Jakob Bohm wrote:
>
>> I don't think a state is really needed for this, if the callback
>> simply checks if the certificate is in the loaded trust collection,
>> and/or if it is self-signed (depending on the application's chosen
>> root CA trust model).
> Yes, though that too is complicated, e.g. DANE-TA(2) validation
> often produces chains where none of the certs are in the local
> store or self-signed.  And checking the trust stores for an
> exact match takes some care...
>
> The stateful approach is in some ways more elementary.
>
Well, I guess that for DANE-TA, it would be OK to just insist
on no SHA-1 in the chain at all.

Given the limited abilities of (at least previous) versions
of the OpenSSL chain validation/building code, just checking
for self-signed would probably be good enough for now.

Hopefully any future improved OpenSSL code (that checks all
attributes currently ignored) would also provide a new
callback prototype that receives extra information about
the (OpenSSL internal) situation in which it was called, such
as "called from TLS server checking received client cert, this
is the end/middle/trusted cert in the candidate chain, and here
is the SSL_CTX* for that connection".  And with more sensibly
named/defined callback return values too (such as "reject this
cert, try another chain", "reject this cert, and all chains
containing it", "abort the connection, never mind the certs",
"accept this cert, despite the list of failed standard checks
reported to the callback (perhaps shown to the user in a prompt)",
"accept this cert and don't check the chain above it").


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From wouter.verhelst at fedict.be  Wed Jul 12 06:35:54 2017
From: wouter.verhelst at fedict.be (Wouter Verhelst)
Date: Wed, 12 Jul 2017 08:35:54 +0200
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <5229530d0c794f0c9eeccd4dce9aad4b@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
 <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>
 <5229530d0c794f0c9eeccd4dce9aad4b@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <39a92527-3df4-aea7-57ee-2f080dc62859@fedict.be>

On 11-07-17 23:44, Salz, Rich via openssl-users wrote:
>> It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.
> 
> No they cannot.
> 
> What *has* been done is a document was created with "weak spots" and another document was created that  changed those weak spots, but the digest was the same.

Correct me if I'm wrong, but wasn't the MD5 certificate hack presented
back at 25C3 based on exactly that scenario? They used the serial number
and timestamp or some other such thing (don't recall the details) as
weak spots and then sent loads of certificate requests to the CA to
effecively brute-force it.

(Of course, CAs are now required to randomize their serial number, so
since that particular attack isn't possible anymore, I agree that for
the time being it's still not a feasible scenario for SHA1, but hey)

-- 
Wouter Verhelst

From me at kelunik.com  Wed Jul 12 12:24:57 2017
From: me at kelunik.com (Niklas Keller)
Date: Wed, 12 Jul 2017 14:24:57 +0200
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <39a92527-3df4-aea7-57ee-2f080dc62859@fedict.be>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
 <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>
 <5229530d0c794f0c9eeccd4dce9aad4b@usma1ex-dag1mb1.msg.corp.akamai.com>
 <39a92527-3df4-aea7-57ee-2f080dc62859@fedict.be>
Message-ID: <CANUQDChU2iY_mVAAzfbmeSBkGsQM4QY_M_R7L0Nq=mmX+1eSyQ@mail.gmail.com>

2017-07-12 8:35 GMT+02:00 Wouter Verhelst <wouter.verhelst at fedict.be>:

> On 11-07-17 23:44, Salz, Rich via openssl-users wrote:
> >> It's very well worth the effort, otherwise there's a security issue,
> because certificates can be forged.
> >
> > No they cannot.
> >
> > What *has* been done is a document was created with "weak spots" and
> another document was created that  changed those weak spots, but the digest
> was the same.
>
> Correct me if I'm wrong, but wasn't the MD5 certificate hack presented
> back at 25C3 based on exactly that scenario? They used the serial number
> and timestamp or some other such thing (don't recall the details) as
> weak spots and then sent loads of certificate requests to the CA to
> effecively brute-force it.
>
> (Of course, CAs are now required to randomize their serial number, so
> since that particular attack isn't possible anymore, I agree that for
> the time being it's still not a feasible scenario for SHA1, but hey)
>

Maybe not currently for SHA-1, but maybe for MD5?

Also not sure whether you can use these old certificates with weak serials
and change the date as well there?

Regards, Niklas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170712/b9a4ea4a/attachment.html>

From jb-openssl at wisemo.com  Wed Jul 12 12:53:36 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 12 Jul 2017 14:53:36 +0200
Subject: [openssl-users] Rejecting SHA-1 certificates
In-Reply-To: <CANUQDChU2iY_mVAAzfbmeSBkGsQM4QY_M_R7L0Nq=mmX+1eSyQ@mail.gmail.com>
References: <CANUQDCgHsmUB=WSD6OGfyJucDuQHBmvKZbRdEC=8OQiTOwhrfw@mail.gmail.com>
 <1FFAE4FB-8AE4-4B04-8347-C70F1C8CE065@dukhovni.org>
 <CANUQDCg4_XP254aZi2n6wetQ3z6VE1_0Pg8t_1HMbWO43vU3qg@mail.gmail.com>
 <5229530d0c794f0c9eeccd4dce9aad4b@usma1ex-dag1mb1.msg.corp.akamai.com>
 <39a92527-3df4-aea7-57ee-2f080dc62859@fedict.be>
 <CANUQDChU2iY_mVAAzfbmeSBkGsQM4QY_M_R7L0Nq=mmX+1eSyQ@mail.gmail.com>
Message-ID: <1236afa3-aac0-33b9-3b0b-b945406e3e46@wisemo.com>

On 12/07/2017 14:24, Niklas Keller wrote:
> 2017-07-12 8:35 GMT+02:00 Wouter Verhelst <wouter.verhelst at fedict.be 
> <mailto:wouter.verhelst at fedict.be>>:
>
>     On 11-07-17 23:44, Salz, Rich via openssl-users wrote:
>     >> It's very well worth the effort, otherwise there's a security
>     issue, because certificates can be forged.
>     >
>     > No they cannot.
>     >
>     > What *has* been done is a document was created with "weak spots"
>     and another document was created that changed those weak spots,
>     but the digest was the same.
>
>     Correct me if I'm wrong, but wasn't the MD5 certificate hack presented
>     back at 25C3 based on exactly that scenario? They used the serial
>     number
>     and timestamp or some other such thing (don't recall the details) as
>     weak spots and then sent loads of certificate requests to the CA to
>     effecively brute-force it.
>
>     (Of course, CAs are now required to randomize their serial number, so
>     since that particular attack isn't possible anymore, I agree that for
>     the time being it's still not a feasible scenario for SHA1, but hey)
>
>
> Maybe not currently for SHA-1, but maybe for MD5?
>
> Also not sure whether you can use these old certificates with weak 
> serials and change the date as well there?
I think the attack was to request a certificate at exactly the right
moment to get a certificate with a date/serial combination that fit
a known hash collision value.  Making the serial contain a lot of
random bits that the requester cannot predict or control prevents
that particular attack from working.

So it's not a matter of "weak serials", but preventing "chosen
serials", at least for the currently known attack on MD5 CAs and
presumed to work against likely initial attacks on SHA-1 CAs,
especially such attacks made before the last trusted CA stops
issuing new certs (about a year ago for SSL, still ongoing for
other cert purposes due to important clients stuck without
stronger hash algorithms in their non-upgradable crypto code).

Because the fake certificate need not be for the same purpose as
the real certificate, to get a fake SSL cert, it may be enough
to attack issuance of non-SSL SHA-1 certs from a CA trusted for
SSL certs.  This is exacerbated if using an OpenSSL version that
makes insufficient checks as to what each CA cert in the chain is
trusted to issue.  Also many installations provide a single
list/directory of CA certs not subdivided by trust purpose.

These doubts and weaknesses are good reason to add an extra check
for weak hash algorithms to the chain validation, either in OpenSSL
or in an application.  At least as a defense in depth.  Of cause
adding this in OpenSSL itself would have to be configurable for
situations partially outside the public trust environment, such
as talking to IoT devices with old crypto libraries and
rechecking/decrypting S/MIME mails received years ago.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From rsalz at akamai.com  Wed Jul 12 16:17:04 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 12 Jul 2017 16:17:04 +0000
Subject: [openssl-users] Issue with TLS1.3 and s_time
In-Reply-To: <DM3PR16MB0540BFCD9A74DF5299D892F385AE0@DM3PR16MB0540.namprd16.prod.outlook.com>
References: <DM3PR16MB0540BFCD9A74DF5299D892F385AE0@DM3PR16MB0540.namprd16.prod.outlook.com>
Message-ID: <f3c95a59cf894081baf546e75e2ae1ed@usma1ex-dag1mb1.msg.corp.akamai.com>

In TLS 1.3 the ?time? field went away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170712/58216504/attachment-0001.html>

From Roelof_Dutoit at symantec.com  Wed Jul 12 18:43:10 2017
From: Roelof_Dutoit at symantec.com (Roelof Du Toit)
Date: Wed, 12 Jul 2017 18:43:10 +0000
Subject: [openssl-users] Issue with TLS1.3 and s_time
Message-ID: <D9E005D9-DC44-49F2-8054-8550C7C92068@symantec.com>

This seems to be a bug in how s_time handles the TLS 1.3 post-handshake NewSessionTicket message; more specifically: not handling the retry when SSL_read() returns -1.

The following diff (in tls1.3-draft-19 branch) appears to resolve the issue:

$ git diff
diff --git a/apps/s_time.c b/apps/s_time.c
index 998ef72..caa1b22 100644
--- a/apps/s_time.c
+++ b/apps/s_time.c
@@ -234,8 +234,8 @@ int s_time_main(int argc, char **argv)
                                    fmt_http_get_cmd, www_path);
             if (SSL_write(scon, buf, buf_len) <= 0)
                 goto end;
-            while ((i = SSL_read(scon, buf, sizeof(buf))) > 0)
-                bytes_read += i;
+            while ((i = SSL_read(scon, buf, sizeof(buf))) > 0 || BIO_should_retry(SSL_get_rbio(scon)))
+                if (i > 0) bytes_read += i;
         }


--Roelof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170712/456836d7/attachment.html>

From matt at openssl.org  Thu Jul 13 12:52:12 2017
From: matt at openssl.org (Matt Caswell)
Date: Thu, 13 Jul 2017 13:52:12 +0100
Subject: [openssl-users] Issue with TLS1.3 and s_time
In-Reply-To: <D9E005D9-DC44-49F2-8054-8550C7C92068@symantec.com>
References: <D9E005D9-DC44-49F2-8054-8550C7C92068@symantec.com>
Message-ID: <a722299a-fde8-fb03-689e-4a38efb36317@openssl.org>



On 12/07/17 19:43, Roelof Du Toit wrote:
> This seems to be a bug in how s_time handles the TLS 1.3 post-handshake
> NewSessionTicket message; more specifically: not handling the retry when
> SSL_read() returns -1.
> 
>  
> 
> The following diff (in tls1.3-draft-19 branch) appears to resolve the issue:


Probably you should use SSL_get_error() rather than BIO_should_retry().
The former is a little more complete (checks some conditions that
BIO_should_retry() does not). Could you submit this as a github PR?

Matt


> 
>  
> 
> $ git diff
> 
> diff --git a/apps/s_time.c b/apps/s_time.c
> 
> index 998ef72..caa1b22 100644
> 
> --- a/apps/s_time.c
> 
> +++ b/apps/s_time.c
> 
> @@ -234,8 +234,8 @@ int s_time_main(int argc, char **argv)
> 
>                                     fmt_http_get_cmd, www_path);
> 
>              if (SSL_write(scon, buf, buf_len) <= 0)
> 
>                  goto end;
> 
> -            while ((i = SSL_read(scon, buf, sizeof(buf))) > 0)
> 
> -                bytes_read += i;
> 
> +            while ((i = SSL_read(scon, buf, sizeof(buf))) > 0 ||
> BIO_should_retry(SSL_get_rbio(scon)))
> 
> +                if (i > 0) bytes_read += i;
> 
>          }
> 
>  
> 
>  
> 
> --Roelof
> 
> 
> 

From vieuxtech at gmail.com  Thu Jul 13 18:07:37 2017
From: vieuxtech at gmail.com (Sam Roberts)
Date: Thu, 13 Jul 2017 11:07:37 -0700
Subject: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib
	in the link line?
Message-ID: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>

I'm having trouble linking on Windows with fipslink.pl, lots of FIPS_
symbols are unresolved.

AFAICT, they are defined by the canister, and fipslink.pl is supposed
to know this, and add them to the link libraries by itself, but it
doesn't seem to do this.

Looking at the linux fipsld, it does appear to have code to find and
add fipscanister.o to the link line.

Any idea what I am doing wrong, or not understanding about fipslink.pl?

Thanks,
Sam

From steve at openssl.org  Thu Jul 13 19:34:52 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 13 Jul 2017 19:34:52 +0000
Subject: [openssl-users] shouldn't fipslink.pl include the
 fipscanister.lib in the link line?
In-Reply-To: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
Message-ID: <20170713193452.GA4799@openssl.org>

On Thu, Jul 13, 2017, Sam Roberts wrote:

> I'm having trouble linking on Windows with fipslink.pl, lots of FIPS_
> symbols are unresolved.
> 
> AFAICT, they are defined by the canister, and fipslink.pl is supposed
> to know this, and add them to the link libraries by itself, but it
> doesn't seem to do this.
> 
> Looking at the linux fipsld, it does appear to have code to find and
> add fipscanister.o to the link line.
> 
> Any idea what I am doing wrong, or not understanding about fipslink.pl?
> 

First if you want to link to the OpenSSL DLLs then you don't need fipslink.pl
at all: just link to them as you would any other application.

If you do want to link against the static libraries then the easiest way to do
that is to examine the contents of nt.mak, look for FIPSLINK and adapt the
rule to your needs.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From vieuxtech at gmail.com  Thu Jul 13 20:24:27 2017
From: vieuxtech at gmail.com (Sam Roberts)
Date: Thu, 13 Jul 2017 13:24:27 -0700
Subject: [openssl-users] shouldn't fipslink.pl include the
 fipscanister.lib in the link line?
In-Reply-To: <20170713193452.GA4799@openssl.org>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
 <20170713193452.GA4799@openssl.org>
Message-ID: <CA+Sj9TkhiuNu2VjhtwvK0H4DtL64iJmSVfWH9B=OokpkG6UEXA@mail.gmail.com>

On Thu, Jul 13, 2017 at 12:34 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
> First if you want to link to the OpenSSL DLLs then you don't need fipslink.pl
> at all: just link to them as you would any other application.

I'm working on Node.js, it links statically, so this isn't an option for me.

> If you do want to link against the static libraries then the easiest way to do
> that is to examine the contents of nt.mak, look for FIPSLINK and adapt the
> rule to your needs.

Where is nt.mak? Its mentioned in the User Guide but I didn't find it
in the github repo, or tarballs for openssl 1.0.2j or 1.1.0c, or
tarballs for openssl-fips 2.0.9, or 2.0.16

Thanks,
Sam

From steve at openssl.org  Thu Jul 13 20:41:09 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 13 Jul 2017 20:41:09 +0000
Subject: [openssl-users] shouldn't fipslink.pl include the
 fipscanister.lib in the link line?
In-Reply-To: <CA+Sj9TkhiuNu2VjhtwvK0H4DtL64iJmSVfWH9B=OokpkG6UEXA@mail.gmail.com>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
 <20170713193452.GA4799@openssl.org>
 <CA+Sj9TkhiuNu2VjhtwvK0H4DtL64iJmSVfWH9B=OokpkG6UEXA@mail.gmail.com>
Message-ID: <20170713204109.GA6116@openssl.org>

On Thu, Jul 13, 2017, Sam Roberts wrote:

> On Thu, Jul 13, 2017 at 12:34 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
> 
> > If you do want to link against the static libraries then the easiest way to do
> > that is to examine the contents of nt.mak, look for FIPSLINK and adapt the
> > rule to your needs.
> 
> Where is nt.mak? Its mentioned in the User Guide but I didn't find it
> in the github repo, or tarballs for openssl 1.0.2j or 1.1.0c, or
> tarballs for openssl-fips 2.0.9, or 2.0.16
> 

It's created by OpenSSL when you follow the Windows build procedure.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From vieuxtech at gmail.com  Thu Jul 13 21:46:39 2017
From: vieuxtech at gmail.com (Sam Roberts)
Date: Thu, 13 Jul 2017 14:46:39 -0700
Subject: [openssl-users] shouldn't fipslink.pl include the
 fipscanister.lib in the link line?
In-Reply-To: <20170713204109.GA6116@openssl.org>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
 <20170713193452.GA4799@openssl.org>
 <CA+Sj9TkhiuNu2VjhtwvK0H4DtL64iJmSVfWH9B=OokpkG6UEXA@mail.gmail.com>
 <20170713204109.GA6116@openssl.org>
Message-ID: <CA+Sj9Tko16Np7HW9v0WGDO2ex=VKe1SZdbtfpXG+hB5oXf4g=Q@mail.gmail.com>

On Thu, Jul 13, 2017 at 1:41 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
> On Thu, Jul 13, 2017, Sam Roberts wrote:
>> On Thu, Jul 13, 2017 at 12:34 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
>> > If you do want to link against the static libraries then the easiest way to do
>> > that is to examine the contents of nt.mak, look for FIPSLINK and adapt the
>> > rule to your needs.
>>
>> Where is nt.mak? Its mentioned in the User Guide but I didn't find it
>> in the github repo, or tarballs for openssl 1.0.2j or 1.1.0c, or
>> tarballs for openssl-fips 2.0.9, or 2.0.16
>>
>
> It's created by OpenSSL when you follow the Windows build procedure.

No luck so far. I dowloaded openssl-1.0.2l did the `perl Configure ...
--with=fipsdir...` from section 4.3.3 and don't have a ms/nt.mak.

Or is it openssl-fips that is going to have the ms/nt.mak? I followed
the directions in section 4.3.1 and I have a ms/ntdll.mak, but no
nt.mak.

For context, I've never done the openssl perl build (until just now,
to try to get a nt.mak), because I'm working on Node.js. It has
openssl copied into its git repo as a dependency, and builds and
statically links it using a gyp based build system. This works fine
for Linux FIPS, but I'm trying to get it working for Windows FIPS.
First I need to figure out the fipslink.pl commands to call by hand,
then I'll have the fun of trying to convince gyp to generate ninja
files that call fipslink.pl correctly.

From npathak2 at ncsu.edu  Thu Jul 13 22:52:42 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Thu, 13 Jul 2017 15:52:42 -0700
Subject: [openssl-users] session resumption tls1.2/tls1.3
Message-ID: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>

Hi All,
Help with these queries please,

1) Is it possible to use external session files (with session info as
identifiers or tickets for out of band resumption) for session resumption
in TLS 1.2. Does it need some kind of callback like the way it is used in
TLS 1.3  with (SSL_set_psk_find_session_callback) /
SSL_set_psk_use_session_callback


2) In TLS 1.3, is early data not enabled for out of band PSK session
resumption. Is it only possible with in-band session resumption.
SSL_write_early_data always fails when I load a session from a session file
to perform external PSK resumption before sending the session data. For
in-band resumption it succeeds.

Thanks
Best Regards,
Neetish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170713/835d4134/attachment.html>

From steve at openssl.org  Fri Jul 14 02:46:42 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 14 Jul 2017 02:46:42 +0000
Subject: [openssl-users] shouldn't fipslink.pl include the
 fipscanister.lib in the link line?
In-Reply-To: <CA+Sj9Tko16Np7HW9v0WGDO2ex=VKe1SZdbtfpXG+hB5oXf4g=Q@mail.gmail.com>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
 <20170713193452.GA4799@openssl.org>
 <CA+Sj9TkhiuNu2VjhtwvK0H4DtL64iJmSVfWH9B=OokpkG6UEXA@mail.gmail.com>
 <20170713204109.GA6116@openssl.org>
 <CA+Sj9Tko16Np7HW9v0WGDO2ex=VKe1SZdbtfpXG+hB5oXf4g=Q@mail.gmail.com>
Message-ID: <20170714024642.GA20103@openssl.org>

On Thu, Jul 13, 2017, Sam Roberts wrote:

> On Thu, Jul 13, 2017 at 1:41 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
> >>
> >> Where is nt.mak? Its mentioned in the User Guide but I didn't find it
> >> in the github repo, or tarballs for openssl 1.0.2j or 1.1.0c, or
> >> tarballs for openssl-fips 2.0.9, or 2.0.16
> >>
> >
> > It's created by OpenSSL when you follow the Windows build procedure.
> 
> No luck so far. I dowloaded openssl-1.0.2l did the `perl Configure ...
> --with=fipsdir...` from section 4.3.3 and don't have a ms/nt.mak.
> 

Are you compiling with VC++ that's the only compiler which is a supported for
FIPS and Windows.

If you are then you need the next step which is:

ms\do_nasm

to get ms\nt.mak

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From matt at openssl.org  Fri Jul 14 09:54:52 2017
From: matt at openssl.org (Matt Caswell)
Date: Fri, 14 Jul 2017 10:54:52 +0100
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
Message-ID: <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>



On 13/07/17 23:52, Neetish Pathak wrote:
> Hi All,
> Help with these queries please,
> 
> 1) Is it possible to use external session files (with session info as
> identifiers or tickets for out of band resumption) for session
> resumption in TLS 1.2. Does it need some kind of callback like the way
> it is used in TLS 1.3  with (SSL_set_psk_find_session_callback) /
> SSL_set_psk_use_session_callback

I'm not entirely clear what you're asking here. The callbacks you
mention are for setting up an external PSK in TLSv1.3. In TLSv1.3 we use
an SSL_SESSION object to encapsulate the PSK details. This is different
to session resumption, where the server sends the session details in a
NewSessionTicket message in one connection, so that we can "resume" it
in a later connection.

So if your question is really "can you external session files for PSK in
TLSv1.2" then the answer is no. PSK works completely differently in TLSv1.2.


> 2) In TLS 1.3, is early data not enabled for out of band PSK session
> resumption. Is it only possible with in-band session resumption. 
> SSL_write_early_data always fails when I load a session from a session
> file to perform external PSK resumption before sending the session data.
> For in-band resumption it succeeds.

Currently we only support early-data for ticket based resumption. You
cannot do it with an external PSK. However this PR (which is currently
going through review) will add that capability:

https://github.com/openssl/openssl/pull/3926

Matt


From aes7dc at mst.edu  Fri Jul 14 15:41:24 2017
From: aes7dc at mst.edu (Andrea Smith)
Date: Fri, 14 Jul 2017 10:41:24 -0500
Subject: [openssl-users] nmake win32 failure
Message-ID: <CAF4jXD0xiawAFkA7FZ9_6MTi8Y1LM2W57VqYCO3QmH_kktz9Hw@mail.gmail.com>

I have successfully gotten a setup for win64 and am trying to get one for
win32 now. I am using version 1.1.0f. I ran the following configure command
successfully:

perl Configure VC-WIN32 -no-asm

However, when I run the nmake command, I get linker errors (unresolved
external symbol) for OPENSSL_UplinkTable while it's creating libcrypto.lib.
All of the examples I am seeing online refer to the "ms/do_ms.bat" command,
which seems to have gone away recently.

Thoughts?

-- 

*Ariella*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170714/bb659419/attachment.html>

From matt at openssl.org  Fri Jul 14 17:14:20 2017
From: matt at openssl.org (Matt Caswell)
Date: Fri, 14 Jul 2017 18:14:20 +0100
Subject: [openssl-users] nmake win32 failure
In-Reply-To: <CAF4jXD0xiawAFkA7FZ9_6MTi8Y1LM2W57VqYCO3QmH_kktz9Hw@mail.gmail.com>
References: <CAF4jXD0xiawAFkA7FZ9_6MTi8Y1LM2W57VqYCO3QmH_kktz9Hw@mail.gmail.com>
Message-ID: <08a743a0-a86d-df1c-7629-26bf8b8f8ed2@openssl.org>



On 14/07/17 16:41, Andrea Smith wrote:
> I have successfully gotten a setup for win64 and am trying to get one
> for win32 now. I am using version 1.1.0f. I ran the following configure
> command successfully:
> 
> perl Configure VC-WIN32 -no-asm
> 
> However, when I run the nmake command, I get linker errors (unresolved
> external symbol) for OPENSSL_UplinkTable while it's creating
> libcrypto.lib.


This happens if you attempt to build OpenSSL configured for 32-bit from
the Visual Studio Developer command prompt for x64. You need to use the
developer command prompt for 32 bit.

Incidentally, I would recommend against no-asm unless you really need to
use it. Using it will impact both your performance (no optimised
algorithm implementations) and your security (misses out some constant
time implementations).

> All of the examples I am seeing online refer to the
> "ms/do_ms.bat" command, which seems to have gone away recently.

Those examples are referring to OpenSSL 1.0.2 and below. The build
procedure changed significantly in OpenSSL 1.1.0.

Matt

From npathak2 at ncsu.edu  Fri Jul 14 19:18:02 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Fri, 14 Jul 2017 12:18:02 -0700
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
Message-ID: <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>

On Fri, Jul 14, 2017 at 2:54 AM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 13/07/17 23:52, Neetish Pathak wrote:
> > Hi All,
> > Help with these queries please,
> >
> > 1) Is it possible to use external session files (with session info as
> > identifiers or tickets for out of band resumption) for session
> > resumption in TLS 1.2. Does it need some kind of callback like the way
> > it is used in TLS 1.3  with (SSL_set_psk_find_session_callback) /
> > SSL_set_psk_use_session_callback
>
> I'm not entirely clear what you're asking here. The callbacks you
> mention are for setting up an external PSK in TLSv1.3. In TLSv1.3 we use
> an SSL_SESSION object to encapsulate the PSK details. This is different
> to session resumption, where the server sends the session details in a
> NewSessionTicket message in one connection, so that we can "resume" it
> in a later connection.
>
> So if your question is really "can you external session files for PSK in
> TLSv1.2" then the answer is no. PSK works completely differently in
> TLSv1.2.
>

Thanks Matt, Apologies for ambiguity in the question

What I mean to ask is it possible to use out of band resumption in TLS 1.2?
How I perform the resumption in my programs using TLS 1.2 is as follows :
1)  Connect client to the server  for the first time
2) when the server sends session id or tickets as the case may be,
new_session_callback is invoked on the client side and I save the session
in a pem file using PEM_write_bio_SSL_SESSION
3)Now when connecting client to the server next time, I read the session
from the pem file and set using SSL_set_session.
4)Session resumption is initiated from the client side and the server works
as expected since it had been caching the session and was not killed.

I observe that the second connection (and subsequent connections) takes
place using resumption. As per my understanding, this is called in-band
resumption

Now my question is if, I kill the server. I re-initialze the server and
want to use the session(pem) file to connect to the server (this is a fresh
connection which should take place using resumption).
In that case, I will need to set the session on both the ends right? Is
this approach correct? In that case, how should one implement it.
This is out-of-band resumption for TLS 1.2 as per my understanding.
Please correct me if I am wrong

Thanks
Best Regards,
Neetish


Thanks

>
>
> > 2) In TLS 1.3, is early data not enabled for out of band PSK session
> > resumption. Is it only possible with in-band session resumption.
> > SSL_write_early_data always fails when I load a session from a session
> > file to perform external PSK resumption before sending the session data.
> > For in-band resumption it succeeds.
>
> Currently we only support early-data for ticket based resumption. You
> cannot do it with an external PSK. However this PR (which is currently
> going through review) will add that capability:
>
> https://github.com/openssl/openssl/pull/3926
>
> Matt
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170714/eb34dcc5/attachment-0001.html>

From Michal.Trojnara at stunnel.org  Sun Jul 16 19:41:21 2017
From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=)
Date: Sun, 16 Jul 2017 21:41:21 +0200
Subject: [openssl-users] stunnel 5.42 released
Message-ID: <2c19aa2d-2c1b-447c-e046-5a7192372f68@stunnel.org>

Dear Users,

I have released version 5.42 of stunnel.

Version 5.42, 2017.07.16, urgency: HIGH
* New features
  - "redirect" also supports "exec" and not only "connect".
  - PKCS#11 engine DLL updated to version 0.4.7.
* Bugfixes
  - Fixed premature cron thread initialization causing hangs.
  - Fixed "verifyPeer = yes" on OpenSSL <= 1.0.1.
  - Fixed pthreads support on OpenSolaris.

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

SHA-256 hashes:
1b6a7aea5ca223990bc8bd621fb0846baa4278e1b3e00ff6eee279cb8e540fab
stunnel-5.42.tar.gz
f3d612b907e2562182c574353c11ce793a3957b88266d5ace0fa99a05d4325e8
stunnel-5.42-win32-installer.exe
9cac7f5b8a11f6d730253e7eb8550f0924af3010fef3149698b174617ee41ccf
stunnel-5.42-android.zip

Best regards,
    Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170716/a3b105f1/attachment.sig>

From matt at openssl.org  Mon Jul 17 08:54:39 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 17 Jul 2017 09:54:39 +0100
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
Message-ID: <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>



On 14/07/17 20:18, Neetish Pathak wrote:
> 
> 
> On Fri, Jul 14, 2017 at 2:54 AM, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 13/07/17 23:52, Neetish Pathak wrote:
>     > Hi All,
>     > Help with these queries please,
>     >
>     > 1) Is it possible to use external session files (with session info as
>     > identifiers or tickets for out of band resumption) for session
>     > resumption in TLS 1.2. Does it need some kind of callback like the way
>     > it is used in TLS 1.3  with (SSL_set_psk_find_session_callback) /
>     > SSL_set_psk_use_session_callback
> 
>     I'm not entirely clear what you're asking here. The callbacks you
>     mention are for setting up an external PSK in TLSv1.3. In TLSv1.3 we use
>     an SSL_SESSION object to encapsulate the PSK details. This is different
>     to session resumption, where the server sends the session details in a
>     NewSessionTicket message in one connection, so that we can "resume" it
>     in a later connection.
> 
>     So if your question is really "can you external session files for PSK in
>     TLSv1.2" then the answer is no. PSK works completely differently in
>     TLSv1.2.
> 
> 
> Thanks Matt, Apologies for ambiguity in the question
> 
> What I mean to ask is it possible to use out of band resumption in TLS 1.2?
> How I perform the resumption in my programs using TLS 1.2 is as follows :
> 1)  Connect client to the server  for the first time
> 2) when the server sends session id or tickets as the case may be,
> new_session_callback is invoked on the client side and I save the
> session in a pem file using PEM_write_bio_SSL_SESSION
> 3)Now when connecting client to the server next time, I read the session
> from the pem file and set using SSL_set_session. 
> 4)Session resumption is initiated from the client side and the server
> works as expected since it had been caching the session and was not killed.
> 
> I observe that the second connection (and subsequent connections) takes
> place using resumption. As per my understanding, this is called in-band
> resumption
> 
> Now my question is if, I kill the server. I re-initialze the server and
> want to use the session(pem) file to connect to the server (this is a
> fresh connection which should take place using resumption).
> In that case, I will need to set the session on both the ends right? Is
> this approach correct? In that case, how should one implement it. 
> This is out-of-band resumption for TLS 1.2 as per my understanding.
> Please correct me if I am wrong

The term out-of-band resumption is somewhat confusing. Anyway, the
server maintains a session cache. That cache can either be internal
(i.e. maintained by OpenSSL), or external (maintained by your own
application code). In the default case a server will just use the
internal session cache. You can populate that cache manually using
SSL_CTX_add_session(). So if you have a set of pre-existing SSL_SESSION
objects (perhaps loaded from a file) you can manually populate that
cache at application startup.

Matt

From vieuxtech at gmail.com  Mon Jul 17 22:20:16 2017
From: vieuxtech at gmail.com (Sam Roberts)
Date: Mon, 17 Jul 2017 15:20:16 -0700
Subject: [openssl-users] shouldn't fipslink.pl include the
 fipscanister.lib in the link line?
In-Reply-To: <20170714024642.GA20103@openssl.org>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
 <20170713193452.GA4799@openssl.org>
 <CA+Sj9TkhiuNu2VjhtwvK0H4DtL64iJmSVfWH9B=OokpkG6UEXA@mail.gmail.com>
 <20170713204109.GA6116@openssl.org>
 <CA+Sj9Tko16Np7HW9v0WGDO2ex=VKe1SZdbtfpXG+hB5oXf4g=Q@mail.gmail.com>
 <20170714024642.GA20103@openssl.org>
Message-ID: <CA+Sj9Tk8v+f8hTTmuAdvV-TQLjM004GFju_y6y9_5UjD=gdesg@mail.gmail.com>

On Thu, Jul 13, 2017 at 7:46 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
> On Thu, Jul 13, 2017, Sam Roberts wrote:
>
>> On Thu, Jul 13, 2017 at 1:41 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
>> >>
>> >> Where is nt.mak? Its mentioned in the User Guide but I didn't find it
>> >> in the github repo, or tarballs for openssl 1.0.2j or 1.1.0c, or
>> >> tarballs for openssl-fips 2.0.9, or 2.0.16
>> >>
>> >
>> > It's created by OpenSSL when you follow the Windows build procedure.
>>
>> No luck so far. I dowloaded openssl-1.0.2l did the `perl Configure ...
>> --with=fipsdir...` from section 4.3.3 and don't have a ms/nt.mak.
>>
>
> Are you compiling with VC++ that's the only compiler which is a supported for
> FIPS and Windows.

yes, visual studio 2015

> If you are then you need the next step which is:
>
> ms\do_nasm
>
> to get ms\nt.mak


That worked to get me the file, thanks.

From noloader at gmail.com  Tue Jul 18 17:25:04 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 18 Jul 2017 13:25:04 -0400
Subject: [openssl-users] Configure 1.0.2 for Windows without readscreen()
Message-ID: <CAH8yC8mp5eDJc4mBkwxbCHzkOyv7dwVBZ8dG+YsEAqYiEwF34Q@mail.gmail.com>

Hi Everyone,

Windows 10 makes CreateCompatibleBitmap (and friends) available for
Desktop Apps only. For other builds, like phones and IoT gadgets, the
functions are not available.

My question is, is it possible to configure OpenSSL 1.0.2 to avoid the
missing Windows APIs, like readscreen()?

If not, is there a way to remove the Windows API specific stuff except
maybe CryptGenRandom?

Looking at https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/rand/rand_win.c,
I don't see an interesting guard. So I'm guessing the rand_win
generator may need to be removed.

Jeff

From npathak2 at ncsu.edu  Tue Jul 18 21:27:07 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Tue, 18 Jul 2017 14:27:07 -0700
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
Message-ID: <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>

On Mon, Jul 17, 2017 at 1:54 AM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 14/07/17 20:18, Neetish Pathak wrote:
> >
> >
> > On Fri, Jul 14, 2017 at 2:54 AM, Matt Caswell <matt at openssl.org
> > <mailto:matt at openssl.org>> wrote:
> >
> >
> >
> >     On 13/07/17 23:52, Neetish Pathak wrote:
> >     > Hi All,
> >     > Help with these queries please,
> >     >
> >     > 1) Is it possible to use external session files (with session info
> as
> >     > identifiers or tickets for out of band resumption) for session
> >     > resumption in TLS 1.2. Does it need some kind of callback like the
> way
> >     > it is used in TLS 1.3  with (SSL_set_psk_find_session_callback) /
> >     > SSL_set_psk_use_session_callback
> >
> >     I'm not entirely clear what you're asking here. The callbacks you
> >     mention are for setting up an external PSK in TLSv1.3. In TLSv1.3 we
> use
> >     an SSL_SESSION object to encapsulate the PSK details. This is
> different
> >     to session resumption, where the server sends the session details in
> a
> >     NewSessionTicket message in one connection, so that we can "resume"
> it
> >     in a later connection.
> >
> >     So if your question is really "can you external session files for
> PSK in
> >     TLSv1.2" then the answer is no. PSK works completely differently in
> >     TLSv1.2.
> >
> >
> > Thanks Matt, Apologies for ambiguity in the question
> >
> > What I mean to ask is it possible to use out of band resumption in TLS
> 1.2?
> > How I perform the resumption in my programs using TLS 1.2 is as follows :
> > 1)  Connect client to the server  for the first time
> > 2) when the server sends session id or tickets as the case may be,
> > new_session_callback is invoked on the client side and I save the
> > session in a pem file using PEM_write_bio_SSL_SESSION
> > 3)Now when connecting client to the server next time, I read the session
> > from the pem file and set using SSL_set_session.
> > 4)Session resumption is initiated from the client side and the server
> > works as expected since it had been caching the session and was not
> killed.
> >
> > I observe that the second connection (and subsequent connections) takes
> > place using resumption. As per my understanding, this is called in-band
> > resumption
> >
> > Now my question is if, I kill the server. I re-initialze the server and
> > want to use the session(pem) file to connect to the server (this is a
> > fresh connection which should take place using resumption).
> > In that case, I will need to set the session on both the ends right? Is
> > this approach correct? In that case, how should one implement it.
> > This is out-of-band resumption for TLS 1.2 as per my understanding.
> > Please correct me if I am wrong
>
> The term out-of-band resumption is somewhat confusing. Anyway, the
> server maintains a session cache. That cache can either be internal
> (i.e. maintained by OpenSSL), or external (maintained by your own
> application code). In the default case a server will just use the
> internal session cache. You can populate that cache manually using
> SSL_CTX_add_session(). So if you have a set of pre-existing SSL_SESSION
> objects (perhaps loaded from a file) you can manually populate that
> cache at application startup.
>



Hi ,
thanks Matt, this is helpful


One more query on how I can enable 0.5 RTT data from the server side. It is
mentioned in TLS 1.3 specification. I thought it can be implemented by
sending early data  from server side after reading the early data. But then
how can that data be read on the client side since read_early_data api is
invalid on client side ?

Thanks
Best Regards,
Neetish

>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170718/c401d68c/attachment-0001.html>

From openssl-users at dukhovni.org  Tue Jul 18 21:43:47 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 18 Jul 2017 21:43:47 +0000
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
Message-ID: <20170718214347.GX8146@mournblade.imrryr.org>

On Mon, Jul 17, 2017 at 09:54:39AM +0100, Matt Caswell wrote:

>                    In the default case a server will just use the
> internal session cache. You can populate that cache manually using
> SSL_CTX_add_session(). So if you have a set of pre-existing SSL_SESSION
> objects (perhaps loaded from a file) you can manually populate that
> cache at application startup.

When server side (non-ticket) caches are enabled in Postfix it uses
a file-based key-value store.  The lookup key is the session id
sent by the client, and the value is the serialized session object.

So it is also possible to load saved sessions on demand.  In Postfix
this is used to share sessions within a pool of cooperating processes,
and the cache is deleted on restart, but that's a design choice
that other applications could (with care) make differently.  I
would avoid using session objects across changes in the OpenSSL
library version between the process that saved the session and the
process that's reading it.

-- 
	Viktor.

From jmogannam at arkhamtechnology.com  Tue Jul 18 22:06:48 2017
From: jmogannam at arkhamtechnology.com (Justin Mogannam)
Date: Tue, 18 Jul 2017 15:06:48 -0700
Subject: [openssl-users] Extract content of DER-encoded package by OID
Message-ID: <1cb401d30012$27103020$75309060$@arkhamtechnology.com>

Hello, 
I have a signedData package that contains an encryptedKeyPackage
(specifically OID 2.16.840.1.101.2.1.2.78.2, aka id-ct-KP-encryptedKeyPkg)
that I want to extract from it. I am somewhat able to extract the sequence
that contains this data via the OpenSSL command line: 

$ openssl asn1parse -in <my_pkg.der> -inform DER -strparse <hard-coded
offset I computed>

However, I am looking for the OpenSSL calls to do the same thing, ideally
extract package contents by its OID without having to know the offset (such
that I can extract the data from any given package by that particular OID).
How would I go about doing this? I've been looking endlessly into asn1.h and
x509.h, and am able to somewhat parse the entire package into a structure,
but I could use some guidance as to how to further break it down into parts.
Thank you, and I hope to hear a response back soon. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170718/c4800e93/attachment.html>

From matt at openssl.org  Wed Jul 19 09:27:45 2017
From: matt at openssl.org (Matt Caswell)
Date: Wed, 19 Jul 2017 10:27:45 +0100
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
Message-ID: <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>



On 18/07/17 22:27, Neetish Pathak wrote:
> Hi ,
> thanks Matt, this is helpful
> 
> 
> One more query on how I can enable 0.5 RTT data from the server side. It
> is mentioned in TLS 1.3 specification. I thought it can be implemented
> by sending early data  from server side after reading the early data.

That is correct, and is as documented on this page:

https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html

> But then how can that data be read on the client side since
> read_early_data api is invalid on client side ?

0.5 RTT data is sent from the server to an unauthenticated client. At
this point in the process the server has sent all of its messages
(including its Certificate/CertificateVerify/Finished messages) but it
has not received the Client Finished or any client
Certificate/CertificateVerify if one is going to be sent.

>From the client's perspective 0.5 RTT data is received *after* it has
processed the server's Certificate/CertificateVerify/Finished messages),
and after it has sent its own Finished (and
Certificate/CertificateVerify if appropriate). In other words from the
client's perspective the server is fully authenticated and 0.5 RTT data
is indistinguishable from post-handshake data. Just use SSL_read() as
normal to receive it.

Matt

From steve at openssl.org  Wed Jul 19 11:25:54 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 19 Jul 2017 11:25:54 +0000
Subject: [openssl-users] Extract content of DER-encoded package by OID
In-Reply-To: <1cb401d30012$27103020$75309060$@arkhamtechnology.com>
References: <1cb401d30012$27103020$75309060$@arkhamtechnology.com>
Message-ID: <20170719112554.GA7698@openssl.org>

On Tue, Jul 18, 2017, Justin Mogannam wrote:

> Hello, 
> I have a signedData package that contains an encryptedKeyPackage
> (specifically OID 2.16.840.1.101.2.1.2.78.2, aka id-ct-KP-encryptedKeyPkg)
> that I want to extract from it. I am somewhat able to extract the sequence
> that contains this data via the OpenSSL command line: 
> 
> $ openssl asn1parse -in <my_pkg.der> -inform DER -strparse <hard-coded
> offset I computed>
> 
> However, I am looking for the OpenSSL calls to do the same thing, ideally
> extract package contents by its OID without having to know the offset (such
> that I can extract the data from any given package by that particular OID).
> How would I go about doing this? I've been looking endlessly into asn1.h and
> x509.h, and am able to somewhat parse the entire package into a structure,
> but I could use some guidance as to how to further break it down into parts.
> Thank you, and I hope to hear a response back soon. 
> 

Well if this follows RFC6032 the outer part will be a ContentInfo structure
which you can parse using d2i_CMS_ContentInfo. From there you can use various
utility functions to analyse it.

For example CMS_get0_eContentType() to get the OID corresponding to the
encapsulated content type and CMS_get0_content() which (if I read the spec
correctly) should get you the EncryptedKeyPackage structure. After that you'll
have to parse it yourself because OpenSSL doesn't support that atructure.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From vieuxtech at gmail.com  Wed Jul 19 18:27:02 2017
From: vieuxtech at gmail.com (Sam Roberts)
Date: Wed, 19 Jul 2017 11:27:02 -0700
Subject: [openssl-users] shouldn't fipslink.pl include the
	fipscanister.lib in the link line?
In-Reply-To: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
Message-ID: <CA+Sj9TmRA8DZ5GqUqsDUv-SNLKT-Db6cVNtXOJfCtCi4w_8emg@mail.gmail.com>

On Thu, Jul 13, 2017 at 11:07 AM, Sam Roberts <vieuxtech at gmail.com> wrote:
> I'm having trouble linking on Windows with fipslink.pl, lots of FIPS_
> symbols are unresolved.

OK, I attempted to do as ms/nt.mak does, rewriting it as a batch file:
https://github.com/sam-github/node/blob/fips-win-ninja/fipslink.bat,
no luck yet.

The args are passed in %2 as a response file from
https://github.com/sam-github/node/blob/574ddeff5197d097d7d872e2ef03127b95b4d5f9/out/Release/build.ninja#L70-L71,
the rsp file is
https://github.com/sam-github/node/blob/574ddeff5197d097d7d872e2ef03127b95b4d5f9/out/Release/openssl-cli.exe.rsp#L52

Note that the lib names used in the node gyp build of openssl vary a
bit from the perl/ms makefile build.

Anyhow, still the same link errors. My eventual goal is to build a
fips node on Windows (Linux works already), but one of its build
pre-reqs is the openssl CLI:

C:\Users\rsam\node\out\Release>c:\users\rsam\perl\bin\perl.exe c:\usr\local\ssl\
fips-2.0\bin\fipslink.pl /nologo /subsystem:console /opt:ref /debug /out:openssl
-cli.exe .\fips_premain.obj @openssl-cli.exe.rsp
Integrity check OK
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\cl.exe" /Fo.\f
ips_premain.obj  -c c:\usr\local\ssl\fips-2.0\lib/fips_premain.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

fips_premain.c
link /nologo /subsystem:console /opt:ref /debug /out:openssl-cli.exe .\fips_prem
ain.obj @openssl-cli.exe.rsp
fips_premain.obj : error LNK2001: unresolved external symbol FIPS_text_start
fips_premain.obj : error LNK2001: unresolved external symbol FIPS_incore_fingerp
rint
fips_premain.obj : error LNK2001: unresolved external symbol FIPS_signature
crypto.lib(openssl.rand_lib.obj) : error LNK2001: unresolved external symbol FIP
S_rand_set_method
crypto.lib(openssl.rand_lib.obj) : error LNK2001: unresolved external symbol FIP
S_get_default_drbg
etc...


I'd love any suggestions, as-is, the only way I can think of to figure
out how FIPS builds are supposed to work is to do a pure-openssl fips
build, get a dump of all the compile and link commands done by the
generated makefiles, s and try working from there to reverse engineer
what the ninja/batch file build should be trying to do.

From jmogannam at arkhamtechnology.com  Wed Jul 19 22:17:04 2017
From: jmogannam at arkhamtechnology.com (Justin Mogannam)
Date: Wed, 19 Jul 2017 15:17:04 -0700
Subject: [openssl-users] Extract content of DER-encoded package by OID
In-Reply-To: <20170719112554.GA7698@openssl.org>
References: <1cb401d30012$27103020$75309060$@arkhamtechnology.com>
 <20170719112554.GA7698@openssl.org>
Message-ID: <0b5001d300dc$c07b2f60$41718e20$@arkhamtechnology.com>

Hi Steve,
What you've described sounds exactly like what I want to do. Couple of
questions/concerns in regards to what you've just stated:

1) Is there a way to initialize a CMS_ContentInfo structure like there is a
way to initialize a BIO structure (such as with BIO_new()? ). I'm looking
through openssl/cms.h but I'm not seeing anything.

2) Once again, I'm looking in openssl/cms.h, and I could not find the
function prototype " d2i_CMS_ContentInfo". I even did a grep on the whole
directory. Is it located somewhere else? I have OpenSSL 1.0.1, which is
after 0.9.8 when the function was added to OpenSSL. 

3) In looking at the function prototype (via
https://www.openssl.org/docs/man1.0.2/crypto/d2i_CMS_ContentInfo.html):
CMS_ContentInfo *d2i_CMS_ContentInfo(CMS_ContentInfo **a, unsigned char
**pp, long length);
I'm assuming **pp is just a pointer to the array with the DER-encoded
certificate in it? I just want to make sure since some of the parameter
names are a little ambiguous in OpenSSL. 

I'm assuming once I'm able to get the DER-encoded certificate in a CMS
object, I can use the function you provided and the ones in cms.h to strip
off "layers" of the certificate to get the encryptedKeyPackage that I want
(which, of course as you mentioned, I'll be able to handle the rest from
there). Thank you very much for your response, as it was very helpful, and I
hope to get just as useful of a response back!

- Justin

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
Dr. Stephen Henson
Sent: Wednesday, July 19, 2017 4:26 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Extract content of DER-encoded package by OID

On Tue, Jul 18, 2017, Justin Mogannam wrote:

> Hello,
> I have a signedData package that contains an encryptedKeyPackage 
> (specifically OID 2.16.840.1.101.2.1.2.78.2, aka 
> id-ct-KP-encryptedKeyPkg) that I want to extract from it. I am 
> somewhat able to extract the sequence that contains this data via the
OpenSSL command line:
> 
> $ openssl asn1parse -in <my_pkg.der> -inform DER -strparse <hard-coded 
> offset I computed>
> 
> However, I am looking for the OpenSSL calls to do the same thing, 
> ideally extract package contents by its OID without having to know the 
> offset (such that I can extract the data from any given package by that
particular OID).
> How would I go about doing this? I've been looking endlessly into 
> asn1.h and x509.h, and am able to somewhat parse the entire package 
> into a structure, but I could use some guidance as to how to further break
it down into parts.
> Thank you, and I hope to hear a response back soon. 
> 

Well if this follows RFC6032 the outer part will be a ContentInfo structure
which you can parse using d2i_CMS_ContentInfo. From there you can use
various utility functions to analyse it.

For example CMS_get0_eContentType() to get the OID corresponding to the
encapsulated content type and CMS_get0_content() which (if I read the spec
correctly) should get you the EncryptedKeyPackage structure. After that
you'll have to parse it yourself because OpenSSL doesn't support that
atructure.

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


From steve at openssl.org  Thu Jul 20 01:27:17 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 20 Jul 2017 01:27:17 +0000
Subject: [openssl-users] shouldn't fipslink.pl include the
 fipscanister.lib in the link line?
In-Reply-To: <CA+Sj9TmRA8DZ5GqUqsDUv-SNLKT-Db6cVNtXOJfCtCi4w_8emg@mail.gmail.com>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
 <CA+Sj9TmRA8DZ5GqUqsDUv-SNLKT-Db6cVNtXOJfCtCi4w_8emg@mail.gmail.com>
Message-ID: <20170720012717.GA23899@openssl.org>

On Wed, Jul 19, 2017, Sam Roberts wrote:

> 
> Note that the lib names used in the node gyp build of openssl vary a
> bit from the perl/ms makefile build.
> 
> Anyhow, still the same link errors. My eventual goal is to build a
> fips node on Windows (Linux works already), but one of its build
> pre-reqs is the openssl CLI:
> 
> C:\Users\rsam\node\out\Release>c:\users\rsam\perl\bin\perl.exe c:\usr\local\ssl\
> fips-2.0\bin\fipslink.pl /nologo /subsystem:console /opt:ref /debug /out:openssl
> -cli.exe .\fips_premain.obj @openssl-cli.exe.rsp
> Integrity check OK
> "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\cl.exe" /Fo.\f
> ips_premain.obj  -c c:\usr\local\ssl\fips-2.0\lib/fips_premain.c
> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x64
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> fips_premain.c
> link /nologo /subsystem:console /opt:ref /debug /out:openssl-cli.exe .\fips_prem
> ain.obj @openssl-cli.exe.rsp
> fips_premain.obj : error LNK2001: unresolved external symbol FIPS_text_start
> fips_premain.obj : error LNK2001: unresolved external symbol FIPS_incore_fingerp
> rint
> fips_premain.obj : error LNK2001: unresolved external symbol FIPS_signature
> crypto.lib(openssl.rand_lib.obj) : error LNK2001: unresolved external symbol FIP
> S_rand_set_method
> crypto.lib(openssl.rand_lib.obj) : error LNK2001: unresolved external symbol FIP
> S_get_default_drbg
> etc...
> 
> 
> I'd love any suggestions, as-is, the only way I can think of to figure
> out how FIPS builds are supposed to work is to do a pure-openssl fips
> build, get a dump of all the compile and link commands done by the
> generated makefiles, s and try working from there to reverse engineer
> what the ninja/batch file build should be trying to do.

Try linking with fipscanister.lib too: that's where those symbols are located.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Thu Jul 20 01:32:24 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 20 Jul 2017 01:32:24 +0000
Subject: [openssl-users] Extract content of DER-encoded package by OID
In-Reply-To: <0b5001d300dc$c07b2f60$41718e20$@arkhamtechnology.com>
References: <1cb401d30012$27103020$75309060$@arkhamtechnology.com>
 <20170719112554.GA7698@openssl.org>
 <0b5001d300dc$c07b2f60$41718e20$@arkhamtechnology.com>
Message-ID: <20170720013224.GB23899@openssl.org>

On Wed, Jul 19, 2017, Justin Mogannam wrote:

> 
> 2) Once again, I'm looking in openssl/cms.h, and I could not find the
> function prototype " d2i_CMS_ContentInfo". I even did a grep on the whole
> directory. Is it located somewhere else? I have OpenSSL 1.0.1, which is
> after 0.9.8 when the function was added to OpenSSL. 
> 

See:

https://www.openssl.org/docs/faq.html#PROG13


> 3) In looking at the function prototype (via
> https://www.openssl.org/docs/man1.0.2/crypto/d2i_CMS_ContentInfo.html):
> CMS_ContentInfo *d2i_CMS_ContentInfo(CMS_ContentInfo **a, unsigned char
> **pp, long length);
> I'm assuming **pp is just a pointer to the array with the DER-encoded
> certificate in it? I just want to make sure since some of the parameter
> names are a little ambiguous in OpenSSL. 
> 
> I'm assuming once I'm able to get the DER-encoded certificate in a CMS
> object, I can use the function you provided and the ones in cms.h to strip
> off "layers" of the certificate to get the encryptedKeyPackage that I want
> (which, of course as you mentioned, I'll be able to handle the rest from
> there). Thank you very much for your response, as it was very helpful, and I
> hope to get just as useful of a response back!
> 

I'm not sure what you mean by "certificate" here. The structure you mentioned
will be a CMS ContentInfo. 

Anyway see:

https://www.openssl.org/docs/faq.html#PROG3

for details about how to decode the DER form.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From tom.browder at gmail.com  Thu Jul 20 19:06:34 2017
From: tom.browder at gmail.com (Tom Browder)
Date: Thu, 20 Jul 2017 14:06:34 -0500
Subject: [openssl-users] [ssllabs-discuss] Apache configuration
In-Reply-To: <0022ac31-0063-c32c-cf99-05e485cab034@thelounge.net>
References: <CAFMGiz_33=vWfMXLD8EbkoHQwrUeUSuRM+RkOOi-V1asZ6rjfA@mail.gmail.com>
 <4531bea4-3f67-bc50-d316-220b3ddf3398@posteo.de>
 <CAFMGiz8c==d_pLaAQLU1ozbOiHLnbSqXTec3=7MKP0iU83Zy+A@mail.gmail.com>
 <95606bfe-b37f-15c9-caf1-b4d09f398ba5@thelounge.net>
 <CAFMGiz-p0UT3tL4DCCrP+2hF9zyD973-3Eb7iH1JoAq1tGZsaQ@mail.gmail.com>
 <d65c5058-5edb-5228-b030-817cabf3cae0@thelounge.net>
 <CAFMGiz_14qOUv6VJiD5ukcDPWdL=1viXFpwzYjTqFdZN7gMVdQ@mail.gmail.com>
 <0022ac31-0063-c32c-cf99-05e485cab034@thelounge.net>
Message-ID: <CAFMGiz9N3qGEX+qe-xo7SeZQmmE5ZJvSPS3RYQYvNE1wsW-Urg@mail.gmail.com>

On Thu, Jul 20, 2017 at 1:57 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>>> Am 20.07.2017 um 18:02 schrieb Tom Browder
>>>> On Thu, Jul 20, 2017 at 10:54 AM, Reindl Harald <h.reindl at thelounge.net>
>>>> wrote
...
>> P.S.  Of course the other part of my motivation in the past has been
>> to see if it can be made to work, regardless of need (due to my
>> butt-head gene from my father's side of the family)
>
...
> well, openssl is the straight to hell
>
> load something into your webserver built against 1.1 and have fun when a
> system library loads 1.0.x by watching the crash

Then what about Ivan's recommendation about installing openssl
alongside a system-wide one?  If that can't be done reliably, surely
there has been a bug report submitted. (I haven't looked at bugs in a
long time)?

-Tom

From jmogannam at arkhamtechnology.com  Thu Jul 20 18:39:32 2017
From: jmogannam at arkhamtechnology.com (Justin Mogannam)
Date: Thu, 20 Jul 2017 11:39:32 -0700
Subject: [openssl-users] Extract content of DER-encoded package by OID
In-Reply-To: <20170720013224.GB23899@openssl.org>
References: <1cb401d30012$27103020$75309060$@arkhamtechnology.com>
 <20170719112554.GA7698@openssl.org>
 <0b5001d300dc$c07b2f60$41718e20$@arkhamtechnology.com>
 <20170720013224.GB23899@openssl.org>
Message-ID: <025201d30187$873ef820$95bce860$@arkhamtechnology.com>

Thanks for the tips thus far. One of the last issues I'm having is actually
declaring a CMS_ContentInfo structure. I just declare :

CMS_ContentInfo cms;

Amd gcc tells me "error: storage size of 'cms' isn't known". This goes back
to my question 1 of the previous email: is there a particular function call
to use to construct a CMS_ContentInfo structure? Thanks! 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
Dr. Stephen Henson
Sent: Wednesday, July 19, 2017 6:32 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Extract content of DER-encoded package by OID

On Wed, Jul 19, 2017, Justin Mogannam wrote:

> 
> 2) Once again, I'm looking in openssl/cms.h, and I could not find the 
> function prototype " d2i_CMS_ContentInfo". I even did a grep on the 
> whole directory. Is it located somewhere else? I have OpenSSL 1.0.1, 
> which is after 0.9.8 when the function was added to OpenSSL.
> 

See:

https://www.openssl.org/docs/faq.html#PROG13


> 3) In looking at the function prototype (via
> https://www.openssl.org/docs/man1.0.2/crypto/d2i_CMS_ContentInfo.html):
> CMS_ContentInfo *d2i_CMS_ContentInfo(CMS_ContentInfo **a, unsigned 
> char **pp, long length); I'm assuming **pp is just a pointer to the 
> array with the DER-encoded certificate in it? I just want to make sure 
> since some of the parameter names are a little ambiguous in OpenSSL.
> 
> I'm assuming once I'm able to get the DER-encoded certificate in a CMS 
> object, I can use the function you provided and the ones in cms.h to 
> strip off "layers" of the certificate to get the encryptedKeyPackage 
> that I want (which, of course as you mentioned, I'll be able to handle 
> the rest from there). Thank you very much for your response, as it was 
> very helpful, and I hope to get just as useful of a response back!
> 

I'm not sure what you mean by "certificate" here. The structure you
mentioned will be a CMS ContentInfo. 

Anyway see:

https://www.openssl.org/docs/faq.html#PROG3

for details about how to decode the DER form.

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


From tom.browder at gmail.com  Thu Jul 20 19:20:05 2017
From: tom.browder at gmail.com (Tom Browder)
Date: Thu, 20 Jul 2017 14:20:05 -0500
Subject: [openssl-users] [ssllabs-discuss] Apache configuration
In-Reply-To: <95a9934c-2ac1-0841-9ffb-73cd00008ead@thelounge.net>
References: <CAFMGiz_33=vWfMXLD8EbkoHQwrUeUSuRM+RkOOi-V1asZ6rjfA@mail.gmail.com>
 <4531bea4-3f67-bc50-d316-220b3ddf3398@posteo.de>
 <CAFMGiz8c==d_pLaAQLU1ozbOiHLnbSqXTec3=7MKP0iU83Zy+A@mail.gmail.com>
 <95606bfe-b37f-15c9-caf1-b4d09f398ba5@thelounge.net>
 <CAFMGiz-p0UT3tL4DCCrP+2hF9zyD973-3Eb7iH1JoAq1tGZsaQ@mail.gmail.com>
 <d65c5058-5edb-5228-b030-817cabf3cae0@thelounge.net>
 <CAFMGiz_14qOUv6VJiD5ukcDPWdL=1viXFpwzYjTqFdZN7gMVdQ@mail.gmail.com>
 <0022ac31-0063-c32c-cf99-05e485cab034@thelounge.net>
 <CAFMGiz9N3qGEX+qe-xo7SeZQmmE5ZJvSPS3RYQYvNE1wsW-Urg@mail.gmail.com>
 <95a9934c-2ac1-0841-9ffb-73cd00008ead@thelounge.net>
Message-ID: <CAFMGiz-KN+JF+Vz4Vb7E_a_f1Dp4=t115j91NWmd3mj1Pj50nA@mail.gmail.com>

On Thu, Jul 20, 2017 at 2:14 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
...
> before having the cluster 2015 in VMware EVC mathcing sandybridge i thought
> "well, the hardware is capable" but VMware filtered out AVX instrcutions and
> everything using openssl crashed with "illegal cpu instuction" which proved
> the compile flags worked but the binary where magnitudes slower with AES
> than the ordinary Fedora ones - hard to say but i guess something optimized
> the AES instructions from the runtime detection away....

It sounds to my novice ears that at least some of the problem is in
the VM layer.  My system is a native-iron one so shouldn't I have a
better chance at success?

-Tom

From jjsbear at hotmail.com  Thu Jul 20 08:53:51 2017
From: jjsbear at hotmail.com (- JinsongJi)
Date: Thu, 20 Jul 2017 08:53:51 +0000
Subject: [openssl-users] =?gb2312?b?tPC4tDogRmFpbGVkIHRvIGJ1aWxkIE9wZW5T?=
	=?gb2312?b?U0wgb24gV2luZG93cw==?=
In-Reply-To: <HKXPR02MB04050ED584AE270E5CA0E69AA8A70@HKXPR02MB0405.apcprd02.prod.outlook.com>
References: <HKXPR02MB04050ED584AE270E5CA0E69AA8A70@HKXPR02MB0405.apcprd02.prod.outlook.com>
Message-ID: <HKXPR02MB04051F576F5447A9917D3E64A8A70@HKXPR02MB0405.apcprd02.prod.outlook.com>

Got it. Only nmake builds here.

Thanks,
Jinsong
________________________________
???: - JinsongJi <jjsbear at hotmail.com>
????: 2017?7?20? 10:42
???: openssl-users at openssl.org
??: Failed to build OpenSSL on Windows

Hi,

I tried to build openssl-1.1.0f (downloaded from https://www.openssl.org/source/) on Windows, but failed when running dmake. And nmake is not recognized.

Output was attached for your reference. ?configdata.pm? and ?makefile? were generated by Configure, I think.

Can you please help point out why dmake failed here? Or I missed some operations before running dmake? Thanks.

Regards,
Jinsong

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170720/4022187f/attachment.html>

From jb-openssl at wisemo.com  Thu Jul 20 20:32:31 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 20 Jul 2017 22:32:31 +0200
Subject: [openssl-users] [ssllabs-discuss] Apache configuration
In-Reply-To: <CAFMGiz9N3qGEX+qe-xo7SeZQmmE5ZJvSPS3RYQYvNE1wsW-Urg@mail.gmail.com>
References: <CAFMGiz_33=vWfMXLD8EbkoHQwrUeUSuRM+RkOOi-V1asZ6rjfA@mail.gmail.com>
 <4531bea4-3f67-bc50-d316-220b3ddf3398@posteo.de>
 <CAFMGiz8c==d_pLaAQLU1ozbOiHLnbSqXTec3=7MKP0iU83Zy+A@mail.gmail.com>
 <95606bfe-b37f-15c9-caf1-b4d09f398ba5@thelounge.net>
 <CAFMGiz-p0UT3tL4DCCrP+2hF9zyD973-3Eb7iH1JoAq1tGZsaQ@mail.gmail.com>
 <d65c5058-5edb-5228-b030-817cabf3cae0@thelounge.net>
 <CAFMGiz_14qOUv6VJiD5ukcDPWdL=1viXFpwzYjTqFdZN7gMVdQ@mail.gmail.com>
 <0022ac31-0063-c32c-cf99-05e485cab034@thelounge.net>
 <CAFMGiz9N3qGEX+qe-xo7SeZQmmE5ZJvSPS3RYQYvNE1wsW-Urg@mail.gmail.com>
Message-ID: <4427cd53-ee11-e4fb-a0c6-714e6c221eed@wisemo.com>

On 20/07/2017 21:06, Tom Browder wrote:
> On Thu, Jul 20, 2017 at 1:57 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>>>> Am 20.07.2017 um 18:02 schrieb Tom Browder
>>>>> On Thu, Jul 20, 2017 at 10:54 AM, Reindl Harald <h.reindl at thelounge.net>
>>>>> wrote
> ...
>>> P.S.  Of course the other part of my motivation in the past has been
>>> to see if it can be made to work, regardless of need (due to my
>>> butt-head gene from my father's side of the family)
> ...
>> well, openssl is the straight to hell
>>
>> load something into your webserver built against 1.1 and have fun when a
>> system library loads 1.0.x by watching the crash
> Then what about Ivan's recommendation about installing openssl
> alongside a system-wide one?  If that can't be done reliably, surely
> there has been a bug report submitted. (I haven't looked at bugs in a
> long time)?
The "DLL hell" problem only happens if someone either:

- Doesn't install with proper so-versioning (with proper so-versioning
  1.0.x is installed as libssl.so.1.0.0 and libcrypto.so.1.0.0 while
  1.1.x is installed as libssl.so.1.1.0 and libcrypto.so.1.1.0).

- Uses a non-unix-like OS where the compilation script doesn't include
  a version number in the DLL file names (that would be a bug in OpenSSL
  1.1.x).

- Uses a 3rd party web server plugin (not an out-of-process cgi) and
  either that plugin or the web server which is compiled/linked to not
  use strongly versioned imports for the OpenSSL functions (this only
  happens with the silly unix-style DLL loader semantics that default
  to ignoring the DLL from which a symbol is imported).

Question to OpenSSL devs: Do the recommended instructions for linking
applications to OpenSSL 1.1.x on unix-like systems ensure strong symbol
versioning so the dynamic loader doesn't mix up symbols from another
OpenSSL version loaded elsewhere in the process?


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From vieuxtech at gmail.com  Thu Jul 20 22:56:30 2017
From: vieuxtech at gmail.com (Sam Roberts)
Date: Thu, 20 Jul 2017 15:56:30 -0700
Subject: [openssl-users] shouldn't fipslink.pl include the
 fipscanister.lib in the link line?
In-Reply-To: <20170720012717.GA23899@openssl.org>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
 <CA+Sj9TmRA8DZ5GqUqsDUv-SNLKT-Db6cVNtXOJfCtCi4w_8emg@mail.gmail.com>
 <20170720012717.GA23899@openssl.org>
Message-ID: <CA+Sj9TkQ5B0Sv+MBNjcmMNigsBgqtYY3zWxuLeoZd8yp9dqb5g@mail.gmail.com>

On Wed, Jul 19, 2017 at 6:27 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
> Try linking with fipscanister.lib too: that's where those symbols are located.

OK, I'd tried that before with no luck, but I tried harder. I found
that if my lib line has the fips_premain.obj, then the
fipscanister.lib, then the rest of the program's obj files and libs in
exactly that order, the symbols are resolved.

That's progress!

Now I'm hitting the dreaded MSVCRT conflicts with use of other libs problem.

Most of the application is compiled with /MT, but openssl-fips-2.0.16
is using /MD, could this be an issue? Can I/should I convince
ms\do_fips to build against the multi-threaded runtime?

It may also be other obj files causing the issue, the MSVC message is
not so helpful, I'm continuing to look.

I used /nodedefaultlib:msvcrt (even though its supposed to not be
recommended) and I got a link of openssl-cli, though with lots of
"LNK4049 locally defined symbol _exit imported", which sounds like its
another symbol of /MT and /MD mismatch.

I also almost got a link of node, but it died with
fipscanister.lib(cryptolib.obj): error LNK2001: unresolved symbol
__imp_wcsstr, and __imp___stdio_common_vsscanf, both of which sound
suspiciously like a problem with the runtime compilation flags to me.


Cheers,
Sam

From steve at openssl.org  Thu Jul 20 23:07:05 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 20 Jul 2017 23:07:05 +0000
Subject: [openssl-users] Extract content of DER-encoded package by OID
In-Reply-To: <025201d30187$873ef820$95bce860$@arkhamtechnology.com>
References: <1cb401d30012$27103020$75309060$@arkhamtechnology.com>
 <20170719112554.GA7698@openssl.org>
 <0b5001d300dc$c07b2f60$41718e20$@arkhamtechnology.com>
 <20170720013224.GB23899@openssl.org>
 <025201d30187$873ef820$95bce860$@arkhamtechnology.com>
Message-ID: <20170720230705.GA17567@openssl.org>

On Thu, Jul 20, 2017, Justin Mogannam wrote:

> Thanks for the tips thus far. One of the last issues I'm having is actually
> declaring a CMS_ContentInfo structure. I just declare :
> 
> CMS_ContentInfo cms;
> 
> Amd gcc tells me "error: storage size of 'cms' isn't known". This goes back
> to my question 1 of the previous email: is there a particular function call
> to use to construct a CMS_ContentInfo structure? Thanks! 
> 

In common with many structures CMS_ContentInfo is opaque so you can only
declare pointers to the structure not the structure itself.  The
d2i_CMS_ContentInfo() function will return a pointer to a CMS_ContentInfo
structure containing the contents of the parsed DER buffer. You can then use
that pointer in other CMS utility functions.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Thu Jul 20 23:08:11 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 20 Jul 2017 23:08:11 +0000
Subject: [openssl-users] shouldn't fipslink.pl include the
 fipscanister.lib in the link line?
In-Reply-To: <CA+Sj9TkQ5B0Sv+MBNjcmMNigsBgqtYY3zWxuLeoZd8yp9dqb5g@mail.gmail.com>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
 <CA+Sj9TmRA8DZ5GqUqsDUv-SNLKT-Db6cVNtXOJfCtCi4w_8emg@mail.gmail.com>
 <20170720012717.GA23899@openssl.org>
 <CA+Sj9TkQ5B0Sv+MBNjcmMNigsBgqtYY3zWxuLeoZd8yp9dqb5g@mail.gmail.com>
Message-ID: <20170720230811.GB17567@openssl.org>

On Thu, Jul 20, 2017, Sam Roberts wrote:

> 
> Most of the application is compiled with /MT, but openssl-fips-2.0.16
> is using /MD, could this be an issue? Can I/should I convince
> ms\do_fips to build against the multi-threaded runtime?
> 

Unfortunately you can't change that part of the build process in any way or
the result is no longer validated.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From vieuxtech at gmail.com  Thu Jul 20 23:54:29 2017
From: vieuxtech at gmail.com (Sam Roberts)
Date: Thu, 20 Jul 2017 16:54:29 -0700
Subject: [openssl-users] shouldn't fipslink.pl include the
 fipscanister.lib in the link line?
In-Reply-To: <20170720230811.GB17567@openssl.org>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
 <CA+Sj9TmRA8DZ5GqUqsDUv-SNLKT-Db6cVNtXOJfCtCi4w_8emg@mail.gmail.com>
 <20170720012717.GA23899@openssl.org>
 <CA+Sj9TkQ5B0Sv+MBNjcmMNigsBgqtYY3zWxuLeoZd8yp9dqb5g@mail.gmail.com>
 <20170720230811.GB17567@openssl.org>
Message-ID: <CA+Sj9T=f8CNBD80BqMZdp6n3MTTiEVTY4nR9GORyuhzKJs0urg@mail.gmail.com>

On Thu, Jul 20, 2017 at 4:08 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
> On Thu, Jul 20, 2017, Sam Roberts wrote:
>
>>
>> Most of the application is compiled with /MT, but openssl-fips-2.0.16
>> is using /MD, could this be an issue? Can I/should I convince
>> ms\do_fips to build against the multi-threaded runtime?
>>
>
> Unfortunately you can't change that part of the build process in any way or
> the result is no longer validated.

OK, then given https://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx
"All modules passed to a given invocation of the linker must have been
compiled with the same run-time library compiler option (/MD, /MT,
/LD)." a static link is impossible, it seems.

I don't think a DLL build will work for node.js given its
distribution/use model, but hypothetically, is there a way to hide
fipscanister in a single-threaded DLL, used by a multi-threaded app?
Are you aware of any multi-threaded OpenSSL FIPS apps on Windows?

node makes almost all of its openssl calls from a single thread, but
there are two exceptions, getting random seeds and pbkdf2, where the
cpu intensive or potentially blocking call is made from a thread pool.

Cheers,
Sam

From jb-openssl at wisemo.com  Fri Jul 21 01:02:05 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 21 Jul 2017 03:02:05 +0200
Subject: [openssl-users] shouldn't fipslink.pl include the
 fipscanister.lib in the link line?
In-Reply-To: <CA+Sj9TkQ5B0Sv+MBNjcmMNigsBgqtYY3zWxuLeoZd8yp9dqb5g@mail.gmail.com>
References: <CA+Sj9TndPTYcEBro7eFNoGhDp=8xaGM4FQpoT5ZiM09WU_08dw@mail.gmail.com>
 <CA+Sj9TmRA8DZ5GqUqsDUv-SNLKT-Db6cVNtXOJfCtCi4w_8emg@mail.gmail.com>
 <20170720012717.GA23899@openssl.org>
 <CA+Sj9TkQ5B0Sv+MBNjcmMNigsBgqtYY3zWxuLeoZd8yp9dqb5g@mail.gmail.com>
Message-ID: <de08a0ca-8752-71be-b024-68ad9c468dc5@wisemo.com>

On 21/07/2017 00:56, Sam Roberts wrote:
> On Wed, Jul 19, 2017 at 6:27 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
>> Try linking with fipscanister.lib too: that's where those symbols are located.
> OK, I'd tried that before with no luck, but I tried harder. I found
> that if my lib line has the fips_premain.obj, then the
> fipscanister.lib, then the rest of the program's obj files and libs in
> exactly that order, the symbols are resolved.
>
> That's progress!
>
> Now I'm hitting the dreaded MSVCRT conflicts with use of other libs problem.
>
> Most of the application is compiled with /MT, but openssl-fips-2.0.16
> is using /MD, could this be an issue? Can I/should I convince
> ms\do_fips to build against the multi-threaded runtime?
>
> It may also be other obj files causing the issue, the MSVC message is
> not so helpful, I'm continuing to look.
>
> I used /nodedefaultlib:msvcrt (even though its supposed to not be
> recommended) and I got a link of openssl-cli, though with lots of
> "LNK4049 locally defined symbol _exit imported", which sounds like its
> another symbol of /MT and /MD mismatch.
That's the warning that something (hopefully only the fips blob and not
the fips-enabled OpenSSL) was compiled with /MD.  This should be harmless
as the linker generates the needed glue (dummy pointer variables pointing
to the symbol, so the /MD compiled code can dereference those as if they
were import table entries).

> I also almost got a link of node, but it died with
> fipscanister.lib(cryptolib.obj): error LNK2001: unresolved symbol
> __imp_wcsstr, and __imp___stdio_common_vsscanf, both of which sound
> suspiciously like a problem with the runtime compilation flags to me.
This is strange, as those two should also have been handled by the
LNK4049 mechanism,unless there is one of the following:

A) Mismatch between compiler versions or C runtime header versions
   between the FIPS canister compile and your final link.

B) Some oddity in how those two symbols are defined in your visual
   studio runtime version.

Either should be possible to work around with some tenacity.  Of cause
doing such work is not "supported" by Microsoft, but what is these days.

If the issue is item B, then linking in a stub file providing the two
missing functions (as wrappers around functions actually in the static
C runtime) might do the trick.

Of cause, you will need to do thorough testing of the resulting
program/dll to make sure there are no other C runtime differences
causing trouble.

P.S.

I kind of wonder what in the fips canister uses wcsstr(), but since
that cannot be changed while retaining the FIPS validation status,
that's just curiousness.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From npathak2 at ncsu.edu  Fri Jul 21 18:01:28 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Fri, 21 Jul 2017 11:01:28 -0700
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
 <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
Message-ID: <CANWFjKDM47-BeUT1byvtp-kR+x4onWHUZWz38MeBMxkQpBG0Lg@mail.gmail.com>

Thanks everyone for clarification on previous queries

1) I had a general query regarding the handshake resumptions.
Since during the session resumption handshake in either TLS 1.2 or TLS 1.3
the key exchange does not take place, the client side and the server side
both resume based on a previously set up session, so the master key is not
going to change . Isn't the data sent post resumption handshake vulnerable
to replay attacks ? why do we say that the data is vulnerable to replay
only with enable-early data in tls 1.3. I think I am confused on some
basics here.

I am saying this because if I save the session in a file, the master key
gets fixed. I see that during the resumption handshake too, the client
hello message has a client_random value which as per my understanding is
required for generating the master secret. But the master key is always
read from the previous session info saved in the file, hence I am a little
confused will the master secret change after every resumption connection.

2) If master secret doesn't change for the resumed connection, shouldn't it
change on each handshake finish (full or resumption handshake) for more
secure communication?
I think that happens only on full-handshake in ephemeral type ciphers (e.g.
ECDHE) but not in RSA type. Am I correct ?



Thanks
BR,
Neetish



On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 18/07/17 22:27, Neetish Pathak wrote:
> > Hi ,
> > thanks Matt, this is helpful
> >
> >
> > One more query on how I can enable 0.5 RTT data from the server side. It
> > is mentioned in TLS 1.3 specification. I thought it can be implemented
> > by sending early data  from server side after reading the early data.
>
> That is correct, and is as documented on this page:
>
> https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html
>
> > But then how can that data be read on the client side since
> > read_early_data api is invalid on client side ?
>
> 0.5 RTT data is sent from the server to an unauthenticated client. At
> this point in the process the server has sent all of its messages
> (including its Certificate/CertificateVerify/Finished messages) but it
> has not received the Client Finished or any client
> Certificate/CertificateVerify if one is going to be sent.
>
> From the client's perspective 0.5 RTT data is received *after* it has
> processed the server's Certificate/CertificateVerify/Finished messages),
> and after it has sent its own Finished (and
> Certificate/CertificateVerify if appropriate). In other words from the
> client's perspective the server is fully authenticated and 0.5 RTT data
> is indistinguishable from post-handshake data. Just use SSL_read() as
> normal to receive it.
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170721/13a00d28/attachment.html>

From npathak2 at ncsu.edu  Fri Jul 21 19:32:48 2017
From: npathak2 at ncsu.edu (neetish)
Date: Fri, 21 Jul 2017 12:32:48 -0700 (MST)
Subject: [openssl-users] TLS false start support on Openssl
In-Reply-To: <BB8D8AEC7DBA1F41810DCB5D38AF56AB8CBAE8A70C@HQ1-EXCH02.corp.brocade.com>
References: <BB8D8AEC7DBA1F41810DCB5D38AF56AB8CBAE8A643@HQ1-EXCH02.corp.brocade.com>
 <4E8F1039.4060203@ts.fujitsu.com>
 <BB8D8AEC7DBA1F41810DCB5D38AF56AB8CBAE8A70C@HQ1-EXCH02.corp.brocade.com>
Message-ID: <1500665568770-71578.post@n7.nabble.com>

@Ritesh,

I am not able to find the patch for False Start which you posted . Afaik ,
false start is not implemented in Openssl. If you have it, could you please
share. The google link that you shared is de-funct.

Thanks
Best Regards,
Neetish



--
View this message in context: http://openssl.6102.n7.nabble.com/TLS-false-start-support-on-Openssl-tp14791p71578.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From jmogannam at arkhamtechnology.com  Fri Jul 21 20:32:41 2017
From: jmogannam at arkhamtechnology.com (Justin Mogannam)
Date: Fri, 21 Jul 2017 13:32:41 -0700
Subject: [openssl-users] Extract content of DER-encoded package by OID
In-Reply-To: <20170720230705.GA17567@openssl.org>
References: <1cb401d30012$27103020$75309060$@arkhamtechnology.com>
 <20170719112554.GA7698@openssl.org>
 <0b5001d300dc$c07b2f60$41718e20$@arkhamtechnology.com>
 <20170720013224.GB23899@openssl.org>
 <025201d30187$873ef820$95bce860$@arkhamtechnology.com>
 <20170720230705.GA17567@openssl.org>
Message-ID: <15c301d30260$809bb380$81d31a80$@arkhamtechnology.com>

Okay, I've made some progress, but hit a wall now. Here's what I have so
far:

/************* start code *************/

char* encrypted;	// DER-encoded buffer */
char* encryptedSize; 	// size in bytes of encrypted buffer

CMS_ContentInfo* cms;

unsigned char* p;
p = encrypted;

CMS_ContentInfo** cmsPtr = &cms;
cms = d2i_CMS_ContentInfo( NULL, &p, encryptedSize );
if ( cms == NULL ) printf("CMS is null!\n");

const ASN1_OBJECT* asn = CMS_get0_eContentType( cms );
if ( asn == NULL ) printf("ASN is null!\n");

/************* end code *************/

None of the checks failed, so the functions passed. However, when I check
asn->data, it appears to be "garbage", or nothing interesting to me. The
flags is 9 (so I'm assuming flag 0x01 and 0x08 were set). Does it look like
I'm doing everything correctly? How would I continue on in parsing the asn1
object/stripping off layers of it? Thanks, and I hope to hear back soon.

- Justin 
 
-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
Dr. Stephen Henson
Sent: Thursday, July 20, 2017 4:07 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Extract content of DER-encoded package by OID

On Thu, Jul 20, 2017, Justin Mogannam wrote:

> Thanks for the tips thus far. One of the last issues I'm having is 
> actually declaring a CMS_ContentInfo structure. I just declare :
> 
> CMS_ContentInfo cms;
> 
> Amd gcc tells me "error: storage size of 'cms' isn't known". This goes 
> back to my question 1 of the previous email: is there a particular 
> function call to use to construct a CMS_ContentInfo structure? Thanks!
> 

In common with many structures CMS_ContentInfo is opaque so you can only
declare pointers to the structure not the structure itself.  The
d2i_CMS_ContentInfo() function will return a pointer to a CMS_ContentInfo
structure containing the contents of the parsed DER buffer. You can then use
that pointer in other CMS utility functions.

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


From googleersatz at oliverniebuhr.de  Sat Jul 22 18:37:27 2017
From: googleersatz at oliverniebuhr.de (Oliver Niebuhr)
Date: Sat, 22 Jul 2017 20:37:27 +0200
Subject: [openssl-users] OpenSSL 1.1+: How to disable building of Manpages
	etc.?
Message-ID: <e87cb865-f078-aae7-8472-381326d09c03@oliverniebuhr.de>

Hi.

I searched the Web and checked the Configure File. Am I blind or is
there really no Parameter to disable the creation of the Documentation?

As I also test the Qt Framework, I often recompile OpenSSL. You are
right, building the Docs will only take 2 Minutes - but it sums up to
countless hours for me.

OS: Linux (Antergos) and Windows 10
Compiler: GCC 7.1+ and VS2017.2+

Thanks!
Oliver

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170722/82149f34/attachment.sig>

From noloader at gmail.com  Sat Jul 22 19:24:30 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 22 Jul 2017 15:24:30 -0400
Subject: [openssl-users] OpenSSL 1.1+: How to disable building of
	Manpages etc.?
In-Reply-To: <e87cb865-f078-aae7-8472-381326d09c03@oliverniebuhr.de>
References: <e87cb865-f078-aae7-8472-381326d09c03@oliverniebuhr.de>
Message-ID: <CAH8yC8kOCo27jBtuwC7dt=RrMzZdr+P9DQtvPJn=gci2sBnGSQ@mail.gmail.com>

On Sat, Jul 22, 2017 at 2:37 PM, Oliver Niebuhr
<googleersatz at oliverniebuhr.de> wrote:
> Hi.
>
> I searched the Web and checked the Configure File. Am I blind or is
> there really no Parameter to disable the creation of the Documentation?
>
> As I also test the Qt Framework, I often recompile OpenSSL. You are
> right, building the Docs will only take 2 Minutes - but it sums up to
> countless hours for me.

Use 'make install_sw'. Maybe something like:

    make distclean
    ./config enable-ec_nistp_64_gcc_128
    make -j 9
    make install_sw

enable-ec_nistp_64_gcc_128 is for x86_64. Also see
https://wiki.openssl.org/index.php/Compilation_and_Installation#Configure_Options.

Jeff

From joe.flowers at nofreewill.com  Mon Jul 24 03:26:18 2017
From: joe.flowers at nofreewill.com (Joe Flowers)
Date: Sun, 23 Jul 2017 23:26:18 -0400
Subject: [openssl-users] Difference between libssl.a in static openssl build
 versus libssl.a in dynamic openssl build ???
Message-ID: <CA+4=ZEN+5SZ4jXpxeH=uk3XN9LW8mK7Z7szVOqnjtc+AQVgJoA@mail.gmail.com>

Hi Everyone,

1.
I am trying to upgrade some libraries of an older version of openssl
(~0.9.7) with the libraries of a less old version of openssl (1.0.0e).


2.
When I perform a dynamic openssl build with the following commands, I get
(among other files) a libssl.a file.

cd /joe/openssl-1.0.1e/dynamic/64bit/openssl-1.0.1e
make clean
setarch x86_64 ./config -m64 -D_GNU_SOURCE -fPIC shared no-zlib
make



3.
When I perform a static openssl build with the following commands, I get
(among other files) another libssl.a file.

cd /joe/openssl-1.0.1e/static/64bit/openssl-1.0.1e
./config -D_GNU_SOURCE
make clean
make



4.
I am trying to determine which one of these two newer libssl.a files I
should use to replace the older ~0.9.7 libssl.a file.


Any ideas how to do this?

I have been trying to use the "readelf " and "file" commands on these 3
different libssl.a files, but I am not seeing a pattern in the files which
allows me to determine which one should be used.

5.
I am compiling on a SLES11 SP1 64-bit machine.


Thanks!!!

Joe
----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170723/8f5754bd/attachment.html>

From rsalz at akamai.com  Mon Jul 24 11:42:31 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 24 Jul 2017 11:42:31 +0000
Subject: [openssl-users] Difference between libssl.a in static openssl
 build versus libssl.a in dynamic openssl build ???
In-Reply-To: <CA+4=ZEN+5SZ4jXpxeH=uk3XN9LW8mK7Z7szVOqnjtc+AQVgJoA@mail.gmail.com>
References: <CA+4=ZEN+5SZ4jXpxeH=uk3XN9LW8mK7Z7szVOqnjtc+AQVgJoA@mail.gmail.com>
Message-ID: <11bfada91382452db1367ce86f7ccb01@usma1ex-dag1mb1.msg.corp.akamai.com>

You know you are going from something horribly out of date to something very out of date, right?

Can?t you at least move to 1.0.2?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170724/cfb1b1fa/attachment.html>

From saatomic at keemail.me  Mon Jul 24 11:35:13 2017
From: saatomic at keemail.me (SaAtomic)
Date: Mon, 24 Jul 2017 13:35:13 +0200 (CEST)
Subject: [openssl-users] Default key length of DH/DHE/ECDH/ECDHE
Message-ID: <KpoNI26--3-0@keemail.me>

I'm not sure if this question is more suitable for the OpenVPN or the OpenSSl users list.

OpenSSL as the ssl/tls library for OpenVPN offers DH with and without ephemeral keys as well as with or without elliptic curves.

With OpenVPN 2.4.0 and OpenSSL 1.0.2l only ECDHE and DHE are available, but I do not have the option to define a key length,
so I assume OpenSSL's default key length will be used.

What is the default key length of OpenSSL for DH, DHE, ECDH and ECDHE?

Thank you and regards,
SaAtomic
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170724/e4cdeb4b/attachment.html>

From rsalz at akamai.com  Mon Jul 24 12:08:40 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 24 Jul 2017 12:08:40 +0000
Subject: [openssl-users] Default key length of DH/DHE/ECDH/ECDHE
In-Reply-To: <KpoNI26--3-0@keemail.me>
References: <KpoNI26--3-0@keemail.me>
Message-ID: <49f93cd399b84853ab083edfabb2dd06@usma1ex-dag1mb1.msg.corp.akamai.com>

For the elliptic curve choices, the curve picked (NIST256, NIST384, whatever) determines the keysize.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170724/e113a44e/attachment-0001.html>

From jb-openssl at wisemo.com  Mon Jul 24 12:16:45 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 24 Jul 2017 14:16:45 +0200
Subject: [openssl-users] Default key length of DH/DHE/ECDH/ECDHE
In-Reply-To: <KpoNI26--3-0@keemail.me>
References: <KpoNI26--3-0@keemail.me>
Message-ID: <15fbdc93-63f3-f3d8-1af7-3a72f684d929@wisemo.com>

On 24/07/2017 13:35, SaAtomic wrote:
> I'm not sure if this question is more suitable for the OpenVPN or the 
> OpenSSl users list.
>
> OpenSSL as the ssl/tls library for OpenVPN offers DH with and without 
> ephemeral keys as well as with or without elliptic curves.
>
> With OpenVPN 2.4.0 and OpenSSL 1.0.2l only ECDHE and DHE are 
> available, but I do not have the option to define a key length,
> so I assume OpenSSL's default key length will be used.
>
> What is the default key length of OpenSSL for DH, DHE, ECDH and ECDHE?
>
For DHE, the key size is set by the group parameters, for
which there is no default other than what the application
(in this case OpenVPN) sets.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From joe.flowers at nofreewill.com  Mon Jul 24 14:54:07 2017
From: joe.flowers at nofreewill.com (Joe Flowers)
Date: Mon, 24 Jul 2017 10:54:07 -0400
Subject: [openssl-users] Difference between libssl.a in static openssl
 build versus libssl.a in dynamic openssl build ???
In-Reply-To: <11bfada91382452db1367ce86f7ccb01@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CA+4=ZEN+5SZ4jXpxeH=uk3XN9LW8mK7Z7szVOqnjtc+AQVgJoA@mail.gmail.com>
 <11bfada91382452db1367ce86f7ccb01@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CA+4=ZEN5T=W42=dfgVt6ndjH=F7-RARy65aah1p25HBR4a0e1Q@mail.gmail.com>

> You know you are going from something horribly out of date to something
very out of date, right?

Yes.

> Can?t you at least move to 1.0.2?

That is out of my hands and is almost entirely irrelevant to the
information I asked for and need. Even if I could upgrade to 1.0.2 the same
problem and same question would remain.






On Mon, Jul 24, 2017 at 7:42 AM, Salz, Rich via openssl-users <
openssl-users at openssl.org> wrote:

> You know you are going from something horribly out of date to something
> very out of date, right?
>
>
>
> Can?t you at least move to 1.0.2?
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170724/142e0413/attachment.html>

From Michael.Wojcik at microfocus.com  Mon Jul 24 15:51:33 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Mon, 24 Jul 2017 15:51:33 +0000
Subject: [openssl-users] Difference between libssl.a in static openssl
 build versus libssl.a in dynamic openssl build ???
In-Reply-To: <CA+4=ZEN5T=W42=dfgVt6ndjH=F7-RARy65aah1p25HBR4a0e1Q@mail.gmail.com>
References: <CA+4=ZEN+5SZ4jXpxeH=uk3XN9LW8mK7Z7szVOqnjtc+AQVgJoA@mail.gmail.com>
 <11bfada91382452db1367ce86f7ccb01@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CA+4=ZEN5T=W42=dfgVt6ndjH=F7-RARy65aah1p25HBR4a0e1Q@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9A970B2@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Joe Flowers
> Sent: Monday, July 24, 2017 08:54
> To: Salz, Rich; openssl-users at openssl.org
> Subject: Re: [openssl-users] Difference between libssl.a in static openssl build versus libssl.a in dynamic openssl build ???

>>?You know you are going from something horribly out of date to something very out of date, right?

> Yes.

>> Can?t you at least move to 1.0.2?

> That is out of my hands and is almost entirely irrelevant to the information I asked for and need.

Perhaps, but it's not irrelevant to your question, because:

- The OpenSSL build process has been updated significantly since the days of 1.0.0 or 1.0.1 (your original message said 1.0.0e, but the directory paths you quoted say 1.0.1e), so it's easier for people to comment on build questions regarding supported releases.

- More importantly, the people who participate on this list have limited resources and other responsibilities. It makes sense for them to focus on questions from people who are using supported releases. That doesn't mean no one should help you, or that no one will; but it would be courteous to acknowledge that fact.

Now, on to your original question:

> When I perform a dynamic openssl build with the following commands, I get (among other files) a libssl.a file.
> ...
> When I perform a static openssl build with the following commands, I get (among other files) another libssl.a file.
> ...
> I am trying to determine which one of these two newer libssl.a files I should use to replace the older ~0.9.7 libssl.a file.

For Linux, I believe it depends on whether you need PIC code, and whether you need the OpenSSL FIPS module. I'm going to ignore the latter case, because FIPS is a nightmarish wasteland of horrors. FIPS aside, I don't know of any reason *not* to use PIC code. The OpenSSL builds I work with always build sharable (PIC, on Linux and appropriate UNIXes) code, which we then put into static libraries, which are linked into dynamic libraries / shared objects containing our own cover routines.

There might be some other use case for building OpenSSL statically on Linux, but I'm not aware of one. Other list members may be.

Now, whether a dynamic-build libssl.a (and libcrypto.a) can be used as drop-in replacements for your 0.9.7 versions is another question entirely, of course.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


From npathak2 at ncsu.edu  Tue Jul 25 01:53:58 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Mon, 24 Jul 2017 18:53:58 -0700
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
 <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
Message-ID: <CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com>

On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 18/07/17 22:27, Neetish Pathak wrote:
> > Hi ,
> > thanks Matt, this is helpful
> >
> >
> > One more query on how I can enable 0.5 RTT data from the server side. It
> > is mentioned in TLS 1.3 specification. I thought it can be implemented
> > by sending early data  from server side after reading the early data.
>
> That is correct, and is as documented on this page:
>
> https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html



Thanks Matt
To send 0.5 RTT data I m sending the early_data from the server side just
after the early_read data. But when I see the wire-shark logs, I see that
the server data is sent only once the complete handshake has taken place.
(which is the same as using SSL_write after SSL_accept).
I am performing following steps on client and server respectively as per
understanding developed from previous discussions

*Pseudocode for client*

tcp_connect

write_early(data)

ssl_connect

if(early_data_write_failed){
      ssl_write(data)
}

ssl_read


*Pseudocode for server*

tcp_accept

read_early{

     if(read_early_success){
          write_early(data)
      }
}

ssl_accept

if(read_early_fail){
    ssl_read
    ssl_write(data)
}


I am measuring latency on the *client side* from TCP connection start  till
it completes the read (ssl_read returns) (analogues to making a request
from client and reading response).
Please suggest what may be going wrong basically with these queries

1) Why is there no difference (or negligible) in latencies when i use early
write and then later ssl_read compared to when I execute normal write/read
on the client side

2) Why does the server not send data (for early write) after the server
Hello(and other encrypted message) message even when early_write succeeds
on server side. Why does server wait to finish the handshake. I know it
waits because I see client sending encrypted messages after server hello
message before my intended application data gets sent from server. These
encrypted messages from the client side are the usual messages from the
client side for handshake completion.

3) Also, the performance of TLS 1.3 using early data or resumption is worse
than TLS 1.2 resumption on LAN. I see on wire-shark that encrypted messages
get exchanged in TLS 1.3 during handshake which are plaintext in TLS 1.2. I
think that causes extra latency. So can we say that TLS 1.3 resumption is
not recommended for LAN for performance enhancement when compared with TLS
1.2 resumption. On WAN, I see TLS 1.3 resumption at par with TLS 1.2
resumption and full handshake better for TLS 1.3.

Thanks
Best regards,
Neetish












> > But then how can that data be read on the client side since
> > read_early_data api is invalid on client side ?
>
> 0.5 RTT data is sent from the server to an unauthenticated client. At
> this point in the process the server has sent all of its messages
> (including its Certificate/CertificateVerify/Finished messages) but it
> has not received the Client Finished or any client
> Certificate/CertificateVerify if one is going to be sent.
>
> From the client's perspective 0.5 RTT data is received *after* it has
> processed the server's Certificate/CertificateVerify/Finished messages),
> and after it has sent its own Finished (and
> Certificate/CertificateVerify if appropriate). In other words from the
> client's perspective the server is fully authenticated and 0.5 RTT data
> is indistinguishable from post-handshake data. Just use SSL_read() as
> normal to receive it.
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170724/3a768b7d/attachment-0001.html>

From seniha.oztemiz at gmail.com  Tue Jul 25 11:15:00 2017
From: seniha.oztemiz at gmail.com (=?UTF-8?B?U2VuaWhhIFMuIMOWWlRFTcSwWiBUVUxHQVI=?=)
Date: Tue, 25 Jul 2017 14:15:00 +0300
Subject: [openssl-users] Open ssl & Freeradius
Message-ID: <CA+63rw7NT321Oo0SzO9dETWw0WX7Btrg0RaEe9AB-J_kmJbv-w@mail.gmail.com>

Hello,

I installed the new version of freeradius and trying to configure it. My
windows10 clients gets authenticated but windows7 clients gets the
following errors. It seems that it is about openssl. Can you help me
regarding this problem. Any suggestions ?

Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: [eaptls verify] = ok
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: Done initial handshake
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: (other): before SSL
initialization
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: TLS_accept: before SSL
initialization
Tue Jul 25 14:11:59 2017 : Debug: Ignoring cbtls_msg call with pseudo
content type 256, version 0
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: TLS_accept: before SSL
initialization
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: <<< recv TLS 1.2  [length
002d]
Tue Jul 25 14:11:59 2017 : Debug: Ignoring cbtls_msg call with pseudo
content type 256, version 0
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: >>> send TLS 1.0 Alert
[length 0002], fatal handshake_failure
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: TLS Alert
write:fatal:handshake failure
Tue Jul 25 14:11:59 2017 : Error: tls: TLS_accept: Error in error
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: Failed in __FUNCTION__
(SSL_read): ../ssl/statem/statem_srvr.c[1404]:error:1417A0C1:SSL
routines:tls_post_process_client_hello:no shared cipher
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: System call (I/O) error (-1)
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: TLS receive handshake
failed during operation
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: [eaptls process] = fail
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap: Failed continuing EAP TTLS (21)
session.  EAP sub-module failed

-- 
Kind regards,

Seniha ?.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170725/d1305e09/attachment.html>

From bkaduk at akamai.com  Tue Jul 25 13:11:08 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Tue, 25 Jul 2017 08:11:08 -0500
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
 <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
 <CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com>
Message-ID: <727734e1-a450-9b53-41e7-630f953de3c8@akamai.com>

[Matt's reply is likely to be high latency]

On 07/24/2017 08:53 PM, Neetish Pathak wrote:
>
>
> On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
>
>
>
>     On 18/07/17 22:27, Neetish Pathak wrote:
>     > Hi ,
>     > thanks Matt, this is helpful
>     >
>     >
>     > One more query on how I can enable 0.5 RTT data from the server
>     side. It
>     > is mentioned in TLS 1.3 specification. I thought it can be
>     implemented
>     > by sending early data  from server side after reading the early
>     data.
>
>     That is correct, and is as documented on this page:
>
>     https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_manmaster_man3_SSL-5Fwrite-5Fearly-5Fdata.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=MfCOjAV83u4xGuIMb7VquiUt64_HFf9UC8LY4eIP_oc&s=ZAcBNcJWKTExKYdPPPOxcSr51esghiaZM82tPTLtbHM&e=>
>
>
>
> Thanks Matt
> To send 0.5 RTT data I m sending the early_data from the server side
> just after the early_read data. But when I see the wire-shark logs, I
> see that the server data is sent only once the complete handshake has
> taken place. (which is the same as using SSL_write after SSL_accept).
> I am performing following steps on client and server respectively as
> per understanding developed from previous discussions
>
> *Pseudocode for client*
> *
> *
> tcp_connect
>
> write_early(data)
>
> ssl_connect
>
> if(early_data_write_failed){
>       ssl_write(data)
> }
>
> ssl_read
>
>
> *Pseudocode for server*
> *
> *
> tcp_accept
> *
> *
> read_early{
>
>      if(read_early_success){
>           write_early(data)
>       }
> }
>
> ssl_accept
>
> if(read_early_fail){
>     ssl_read
>     ssl_write(data)
> }
>
>
> I am measuring latency on the *client side* from TCP connection start
>  till it completes the read (ssl_read returns) (analogues to making a
> request from client and reading response).
> Please suggest what may be going wrong basically with these queries
>
> 1) Why is there no difference (or negligible) in latencies when i use
> early write and then later ssl_read compared to when I execute normal
> write/read on the client side
>

Maybe I misunderstand the question, but isn't this is just a natural
consequence of the server (mis)behavior in (2)?

> 2) Why does the server not send data (for early write) after the
> server Hello(and other encrypted message) message even when
> early_write succeeds on server side. Why does server wait to finish
> the handshake. I know it waits because I see client sending encrypted
> messages after server hello message before my intended application
> data gets sent from server. These encrypted messages from the client
> side are the usual messages from the client side for handshake completion.
>

>From a quick look through the state machine code, this is supposed to
work.  But someone would probably have to instrument the code (e.g.,
with printf) to tell why the delay is being introduced.  I don't think I
have the availability to do so in the near future, myself.

> 3) Also, the performance of TLS 1.3 using early data or resumption is
> worse than TLS 1.2 resumption on LAN. I see on wire-shark that
> encrypted messages get exchanged in TLS 1.3 during handshake which are
> plaintext in TLS 1.2. I think that causes extra latency. So can we say
> that TLS 1.3 resumption is not recommended for LAN for performance
> enhancement when compared with TLS 1.2 resumption. On WAN, I see TLS
> 1.3 resumption at par with TLS 1.2 resumption and full handshake
> better for TLS 1.3.
>

It seems like it hasn't really sunk in for you that TLS 1.3 is a
seriously different protocol than TLS 1.2, and it provides stronger
security properties, remediating weaknesses of TLS 1.2.  So no, we
should not recommend TLS 1.2 resumption on the LAN -- we should
recommend the more secure option!  If you continue to believe that
latency trumps everything else, you could experiment with
SSL_OP_ALLOW_NO_DHE_KEX to cut out some of the heavier-weight asymmetric
crypto, though it looks like you'd want to patch
ssl/statem/extensions_clnt.c to not send TLSEXT_KEX_MODE_KE_DHE, as I
don't see a way to configure the server to prefer the non-DHE PSK key
exchange.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170725/756d64f7/attachment.html>

From shinelight at shininglightpro.com  Tue Jul 25 13:10:57 2017
From: shinelight at shininglightpro.com (Thomas J. Hruska)
Date: Tue, 25 Jul 2017 06:10:57 -0700
Subject: [openssl-users] Open ssl & Freeradius
In-Reply-To: <CA+63rw7NT321Oo0SzO9dETWw0WX7Btrg0RaEe9AB-J_kmJbv-w@mail.gmail.com>
References: <CA+63rw7NT321Oo0SzO9dETWw0WX7Btrg0RaEe9AB-J_kmJbv-w@mail.gmail.com>
Message-ID: <9ff93d98-197d-836e-f6e6-a0de09105157@shininglightpro.com>

On 7/25/2017 4:15 AM, Seniha S. ?ZTEM?Z TULGAR wrote:
> Hello,
> 
> I installed the new version of freeradius and trying to configure it. My
> windows10 clients gets authenticated but windows7 clients gets the
> following errors. It seems that it is about openssl. Can you help me
> regarding this problem. Any suggestions ?

You are technically on the wrong list.  The Freeradius project has its 
own user mailing list.  You should ask questions about Freeradius on 
that list.


> Tue Jul 25 14:11:59 2017 : Error: tls: TLS_accept: Error in error

This line is entertaining.  (But not relevant.)


> Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: Failed in __FUNCTION__
> (SSL_read): ../ssl/statem/statem_srvr.c[1404]:error:1417A0C1:SSL
> routines:tls_post_process_client_hello:no shared cipher

This is your problem.  The handshake between Freeradius and your client 
failed due to "no shared cipher".  Change your server and/or client 
cipher list(s) to something compatible.

-- 
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/

From Amr.Hegazi at vector.com  Tue Jul 25 16:49:53 2017
From: Amr.Hegazi at vector.com (Hegazi, Amr)
Date: Tue, 25 Jul 2017 16:49:53 +0000
Subject: [openssl-users] Considering C# OpenSSL openssl-net-master
Message-ID: <A6D54C65320840469319C2B2692E921405279AD8@vistrex4.vi.vector.int>

Hello *,

I'm using the last version of C# OpenSSL from https://github.com/openssl-net/openssl-net (This wrapper is based on version 1.0.2a of libeay32.dll and ssleay32.dll).

I'm using C# OpenSSL to test my Tls Client that supports TLS starting from version 1.2 and all the cipher suites. Moreover, I'm using Microsoft windows 7. I have already installed Microsoft visual C++ 2010 express and Microsoft visual Studio 2010.

I always face an error "TLSv1.2  81 - Alert (Level: Fatal, Description: Insufficient Security)"

I have debugged the issue. The issue come from a function called SSL_CTX_new() which is connected to ssleay32.dll. the clienthello is always sent correctly and then the OpenSSL server replies with Insufficient Security

The console also shows this:
.NET   HSM Received: ClientHello (188 bytes)
.NET   Offered suite by client: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) [not supported]
.NET   Offered suite by client: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) [not supported]
.NET   Offered suite by client: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) [not supported]
.NET   Offered suite by client: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) [not supported]
.NET   Offered suite by client: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) [not supported]
.NET   Offered suite by client: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) [not supported]
.NET   Offered suite by client: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) [not supported]
.NET   Offered suite by client: TLS_ECDH_ECDSA_WITH_NULL_SHA (0xc001) [not supported]
.NET   Offered suite by client: TLS_RSA_WITH_NULL_SHA256 (0x003b) [not supported]
.NET   Offered suite by client: TLS_RSA_WITH_NULL_SHA (0x0002) [not supported]
.NET   ALERT SENT    : Fatal InsufficientSecurity
.NET   no shared cipher suites

And in Wireshark shows this:

"3406.315537","fe80::ff:fe00:2","fe80::1:5","SSL","271","Client Hello"
"3419.805155","fe80::1:5","fe80::ff:fe00:2","TLSv1.2","81","Alert (Level: Fatal, Description: Insufficient Security)"

So, I think the error is in something related to configuration of ssleay32.dll

My code is simple and is as follows:

try
        {
              TestCaseBegin();

            Output.WriteLine("TLS Server Certificate preparation");
            CertDir = Path.GetFullPath("..\\Appl\\Certificates\\Certificate");
TlsServerCertificate = loadCertificateFromFile(Path.Combine(CertDir, @"Vector_ServerCertificate_RsaSha1_IA_pfx.pfx"), "123456");
TlsServerCaCertificates = new X509Chain(OpenSSL.Core.BIO.File(Path.Combine(CertDir, @"Vector_ServerCertificate_RsaSha1_Root_cert.cer"), "r"));

            Output.WriteLine("Start connection");
            TS_RcTlsConnect(TlsConnectMode.Rsa);

            Output.WriteLine("Send Client Hello");
            TS_WaitForTcpConnection();

            Output.WriteLine("make sslStreamServer");
SslStream sslStreamServer = new SslStream(tcpClient.GetStream(), true, MyRemoteCertificateValidationHandler,MyLocalCertificateSelectionHandler);

Output.WriteLine("Start AuthenticateAsServer");

sslStreamServer.AuthenticateAsServer(TlsServerCertificate, false, TlsServerCaCertificates, SslProtocols.Tls, SslStrength.All, false);
        }

        catch (TestStepFailException e)
{
HandleTestStepFailException(e);
Output.WriteLine(e.ToString());
             }
       catch (Exception ex)
{
PrintException(ex);
                    Output.WriteLine(ex.ToString());
             }
        finally
        {
            TestCaseEnd();
        }

Has anyone an idea?

Best Regards;

Amr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170725/af2b828a/attachment-0001.html>

From rsalz at akamai.com  Tue Jul 25 17:00:56 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 25 Jul 2017 17:00:56 +0000
Subject: [openssl-users] Considering C# OpenSSL openssl-net-master
In-Reply-To: <A6D54C65320840469319C2B2692E921405279AD8@vistrex4.vi.vector.int>
References: <A6D54C65320840469319C2B2692E921405279AD8@vistrex4.vi.vector.int>
Message-ID: <6482a682d8cf45d7ba8c005870d06c6c@usma1ex-dag1mb1.msg.corp.akamai.com>

If you want to use those ciphers, you need to set SECLEVEL=0 when you specify the ciphers.
I have no idea how to do that for the OpoenSSL C# binding.  Maybe post an issue on openssl-net?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170725/07d83e4e/attachment.html>

From npathak2 at ncsu.edu  Tue Jul 25 23:05:47 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Tue, 25 Jul 2017 16:05:47 -0700
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <727734e1-a450-9b53-41e7-630f953de3c8@akamai.com>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
 <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
 <CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com>
 <727734e1-a450-9b53-41e7-630f953de3c8@akamai.com>
Message-ID: <CANWFjKDDNGP6eEwha+AY-EyunWz24LNQ-Jx9c8EKk5X5Zz06wA@mail.gmail.com>

Thanks Ben for your reply

On Tue, Jul 25, 2017 at 6:11 AM, Benjamin Kaduk <bkaduk at akamai.com> wrote:

> [Matt's reply is likely to be high latency]
>
>
> On 07/24/2017 08:53 PM, Neetish Pathak wrote:
>
>
>
> On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <matt at openssl.org> wrote:
>
>>
>>
>> On 18/07/17 22:27, Neetish Pathak wrote:
>> > Hi ,
>> > thanks Matt, this is helpful
>> >
>> >
>> > One more query on how I can enable 0.5 RTT data from the server side. It
>> > is mentioned in TLS 1.3 specification. I thought it can be implemented
>> > by sending early data  from server side after reading the early data.
>>
>> That is correct, and is as documented on this page:
>>
>> https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_manmaster_man3_SSL-5Fwrite-5Fearly-5Fdata.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=MfCOjAV83u4xGuIMb7VquiUt64_HFf9UC8LY4eIP_oc&s=ZAcBNcJWKTExKYdPPPOxcSr51esghiaZM82tPTLtbHM&e=>
>
>
>
> Thanks Matt
> To send 0.5 RTT data I m sending the early_data from the server side just
> after the early_read data. But when I see the wire-shark logs, I see that
> the server data is sent only once the complete handshake has taken place.
> (which is the same as using SSL_write after SSL_accept).
> I am performing following steps on client and server respectively as per
> understanding developed from previous discussions
>
> *Pseudocode for client*
>
> tcp_connect
>
> write_early(data)
>
> ssl_connect
>
> if(early_data_write_failed){
>       ssl_write(data)
> }
>
> ssl_read
>
>
> *Pseudocode for server*
>
> tcp_accept
>
> read_early{
>
>      if(read_early_success){
>           write_early(data)
>       }
> }
>
> ssl_accept
>
> if(read_early_fail){
>     ssl_read
>     ssl_write(data)
> }
>
>
> I am measuring latency on the *client side* from TCP connection start
>  till it completes the read (ssl_read returns) (analogues to making a
> request from client and reading response).
> Please suggest what may be going wrong basically with these queries
>
> 1) Why is there no difference (or negligible) in latencies when i use
> early write and then later ssl_read compared to when I execute normal
> write/read on the client side
>
>
> Maybe I misunderstand the question, but isn't this is just a natural
> consequence of the server (mis)behavior in (2)?
>


Yes, this is right, the server misbehavior is causing this.


>
>
> 2) Why does the server not send data (for early write) after the server
> Hello(and other encrypted message) message even when early_write succeeds
> on server side. Why does server wait to finish the handshake. I know it
> waits because I see client sending encrypted messages after server hello
> message before my intended application data gets sent from server. These
> encrypted messages from the client side are the usual messages from the
> client side for handshake completion.
>
>
> From a quick look through the state machine code, this is supposed to
> work.  But someone would probably have to instrument the code (e.g., with
> printf) to tell why the delay is being introduced.  I don't think I have
> the availability to do so in the near future, myself.
>


I see that the application data is not being sent from server to an
unauthenticated client. The server is sending data only after receiving
some encrypted message which I believe is the EndOfEarlyData and Finished
messages. Following is  a dump of wireshark logs for the communication with
early data enabled. I also tried with some logs in Openssl libraries, I see
early data gets written from server side when write_early_data is called.
Internally SSL_write_ex is called which completes write and handshake. But
I am not sure why application data is not actually pushed from the server
side. It is waiting for the Client finished message.
I have disabled Nagle's algo during this operation.

Client port is 56806 and server port is 12345


No.     Time           Source                Destination           Protocol
Length Info
    207 18.380298      ::1                   ::1                   TLSv1.3
 956    Client Hello                   ----------------- Client Hello


No.     Time           Source                Destination           Protocol
Length Info
    208 18.380335      ::1                   ::1                   TLSv1.3
 2849   Application Data           ------------------*Early Data from the
client side (Intended Application Data)*
Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 881,
Ack: 1, Len: 2773

No.     Time           Source                Destination           Protocol
Length Info
    211 18.380624      ::1                   ::1                   TLSv1.3
 219    Server Hello, Application Data, Application Data . ------------Server
Hello and (encrypted handshake message/extensions)
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1,
Ack: 3654, Len: 143

No.     Time           Source                Destination           Protocol
Length Info
    213 18.380819      ::1                   ::1                   TLSv1.3
 160    Application Data, Application Data    ------Encrypted handshake msg
from client (*I believe they are end early data and finished*)
Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 3654,
Ack: 144, Len: 84


No.     Time           Source                Destination           Protocol
Length Info
    215 18.381122      ::1                   ::1                   TLSv1.3
 762    Application Data
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 144,
Ack: 3738, Len: 686   -----I don't know why this application data is sent
from server. My guess is this is session info


No.     Time           Source                Destination           Protocol
Length Info
    217 18.381210      ::1                   ::1                   TLSv1.3
 9917   Application Data          ----------*Intended Application Data that
was intended to be early data *
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 830,
Ack: 3738, Len: 9841

No.     Time           Source                Destination           Protocol
Length Info
    219 18.381308      ::1                   ::1                   TLSv1.3
 100    Application Data .             ---------Application Data from
client (I also see this application data sent everytime, not sure why)
Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 3738,
Ack: 10671, Len: 24


No.     Time           Source                Destination           Protocol
Length Info
    220 18.381309      ::1                   ::1                   TLSv1.3
 100    Application Data .  ---------Application Data from server (I also
see this application data sent everytime, not sure why)
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
10671, Ack: 3738, Len: 24

Please provide any comments if you have or how I should go about debugging
it. Correct me if I am doing it wrong




>
>
> 3) Also, the performance of TLS 1.3 using early data or resumption is
> worse than TLS 1.2 resumption on LAN. I see on wire-shark that encrypted
> messages get exchanged in TLS 1.3 during handshake which are plaintext in
> TLS 1.2. I think that causes extra latency. So can we say that TLS 1.3
> resumption is not recommended for LAN for performance enhancement when
> compared with TLS 1.2 resumption. On WAN, I see TLS 1.3 resumption at par
> with TLS 1.2 resumption and full handshake better for TLS 1.3.
>
>
> It seems like it hasn't really sunk in for you that TLS 1.3 is a seriously
> different protocol than TLS 1.2, and it provides stronger security
> properties, remediating weaknesses of TLS 1.2.  So no, we should not
> recommend TLS 1.2 resumption on the LAN -- we should recommend the more
> secure option!  If you continue to believe that latency trumps everything
> else, you could experiment with SSL_OP_ALLOW_NO_DHE_KEX to cut out some of
> the heavier-weight asymmetric crypto, though it looks like you'd want to
> patch ssl/statem/extensions_clnt.c to not send TLSEXT_KEX_MODE_KE_DHE, as I
> don't see a way to configure the server to prefer the non-DHE PSK key
> exchange.
>


OK, I understand that, Thanks Ben. I think I got a small improvement on
latency by removing TLSEXT_KEX_MODE_KE_DHE. But I also reckon that security
comes first and hence it requires deliberation.

 Thanks
BR,
Neetish

>
> -Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170725/5207b992/attachment-0001.html>

From saatomic at keemail.me  Wed Jul 26 06:45:20 2017
From: saatomic at keemail.me (SaAtomic)
Date: Wed, 26 Jul 2017 08:45:20 +0200 (CEST)
Subject: [openssl-users] Security of DH in TLS
Message-ID: <Kpxd7JY--3-0@keemail.me>

I'm trying to comprehend the security impact of the different DH implementations on TLS.

The main differences between the implementations are:
DHDHEECDHECDHE



Where the ephemeral DH provides forward secrecy, thus provides additional security.




I'm not really sure how the elliptic curves impact the security of DH. I think I've previously read something like, the key size (or public certificate length?) of DH can be smaller, with the use of elliptic curves. So without the use of elliptic curves the key size should be at least 2048, to be considered secure.




Is my assumption correct?

How can I identify the key size/ public certificate length (I'm not sure which is the correct term), to determine the security of DH in TLS?




Can I use the .pem file, used for DH, of my server to determine this?

I've created the .pem file with the following command:




openssl dhparam -out dhparam.pem 4096




and with the following command I believe I can determine the key length:




openssl dhparam -inform PEM -in ./dhparam.pem -check -text

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/ac53625c/attachment.html>

From paulyang.inf at gmail.com  Wed Jul 26 07:19:31 2017
From: paulyang.inf at gmail.com (Paul Yang)
Date: Wed, 26 Jul 2017 15:19:31 +0800
Subject: [openssl-users] Security of DH in TLS
In-Reply-To: <Kpxd7JY--3-0@keemail.me>
References: <Kpxd7JY--3-0@keemail.me>
Message-ID: <6BB66A48-463C-4E7A-B975-0859A861EFF0@gmail.com>

The ?key size? concept is usually referred to the length of modulus. (In public key crypto area)

For DH and ECDH, it (the size) ?s generated and defined in the ?parameters?, as you pasted. Parameters are not exactly the final ?keys?, they are the ?materials? to produce keys (both private ones and public ones), either for DH or ECDH. For DH, you generate parameters based on a given length of prime, and this length is what you called ?key size? (e.g. 2048), for ECC the parameters are generated based on named curves, such as prime192v1/prime239v1..., in this case, the ?key size? is 192/239bit. In both case, the prime numbers are used as modulus being used while doing DH or EC crypto calculations...

If you get either a DH or EC key, you could use the following command of OpenSSL to check the ?key size?:

openssl pkey -in xyz.key -noout -text

check the Private-Key: (xxxx bit) in the output.

> On 26 Jul 2017, at 14:45, SaAtomic <saatomic at keemail.me> wrote:
> 
> I'm trying to comprehend the security impact of the different DH implementations on TLS.
> 
> The main differences between the implementations are:
> DH
> DHE
> ECDH
> ECDHE
> 
> 
> Where the ephemeral DH provides forward secrecy, thus provides additional security.
> 
> 
> 
> I'm not really sure how the elliptic curves impact the security of DH. I think I've previously read something like, the key size (or public certificate length?) of DH can be smaller, with the use of elliptic curves. So without the use of elliptic curves the key size should be at least 2048, to be considered secure.
> 
> 
> 
> Is my assumption correct?
> 
> How can I identify the key size/ public certificate length (I'm not sure which is the correct term), to determine the security of DH in TLS?
> 
> 
> 
> Can I use the .pem file, used for DH, of my server to determine this?
> 
> I've created the .pem file with the following command:
> 
> 
> 
> openssl dhparam -out dhparam.pem 4096
> 
> 
> 
> and with the following command I believe I can determine the key length:
> 
> 
> 
> openssl dhparam -inform PEM -in ./dhparam.pem -check -text
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/07804f7f/attachment.html>

From saatomic at keemail.me  Wed Jul 26 07:56:24 2017
From: saatomic at keemail.me (SaAtomic)
Date: Wed, 26 Jul 2017 09:56:24 +0200 (CEST)
Subject: [openssl-users] Security of DH in TLS
Message-ID: <KpxtOOc--3-0@keemail.me>

Thanks for the reply.
I'm still not sure I understand this correctly. 

So the  length of modulus is the essential part, determining the security of the DH, right?
With ECC, this is defined by the used curves.
Without ECC, this is determined by the DH parameters (from the .pem file I mentioned).

If a server only supported ECDH or ECDHE, the DH parameters (.pem) file wouldn't even be needed.

Is this correct?

Thank you for your help,
kind regards,
SaAtomic

---------
> Paul Yang paulyang.inf at gmail.com
> Wed Jul 26 07:19:31 UTC 2017
> The ?key size? concept is usually referred to the length of modulus. (In public key crypto area)
> For DH and ECDH, it (the size) ?s generated and defined in the ?parameters?, as you pasted. Parameters are not exactly the final ?keys?, they are the ?materials? to produce keys (both private ones and public ones), either for DH or ECDH. For DH, you generate parameters based on a given length of prime, and this length is what you called ?key size? (e.g. 2048), for ECC the parameters are generated based on named curves, such as prime192v1/prime239v1..., in this case, the ?key > size? is 192/239bit. In both case, the prime numbers are used as modulus being used while doing DH or EC crypto calculations...
> 
> If you get either a DH or EC key, you could use the following command of OpenSSL to check the ?key size?:
> 
> openssl pkey -in xyz.key -noout -text
> 
> check the Private-Key: (xxxx bit) in the output.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/0ed5e0da/attachment.html>

From paulyang.inf at gmail.com  Wed Jul 26 08:14:28 2017
From: paulyang.inf at gmail.com (Paul Yang)
Date: Wed, 26 Jul 2017 16:14:28 +0800
Subject: [openssl-users] Security of DH in TLS
In-Reply-To: <KpxtOOc--3-0@keemail.me>
References: <KpxtOOc--3-0@keemail.me>
Message-ID: <BF8CD63E-57C2-4FCB-9A07-0E698A1FFAD4@gmail.com>


> On 26 Jul 2017, at 15:56, SaAtomic <saatomic at keemail.me> wrote:
> 
> Thanks for the reply.
> I'm still not sure I understand this correctly. 
> 
> So the length of modulus is the essential part, determining the security of the DH, right?

Mostly.

> With ECC, this is defined by the used curves.
> Without ECC, this is determined by the DH parameters (from the .pem file I mentioned).
> 
> If a server only supported ECDH or ECDHE, the DH parameters (.pem) file wouldn't even be needed.

Yes, in that case, you only need an EC key (and also EC parameters to generate this key, of course)

> 
> Is this correct?
> 
> Thank you for your help,
> kind regards,
> SaAtomic
> 
> ---------
> > Paul Yang paulyang.inf at gmail.com
> > Wed Jul 26 07:19:31 UTC 2017
> > The ?key size? concept is usually referred to the length of modulus. (In public key crypto area)
> > For DH and ECDH, it (the size) ?s generated and defined in the ?parameters?, as you pasted. Parameters are not exactly the final ?keys?, they are the ?materials? to produce keys (both private ones and public ones), either for DH or ECDH. For DH, you generate parameters based on a given length of prime, and this length is what you called ?key size? (e.g. 2048), for ECC the parameters are generated based on named curves, such as prime192v1/prime239v1..., in this case, the ?key > size? is 192/239bit. In both case, the prime numbers are used as modulus being used while doing DH or EC crypto calculations...
> > 
> > If you get either a DH or EC key, you could use the following command of OpenSSL to check the ?key size?:
> > 
> > openssl pkey -in xyz.key -noout -text
> > 
> > check the Private-Key: (xxxx bit) in the output.


From saatomic at keemail.me  Wed Jul 26 08:21:26 2017
From: saatomic at keemail.me (SaAtomic)
Date: Wed, 26 Jul 2017 10:21:26 +0200 (CEST)
Subject: [openssl-users] Security of DH in TLS
In-Reply-To: <BF8CD63E-57C2-4FCB-9A07-0E698A1FFAD4@gmail.com>
References: <KpxtOOc--3-0@keemail.me> <<KpxtOOc--3-0@keemail.me>>
 <BF8CD63E-57C2-4FCB-9A07-0E698A1FFAD4@gmail.com>
Message-ID: <Kpxz72Q--3-0@keemail.me>

The subject is much clearer to me now, thank you.

The EC key you mentioned is not created manually, correct?
This key is a result of ECC, which is done by OpenSSL.

So if I set up a server offering TLS connections and only offer ECDH/ECDHE, no additional data has to be generated manually, correct?

Kind regards,
SaAtomic


26. Jul 2017 10:14 by paulyang.inf at gmail.com:


>> On 26 Jul 2017, at 15:56, SaAtomic <>> saatomic at keemail.me>> > wrote:
>>
>> Thanks for the reply.
>> I'm still not sure I understand this correctly. 
>>
>> So the length of modulus is the essential part, determining the security of the DH, right?
>
> Mostly.
>
>> With ECC, this is defined by the used curves.
>> Without ECC, this is determined by the DH parameters (from the .pem file I mentioned).
>>
>> If a server only supported ECDH or ECDHE, the DH parameters (.pem) file wouldn't even be needed.
>
> Yes, in that case, you only need an EC key (and also EC parameters to generate this key, of course)
>
>>
>> Is this correct?
>>
>> Thank you for your help,
>> kind regards,
>> SaAtomic
>>
>> ---------
>> > Paul Yang paulyang.inf at gmail.com
>> > Wed Jul 26 07:19:31 UTC 2017
>> > The ?key size? concept is usually referred to the length of modulus. (In public key crypto area)
>> > For DH and ECDH, it (the size) ?s generated and defined in the ?parameters?, as you pasted. Parameters are not exactly the final ?keys?, they are the ?materials? to produce keys (both private ones and public ones), either for DH or ECDH. For DH, you generate parameters based on a given length of prime, and this length is what you called ?key size? (e.g. 2048), for ECC the parameters are generated based on named curves, such as prime192v1/prime239v1..., in this case, the ?key > size? is 192/239bit. In both case, the prime numbers are used as modulus being used while doing DH or EC crypto calculations...
>> > 
>> > If you get either a DH or EC key, you could use the following command of OpenSSL to check the ?key size?:
>> > 
>> > openssl pkey -in xyz.key -noout -text
>> > 
>> > check the Private-Key: (xxxx bit) in the output.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/be1a9c9d/attachment-0001.html>

From paulyang.inf at gmail.com  Wed Jul 26 08:39:47 2017
From: paulyang.inf at gmail.com (Paul Yang)
Date: Wed, 26 Jul 2017 16:39:47 +0800
Subject: [openssl-users] Security of DH in TLS
In-Reply-To: <Kpxz72Q--3-0@keemail.me>
References: <KpxtOOc--3-0@keemail.me> <KpxtOOc--3-0@keemail.me>
 <BF8CD63E-57C2-4FCB-9A07-0E698A1FFAD4@gmail.com> <Kpxz72Q--3-0@keemail.me>
Message-ID: <B614FECB-BA0E-472D-8C7F-26E164CF54B5@gmail.com>


> On 26 Jul 2017, at 16:21, SaAtomic <saatomic at keemail.me> wrote:
> 
> The subject is much clearer to me now, thank you.
> 
> The EC key you mentioned is not created manually, correct?
> This key is a result of ECC, which is done by OpenSSL.
> 
> So if I set up a server offering TLS connections and only offer ECDH/ECDHE, no additional data has to be generated manually, correct?

Ahh, that depends on how you use ECC in TLS. If you use something like ?ECDHE-RSA-XXX-YYY?, you don?t need to manipulate the ECC stuff ?manually?, since the authentication part of that cipher suite is RSA, just preparing an RSA key/certificate is enough. But if you want to use stuffs like ?ECDHE-ECDSA-XXX-YYY?, you need to prepare ECC private key (and also the corresponding certificate that encodes the ECC public key). For ECDH ciphers (without the ?E? part), that?s more confused, IIRC, in such case the authentication part of that kind ciphers indicates what signature algorithm is used to sign the certificate, but not the ?public-key-type? in the certificate, so anyway you probably need to get a ECC key/certificate pair. But the without-?E? version of such usage seems rare, I have never meet one in production environment...

And also, don?t mix up the ECC keys used in a `key exchange? phase during TLS handshake with the keys used in ?auth? phase. I suggest you to read the following RFC documentation to get clear understandings on this: https://www.ietf.org/rfc/rfc4492.txt <https://www.ietf.org/rfc/rfc4492.txt>

Hope it helps : )

> 
> Kind regards,
> SaAtomic
> 
> 
> 26. Jul 2017 10:14 by paulyang.inf at gmail.com <mailto:paulyang.inf at gmail.com>:
> 
> On 26 Jul 2017, at 15:56, SaAtomic <saatomic at keemail.me <mailto:saatomic at keemail.me>> wrote:
> 
> Thanks for the reply.
> I'm still not sure I understand this correctly. 
> 
> So the length of modulus is the essential part, determining the security of the DH, right?
> 
> Mostly.
> With ECC, this is defined by the used curves.
> Without ECC, this is determined by the DH parameters (from the .pem file I mentioned).
> 
> If a server only supported ECDH or ECDHE, the DH parameters (.pem) file wouldn't even be needed.
> 
> Yes, in that case, you only need an EC key (and also EC parameters to generate this key, of course)
> 
> Is this correct?
> 
> Thank you for your help,
> kind regards,
> SaAtomic
> 
> ---------
> > Paul Yang paulyang.inf at gmail.com
> > Wed Jul 26 07:19:31 UTC 2017
> > The ?key size? concept is usually referred to the length of modulus. (In public key crypto area)
> > For DH and ECDH, it (the size) ?s generated and defined in the ?parameters?, as you pasted. Parameters are not exactly the final ?keys?, they are the ?materials? to produce keys (both private ones and public ones), either for DH or ECDH. For DH, you generate parameters based on a given length of prime, and this length is what you called ?key size? (e.g. 2048), for ECC the parameters are generated based on named curves, such as prime192v1/prime239v1..., in this case, the ?key > size? is 192/239bit. In both case, the prime numbers are used as modulus being used while doing DH or EC crypto calculations...
> > 
> > If you get either a DH or EC key, you could use the following command of OpenSSL to check the ?key size?:
> > 
> > openssl pkey -in xyz.key -noout -text
> > 
> > check the Private-Key: (xxxx bit) in the output.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/0050a7fc/attachment.html>

From saatomic at keemail.me  Wed Jul 26 10:38:54 2017
From: saatomic at keemail.me (SaAtomic)
Date: Wed, 26 Jul 2017 12:38:54 +0200 (CEST)
Subject: [openssl-users] Security of DH in TLS
In-Reply-To: <B614FECB-BA0E-472D-8C7F-26E164CF54B5@gmail.com>
References: <KpxtOOc--3-0@keemail.me> <<KpxtOOc--3-0@keemail.me>>
 <BF8CD63E-57C2-4FCB-9A07-0E698A1FFAD4@gmail.com> <Kpxz72Q--3-0@keemail.me>
 <<Kpxz72Q--3-0@keemail.me>> <B614FECB-BA0E-472D-8C7F-26E164CF54B5@gmail.com>
Message-ID: <KpyT_aK--3-0@keemail.me>


Thank you for the elaboration and the link.
One more follow-up question :)

With OpenVPN, when I configure a TLS cipher suite like `TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256`, I never manually created an ECC private key.
You mentioned that this is required for such cipher suites. Does in this case OpenVPN take over that task, or is that yet another special case?

Kinds regards,
SaAtomic

26. Jul 2017 10:39 by paulyang.inf at gmail.com:


>
>
>> On 26 Jul 2017, at 16:21, SaAtomic <>> saatomic at keemail.me>> > wrote:
>>           >> The subject is much clearer to me now, thank you.
>>
>> The EC key you mentioned is not created manually, correct?
>> This key is a result of ECC, which is done by OpenSSL.
>>
>> So if I set up a server offering TLS connections and only offer ECDH/ECDHE, no additional data has to be generated manually, correct?
>>
>
> Ahh, that depends on how you use ECC in TLS. If you use something like ?ECDHE-RSA-XXX-YYY?, you don?t need to manipulate the ECC stuff ?manually?, since the authentication part of that cipher suite is RSA, just preparing an RSA key/certificate is enough. But if you want to use stuffs like ?ECDHE-ECDSA-XXX-YYY?, you need to prepare ECC private key (and also the corresponding certificate that encodes the ECC public key). For ECDH ciphers (without the ?E? part), that?s more confused, IIRC, in such case the authentication part of that kind ciphers indicates what signature algorithm is used to sign the certificate, but not the ?public-key-type? in the certificate, so anyway you probably need to get a ECC key/certificate pair. But the without-?E? version of such usage seems rare, I have never meet one in production environment...
> And also, don?t mix up the ECC keys used in a `key exchange? phase during TLS handshake with the keys used in ?auth? phase. I suggest you to read the following RFC documentation to get clear understandings on this:?> https://www.ietf.org/rfc/rfc4492.txt
> Hope it helps : )
>
>>
>> Kind regards,
>> SaAtomic
>>
>>
>> 26. Jul 2017 10:14 by >> paulyang.inf at gmail.com>> :
>>
>>
>>>> On 26 Jul 2017, at 15:56, SaAtomic <>>>> saatomic at keemail.me>>>> > wrote:
>>>>
>>>> Thanks for the reply.
>>>> I'm still not sure I understand this correctly. 
>>>>
>>>> So the length of modulus is the essential part, determining the security of the DH, right?
>>>
>>> Mostly.
>>>
>>>> With ECC, this is defined by the used curves.
>>>> Without ECC, this is determined by the DH parameters (from the .pem file I mentioned).
>>>>
>>>> If a server only supported ECDH or ECDHE, the DH parameters (.pem) file wouldn't even be needed.
>>>
>>> Yes, in that case, you only need an EC key (and also EC parameters to generate this key, of course)
>>>
>>>>
>>>> Is this correct?
>>>>
>>>> Thank you for your help,
>>>> kind regards,
>>>> SaAtomic
>>>>
>>>> ---------
>>>> > Paul Yang paulyang.inf at >>>> gmail.com
>>>> > Wed Jul 26 07:19:31 UTC 2017
>>>> > The ?key size? concept is usually referred to the length of modulus. (In public key crypto area)
>>>> > For DH and ECDH, it (the size) ?s generated and defined in the ?parameters?, as you pasted. Parameters are not exactly the final ?keys?, they are the ?materials? to produce keys (both private ones and public ones), either for DH or ECDH. For DH, you generate parameters based on a given length of prime, and this length is what you called ?key size? (e.g. 2048), for ECC the parameters are generated based on named curves, such as prime192v1/prime239v1..., in this case, the ?key > size? is 192/239bit. In both case, the prime numbers are used as modulus being used while doing DH or EC crypto calculations...
>>>> > 
>>>> > If you get either a DH or EC key, you could use the following command of OpenSSL to check the ?key size?:
>>>> > 
>>>> > openssl pkey -in xyz.key -noout -text
>>>> > 
>>>> > check the Private-Key: (xxxx bit) in the output.
>>   
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/626b614d/attachment.html>

From paulyang.inf at gmail.com  Wed Jul 26 12:08:31 2017
From: paulyang.inf at gmail.com (Paul Yang)
Date: Wed, 26 Jul 2017 20:08:31 +0800
Subject: [openssl-users] Security of DH in TLS
In-Reply-To: <KpyT_aK--3-0@keemail.me>
References: <KpxtOOc--3-0@keemail.me> <KpxtOOc--3-0@keemail.me>
 <BF8CD63E-57C2-4FCB-9A07-0E698A1FFAD4@gmail.com> <Kpxz72Q--3-0@keemail.me>
 <Kpxz72Q--3-0@keemail.me> <B614FECB-BA0E-472D-8C7F-26E164CF54B5@gmail.com>
 <KpyT_aK--3-0@keemail.me>
Message-ID: <5ED39EBC-1C98-42D1-8844-919B69FEA9EB@gmail.com>

No idea on OpenVPN, I guess you could ask them directly : )

> On 26 Jul 2017, at 18:38, SaAtomic <saatomic at keemail.me> wrote:
> 
> 
> Thank you for the elaboration and the link.
> One more follow-up question :)
> 
> With OpenVPN, when I configure a TLS cipher suite like `TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256`, I never manually created an ECC private key.
> You mentioned that this is required for such cipher suites. Does in this case OpenVPN take over that task, or is that yet another special case?
> 
> Kinds regards,
> SaAtomic
> 
> 26. Jul 2017 10:39 by paulyang.inf at gmail.com <mailto:paulyang.inf at gmail.com>:
> 
> 
> On 26 Jul 2017, at 16:21, SaAtomic <saatomic at keemail.me <mailto:saatomic at keemail.me>> wrote:
> 
> The subject is much clearer to me now, thank you.
> 
> The EC key you mentioned is not created manually, correct?
> This key is a result of ECC, which is done by OpenSSL.
> 
> So if I set up a server offering TLS connections and only offer ECDH/ECDHE, no additional data has to be generated manually, correct?
> 
> Ahh, that depends on how you use ECC in TLS. If you use something like ?ECDHE-RSA-XXX-YYY?, you don?t need to manipulate the ECC stuff ?manually?, since the authentication part of that cipher suite is RSA, just preparing an RSA key/certificate is enough. But if you want to use stuffs like ?ECDHE-ECDSA-XXX-YYY?, you need to prepare ECC private key (and also the corresponding certificate that encodes the ECC public key). For ECDH ciphers (without the ?E? part), that?s more confused, IIRC, in such case the authentication part of that kind ciphers indicates what signature algorithm is used to sign the certificate, but not the ?public-key-type? in the certificate, so anyway you probably need to get a ECC key/certificate pair. But the without-?E? version of such usage seems rare, I have never meet one in production environment...
> 
> And also, don?t mix up the ECC keys used in a `key exchange? phase during TLS handshake with the keys used in ?auth? phase. I suggest you to read the following RFC documentation to get clear understandings on this: https://www.ietf.org/rfc/rfc4492.txt <https://www.ietf.org/rfc/rfc4492.txt>
> 
> Hope it helps : )
> 
> 
> Kind regards,
> SaAtomic
> 
> 
> 26. Jul 2017 10:14 by paulyang.inf at gmail.com <mailto:paulyang.inf at gmail.com>:
> 
> On 26 Jul 2017, at 15:56, SaAtomic <saatomic at keemail.me <mailto:saatomic at keemail.me>> wrote:
> 
> Thanks for the reply.
> I'm still not sure I understand this correctly. 
> 
> So the length of modulus is the essential part, determining the security of the DH, right?
> 
> Mostly.
> With ECC, this is defined by the used curves.
> Without ECC, this is determined by the DH parameters (from the .pem file I mentioned).
> 
> If a server only supported ECDH or ECDHE, the DH parameters (.pem) file wouldn't even be needed.
> 
> Yes, in that case, you only need an EC key (and also EC parameters to generate this key, of course)
> 
> Is this correct?
> 
> Thank you for your help,
> kind regards,
> SaAtomic
> 
> ---------
> > Paul Yang paulyang.inf at gmail.com <http://gmail.com/>
> > Wed Jul 26 07:19:31 UTC 2017
> > The ?key size? concept is usually referred to the length of modulus. (In public key crypto area)
> > For DH and ECDH, it (the size) ?s generated and defined in the ?parameters?, as you pasted. Parameters are not exactly the final ?keys?, they are the ?materials? to produce keys (both private ones and public ones), either for DH or ECDH. For DH, you generate parameters based on a given length of prime, and this length is what you called ?key size? (e.g. 2048), for ECC the parameters are generated based on named curves, such as prime192v1/prime239v1..., in this case, the ?key > size? is 192/239bit. In both case, the prime numbers are used as modulus being used while doing DH or EC crypto calculations...
> > 
> > If you get either a DH or EC key, you could use the following command of OpenSSL to check the ?key size?:
> > 
> > openssl pkey -in xyz.key -noout -text
> > 
> > check the Private-Key: (xxxx bit) in the output.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/3c3770dd/attachment-0001.html>

From Amr.Hegazi at vector.com  Wed Jul 26 14:06:47 2017
From: Amr.Hegazi at vector.com (Hegazi, Amr)
Date: Wed, 26 Jul 2017 14:06:47 +0000
Subject: [openssl-users] C# OpenSSL openssl-net-master - OpenSSL Server
	malfunction
Message-ID: <A6D54C65320840469319C2B2692E92140527A396@vistrex4.vi.vector.int>

Hello *,

Even if no one know what to do, has anyone ever used OpenSSL Server? and if so, is there any configuration parameters that I should take care of in case of OpenSSL Server?

I hope to hear positive response from you guys.

Best Regards,

Amr

From: Hegazi, Amr
Sent: Tuesday, July 25, 2017 6:50 PM
To: 'openssl-users at openssl.org'
Subject: Considering C# OpenSSL openssl-net-master

Hello *,

I'm using the last version of C# OpenSSL from https://github.com/openssl-net/openssl-net (This wrapper is based on version 1.0.2a of libeay32.dll and ssleay32.dll).

I'm using C# OpenSSL to test my Tls Client that supports TLS starting from version 1.2 and all the cipher suites. Moreover, I'm using Microsoft windows 7. I have already installed Microsoft visual C++ 2010 express and Microsoft visual Studio 2010.

I always face an error "TLSv1.2  81 - Alert (Level: Fatal, Description: Insufficient Security)"

I have debugged the issue. The issue come from a function called SSL_CTX_new() which is connected to ssleay32.dll. the clienthello is always sent correctly and then the OpenSSL server replies with Insufficient Security

The console also shows this:
.NET   HSM Received: ClientHello (188 bytes)
.NET   Offered suite by client: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) [not supported]
.NET   Offered suite by client: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) [not supported]
.NET   Offered suite by client: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) [not supported]
.NET   Offered suite by client: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) [not supported]
.NET   Offered suite by client: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) [not supported]
.NET   Offered suite by client: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) [not supported]
.NET   Offered suite by client: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) [not supported]
.NET   Offered suite by client: TLS_ECDH_ECDSA_WITH_NULL_SHA (0xc001) [not supported]
.NET   Offered suite by client: TLS_RSA_WITH_NULL_SHA256 (0x003b) [not supported]
.NET   Offered suite by client: TLS_RSA_WITH_NULL_SHA (0x0002) [not supported]
.NET   ALERT SENT    : Fatal InsufficientSecurity
.NET   no shared cipher suites

And in Wireshark shows this:

"3406.315537","fe80::ff:fe00:2","fe80::1:5","SSL","271","Client Hello"
"3419.805155","fe80::1:5","fe80::ff:fe00:2","TLSv1.2","81","Alert (Level: Fatal, Description: Insufficient Security)"

So, I think the error is in something related to configuration of ssleay32.dll

My code is simple and is as follows:

try
        {
              TestCaseBegin();

            Output.WriteLine("TLS Server Certificate preparation");
            CertDir = Path.GetFullPath("..\\Appl\\Certificates\\Certificate");
TlsServerCertificate = loadCertificateFromFile(Path.Combine(CertDir, @"Vector_ServerCertificate_RsaSha1_IA_pfx.pfx"), "123456");
TlsServerCaCertificates = new X509Chain(OpenSSL.Core.BIO.File(Path.Combine(CertDir, @"Vector_ServerCertificate_RsaSha1_Root_cert.cer"), "r"));

            Output.WriteLine("Start connection");
            TS_RcTlsConnect(TlsConnectMode.Rsa);

            Output.WriteLine("Send Client Hello");
            TS_WaitForTcpConnection();

            Output.WriteLine("make sslStreamServer");
SslStream sslStreamServer = new SslStream(tcpClient.GetStream(), true, MyRemoteCertificateValidationHandler,MyLocalCertificateSelectionHandler);

Output.WriteLine("Start AuthenticateAsServer");

sslStreamServer.AuthenticateAsServer(TlsServerCertificate, false, TlsServerCaCertificates, SslProtocols.Tls, SslStrength.All, false);
        }

        catch (TestStepFailException e)
{
HandleTestStepFailException(e);
Output.WriteLine(e.ToString());
             }
       catch (Exception ex)
{
PrintException(ex);
                    Output.WriteLine(ex.ToString());
             }
        finally
        {
            TestCaseEnd();
        }

Has anyone an idea?

Best Regards;

Amr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/4b6a1009/attachment.html>

From michele.mase at gmail.com  Wed Jul 26 15:13:20 2017
From: michele.mase at gmail.com (Michele Mase')
Date: Wed, 26 Jul 2017 17:13:20 +0200
Subject: [openssl-users] private key difference: openssl genrsa vs opnessl
	req newkey
Message-ID: <CAC=HunttAjaSwcnWzuatZW_w2fCDA9WfO0CnTqmHK5_5GpvWEw@mail.gmail.com>

During the generation of x509 certificates, both commands give the same
results:

Command "a": openssl req -nodes -newkey rsa:2048 -keyout example.key -out
example.csr -subj "/C=GB/ST=London/L=London/O=Global Security/OU=IT
Department/CN=example.com"
Command "b": openssl genrsa -out example.key

Both commands give me a private key without password, a key that is not
encrypted.
To remove the passphrase from private key, I use the
Command "c":openssl rsa -in example.key -out example2.key

The command "c" against the example.key generated by command "a", gives the
same private key with different content between --BEGIN RSA and --END RSA.
Simply, try the following:
diff example.key example2.key, the files are different.

The command "c" against example.key generate by the command "b" produces
the same file. No differences.

Why?
Perhaps I missed something in openssl manual ... :(
These differenced gave me troubles using custom certificates in some
software.
Any suggestion?
Regards
Michele MAs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/37e4a963/attachment-0001.html>

From bkaduk at akamai.com  Wed Jul 26 16:29:15 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Wed, 26 Jul 2017 11:29:15 -0500
Subject: [openssl-users] private key difference: openssl genrsa vs
 opnessl req newkey
In-Reply-To: <CAC=HunttAjaSwcnWzuatZW_w2fCDA9WfO0CnTqmHK5_5GpvWEw@mail.gmail.com>
References: <CAC=HunttAjaSwcnWzuatZW_w2fCDA9WfO0CnTqmHK5_5GpvWEw@mail.gmail.com>
Message-ID: <9e1b4814-7379-b476-2818-aed1cefe7312@akamai.com>

On 07/26/2017 10:13 AM, Michele Mase' wrote:
> During the generation of x509 certificates, both commands give the
> same results:
>
> Command "a": openssl req -nodes -newkey rsa:2048 -keyout example.key
> -out example.csr -subj "/C=GB/ST=London/L=London/O=Global
> Security/OU=IT Department/CN=example.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=SvmGwnxF6Arf5U_XmN1vPPpie6IFH3h5CkVhveCn26I&s=AMT2W-m9xgiUsKMETv-WcWALqfQnX1rujJdNTJsVz1E&e=>"
> Command "b": openssl genrsa -out example.key
>
> Both commands give me a private key without password, a key that is
> not encrypted.
> To remove the passphrase from private key, I use the
> Command "c":openssl rsa -in example.key -out example2.key
>
> The command "c" against the example.key generated by command "a",
> gives the same private key with different content between --BEGIN RSA
> and --END RSA. Simply, try the following:
> diff example.key example2.key, the files are different.
>
> The command "c" against example.key generate by the command "b"
> produces the same file. No differences.
>
> Why?
> Perhaps I missed something in openssl manual ... :(
> These differenced gave me troubles using custom certificates in some
> software.
> Any suggestion?

The output from openssl req includes an additional layer of encoding and
the rsaEncryption OID around the actual key parameters, as can be seen
using openssl asn1parse.  The conversion with 'openssl rsa' removes that
extra encoding.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/93760baa/attachment.html>

From michele.mase at gmail.com  Wed Jul 26 19:21:43 2017
From: michele.mase at gmail.com (Michele Mase')
Date: Wed, 26 Jul 2017 21:21:43 +0200
Subject: [openssl-users] private key difference: openssl genrsa vs
 opnessl req newkey
Message-ID: <CAC=HuntL4nCvOKNFNCKErub-Z9Ga0wEh03ygwicnETwbhDbeiw@mail.gmail.com>

Tx.
So, what should be the command line to use in order to obtain the same key?
openssl genrsa ....
openssl req -nodes -newkey rsa:2048 some_extra_parameters ....
Michele MAs?

On Wed, Jul 26, 2017 at 6:29 PM, Benjamin Kaduk <bkaduk at akamai.com> wrote:

> On 07/26/2017 10:13 AM, Michele Mase' wrote:
>
> During the generation of x509 certificates, both commands give the same
> results:
>
> Command "a": openssl req -nodes -newkey rsa:2048 -keyout example.key -out
> example.csr -subj "/C=GB/ST=London/L=London/O=Global Security/OU=IT
> Department/CN=example.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=SvmGwnxF6Arf5U_XmN1vPPpie6IFH3h5CkVhveCn26I&s=AMT2W-m9xgiUsKMETv-WcWALqfQnX1rujJdNTJsVz1E&e=>
> "
> Command "b": openssl genrsa -out example.key
>
> Both commands give me a private key without password, a key that is not
> encrypted.
> To remove the passphrase from private key, I use the
> Command "c":openssl rsa -in example.key -out example2.key
>
> The command "c" against the example.key generated by command "a", gives
> the same private key with different content between --BEGIN RSA and --END
> RSA. Simply, try the following:
> diff example.key example2.key, the files are different.
>
> The command "c" against example.key generate by the command "b" produces
> the same file. No differences.
>
> Why?
> Perhaps I missed something in openssl manual ... :(
> These differenced gave me troubles using custom certificates in some
> software.
> Any suggestion?
>
>
> The output from openssl req includes an additional layer of encoding and
> the rsaEncryption OID around the actual key parameters, as can be seen
> using openssl asn1parse.  The conversion with 'openssl rsa' removes that
> extra encoding.
>
> -Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/5b1f306c/attachment.html>

From jb-openssl at wisemo.com  Wed Jul 26 19:58:36 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 26 Jul 2017 21:58:36 +0200
Subject: [openssl-users] Considering C# OpenSSL openssl-net-master
In-Reply-To: <6482a682d8cf45d7ba8c005870d06c6c@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <A6D54C65320840469319C2B2692E921405279AD8@vistrex4.vi.vector.int>
 <6482a682d8cf45d7ba8c005870d06c6c@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <91f20dc5-4061-4f17-66d6-2475c1739a86@wisemo.com>

On 25/07/2017 19:00, Salz, Rich via openssl-users wrote:
>
> If you want to use those ciphers, you need to set SECLEVEL=0 when you 
> specify the ciphers.
>
> I have no idea how to do that for the OpoenSSL C# binding.  Maybe post 
> an issue on openssl-net?
>
>

When did TLS_RSA_WITH_AES_128_CBC_SHA256 and higher become
"low security"?

It looks like the client is an older product (ECDH only offered
for ECDSA certs, classic DH not offered, no algorithms above
128 bits).

So I guess the OP just needs to check if he is using an empty
cipher string or something silly like that.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From jeremy.farrell at oracle.com  Wed Jul 26 20:31:15 2017
From: jeremy.farrell at oracle.com (J. J. Farrell)
Date: Wed, 26 Jul 2017 21:31:15 +0100
Subject: [openssl-users] Considering C# OpenSSL openssl-net-master
In-Reply-To: <91f20dc5-4061-4f17-66d6-2475c1739a86@wisemo.com>
References: <A6D54C65320840469319C2B2692E921405279AD8@vistrex4.vi.vector.int>
 <6482a682d8cf45d7ba8c005870d06c6c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <91f20dc5-4061-4f17-66d6-2475c1739a86@wisemo.com>
Message-ID: <8e7cdfef-9639-fc39-5c10-d85be49dac0f@oracle.com>

On 26/07/2017 20:58, Jakob Bohm wrote:
> On 25/07/2017 19:00, Salz, Rich via openssl-users wrote:
>>
>> If you want to use those ciphers, you need to set SECLEVEL=0 when you 
>> specify the ciphers.
>
> When did TLS_RSA_WITH_AES_128_CBC_SHA256 and higher become
> "low security"?
>
> It looks like the client is an older product (ECDH only offered
> for ECDSA certs, classic DH not offered, no algorithms above
> 128 bits).
>
> So I guess the OP just needs to check if he is using an empty
> cipher string or something silly like that.

The OP said he was testing his "Tls Client that supports TLS starting 
from version 1.2 and all the cipher suites". Perhaps he's found his 
first bug, since the client isn't offering all the TLS 1.2 cipher suites ...

-- 
J. J. Farrell
Not speaking for Oracle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170726/86f70f56/attachment.html>

From rgm at htt-consult.com  Thu Jul 27 14:18:50 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 27 Jul 2017 10:18:50 -0400
Subject: [openssl-users] EDDSA certificates
In-Reply-To: <275dad3d0ada432d9c7b2b5f30db2b8f@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <b3bd575f-c65a-25c8-52e2-5601f2ccf75e@htt-consult.com>
 <275dad3d0ada432d9c7b2b5f30db2b8f@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <eb949b6e-b5b6-15eb-444e-68d3ccf13590@htt-consult.com>

Rich,

Meant to ask you about this at IETF.

Given draft-ietf-curdle-pkix-05.txt sec 10, is there openssl code to 
produce these???

And, relatedly, what do you think about CBOR encoding rather than 
ASN.1?  Kill ASN.1 in constrained devices and save on transmission costs?

Thanks

Bob

On 03/16/2017 07:04 PM, Salz, Rich via openssl-users wrote:
>   
>> Does any version of OpenSSL provide support for EDDSA, particularly creating
>> and displaying the content of them?
> Not yet.  EDDSA for 25519 and 448 would be great to have in the next relese, tho.


From bkaduk at akamai.com  Thu Jul 27 14:45:34 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Thu, 27 Jul 2017 09:45:34 -0500
Subject: [openssl-users] EDDSA certificates
In-Reply-To: <eb949b6e-b5b6-15eb-444e-68d3ccf13590@htt-consult.com>
References: <b3bd575f-c65a-25c8-52e2-5601f2ccf75e@htt-consult.com>
 <275dad3d0ada432d9c7b2b5f30db2b8f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <eb949b6e-b5b6-15eb-444e-68d3ccf13590@htt-consult.com>
Message-ID: <3da85680-edb0-cef5-d6e7-b8f02754d824@akamai.com>

On 07/27/2017 09:18 AM, Robert Moskowitz wrote:
> Rich,
>
> Meant to ask you about this at IETF.
>
> Given draft-ietf-curdle-pkix-05.txt sec 10, is there openssl code to
> produce these???
>

There is code to validate them, per commit
4328dd41582bcdca8e4f51f0a3abadfafa2163ee.  I didn't look hard enough to
find how to generate them, but it ought to be there too.

> And, relatedly, what do you think about CBOR encoding rather than
> ASN.1?  Kill ASN.1 in constrained devices and save on transmission costs?

It seems hard to shift a big ecosystem and introduce risk of
incompatibility, but I haven't really thought about it.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170727/5d3dbe7a/attachment.html>

From todd at toddblum.org  Thu Jul 27 19:49:02 2017
From: todd at toddblum.org (Todd Blum)
Date: Thu, 27 Jul 2017 15:49:02 -0400
Subject: [openssl-users] Apache/OpenSSL1.1 sending Fatal,
 Description: Handshake Failure' packet to WebDAV client
Message-ID: <CAPKwGrdiNJB=qWDpTzF1vqad=ipS2CcKnsfuMNJGyy-dN4DzgA@mail.gmail.com>

Hello,

I have an Apache 2.4.27/OpenSSL1.1.0f server running with mod_dav enabled.

One of my WebDAV clients can't connect to it, but all other WebDAV clients
(WinSCP, etc.) are connecting OK.

Apache sends a 'Handshake Failure' immediately:

No.     Time                    Source                Destination
Length Protocol Src Prt Dst Prt Info
      4 2017-07-24 22:38:38.516 xxx.xxx.xxx.xx        yyy.yyy.yyy.yy
 180    SSLv2    52883   443     Client Hello
      5 2017-07-24 22:38:38.516 yyy.yyy.yyy.yy        xxx.xxx.xxx.xx
 84     TCP      443     52883   443?52883 [ACK] Seq=1 Ack=49 Win=525568
Len=0
      6 2017-07-24 22:38:38.525 yyy.yyy.yyy.yy        xxx.xxx.xxx.xx
 98     SSLv3    443     52883   Alert (Level: Fatal, Description:
Handshake Failure)

The client's 'Client Hello' packet is as follows:

No.     Time                    Source                Destination
Length Protocol Src Prt Dst Prt Info
      4 2017-07-25 14:58:26.128 xxx.xxx.xxx.xx        xxx.xxx.xxx.xx
 180    SSLv2    62572   443     Client Hello

Frame 4: 180 bytes on wire (1440 bits), 92 bytes captured (736 bits) on
interface 0
Null/Loopback
Internet Protocol Version 4, Src: xxx.xxx.xxx.xx (xxx.xxx.xxx.xx), Dst:
xxx.xxx.xxx.xx (xxx.xxx.xxx.xx)
Transmission Control Protocol, Src Port: 62572 (62572), Dst Port: 443
(443), Seq: 1, Ack: 1, Len: 48
Secure Sockets Layer
    SSLv2 Record Layer: Client Hello
        [Version: SSL 2.0 (0x0002)]
        Length: 46
        Handshake Message Type: Client Hello (1)
        Version: SSL 3.0 (0x0300)
        Cipher Spec Length: 21
        Session ID Length: 0
        Challenge Length: 16
        Cipher Specs (7 specs)
            Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a)
            Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013)
            Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x000005)
            Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x000004)
            Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080)
            Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0)
            Cipher Spec: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x0000ff)
        Challenge

Has anyone else had anything like this?

Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170727/71cdb246/attachment.html>

From bkaduk at akamai.com  Thu Jul 27 20:03:49 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Thu, 27 Jul 2017 15:03:49 -0500
Subject: [openssl-users] Apache/OpenSSL1.1 sending Fatal,
 Description: Handshake Failure' packet to WebDAV client
In-Reply-To: <CAPKwGrdiNJB=qWDpTzF1vqad=ipS2CcKnsfuMNJGyy-dN4DzgA@mail.gmail.com>
References: <CAPKwGrdiNJB=qWDpTzF1vqad=ipS2CcKnsfuMNJGyy-dN4DzgA@mail.gmail.com>
Message-ID: <06817a77-4b4b-a72d-8507-aa840f19fb07@akamai.com>

On 07/27/2017 02:49 PM, Todd Blum wrote:
>     SSLv2 Record Layer: Client Hello

SSLv2-compatible ClientHello is pretty old and probably unneeded

>         [Version: SSL 2.0 (0x0002)]
>         Length: 46
>         Handshake Message Type: Client Hello (1)
>         Version: SSL 3.0 (0x0300)
>         Cipher Spec Length: 21
>         Session ID Length: 0
>         Challenge Length: 16
>         Cipher Specs (7 specs)
>             Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a)
>             Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013)
>             Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x000005)
>             Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x000004)
>             Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080)
>             Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0)
>             Cipher Spec: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x0000ff)
>         Challenge

All of those are pretty bad ciphers; can you update the client to use
better ones?

Otherwise you might have to do something like include @SECLEVEL=0 in the
cipher spec on the server to enable the weak ciphers.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170727/8b26f3a4/attachment.html>

From bkaduk at akamai.com  Thu Jul 27 20:20:06 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Thu, 27 Jul 2017 15:20:06 -0500
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <CANWFjKDDNGP6eEwha+AY-EyunWz24LNQ-Jx9c8EKk5X5Zz06wA@mail.gmail.com>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
 <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
 <CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com>
 <727734e1-a450-9b53-41e7-630f953de3c8@akamai.com>
 <CANWFjKDDNGP6eEwha+AY-EyunWz24LNQ-Jx9c8EKk5X5Zz06wA@mail.gmail.com>
Message-ID: <41d4cace-d05e-c4dc-bc9b-71d1b3f04d29@akamai.com>

On 07/25/2017 06:05 PM, Neetish Pathak wrote:
>
>
> Please provide any comments if you have or how I should go about
> debugging it. Correct me if I am doing it wrong
>

I don't really have any good suggestions for debugging it.  It might be
interesting to run in a debugger and collect full backtraces on each
entry to ssl3_write_pending() on the server.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170727/1ee43d5a/attachment-0001.html>

From kgoldman at us.ibm.com  Thu Jul 27 22:22:41 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 27 Jul 2017 18:22:41 -0400
Subject: [openssl-users] Openssl 1.1 RSA_get0_key() documentation
Message-ID: <oldp2k$s6e$1@blaine.gmane.org>

The __current__ code for this function returns values if the **BIGNUM is 
not NULL.  Thus, it appears safe to pass in NULL for values not needed.

However, the documentation is silent on this behavior.

If this behavior is guaranteed, it would be nice if it was documented.

If not, a comment in the code to than effect would be useful.


From swethahariharan1810 at gmail.com  Fri Jul 28 04:15:53 2017
From: swethahariharan1810 at gmail.com (Swetha Hariharan)
Date: Fri, 28 Jul 2017 09:45:53 +0530
Subject: [openssl-users] Fwd: CAVP fips_rsastest.c not producing the correct
	signature?
In-Reply-To: <CAL2_fyDjnQO9apUtWvna3tdDaAET9fDVh=hTFQ6EqKpt=YRp6A@mail.gmail.com>
References: <CAL2_fyDjnQO9apUtWvna3tdDaAET9fDVh=hTFQ6EqKpt=YRp6A@mail.gmail.com>
Message-ID: <CAL2_fyA8fZaDaVJ89mqEdALUfT44uc8f+b1xZ=2d9Rffa3KKVg@mail.gmail.com>

I am trying test the rsa 186-2 openssl fips module 2.0.16 implementation
using the NIST Testvectors. Using the  fips_rsastest.c file the
FIPS_rsa_x931_generate_key_ex(rsa, keylen, bn_e, NULL) function called to
generate the modulus n as the output and taking modulus size as the input
i,e [mod=1024]. Then this modulus along with the appropriate hash function
and message is passed to FIPS_rsa_sign(rsa, Msg, Msglen, dgst, pad_mode,
Saltlen, NULL,sigbuf, (unsigned int *)&siglen) to obtain the signature as
the output.
But each time i execute the c code it generates different modulus n. Why is
output changing after every execution. What am i doing wrong? I am facing
the same problem with DSA parameter generation also. It will help me.


-- 
With Regards,
Swetha H



-- 
With Regards,
Swetha H
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170728/4ad6cf18/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fips_rsastest.c
Type: text/x-csrc
Size: 8058 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170728/4ad6cf18/attachment.c>

From noloader at gmail.com  Fri Jul 28 06:07:11 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 28 Jul 2017 02:07:11 -0400
Subject: [openssl-users] Fwd: CAVP fips_rsastest.c not producing the
 correct signature?
In-Reply-To: <CAL2_fyA8fZaDaVJ89mqEdALUfT44uc8f+b1xZ=2d9Rffa3KKVg@mail.gmail.com>
References: <CAL2_fyDjnQO9apUtWvna3tdDaAET9fDVh=hTFQ6EqKpt=YRp6A@mail.gmail.com>
 <CAL2_fyA8fZaDaVJ89mqEdALUfT44uc8f+b1xZ=2d9Rffa3KKVg@mail.gmail.com>
Message-ID: <CAH8yC8=bbmLrXDxqcHsxypOHNyHkvvJK5pyDvxLfds3hfQtH0A@mail.gmail.com>

On Fri, Jul 28, 2017 at 12:15 AM, Swetha Hariharan
<swethahariharan1810 at gmail.com> wrote:
>
>
> I am trying test the rsa 186-2 openssl fips module 2.0.16 implementation
> using the NIST Testvectors. Using the  fips_rsastest.c file the
> FIPS_rsa_x931_generate_key_ex(rsa, keylen, bn_e, NULL) function called to
> generate the modulus n as the output and taking modulus size as the input
> i,e [mod=1024]. Then this modulus along with the appropriate hash function
> and message is passed to FIPS_rsa_sign(rsa, Msg, Msglen, dgst, pad_mode,
> Saltlen, NULL,sigbuf, (unsigned int *)&siglen) to obtain the signature as
> the output.
> But each time i execute the c code it generates different modulus n. Why is
> output changing after every execution. What am i doing wrong? I am facing
> the same problem with DSA parameter generation also. It will help me.

Key generation for RSA and DSA use pairwise consistency checks, not
known answer tests.

Jeff

From georg.hoellrigl at gmx.at  Fri Jul 28 11:16:46 2017
From: georg.hoellrigl at gmx.at (=?UTF-8?Q?=22Georg_H=C3=B6llrigl=22?=)
Date: Fri, 28 Jul 2017 13:16:46 +0200
Subject: [openssl-users] openssl rsa -check
Message-ID: <trinity-a1a126ee-5e63-4544-9c8d-15a3713b5d94-1501240606117@3capp-gmx-bs52>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170728/0d2514db/attachment.html>

From paulyang.inf at gmail.com  Fri Jul 28 16:21:02 2017
From: paulyang.inf at gmail.com (Paul Yang)
Date: Sat, 29 Jul 2017 00:21:02 +0800
Subject: [openssl-users] openssl rsa -check
In-Reply-To: <trinity-a1a126ee-5e63-4544-9c8d-15a3713b5d94-1501240606117@3capp-gmx-bs52>
References: <trinity-a1a126ee-5e63-4544-9c8d-15a3713b5d94-1501240606117@3capp-gmx-bs52>
Message-ID: <ECB44814-645C-43BD-AE2A-215AA4B1F8BD@gmail.com>

Hmmm, it?s a bug introduced by the use of RSA_check_key_ex function. Thanks for reporting.

> On 28 Jul 2017, at 19:16, Georg H?llrigl <georg.hoellrigl at gmx.at> wrote:
> 
> Hello,
>  
> I think there is something broken with verifying the Private Key with "openssl rsa -check" like it was described in https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html <https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html>
>  
> I tried to implement better checking in a script that tells me if a key matches a certificate or certificate request.
>  
> To reproduce, get the fake private key from https://github.com/hannob/tlshelpers/blob/master/examples/symantec.key <https://github.com/hannob/tlshelpers/blob/master/examples/symantec.key>
>  
> Verify the key with openssl 1.0.1e-fips or 1.0.2h:
> $OPENSSL rsa -in symantec-broken.key -check -noout
> RSA key error: n does not equal p q
>  
> Verify the key with openssl 1.1.0c or 1.1.0f (gives no output)
> $OPENSSL rsa -in symantec-broken.key -check -noout
>  
>  
> I would expect 1.1.0 to report the faked key in some way.
> Even the returnvalue for openssl returns with a 0 no matter if used a legimate key or a faked key.
>  
>  
>  
> Kind Regards,
> Georg
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170729/d320aefa/attachment-0001.html>

From paulyang.inf at gmail.com  Fri Jul 28 16:34:18 2017
From: paulyang.inf at gmail.com (Paul Yang)
Date: Sat, 29 Jul 2017 00:34:18 +0800
Subject: [openssl-users] openssl rsa -check
In-Reply-To: <ECB44814-645C-43BD-AE2A-215AA4B1F8BD@gmail.com>
References: <trinity-a1a126ee-5e63-4544-9c8d-15a3713b5d94-1501240606117@3capp-gmx-bs52>
 <ECB44814-645C-43BD-AE2A-215AA4B1F8BD@gmail.com>
Message-ID: <F7FFAB04-556A-432B-AC69-A1C18B115F1A@gmail.com>

Please refer to this: https://github.com/openssl/openssl/pull/4043 <https://github.com/openssl/openssl/pull/4043>

> On 29 Jul 2017, at 00:21, Paul Yang <paulyang.inf at gmail.com <mailto:paulyang.inf at gmail.com>> wrote:
> 
> Hmmm, it?s a bug introduced by the use of RSA_check_key_ex function. Thanks for reporting.
> 
>> On 28 Jul 2017, at 19:16, Georg H?llrigl <georg.hoellrigl at gmx.at <mailto:georg.hoellrigl at gmx.at>> wrote:
>> 
>> Hello,
>>  
>> I think there is something broken with verifying the Private Key with "openssl rsa -check" like it was described in https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html <https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html>
>>  
>> I tried to implement better checking in a script that tells me if a key matches a certificate or certificate request.
>>  
>> To reproduce, get the fake private key from https://github.com/hannob/tlshelpers/blob/master/examples/symantec.key <https://github.com/hannob/tlshelpers/blob/master/examples/symantec.key>
>>  
>> Verify the key with openssl 1.0.1e-fips or 1.0.2h:
>> $OPENSSL rsa -in symantec-broken.key -check -noout
>> RSA key error: n does not equal p q
>>  
>> Verify the key with openssl 1.1.0c or 1.1.0f (gives no output)
>> $OPENSSL rsa -in symantec-broken.key -check -noout
>>  
>>  
>> I would expect 1.1.0 to report the faked key in some way.
>> Even the returnvalue for openssl returns with a 0 no matter if used a legimate key or a faked key.
>>  
>>  
>>  
>> Kind Regards,
>> Georg
>> -- 
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users <https://mta.openssl.org/mailman/listinfo/openssl-users>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170729/5a9240d9/attachment.html>

From noloader at gmail.com  Fri Jul 28 19:47:07 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 28 Jul 2017 15:47:07 -0400
Subject: [openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?
Message-ID: <CAH8yC8=5Tx0taPMJpVuHK8DrsJE=uHYL0x_wv4-sTS=wWJA_+w@mail.gmail.com>

I thought RDRAND was disabled as the default random engine since
1.0.1f. Has that changed in OpenSSL 1.1.0?

Related, see:

* https://stackoverflow.com/q/45370852/608639
* http://seclists.org/fulldisclosure/2013/Dec/99
* https://software.intel.com/en-us/blogs/2014/10/03/changes-to-rdrand-integration-in-openssl
* https://trac.torproject.org/projects/tor/ticket/10402

From uri at ll.mit.edu  Fri Jul 28 19:50:10 2017
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Fri, 28 Jul 2017 19:50:10 +0000
Subject: [openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?
In-Reply-To: <CAH8yC8=5Tx0taPMJpVuHK8DrsJE=uHYL0x_wv4-sTS=wWJA_+w@mail.gmail.com>
References: <CAH8yC8=5Tx0taPMJpVuHK8DrsJE=uHYL0x_wv4-sTS=wWJA_+w@mail.gmail.com>
Message-ID: <301316EC-200C-44BA-98E5-468CB604EA51@ll.mit.edu>

I sincerely hope it is not so.

--
Regards,
Uri Blumenthal

On 7/28/17, 15:47, "openssl-users on behalf of Jeffrey Walton" <openssl-users-bounces at openssl.org on behalf of noloader at gmail.com> wrote:

    I thought RDRAND was disabled as the default random engine since
    1.0.1f. Has that changed in OpenSSL 1.1.0?
    
    Related, see:
    
    * https://stackoverflow.com/q/45370852/608639
    * http://seclists.org/fulldisclosure/2013/Dec/99
    * https://software.intel.com/en-us/blogs/2014/10/03/changes-to-rdrand-integration-in-openssl
    * https://trac.torproject.org/projects/tor/ticket/10402
    -- 
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170728/c2b2e6c3/attachment.bin>

From rsalz at akamai.com  Fri Jul 28 19:53:25 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 28 Jul 2017 19:53:25 +0000
Subject: [openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?
In-Reply-To: <301316EC-200C-44BA-98E5-468CB604EA51@ll.mit.edu>
References: <CAH8yC8=5Tx0taPMJpVuHK8DrsJE=uHYL0x_wv4-sTS=wWJA_+w@mail.gmail.com>
 <301316EC-200C-44BA-98E5-468CB604EA51@ll.mit.edu>
Message-ID: <2e00faf8224a4b4094bb03894ec3c407@usma1ex-dag1mb1.msg.corp.akamai.com>

>     I thought RDRAND was disabled as the default random engine since
>     1.0.1f. Has that changed in OpenSSL 1.1.0?

No.  Do "git grep ENGINE_set_default_RAND"



From noloader at gmail.com  Fri Jul 28 19:57:21 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 28 Jul 2017 15:57:21 -0400
Subject: [openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?
In-Reply-To: <2e00faf8224a4b4094bb03894ec3c407@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAH8yC8=5Tx0taPMJpVuHK8DrsJE=uHYL0x_wv4-sTS=wWJA_+w@mail.gmail.com>
 <301316EC-200C-44BA-98E5-468CB604EA51@ll.mit.edu>
 <2e00faf8224a4b4094bb03894ec3c407@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAH8yC8kAmV06zB_zU=cktns7+tA1ftHsfmop5s3ve54YuVE5Rg@mail.gmail.com>

On Fri, Jul 28, 2017 at 3:53 PM, Salz, Rich <rsalz at akamai.com> wrote:
>>     I thought RDRAND was disabled as the default random engine since
>>     1.0.1f. Has that changed in OpenSSL 1.1.0?
>
> No.  Do "git grep ENGINE_set_default_RAND"

Ack, thanks. I wonder where that's coming from for 1.1.0. Maybe
Dropbox is providing vendor patches.

Jeff

From rsalz at akamai.com  Fri Jul 28 20:05:15 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 28 Jul 2017 20:05:15 +0000
Subject: [openssl-users] Openssl 1.1 RSA_get0_key() documentation
In-Reply-To: <oldp2k$s6e$1@blaine.gmane.org>
References: <oldp2k$s6e$1@blaine.gmane.org>
Message-ID: <a0aa857007644183ac740b30451ceef4@usma1ex-dag1mb1.msg.corp.akamai.com>

> The __current__ code for this function returns values if the **BIGNUM is
> not NULL.  Thus, it appears safe to pass in NULL for values not needed.

Yes.  That's true for many "get" functions.

> However, the documentation is silent on this behavior.
> 
> If this behavior is guaranteed, it would be nice if it was documented.

Wanna open an issue to fix the doc? :)

From kgoldman at us.ibm.com  Fri Jul 28 20:15:47 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 28 Jul 2017 16:15:47 -0400
Subject: [openssl-users] Openssl 1.1 RSA_get0_key() documentation
In-Reply-To: <a0aa857007644183ac740b30451ceef4@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <oldp2k$s6e$1@blaine.gmane.org>
 <a0aa857007644183ac740b30451ceef4@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <olg60j$l3a$1@blaine.gmane.org>

On 7/28/2017 4:05 PM, Salz, Rich via openssl-users wrote:
>> The __current__ code for this function returns values if the **BIGNUM is
>> not NULL.  Thus, it appears safe to pass in NULL for values not needed.
> 
>>
>> If this behavior is guaranteed, it would be nice if it was documented.
> 
> Wanna open an issue to fix the doc? :)
> 

I'd be happy to, but I don't know how.

I'd also be willing to help with documentation, if that's possible.



From babedoudi at yahoo.fr  Sat Jul 29 17:30:36 2017
From: babedoudi at yahoo.fr (me)
Date: Sat, 29 Jul 2017 18:30:36 +0100
Subject: [openssl-users] Optimized way to encrypt data with different ivs
	using AES/GCM
Message-ID: <4e4090be-ec67-ec6a-0160-c08268dfb75e@yahoo.fr>

Hello OpenSSL experts,

I am encrypting a stream of data using OpenSSL C API and AES/GCM with 
16-byte ivs. The stream is split into several chunks that need to be 
encrypted with the same key but different ivs. So far I have the 
following flow:

###
for data_chunk:
     iv = newIv()
     EVP_CIPHER_CTX_new
     EVP_EncryptInit_ex(ctx, EVP_aes_128_gcm(), NULL, NULL, NULL)
     EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 16, NULL))
     EVP_EncryptInit_ex(ctx, NULL, NULL, key, iv))

     EVP_EncryptUpdate
     EVP_EncryptFinal_ex
     EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG...

     EVP_CIPHER_CTX_free
###

I am looking into improving performance by reusing objects, ideally the 
following way:

###
EVP_CIPHER_CTX_new
EVP_EncryptInit_ex(ctx, EVP_aes_128_gcm(), NULL, NULL, NULL)
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 16, NULL))

for data_chunk:
     iv = newIv()
     EVP_EncryptInit_ex(ctx, NULL, NULL, key, iv))

     EVP_EncryptUpdate
     EVP_EncryptFinal_ex
     EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG...

EVP_CIPHER_CTX_free
###

The OpenSSL documentation is not entirely clear if this is recommended, 
is there any concern with the approach? Would that also work for decryption?

Many thanks.

From georg.hoellrigl at gmx.at  Sun Jul 30 08:12:36 2017
From: georg.hoellrigl at gmx.at (=?UTF-8?Q?Georg_H=C3=B6llrigl?=)
Date: Sun, 30 Jul 2017 10:12:36 +0200
Subject: [openssl-users] openssl rsa -check
In-Reply-To: <F7FFAB04-556A-432B-AC69-A1C18B115F1A@gmail.com>
References: <trinity-a1a126ee-5e63-4544-9c8d-15a3713b5d94-1501240606117@3capp-gmx-bs52>
 <ECB44814-645C-43BD-AE2A-215AA4B1F8BD@gmail.com>
 <F7FFAB04-556A-432B-AC69-A1C18B115F1A@gmail.com>
Message-ID: <00af01d3090b$9d52b5d0$d7f82170$@gmx.at>

Wow that was fast

Keep up that awsome work!

 

Thank you.

 

Kind Regards,

Georg

 

 

Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Paul Yang
Gesendet: Freitag, 28. Juli 2017 18:34
An: Openssl Users <openssl-users at openssl.org>
Betreff: Re: [openssl-users] openssl rsa -check

 

Please refer to this: https://github.com/openssl/openssl/pull/4043

 

On 29 Jul 2017, at 00:21, Paul Yang <paulyang.inf at gmail.com <mailto:paulyang.inf at gmail.com> > wrote:

 

Hmmm, it?s a bug introduced by the use of RSA_check_key_ex function. Thanks for reporting.

 

On 28 Jul 2017, at 19:16, Georg H?llrigl <georg.hoellrigl at gmx.at <mailto:georg.hoellrigl at gmx.at> > wrote:

 

Hello,

 

I think there is something broken with verifying the Private Key with "openssl rsa -check" like it was described in https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html

 

I tried to implement better checking in a script that tells me if a key matches a certificate or certificate request.

 

To reproduce, get the fake private key from https://github.com/hannob/tlshelpers/blob/master/examples/symantec.key

 

Verify the key with openssl 1.0.1e-fips or 1.0.2h:

$OPENSSL rsa -in symantec-broken.key -check -noout
RSA key error: n does not equal p q

 

Verify the key with openssl 1.1.0c or 1.1.0f (gives no output)

$OPENSSL rsa -in symantec-broken.key -check -noout

 

 

I would expect 1.1.0 to report the faked key in some way.

Even the returnvalue for openssl returns with a 0 no matter if used a legimate key or a faked key.

 

 

 

Kind Regards,

Georg

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

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170730/0dd1663d/attachment.html>

From matt at openssl.org  Mon Jul 31 13:20:59 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 31 Jul 2017 14:20:59 +0100
Subject: [openssl-users] Openssl 1.1 RSA_get0_key() documentation
In-Reply-To: <olg60j$l3a$1@blaine.gmane.org>
References: <oldp2k$s6e$1@blaine.gmane.org>
 <a0aa857007644183ac740b30451ceef4@usma1ex-dag1mb1.msg.corp.akamai.com>
 <olg60j$l3a$1@blaine.gmane.org>
Message-ID: <13d90b19-434b-3169-869b-673a2d498094@openssl.org>



On 28/07/17 21:15, Ken Goldman wrote:
> On 7/28/2017 4:05 PM, Salz, Rich via openssl-users wrote:
>>> The __current__ code for this function returns values if the **BIGNUM is
>>> not NULL.  Thus, it appears safe to pass in NULL for values not needed.
>>
>>>
>>> If this behavior is guaranteed, it would be nice if it was documented.
>>
>> Wanna open an issue to fix the doc? :)
>>
> 
> I'd be happy to, but I don't know how.

Click "New Issue" on this page:

https://github.com/openssl/openssl/issues

You'll need a github user id.

> 
> I'd also be willing to help with documentation, if that's possible.

It is possible. Make the relevant changes (file
doc/man3/RSA_get0_key.pod) in a recent checkout of master and then
create a github pull request:

https://github.com/openssl/openssl/pulls


Matt

From kgoldman at us.ibm.com  Mon Jul 31 14:31:55 2017
From: kgoldman at us.ibm.com (Kenneth Goldman)
Date: Mon, 31 Jul 2017 10:31:55 -0400
Subject: [openssl-users] Openssl 1.1 RSA_get0_key() documentation ->
	needs-cla
In-Reply-To: <13d90b19-434b-3169-869b-673a2d498094@openssl.org>
References: <oldp2k$s6e$1@blaine.gmane.org>
 <a0aa857007644183ac740b30451ceef4@usma1ex-dag1mb1.msg.corp.akamai.com>
 <olg60j$l3a$1@blaine.gmane.org>
 <13d90b19-434b-3169-869b-673a2d498094@openssl.org>
Message-ID: <OF2C1438AF.A9A85A97-ON0025816E.004FABF1-8525816E.004FDCDB@notes.na.collabserv.com>

"openssl-users" <openssl-users-bounces at openssl.org> wrote on 07/31/2017 
09:20:59 AM:

> From: Matt Caswell <matt at openssl.org>
> To: openssl-users at openssl.org
> Date: 07/31/2017 09:21 AM
> 
> Click "New Issue" on this page:
> 
> https://github.com/openssl/openssl/issues
> 
> You'll need a github user id.
> 
> > 
> > I'd also be willing to help with documentation, if that's possible.
> 
> It is possible. Make the relevant changes (file
> doc/man3/RSA_get0_key.pod) in a recent checkout of master and then
> create a github pull request:
> 
> https://github.com/openssl/openssl/pulls

I have an ID, but the pull request is marked needs-cla.

How do I sign it?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170731/67b9813f/attachment-0001.html>

From matt at openssl.org  Mon Jul 31 14:34:41 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 31 Jul 2017 15:34:41 +0100
Subject: [openssl-users] Openssl 1.1 RSA_get0_key() documentation ->
 needs-cla
In-Reply-To: <OF2C1438AF.A9A85A97-ON0025816E.004FABF1-8525816E.004FDCDB@notes.na.collabserv.com>
References: <oldp2k$s6e$1@blaine.gmane.org>
 <a0aa857007644183ac740b30451ceef4@usma1ex-dag1mb1.msg.corp.akamai.com>
 <olg60j$l3a$1@blaine.gmane.org>
 <13d90b19-434b-3169-869b-673a2d498094@openssl.org>
 <OF2C1438AF.A9A85A97-ON0025816E.004FABF1-8525816E.004FDCDB@notes.na.collabserv.com>
Message-ID: <a459c965-278a-ee50-e18a-3c71f8074fc9@openssl.org>



On 31/07/17 15:31, Kenneth Goldman wrote:
> "openssl-users" <openssl-users-bounces at openssl.org> wrote on 07/31/2017
> 09:20:59 AM:
> 
>> From: Matt Caswell <matt at openssl.org>
>> To: openssl-users at openssl.org
>> Date: 07/31/2017 09:21 AM
>>
>> Click "New Issue" on this page:
>>
>> https://github.com/openssl/openssl/issues
>>
>> You'll need a github user id.
>>
>> >
>> > I'd also be willing to help with documentation, if that's possible.
>>
>> It is possible. Make the relevant changes (file
>> doc/man3/RSA_get0_key.pod) in a recent checkout of master and then
>> create a github pull request:
>>
>> https://github.com/openssl/openssl/pulls
> 
> I have an ID, but the pull request is marked needs-cla.
> 
> How do I sign it?

I just posted some commentary on that in the PR itself. Short answer, see:

https://www.openssl.org/policies/cla.html

Matt


From matt at openssl.org  Mon Jul 31 16:43:12 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 31 Jul 2017 17:43:12 +0100
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <CANWFjKDDNGP6eEwha+AY-EyunWz24LNQ-Jx9c8EKk5X5Zz06wA@mail.gmail.com>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
 <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
 <CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com>
 <727734e1-a450-9b53-41e7-630f953de3c8@akamai.com>
 <CANWFjKDDNGP6eEwha+AY-EyunWz24LNQ-Jx9c8EKk5X5Zz06wA@mail.gmail.com>
Message-ID: <91195d2f-94ea-6916-59b5-735c5f98a4c9@openssl.org>

Apologies for the delayed response - I've been away on holiday. Comments
inserted below.

Matt


On 26/07/17 00:05, Neetish Pathak wrote:
>>     *Pseudocode for server*
>>     *
>>     *
>>     tcp_accept
>>     *
>>     *
>>     read_early{
>>
>>          if(read_early_success){
>>               write_early(data)
>>           }
>>     }

There is a bit of complexity here (covered in the docs), i.e.
SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a success,
but the server may or may not be able to write early data. I assume that
you have covered that in your actual code and it's just skimmed over
here in your pseudo code.


>>     2) Why does the server not send data (for early write) after the
>>     server Hello(and other encrypted message) message even when
>>     early_write succeeds on server side. Why does server wait to
>>     finish the handshake. I know it waits because I see client sending
>>     encrypted messages after server hello message before my intended
>>     application data gets sent from server. These encrypted messages
>>     from the client side are the usual messages from the client side
>>     for handshake completion.
>>
> 
>     From a quick look through the state machine code, this is supposed
>     to work.  But someone would probably have to instrument the code
>     (e.g., with printf) to tell why the delay is being introduced.  I
>     don't think I have the availability to do so in the near future, myself.
> 
> 
> 
> I see that the application data is not being sent from server to an
> unauthenticated client. The server is sending data only after receiving
> some encrypted message which I believe is the EndOfEarlyData and
> Finished messages. Following is  a dump of wireshark logs for the
> communication with early data enabled. I also tried with some logs in
> Openssl libraries, I see early data gets written from server side when
> write_early_data is called. Internally SSL_write_ex is called which
> completes write and handshake. But I am not sure why application data is
> not actually pushed from the server side. It is waiting for the Client
> finished message. 
> I have disabled Nagle's algo during this operation.

Can you confirm whether you have disabled Nagle's algo on both the
client *and* the server?`


> 
> Client port is 56806 and server port is 12345
> 
> 
> No.     Time           Source                Destination          
> Protocol Length Info
>     207 18.380298      ::1                   ::1                  
> TLSv1.3  956    Client Hello                  ----------------- Client Hello
> 
> 
> No.     Time           Source                Destination          
> Protocol Length Info
>     208 18.380335      ::1                   ::1                  
> TLSv1.3  2849   Application Data          ------------------*Early Data
> from the client side (Intended Application Data)*
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 881, Ack: 1, Len: 2773
> 
> No.     Time           Source                Destination          
> Protocol Length Info
>     211 18.380624      ::1                   ::1                  
> TLSv1.3  219    Server Hello, Application Data, Application Data .
> ------------Server Hello and (encrypted handshake message/extensions)
> Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1,
> Ack: 3654, Len: 143
> 
> No.     Time           Source                Destination          
> Protocol Length Info
>     213 18.380819      ::1                   ::1                  
> TLSv1.3  160    Application Data, Application Data    ------Encrypted
> handshake msg from client (*I believe they are end early data and finished*)
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 3654, Ack: 144, Len: 84
> 
> 
> No.     Time           Source                Destination          
> Protocol Length Info
>     215 18.381122      ::1                   ::1                  
> TLSv1.3  762    Application Data
> Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
> 144, Ack: 3738, Len: 686   -----I don't know why this application data
> is sent from server. My guess is this is session info

It could be the NewSessionTicket message going from the server to the
client. But if so that is a little strange. The NST message is only sent
after the handshake is complete (so no more early data is possible). At
this point SSL_read_early_data() should have returned
SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
and any calls to SSL_write_early_data() will fail.



> 
> 
> No.     Time           Source                Destination          
> Protocol Length Info
>     217 18.381210      ::1                   ::1                  
> TLSv1.3  9917   Application Data          ----------*Intended
> Application Data that was intended to be early data *
> Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
> 830, Ack: 3738, Len: 9841
> 
> No.     Time           Source                Destination          
> Protocol Length Info
>     219 18.381308      ::1                   ::1                  
> TLSv1.3  100    Application Data .             ---------Application Data
> from client (I also see this application data sent everytime, not sure why)
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 3738, Ack: 10671, Len: 24
> 
> 
> No.     Time           Source                Destination          
> Protocol Length Info
>     220 18.381309      ::1                   ::1                  
> TLSv1.3  100    Application Data .  ---------Application Data from
> server (I also see this application data sent everytime, not sure why)

Perhaps these are close_notify alerts? Are you shutting down the
connection cleanly at this point?

Matt

From matt at openssl.org  Mon Jul 31 16:58:03 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 31 Jul 2017 17:58:03 +0100
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <91195d2f-94ea-6916-59b5-735c5f98a4c9@openssl.org>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
 <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
 <CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com>
 <727734e1-a450-9b53-41e7-630f953de3c8@akamai.com>
 <CANWFjKDDNGP6eEwha+AY-EyunWz24LNQ-Jx9c8EKk5X5Zz06wA@mail.gmail.com>
 <91195d2f-94ea-6916-59b5-735c5f98a4c9@openssl.org>
Message-ID: <fdc3926c-a76e-3d37-9b72-de70f16b4f9b@openssl.org>



On 31/07/17 17:43, Matt Caswell wrote:
> It could be the NewSessionTicket message going from the server to the
> client. But if so that is a little strange. The NST message is only sent
> after the handshake is complete (so no more early data is possible). At
> this point SSL_read_early_data() should have returned
> SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,

I meant to say SSL_read_early_data() should have returned
SSL_READ_EARLY_DATA_FINISH.

Matt

From kgoldman at us.ibm.com  Mon Jul 31 18:18:17 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Mon, 31 Jul 2017 14:18:17 -0400
Subject: [openssl-users] openssl 1.0 and 1.1 co-exist
In-Reply-To: <5a988e8d-93ce-a2af-a542-ae34e08b2f8e@wisemo.com>
References: <oieb9k$n4m$1@blaine.gmane.org>
 <20170622023059.GU23375@mournblade.imrryr.org>
 <5a988e8d-93ce-a2af-a542-ae34e08b2f8e@wisemo.com>
Message-ID: <olns86$78g$1@blaine.gmane.org>

On 6/22/2017 7:05 AM, Jakob Bohm wrote:
> On 22/06/2017 04:31, Viktor Dukhovni wrote:
>> On Wed, Jun 21, 2017 at 01:44:34PM -0400, Ken Goldman wrote:
>>
>>> This is probably Linux specific ...
>>>
>>> Can both openssl versions co-exist on the same platform.  I know that 
>>> the
>>> .so is versioned, but how about the header files?  Can I choose which
>>> library to build with?

I wasn't specific enough.

1 - ... using standard rpms, not a custom install
2 - ... building as well as executing
3 - ... just modifying the makefile to point to different headers and so

I.e., do the headers both go into /usr/include/openssl (which would clash)?

Do the .so's both have the same name - libcrypto.so?

It already works with a custom install and makefile.


From npathak2 at ncsu.edu  Mon Jul 31 19:37:32 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Mon, 31 Jul 2017 12:37:32 -0700
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <91195d2f-94ea-6916-59b5-735c5f98a4c9@openssl.org>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
 <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
 <CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com>
 <727734e1-a450-9b53-41e7-630f953de3c8@akamai.com>
 <CANWFjKDDNGP6eEwha+AY-EyunWz24LNQ-Jx9c8EKk5X5Zz06wA@mail.gmail.com>
 <91195d2f-94ea-6916-59b5-735c5f98a4c9@openssl.org>
Message-ID: <CANWFjKD_Qnm2HcvtB_wSD3yCEKOMvyuN8Pxjd=vwZ3Oyyefupg@mail.gmail.com>

On Mon, Jul 31, 2017 at 9:43 AM, Matt Caswell <matt at openssl.org> wrote:

> Apologies for the delayed response - I've been away on holiday. Comments
> inserted below.
>


No problem thanks for the replies

>
> Matt
>
>
> On 26/07/17 00:05, Neetish Pathak wrote:
> >>     *Pseudocode for server*
> >>     *
> >>     *
> >>     tcp_accept
> >>     *
> >>     *
> >>     read_early{
> >>
> >>          if(read_early_success){
> >>               write_early(data)
> >>           }
> >>     }
>
> There is a bit of complexity here (covered in the docs), i.e.
> SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
> SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a success,
> but the server may or may not be able to write early data. I assume that
> you have covered that in your actual code and it's just skimmed over
> here in your pseudo code.
>


So, I consider read_early_sucess when  SSL_read_early_data() returns
SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted
before declaring success. Look at the case checks below

*case* SSL_READ_EARLY_DATA_SUCCESS:

        totalBytes += readBytes;

*         break*;


*case* SSL_READ_EARLY_DATA_FINISH:

       totalBytes += readBytes;

*       if* (SSL_EARLY_DATA_ACCEPTED == SSL_get_early_data_status(*this*->conn)
&& totalBytes > 0) {

             readBuf = string(readBuffer);

*             return* SUCCESS;

      }


So, are you suggesting that early data may not be written from the server
side if SSL_READ_EARLY_DATA_FINISH is received. Should I try writing before
that (as in when SSL_READ_EARLY_DATA_SUCCESS is received )

>
>
> >>     2) Why does the server not send data (for early write) after the
> >>     server Hello(and other encrypted message) message even when
> >>     early_write succeeds on server side. Why does server wait to
> >>     finish the handshake. I know it waits because I see client sending
> >>     encrypted messages after server hello message before my intended
> >>     application data gets sent from server. These encrypted messages
> >>     from the client side are the usual messages from the client side
> >>     for handshake completion.
> >>
> >
> >     From a quick look through the state machine code, this is supposed
> >     to work.  But someone would probably have to instrument the code
> >     (e.g., with printf) to tell why the delay is being introduced.  I
> >     don't think I have the availability to do so in the near future,
> myself.
> >
> >
> >
> > I see that the application data is not being sent from server to an
> > unauthenticated client. The server is sending data only after receiving
> > some encrypted message which I believe is the EndOfEarlyData and
> > Finished messages. Following is  a dump of wireshark logs for the
> > communication with early data enabled. I also tried with some logs in
> > Openssl libraries, I see early data gets written from server side when
> > write_early_data is called. Internally SSL_write_ex is called which
> > completes write and handshake. But I am not sure why application data is
> > not actually pushed from the server side. It is waiting for the Client
> > finished message.
> > I have disabled Nagle's algo during this operation.
>
> Can you confirm whether you have disabled Nagle's algo on both the
> client *and* the server?`
>


Nagle's algorithm is disabled on both the client and the server side.

>
>
> >
> > Client port is 56806 and server port is 12345
> >
> >
> > No.     Time           Source                Destination
> > Protocol Length Info
> >     207 18.380298      ::1                   ::1
> > TLSv1.3  956    Client Hello                  ----------------- Client
> Hello
> >
> >
> > No.     Time           Source                Destination
> > Protocol Length Info
> >     208 18.380335      ::1                   ::1
> > TLSv1.3  2849   Application Data          ------------------*Early Data
> > from the client side (Intended Application Data)*
> > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> > 881, Ack: 1, Len: 2773
> >
> > No.     Time           Source                Destination
> > Protocol Length Info
> >     211 18.380624      ::1                   ::1
> > TLSv1.3  219    Server Hello, Application Data, Application Data .
> > ------------Server Hello and (encrypted handshake message/extensions)
> > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1,
> > Ack: 3654, Len: 143
> >
> > No.     Time           Source                Destination
> > Protocol Length Info
> >     213 18.380819      ::1                   ::1
> > TLSv1.3  160    Application Data, Application Data    ------Encrypted
> > handshake msg from client (*I believe they are end early data and
> finished*)
> > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> > 3654, Ack: 144, Len: 84
> >
> >
> > No.     Time           Source                Destination
> > Protocol Length Info
> >     215 18.381122      ::1                   ::1
> > TLSv1.3  762    Application Data
> > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
> > 144, Ack: 3738, Len: 686   -----I don't know why this application data
> > is sent from server. My guess is this is session info
>
> It could be the NewSessionTicket message going from the server to the
> client. But if so that is a little strange. The NST message is only sent
> after the handshake is complete (so no more early data is possible). At
> this point SSL_read_early_data() should have returned
> SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
> and any calls to SSL_write_early_data() will fail.
>

Yes, here the handshake is completed. Will the new session ticket be sent
each time after the handshake? In theTLS 1.3 draft, it is mentioned that
new session tickets may be sent after server receives Finished from the
client and it creates a unique association between the ticket value and a
secret PSK derived from the resumption master secret.
But looks like, I am receiving new session ticket every-time. So, as per
the implementation, new session ticket is a must I guess. Am I right? When
will I not receive new session ticket in TLS 1.3?

Also, I believe it is different than how new session ticket works in TLS
1.2 where it was sent only once to share the encrypted ticket from the
server side when the client indicates support for session tickets.


>
> >
> >
> > No.     Time           Source                Destination
> > Protocol Length Info
> >     217 18.381210      ::1                   ::1
> > TLSv1.3  9917   Application Data          ----------*Intended
> > Application Data that was intended to be early data *
> > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
> > 830, Ack: 3738, Len: 9841
> >
> > No.     Time           Source                Destination
> > Protocol Length Info
> >     219 18.381308      ::1                   ::1
> > TLSv1.3  100    Application Data .             ---------Application Data
> > from client (I also see this application data sent everytime, not sure
> why)
> > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> > 3738, Ack: 10671, Len: 24
> >
> >
> > No.     Time           Source                Destination
> > Protocol Length Info
> >     220 18.381309      ::1                   ::1
> > TLSv1.3  100    Application Data .  ---------Application Data from
> > server (I also see this application data sent everytime, not sure why)
>
> Perhaps these are close_notify alerts? Are you shutting down the
> connection cleanly at this point?
>

I am shutting down the connection from the client side. Server is up all
the time for any new connection.

Thanks
Neetish

>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170731/64a3576e/attachment-0001.html>

From amrithathorath87 at gmail.com  Mon Jul 31 20:10:22 2017
From: amrithathorath87 at gmail.com (amritha thorath)
Date: Mon, 31 Jul 2017 16:10:22 -0400
Subject: [openssl-users] OpenSSL on windows
Message-ID: <CALpLYRsJc+c-tCQxxSocBAJRbqLzN4a=8FLNFn0CN_Wh939tEQ@mail.gmail.com>

Hi I'm trying to run amy application with OpenSSL libraries.
I've generated fipscanister.lib, ssleay32.lib and libeayfips32.lib.
In my code I'm making a call to FIPS_rsa_sign(). The test crashes when the
control hits this function.
But the same code runs successfully on Linux.

-- 
Thanks...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170731/2a676bf8/attachment.html>

From matt at openssl.org  Mon Jul 31 21:00:21 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 31 Jul 2017 22:00:21 +0100
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <CANWFjKD_Qnm2HcvtB_wSD3yCEKOMvyuN8Pxjd=vwZ3Oyyefupg@mail.gmail.com>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
 <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
 <CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com>
 <727734e1-a450-9b53-41e7-630f953de3c8@akamai.com>
 <CANWFjKDDNGP6eEwha+AY-EyunWz24LNQ-Jx9c8EKk5X5Zz06wA@mail.gmail.com>
 <91195d2f-94ea-6916-59b5-735c5f98a4c9@openssl.org>
 <CANWFjKD_Qnm2HcvtB_wSD3yCEKOMvyuN8Pxjd=vwZ3Oyyefupg@mail.gmail.com>
Message-ID: <8ecfa5ad-24da-4a08-3168-f0fb97899cfb@openssl.org>



On 31/07/17 20:37, Neetish Pathak wrote:
>     On 26/07/17 00:05, Neetish Pathak wrote:
>     >>     *Pseudocode for server*
>     >>     *
>     >>     *
>     >>     tcp_accept
>     >>     *
>     >>     *
>     >>     read_early{
>     >>
>     >>          if(read_early_success){
>     >>               write_early(data)
>     >>           }
>     >>     }
> 
>     There is a bit of complexity here (covered in the docs), i.e.
>     SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
>     SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a success,
>     but the server may or may not be able to write early data. I assume that
>     you have covered that in your actual code and it's just skimmed over
>     here in your pseudo code.
> 
> 
> 
> So, I consider read_early_sucess when  SSL_read_early_data() returns
> SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted
> before declaring success. Look at the case checks below
> 
> *case* SSL_READ_EARLY_DATA_SUCCESS:
> 
>         totalBytes += readBytes;
> 
> *         break*;
> 
> *
> *
> 
> *case* SSL_READ_EARLY_DATA_FINISH:
> 
>        totalBytes += readBytes;
> 
> *       if* (SSL_EARLY_DATA_ACCEPTED ==
> SSL_get_early_data_status(*this*->conn) && totalBytes > 0) {
> 
>              readBuf = string(readBuffer);
> 
> *             return* SUCCESS;
> 
>       }
> 
> 
> So, are you suggesting that early data may not be written from the
> server side if SSL_READ_EARLY_DATA_FINISH is received. Should I try
> writing before that (as in when SSL_READ_EARLY_DATA_SUCCESS is received )


SSL_READ_EARLY_DATA_FINISH is not returned until we have seen the
EndOfEarlyData message. Often (but not always - dependent on the
implementation) the client Finished message is also in the same packet
which OpenSSL will immediately try and process. As soon as it has done
so the handshake is complete and it is too late for the server to write
early data. Calls to SSL_write_early_data() by the server at this point
should fail (do you not see this???).

You should write early data on the server side as soon as
SSL_READ_EARLY_DATA_SUCCESS is received.



>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     215 18.381122      ::1                   ::1
>     > TLSv1.3  762    Application Data
>     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
>     > 144, Ack: 3738, Len: 686   -----I don't know why this application data
>     > is sent from server. My guess is this is session info
> 
>     It could be the NewSessionTicket message going from the server to the
>     client. But if so that is a little strange. The NST message is only sent
>     after the handshake is complete (so no more early data is possible). At
>     this point SSL_read_early_data() should have returned
>     SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
>     and any calls to SSL_write_early_data() will fail.
> 
> 
> Yes, here the handshake is completed. Will the new session ticket be
> sent each time after the handshake? In theTLS 1.3 draft, it is mentioned
> that new session tickets may be sent after server receives Finished from
> the client and it creates a unique association between the ticket value
> and a secret PSK derived from the resumption master secret. 
> But looks like, I am receiving new session ticket every-time. So, as per
> the implementation, new session ticket is a must I guess. Am I right?
> When will I not receive new session ticket in TLS 1.3?

The OpenSSL implementation *always* sends a NewSessionTicket message
immediately after the handshake is complete. This is not required, but
is allowed by the spec. Currently there is no way to disable this
behaviour. Do you need/want it (if so, why)?

> 
> Also, I believe it is different than how new session ticket works in TLS
> 1.2 where it was sent only once to share the encrypted ticket from the
> server side when the client indicates support for session tickets.

Yes, TLSv1.2 session tickets share the same name and have a similar
purpose, but are otherwise *completely* different to TLSv1.3 session
tickets.


>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     217 18.381210      ::1                   ::1
>     > TLSv1.3  9917   Application Data          ----------*Intended
>     > Application Data that was intended to be early data *
>     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
>     > 830, Ack: 3738, Len: 9841
>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     219 18.381308      ::1                   ::1
>     > TLSv1.3  100    Application Data .             ---------Application Data
>     > from client (I also see this application data sent everytime, not sure why)
>     > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
>     > 3738, Ack: 10671, Len: 24
>     >
>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     220 18.381309      ::1                   ::1
>     > TLSv1.3  100    Application Data .  ---------Application Data from
>     > server (I also see this application data sent everytime, not sure why)
> 
>     Perhaps these are close_notify alerts? Are you shutting down the
>     connection cleanly at this point?
> 
> 
> I am shutting down the connection from the client side. Server is up all
> the time for any new connection.

As soon as you call SSL_shutdown() then a close_notify alert is sent.
Typically you do that on both the client and the server sides which
seems to match your wireshark trace.

Matt