From pwithopf at adiscon.com  Fri Dec  1 07:27:43 2017
From: pwithopf at adiscon.com (Pascal Withopf)
Date: Fri, 1 Dec 2017 08:27:43 +0100
Subject: [openssl-users] Problem verifying a certificate chain
In-Reply-To: <EA0B2FFE-B1F4-4A01-9E99-2D3F09239613@dukhovni.org>
References: <CAJGZxNQNv=S3M2-H3mBTLfP_QwZN9PS4fyxawAVtpU5vqL5PXA@mail.gmail.com>
 <20171129154829.GK3322@mournblade.imrryr.org>
 <CAJGZxNRCLfBVrkSn6ZhU2bZn9aFGe_mWn++rpMBF2=yKW2_uRA@mail.gmail.com>
 <7548F499-C526-47EF-83BE-0647A7199FD8@dukhovni.org>
 <CAJGZxNSb=pu-qXa-7qJ7ZW=Z=QR7X_3+pw8=_HNbDC=hbQ5P5w@mail.gmail.com>
 <EA0B2FFE-B1F4-4A01-9E99-2D3F09239613@dukhovni.org>
Message-ID: <CAJGZxNSMeemA3beNB7SuYE5cxWADXmenLeJC3hcsXzu5OxL4ug@mail.gmail.com>

Yes it's only for testing so it doesn't matter.

But how do I do this?

2017-11-30 19:54 GMT+01:00 Viktor Dukhovni <openssl-users at dukhovni.org>:

>
>
> > On Nov 30, 2017, at 2:46 AM, Pascal Withopf <pwithopf at adiscon.com>
> wrote:
> >
> > Here is serverCA.pem as a file and as text
>
> These are, I expect, test certs and keys, so posting the keys too
> is presumably not a problem...
>
> In any case, the problem is that the CA certificate is a v1
> certificate with no extensions.  It needs to be a v3 certificate
> with basicConstraints CA:true, and keyUsage befitting a CA.
>
> Certificate:
>     Data:
>         Version: 1 (0x0)
>         Serial Number:
>             92:fb:86:47:d7:eb:1f:c3
>     Signature Algorithm: sha1WithRSAEncryption
>         Issuer: C=XX, ST=XX, L=test, O=Testorganisation, CN=Root CA
>         Validity
>             Not Before: Nov 30 07:30:13 2017 GMT
>             Not After : Dec 30 07:30:13 2017 GMT
>         Subject: C=XX, ST=XX, L=test, O=Testorganisation, CN=Server CA
>         Subject Public Key Info:
>             Public Key Algorithm: rsaEncryption
>                 Public-Key: (1024 bit)
>                 Modulus:
>                     00:ba:f3:7b:2b:e3:e6:ed:e4:ec:90:01:99:05:59:
>                     62:94:16:eb:f0:fd:07:8e:5d:13:38:85:04:72:48:
>                     05:48:76:c2:0b:bb:63:79:c7:49:4b:d2:33:5d:75:
>                     6f:f2:79:c7:55:db:23:4d:b6:4a:89:82:b6:ff:aa:
>                     1d:d2:07:1b:4d:68:c8:f5:3d:87:b6:76:05:bd:4a:
>                     0a:79:d8:27:e0:0d:a7:a7:7b:39:13:85:7b:d3:b0:
>                     02:cb:0e:3d:27:d9:a6:8a:a0:65:7c:a8:3a:72:73:
>                     a9:61:af:99:39:97:e5:f7:9c:8d:3d:4a:bd:ac:af:
>                     4a:80:31:d7:46:c7:9a:3f:65
>                 Exponent: 65537 (0x10001)
>     Signature Algorithm: sha1WithRSAEncryption
>          aa:d0:92:67:17:00:fe:33:7f:b9:94:2c:63:6e:ce:cf:02:25:
>          77:d9:df:1e:89:3f:6b:fd:02:54:73:04:36:54:c1:5a:a5:35:
>          27:4b:9d:55:55:f1:9f:d4:72:10:9a:e0:3d:42:e2:8a:af:80:
>          aa:00:92:16:3d:16:49:9a:df:94:13:63:df:50:99:50:87:1e:
>          a0:52:5e:ec:8b:23:4c:28:e8:f8:f3:fc:10:fc:8d:72:1d:3f:
>          40:ac:89:42:18:d5:80:03:df:ad:24:ff:74:c3:4e:e0:de:ac:
>          01:7a:df:b0:62:67:1b:85:84:bd:c4:d4:89:79:41:21:46:d6:
>          59:06
>
>
> --
>         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/20171201/5f43d069/attachment.html>

From jameshfisher at gmail.com  Fri Dec  1 19:39:21 2017
From: jameshfisher at gmail.com (James Fisher)
Date: Fri, 01 Dec 2017 19:39:21 +0000
Subject: [openssl-users] What is the output format of `openssl pkcs12`? How
 can I make it output a PKCS#1 private key?
Message-ID: <CAC_Q48BgUp_EMjHSF9Em+72o_4N_8fUmWzdZx7Gh1n_0pyBF8Q@mail.gmail.com>

Hi,

I have a `Certificates.p12` file that I wish to convert to a
`certificates.pem` containing an unencrypted private key in PKCS#1 format.
I have previously been able to do this by running:

    openssl pkcs12 -in Certificates.p12 -out certificates.pem -nodes
-clcerts

The resulting `certificates.pem` file has a `PRIVATE KEY` PEM block, as
expected. However, the library I'm using
<https://github.com/sideshow/apns2/blob/master/certificate/certificate.go#L80>
does
not understand this PEM block, because it expects it to be a PKCS#1 private
key. The ASN.1 structure of a PKCS#1 private key is defined by RFC 3447
<https://tools.ietf.org/html/rfc3447#appendix-A.1.2> as:

    RSAPrivateKey ::= SEQUENCE {
        version           Version,
        modulus           INTEGER,  -- n
        publicExponent    INTEGER,  -- e
        privateExponent   INTEGER,  -- d
        prime1            INTEGER,  -- p
        prime2            INTEGER,  -- q
        exponent1         INTEGER,  -- d mod (p-1)
        exponent2         INTEGER,  -- d mod (q-1)
        coefficient       INTEGER,  -- (inverse of q) mod p
        otherPrimeInfos   OtherPrimeInfos OPTIONAL
    }

The bad private key block in my `certificates.pem` does not have this
PKCS#1 structure! Instead, its ASN.1 structure looks like this:

    $ openssl asn1parse -i -in badprivatekey.pem
        0:d=0  hl=4 l=1212 cons: SEQUENCE
        4:d=1  hl=2 l=   1 prim:  INTEGER           :00
        7:d=1  hl=2 l=  13 cons:  SEQUENCE
        9:d=2  hl=2 l=   9 prim:   OBJECT            :rsaEncryption
       20:d=2  hl=2 l=   0 prim:   NULL
       22:d=1  hl=4 l=1190 prim:  OCTET STRING      [HEX
DUMP]:308204A...very long hex...

What is the above format? The documentation for `openssl pkcs12`
<https://wiki.openssl.org/index.php/Manual:Pkcs12(1)> only vaguely says
that its output is "written in PEM format." I need a stronger guarantee
that the private key PEM block is in PKCS#1 format.

The strange thing is that `openssl rsa` understands the strange format of
the "bad" private key, and can convert it to the right PKCS#1 structure
with:

    openssl rsa -in badprivatekey.pem -out goodprivatekey.pem

Although `openssl rsa` understands the input file, the tool seems unable to
tell me _why_, i.e. what the format of the input file is.

What is the output format of `openssl pkcs12`? Specifically what is the
format of its private key block? How do I make `openssl pkcs12` output a
correct PKCS#1 private key?

Thanks,
Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171201/dad3550c/attachment.html>

From director at openca.org  Fri Dec  1 19:14:54 2017
From: director at openca.org (Dr. Pala)
Date: Fri, 1 Dec 2017 12:14:54 -0700
Subject: [openssl-users] ASN1 & Recursive Structures definition
Message-ID: <2c480bc2-3367-38e9-f4d8-3e7b37e42cb8@openca.org>

Hi all,

I am trying to define an ASN1 structure similar to this:

ASN1_SEQUENCE(TEST) = {
     ASN1_SIMPLE(TEST, version, ASN1_INTEGER),
     ASN1_EXP_SEQUENCE_OF_OPT(TEST, otherTests, TEST, 0)
} ASN1_SEQUENCE_END(TEST)

IMPLEMENT_ASN1_FUNCTIONS(TEST) [**]

what is the correct procedure for doing that ? The problem is that the 
"otherTests" field should be a sequence of "TEST" structures, but 
defined like that it won't work.

Is there a way to solve the issue ? Or shall we use something like 
ASN1_ANY to avoid the circular reference ?

Cheers,
Max

[**] = For completeness, that is what is defined in the test.c - in 
test.h we define the struct as usual

 ??? struct test_st;
     typedef struct test_st TEST;

 ??? typedef struct test_st {
         ASN1_INTEGER * version;
         STACK_OF(TEST) * otherTests;
     } TEST;

 ??? DECLARE_ASN1_FUNCTIONS(TEST)

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171201/5a26df89/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecglhfmndemlfmfa.png
Type: image/png
Size: 3146 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171201/5a26df89/attachment-0001.png>

From openssl at jordan.maileater.net  Fri Dec  1 22:17:55 2017
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Fri, 1 Dec 2017 14:17:55 -0800
Subject: [openssl-users] FIPS certification for openssl
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9ADF474@prvxmb03.microfocus.com>
References: <OF225AF5ED.252E8848-ON002581E7.00443BD9-652581E7.0044AE6A@notes.na.collabserv.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADD93A@prvxmb03.microfocus.com>
 <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com>
 <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com>
 <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net>
 <0D2E376C-E755-4105-B282-87F19F496092@akamai.com>
 <bb456b58-f0ac-662d-5327-a922e633858d@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADF474@prvxmb03.microfocus.com>
Message-ID: <f8ef6644-7805-9122-6775-ab5a54a9cba7@jordan.maileater.net>

On 11/30/2017 5:41 AM, Michael Wojcik wrote:
> There are a great many OpenSSL consumers. Making radical changes to the default behavior of the API would break many applications - and so it's likely those applications would stop updating their OpenSSL builds.

Yes, compatibility is a concern.? So make the "default to secure"
options be new functions.

> If the application is well-written, the user doesn't need the application source now. If the application isn't well-written, being able to change "settings" is not one of your bigger problems.

You really think that most applications handle all this stuff right??
See below.

>> Looking at it another way:? browsers manage to do it...
> Manage to do what, exactly? And how are browsers a good model for the vast range of OpenSSL applications? They're just one type of client that nearly always uses a very particular PKI model.

Manage to make reasonably secure connections with a minimum of user hassle.

Is it really right that a basic client (from the O'Reilly book) is over
300 lines long?? (client3.c, common.c, reentrant.c)

But the really dangerous thing is that if you miss a step, what you get
is a silently insecure connection rather than a failure.

Do you really like having OpenSSL featured in papers like this?
The most dangerous code in the world: validating SSL certificates in
non-browser software
<http://crypto.stanford.edu/%7Edabo/pubs/abstracts/ssl-client-bugs.html>

-- 
Jordan Brown, Oracle Solaris

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

From laprus.pro at outlook.com  Fri Dec  1 22:21:37 2017
From: laprus.pro at outlook.com (FOURES TOM)
Date: Fri, 1 Dec 2017 22:21:37 +0000
Subject: [openssl-users] Serial Number with OpenSSL
Message-ID: <HE1PR02MB319684EF90815336C79F072ECB390@HE1PR02MB3196.eurprd02.prod.outlook.com>

Hello,

When I see SSL certificates, their serial number is like this : 0A:8D:9A:4Q:8X:1A:0B:88:18:1Z

So, how could I set my serial file (with serial.old) for to obtain User Certificates with this serial using my openssl.cnf file?


Thank you for your help!

Have a nice day.

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

From Michael.Wojcik at microfocus.com  Fri Dec  1 22:57:18 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 1 Dec 2017 22:57:18 +0000
Subject: [openssl-users] FIPS certification for openssl
In-Reply-To: <f8ef6644-7805-9122-6775-ab5a54a9cba7@jordan.maileater.net>
References: <OF225AF5ED.252E8848-ON002581E7.00443BD9-652581E7.0044AE6A@notes.na.collabserv.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADD93A@prvxmb03.microfocus.com>
 <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com>
 <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com>
 <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net>
 <0D2E376C-E755-4105-B282-87F19F496092@akamai.com>
 <bb456b58-f0ac-662d-5327-a922e633858d@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADF474@prvxmb03.microfocus.com>
 <f8ef6644-7805-9122-6775-ab5a54a9cba7@jordan.maileater.net>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D84@prvxmb03.microfocus.com>

> From: Jordan Brown [mailto:openssl at jordan.maileater.net] 
> Sent: Friday, December 01, 2017 17:18

> On 11/30/2017 5:41 AM, Michael Wojcik wrote:

> > There are a great many OpenSSL consumers. Making radical changes to the default behavior of the API would break 
> > many applications - and so it's likely those applications would stop updating their OpenSSL builds.

> Yes, compatibility is a concern.? So make the "default to secure" options be new functions.

That's certainly better than what you proposed in your previous messages. It's still not where I'd want to see the core OpenSSL developers spending their time, though.

Of course, anyone's free to write their own API on top of what OpenSSL provides, and even make a pull request to contribute it to the project.

> > If the application is well-written, the user doesn't need the application source now. If the application isn't well-written,
> > being able to change "settings" is not one of your bigger problems.

> You really think that most applications handle all this stuff right?? See below.

No. That's not what I wrote.

> > > Looking at it another way:? browsers manage to do it...
> > Manage to do what, exactly? And how are browsers a good model for the vast range of OpenSSL applications? They're
> >  just one type of client that nearly always uses a very particular PKI model.

> Manage to make reasonably secure connections with a minimum of user hassle.

Still just one type of client.

> Is it really right that a basic client (from the O'Reilly book) is over 300 lines long?? (client3.c, common.c, reentrant.c)

As I said: nothing is stopping anyone from wrapping that up in an API.

> But the really dangerous thing is that if you miss a step, what you get is a silently insecure connection rather than a
>  failure.

Depends on what step you miss.

Look, I'm well aware this is a problem. I just gave an internal presentation to a roomful of developers on this very subject in October. But I don't think changing OpenSSL to consult "per-user or system-wide configuration files" by default - which is what you appeared to propose in the note I was responding to - is the right solution. Nor, as I said above, do I think it's where the OpenSSL Project developers should be focussing their efforts at this time. If someone else wants to, fine - though I think it's a much harder problem than you're making it out to be.

> Do you really like having OpenSSL featured in papers like this?
> The most dangerous code in the world: validating SSL certificates in non-browser software

Better than being omitted. And I'm well aware of that paper (an old [well, since 2012] favorite); I discussed it in the talk I mentioned above.

Frankly, what I'd like is fewer people using OpenSSL at all. Not necessarily fewer applications, but fewer *people*. Cryptography and security are inherently difficult; TLS is particularly bad, because of its history, configurability, interoperability demands, and horrendously broken PKI. It's an area for experts. I'd like the barrier to entry to be *higher*, so we'd see fewer people posting messages like "I tried to write a server using OpenSSL but I don't understand cipher suites".

Hell, as the "Most Dangerous Code" paper itself points out at some length, JSSE tried for "secure by default", but many JSSE-based applications use the wrong APIs and unwittingly bypass certificate validation. Secure-by-default is extremely difficult with TLS.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From Michael.Wojcik at microfocus.com  Fri Dec  1 22:57:17 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 1 Dec 2017 22:57:17 +0000
Subject: [openssl-users] What is the output format of `openssl pkcs12`?
 How can I make it output a PKCS#1 private key?
In-Reply-To: <CAC_Q48BgUp_EMjHSF9Em+72o_4N_8fUmWzdZx7Gh1n_0pyBF8Q@mail.gmail.com>
References: <CAC_Q48BgUp_EMjHSF9Em+72o_4N_8fUmWzdZx7Gh1n_0pyBF8Q@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D81@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of James Fisher
> Sent: Friday, December 01, 2017 14:39

Haven't seen any other replies to this yet. I don't have time to verify any of the below right now, so this is just off the top of my head and may well be wrong.

> I have a `Certificates.p12` file that I wish to convert to a `certificates.pem` containing an unencrypted private key in
> PKCS#1 format. I have previously been able to do this by running:
>
>? ? openssl pkcs12 -in Certificates.p12 -out certificates.pem -nodes -clcerts

> The resulting `certificates.pem` file has a `PRIVATE KEY` PEM block, as expected. However,?the library I'm using?does not
> understand this PEM block, because it expects it to be a PKCS#1 private key....
>
> The bad private key block in my `certificates.pem` does not have this PKCS#1 structure!

I'd guess it's the OpenSSL / SSLeay key structure, as used by e.g. "openssl rsa". See the note here:
https://wiki.openssl.org/index.php/Manual:Rsa(1)

> I need a stronger guarantee that the private key PEM block is in PKCS#1 format.

I don't think OpenSSL is going to make you that guarantee.

> The strange thing is that `openssl rsa` understands the strange format of the "bad" private key, and can convert it to
> the right PKCS#1 structure with:
>
>? ? openssl rsa -in badprivatekey.pem -out goodprivatekey.pem

Hmm. Maybe "openssl rsa" was changed at some point to output PKCS#1, but "openssl pkcs12" is still using the SSLeay format?

> What is the output format of `openssl pkcs12`? Specifically what is the format of its private key block? How do I make
> `openssl pkcs12` output a correct PKCS#1 private key?

I'd write a script that uses openssl pkcs12, splits the file on PEM delimiters, and then reencodes the key using openssl rsa. Any competent scripting language should be able to do that; you even do it with Windows cmd. You've already found that procedure works, so why boil the ocean?

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From levitte at openssl.org  Fri Dec  1 23:13:59 2017
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 02 Dec 2017 00:13:59 +0100 (CET)
Subject: [openssl-users] openssl-users Digest, Vol 37, Issue 1
In-Reply-To: <mailman.350.1512164055.27609.openssl-users@openssl.org>
References: <mailman.350.1512164055.27609.openssl-users@openssl.org>
Message-ID: <20171202.001359.1821210342757029511.levitte@openssl.org>

In message <mailman.350.1512164055.27609.openssl-users at openssl.org> on Fri, 01 Dec 2017 21:34:15 +0000, openssl-users-request at openssl.org said:

openssl-users-request> Hi,
openssl-users-request> 
openssl-users-request> I have a `Certificates.p12` file that I wish to convert to a
openssl-users-request> `certificates.pem` containing an unencrypted private key in PKCS#1 format.
openssl-users-request> I have previously been able to do this by running:
openssl-users-request> 
openssl-users-request>     openssl pkcs12 -in Certificates.p12 -out certificates.pem -nodes
openssl-users-request> -clcerts
openssl-users-request> 
openssl-users-request> The resulting `certificates.pem` file has a `PRIVATE KEY` PEM block, as
openssl-users-request> expected. However, the library I'm using
openssl-users-request> <https://github.com/sideshow/apns2/blob/master/certificate/certificate.go#L80>
openssl-users-request> does
openssl-users-request> not understand this PEM block, because it expects it to be a PKCS#1 private
openssl-users-request> key. The ASN.1 structure of a PKCS#1 private key is defined by RFC 3447
openssl-users-request> <https://tools.ietf.org/html/rfc3447#appendix-A.1.2> as:

'openssl pkcs12' outputs a PKCS#8 structure, which is the default for
new private keys in OpenSSL.  You might be interested in this
structure, it's documented in RFC 5208:

    https://tools.ietf.org/html/rfc5208

You might want to tell github:sideshow as well...  it's actually
pretty easy, the package they use has a function to parse PKCS#8
private keys as well:

    https://golang.org/pkg/crypto/x509/#ParsePKCS8PrivateKey

openssl-users-request> How do I make `openssl pkcs12` output a correct
openssl-users-request> PKCS#1 private key?

You don't.  If you want to insist on an older format, then conversion
it is.

Cheers,
Richard

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

From levitte at openssl.org  Fri Dec  1 23:22:35 2017
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 02 Dec 2017 00:22:35 +0100 (CET)
Subject: [openssl-users] ASN1 & Recursive Structures definition
In-Reply-To: <2c480bc2-3367-38e9-f4d8-3e7b37e42cb8@openca.org>
References: <2c480bc2-3367-38e9-f4d8-3e7b37e42cb8@openca.org>
Message-ID: <20171202.002235.2206435799327755411.levitte@openssl.org>

In message <2c480bc2-3367-38e9-f4d8-3e7b37e42cb8 at openca.org> on Fri, 1 Dec 2017 12:14:54 -0700, "Dr. Pala" <director at openca.org> said:

director> I am trying to define an ASN1 structure similar to this:
director> 
director> ASN1_SEQUENCE(TEST) = {
director>     ASN1_SIMPLE(TEST, version, ASN1_INTEGER),
director>     ASN1_EXP_SEQUENCE_OF_OPT(TEST, otherTests, TEST, 0)
director> } ASN1_SEQUENCE_END(TEST)
director> 
director> IMPLEMENT_ASN1_FUNCTIONS(TEST) [**]
director> 
director> what is the correct procedure for doing that ? The problem
director> is that the "otherTests" field should be a sequence of
director> "TEST" structures, but defined like that it won't work.
director> 
director> Is there a way to solve the issue ? Or shall we use
director> something like ASN1_ANY to avoid the circular reference ?

Nope...  all it takes is a forward declaration:

    ASN1_SEQUENCE(TEST);
    ASN1_SEQUENCE(TEST) = {
        ASN1_SIMPLE(TEST, version, ASN1_INTEGER),
        ASN1_EXP_SEQUENCE_OF_OPT(TEST, otherTests, TEST, 0)
    } ASN1_SEQUENCE_END(TEST)
    
    IMPLEMENT_ASN1_FUNCTIONS(TEST)

(I tested that just now)

Cheers,
Richard

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

From openssl at jordan.maileater.net  Sat Dec  2 00:47:39 2017
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Fri, 1 Dec 2017 16:47:39 -0800
Subject: [openssl-users] FIPS certification for openssl
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D84@prvxmb03.microfocus.com>
References: <OF225AF5ED.252E8848-ON002581E7.00443BD9-652581E7.0044AE6A@notes.na.collabserv.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADD93A@prvxmb03.microfocus.com>
 <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com>
 <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com>
 <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net>
 <0D2E376C-E755-4105-B282-87F19F496092@akamai.com>
 <bb456b58-f0ac-662d-5327-a922e633858d@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADF474@prvxmb03.microfocus.com>
 <f8ef6644-7805-9122-6775-ab5a54a9cba7@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D84@prvxmb03.microfocus.com>
Message-ID: <c16f8787-027a-d7e2-3d5c-4236855818c9@jordan.maileater.net>

On 12/1/2017 2:57 PM, Michael Wojcik wrote:
>> Yes, compatibility is a concern.? So make the "default to secure" options be new functions.
> That's certainly better than what you proposed in your previous messages.

Sorry, I wasn't trying to propose any particular concrete interfaces.? I
was trying to speak abstractly:? "a client should be able to say 'give
me a secure connection to host:port' and have sensible and secure things
happen with a single call.? Maybe two, one to create a handle and the
other to actually set up the connection (to allow for intervening calls
that customize the connection)."? (OK, yeah, I did get a bit more
concrete later, but I never said "change the existing functions".)

> Of course, anyone's free to write their own API on top of what OpenSSL provides, and even make a pull request to contribute it to the project.

If only I had the time.? I do greatly respect the work that people do on
FOSS projects.? I just wish more would focus on getting the common cases
to be easy and bulletproof, and less on being all things to all people.

>>>> Looking at it another way:? browsers manage to do it...
>>> Manage to do what, exactly? And how are browsers a good model for the vast range of OpenSSL applications? They're
>>>  just one type of client that nearly always uses a very particular PKI model.
>> Manage to make reasonably secure connections with a minimum of user hassle.
> Still just one type of client.

Maybe I just don't have a big enough picture, but in my TLS-related work
(mostly client LDAP, but some other stuff) I keep coming back to a
browser as the behavior that I should emulate.

> Frankly, what I'd like is fewer people using OpenSSL at all. Not
> necessarily fewer applications, but fewer *people*. Cryptography and
> security are inherently difficult; TLS is particularly bad, because of
> its history, configurability, interoperability demands, and
> horrendously broken PKI. It's an area for experts. I'd like the
> barrier to entry to be *higher*, so we'd see fewer people posting
> messages like "I tried to write a server using OpenSSL but I don't
> understand cipher suites". 

What should they use instead?

What *should* core OpenSSL developers be focused on?

And why should callers have to understand cipher suites at any deep
level?? Why should they need to know any more than "there are multiple
algorithms, and new algorithms are introduced occasionally, and old
algorithms are defeated occasionally, but you may need old algorithms
for interoperability, so you need to have a way to select which
algorithms you accept"?? That's pretty much the limits of my mental
model; what am I missing?

-- 
Jordan Brown, Oracle Solaris

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

From aerowolf at gmail.com  Sat Dec  2 01:02:17 2017
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Fri, 1 Dec 2017 17:02:17 -0800
Subject: [openssl-users] Serial Number with OpenSSL
In-Reply-To: <HE1PR02MB319684EF90815336C79F072ECB390@HE1PR02MB3196.eurprd02.prod.outlook.com>
References: <HE1PR02MB319684EF90815336C79F072ECB390@HE1PR02MB3196.eurprd02.prod.outlook.com>
Message-ID: <CAPMEXDbOKRsXbBRsZGtrX-EDSaN8pfVpSkqor1_uTrwRt-sF6g@mail.gmail.com>

4Q? 8X? 1Z?

Those are not octets that can show up in serial numbers.

-Kyle H

On Fri, Dec 1, 2017 at 2:21 PM, FOURES TOM <laprus.pro at outlook.com> wrote:
> Hello,
>
> When I see SSL certificates, their serial number is like this :
> 0A:8D:9A:4Q:8X:1A:0B:88:18:1Z
>
> So, how could I set my serial file (with serial.old) for to obtain User
> Certificates with this serial using my openssl.cnf file?
>
>
> Thank you for your help!
>
> Have a nice day.
>
> Aris
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

From debbie10t at gmail.com  Sat Dec  2 02:01:25 2017
From: debbie10t at gmail.com (debbie10t)
Date: Sat, 2 Dec 2017 02:01:25 +0000
Subject: [openssl-users] FIPS certification for openssl
In-Reply-To: <A81FD129-BA23-43A7-95BD-125FFCB7BF84@akamai.com>
References: <OF225AF5ED.252E8848-ON002581E7.00443BD9-652581E7.0044AE6A@notes.na.collabserv.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADD93A@prvxmb03.microfocus.com>
 <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com>
 <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADEFF1@prvxmb03.microfocus.com>
 <A81FD129-BA23-43A7-95BD-125FFCB7BF84@akamai.com>
Message-ID: <e5bc4c48-2548-aa5d-3dd4-1426711b84b1@gmail.com>

Hi there,

long time lurker ..

This sort of thing is a Remarkably Unique Occasion ...

Personally, I do subscribe here for genuine, up to date,
informative and even humorous (on occasion) information.

I do not expect this to be the sole source of my knowledge.

But .. I did learn of the impending and drastic changes
via this list *and not as an official notice but rather
by accident.

Personally, I would like to see such critical changes
flood the openssl chambers .. but I do also respect that
the people involved may have made their own personal choices
regarding their actions ... I guess it is very complicatted....

I would say "Good ~/Luck and Thank You" to those we loose
And (personally) "Thank You for stepping Into the breach"
those who choose to .. because they can ! .. I could not

God damn that Single Malt !




On 29/11/17 23:01, Salz, Rich via openssl-users wrote:
> ? It probably wouldn't hurt to post something to the lists when there's a blog post with news like this  - items that subscribers would likely feel is important. Blog posts like the recent "OpenSSL in China" series probably don't need to be mentioned on the lists. But it's subjective, and I wouldn't want to create more work for anyone.
>      
> It?s a lot easier than writing the blog posts (
> 
> We should have been doing this from the very beginning, oops.  We?ll try to do better.
> 


From madwolf at openca.org  Sat Dec  2 03:22:09 2017
From: madwolf at openca.org (Dr. Pala)
Date: Fri, 1 Dec 2017 20:22:09 -0700
Subject: [openssl-users] ASN1 & Recursive Structures definition
In-Reply-To: <20171202.002235.2206435799327755411.levitte@openssl.org>
References: <2c480bc2-3367-38e9-f4d8-3e7b37e42cb8@openca.org>
 <20171202.002235.2206435799327755411.levitte@openssl.org>
Message-ID: <d1eeba62-f25f-c984-dc77-94a150cf73c1@openca.org>

Hi Richard,

thanks :D That worked. I have a new challenge for you now. Here's what I 
am trying to do:

ASN1_SEQUENCE(TEST);
ASN1_SEQUENCE(TBS_TEST) = {
     ASN1_SIMPLE(TBS_TEST, version, ASN1_INTEGER),
     ASN1_EXP_SEQUENCE_OF_OPT(TBS_TEST, otherTests, TEST, 0)
} ASN1_SEQUENCE_END(TEST)

IMPLEMENT_ASN1_FUNCTIONS(TBS_TEST) [**]

ASN1_SEQUENCE(TEST) = {
     ASN1_SIMPLE(TEST, tbsTest, ASN1_INTEGER),
     ASN1_EXP_OPT(TEST, optionalSignature, TEST_SIGNATURE, 0)
} ASN1_SEQUENCE_END(TEST)

IMPLEMENT_ASN1_FUNCTIONS(TEST) [**]

In this case, the difference is that TBS_TEST has, inside the otherTests 
that are of type TEST. The TEST is built out of a tbsTest and an 
optionalSignature - but it is defined after TBS_TEST.

What to do in this case ?

Cheers,
Max


On 12/1/17 4:22 PM, Richard Levitte wrote:
> In message <2c480bc2-3367-38e9-f4d8-3e7b37e42cb8 at openca.org> on Fri, 1 Dec 2017 12:14:54 -0700, "Dr. Pala" <director at openca.org> said:
>
> director> I am trying to define an ASN1 structure similar to this:
> director>
> director> ASN1_SEQUENCE(TEST) = {
> director>     ASN1_SIMPLE(TEST, version, ASN1_INTEGER),
> director>     ASN1_EXP_SEQUENCE_OF_OPT(TEST, otherTests, TEST, 0)
> director> } ASN1_SEQUENCE_END(TEST)
> director>
> director> IMPLEMENT_ASN1_FUNCTIONS(TEST) [**]
> director>
> director> what is the correct procedure for doing that ? The problem
> director> is that the "otherTests" field should be a sequence of
> director> "TEST" structures, but defined like that it won't work.
> director>
> director> Is there a way to solve the issue ? Or shall we use
> director> something like ASN1_ANY to avoid the circular reference ?
>
> Nope...  all it takes is a forward declaration:
>
>      ASN1_SEQUENCE(TEST);
>      ASN1_SEQUENCE(TEST) = {
>          ASN1_SIMPLE(TEST, version, ASN1_INTEGER),
>          ASN1_EXP_SEQUENCE_OF_OPT(TEST, otherTests, TEST, 0)
>      } ASN1_SEQUENCE_END(TEST)
>      
>      IMPLEMENT_ASN1_FUNCTIONS(TEST)
>
> (I tested that just now)
>
> Cheers,
> Richard
>


From mcr at sandelman.ca  Sat Dec  2 04:22:34 2017
From: mcr at sandelman.ca (Michael Richardson)
Date: Fri, 01 Dec 2017 23:22:34 -0500
Subject: [openssl-users] Serial Number with OpenSSL
In-Reply-To: <HE1PR02MB319684EF90815336C79F072ECB390@HE1PR02MB3196.eurprd02.prod.outlook.com>
References: <HE1PR02MB319684EF90815336C79F072ECB390@HE1PR02MB3196.eurprd02.prod.outlook.com>
Message-ID: <9387.1512188554@obiwan.sandelman.ca>


FOURES TOM <laprus.pro at outlook.com> wrote:
    > When I see SSL certificates, their serial number is like this :
    > 0A:8D:9A:4Q:8X:1A:0B:88:18:1Z

That's an unusual Serial Number, which even if you made this up, is just an
integer.

IDevID/802.1AR certificates will have a subjectAltName that is sometimes
called Serial Number, so I wonder if that is what you are seeing?

    > So, how could I set my serial file (with serial.old) for to obtain
    > User Certificates with this serial using my openssl.cnf file?


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171201/0a6c554d/attachment-0001.sig>

From levitte at openssl.org  Sat Dec  2 11:54:08 2017
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 02 Dec 2017 12:54:08 +0100 (CET)
Subject: [openssl-users] ASN1 & Recursive Structures definition
In-Reply-To: <d1eeba62-f25f-c984-dc77-94a150cf73c1@openca.org>
References: <2c480bc2-3367-38e9-f4d8-3e7b37e42cb8@openca.org>
 <20171202.002235.2206435799327755411.levitte@openssl.org>
 <d1eeba62-f25f-c984-dc77-94a150cf73c1@openca.org>
Message-ID: <20171202.125408.1222423086056733693.levitte@openssl.org>

In message <d1eeba62-f25f-c984-dc77-94a150cf73c1 at openca.org> on Fri, 1 Dec 2017 20:22:09 -0700, "Dr. Pala" <madwolf at openca.org> said:

madwolf> Hi Richard,
madwolf> 
madwolf> thanks :D That worked. I have a new challenge for you now. Here's what
madwolf> I am trying to do:
madwolf> 
madwolf> ASN1_SEQUENCE(TEST);
madwolf> ASN1_SEQUENCE(TBS_TEST) = {
madwolf>     ASN1_SIMPLE(TBS_TEST, version, ASN1_INTEGER),
madwolf>     ASN1_EXP_SEQUENCE_OF_OPT(TBS_TEST, otherTests, TEST, 0)
madwolf> } ASN1_SEQUENCE_END(TEST)
madwolf> 
madwolf> IMPLEMENT_ASN1_FUNCTIONS(TBS_TEST) [**]
madwolf> 
madwolf> ASN1_SEQUENCE(TEST) = {
madwolf>     ASN1_SIMPLE(TEST, tbsTest, ASN1_INTEGER),
madwolf>     ASN1_EXP_OPT(TEST, optionalSignature, TEST_SIGNATURE, 0)
madwolf> } ASN1_SEQUENCE_END(TEST)
madwolf> 
madwolf> IMPLEMENT_ASN1_FUNCTIONS(TEST) [**]
madwolf> 
madwolf> In this case, the difference is that TBS_TEST has, inside the
madwolf> otherTests that are of type TEST. The TEST is built out of a tbsTest
madwolf> and an optionalSignature - but it is defined after TBS_TEST.
madwolf> 
madwolf> What to do in this case ?

It seems to me that you need to do some kind of forward declaration of
TEST_SIGNATURE as well, before the construction of TEST.  (also, to be
picky, you need to make sure that ASN1_SEQUENCE(TBS_TEST) is ended
with ASN1_SEQUENCE_END(TBS_TEST), not ASN1_SEQUENCE_END(TEST))

Cheers,
Richard

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

From Michael.Wojcik at microfocus.com  Sat Dec  2 14:35:40 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Sat, 2 Dec 2017 14:35:40 +0000
Subject: [openssl-users] FIPS certification for openssl
In-Reply-To: <c16f8787-027a-d7e2-3d5c-4236855818c9@jordan.maileater.net>
References: <OF225AF5ED.252E8848-ON002581E7.00443BD9-652581E7.0044AE6A@notes.na.collabserv.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADD93A@prvxmb03.microfocus.com>
 <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com>
 <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com>
 <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net>
 <0D2E376C-E755-4105-B282-87F19F496092@akamai.com>
 <bb456b58-f0ac-662d-5327-a922e633858d@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADF474@prvxmb03.microfocus.com>
 <f8ef6644-7805-9122-6775-ab5a54a9cba7@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D84@prvxmb03.microfocus.com>
 <c16f8787-027a-d7e2-3d5c-4236855818c9@jordan.maileater.net>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com>

> From: Jordan Brown [mailto:openssl at jordan.maileater.net] 
> Sent: Friday, December 01, 2017 19:48

> On 12/1/2017 2:57 PM, Michael Wojcik wrote:

> > Of course, anyone's free to write their own API on top of what OpenSSL provides, and even make a pull request to
> > contribute it to the project.

> If only I had the time.? I do greatly respect the work that people do on FOSS projects.? I just wish more would focus on
> getting the common cases to be easy and bulletproof, and less on being all things to all people.

Well, I suppose this is the core of our disagreement. I don't think that should be at the top of the priority list, or indeed high enough to make it likely to happen any time soon.

My personal priority list for OpenSSL is bug fixes and code cleanup (static and dynamic analysis of the 1.1.x codebase would be good, and one of these days I'll get around to doing it myself), and continuing the TLSv1.3 implementation until that standard finally settles down. (I'm not much of a TLSv1.3 fan, but customers will demand it.) If there's spare time, the docs always need work. PKCS#12 support could be improved (though maybe it's better in 1.1.x).

Reasonable people can of course disagree. I don't think your position is indefensible; I just don't agree with it.

As I said, I recognize the utility ofa simple client library. I wrote one that does secure-by-default myself. It's in a commercial product and I don't control the IP, so it's not open source - but it really wasn't that difficult or time-consuming. Which is probably why a bunch of other people have done it too: libcurl, OpenLDAP (OK, OpenLDAP is a shambling horror), TLS modules for various languages and frameworks, ...

And for the server side, the best answer is often "use an existing server". Sure, there are plenty of use cases where that's not feasible, but I also see a fair bit of people writing server-side TLS code when they could simply hang their application off an existing server.

A better question might be "why are the common cases common at all?". Why are so many people writing code that calls the OpenSSL API?

> Maybe I just don't have a big enough picture, but in my TLS-related work (mostly client LDAP, but some other stuff) I
> keep coming back to a browser as the behavior that I should emulate.

Yes, I'd have to call that a pretty limited use case. It doesn't cover the server side at all. It doesn't do much for client certificates (which browsers do not handle well). For that matter, browsers don't do a very good job with PKI; they basically say "hey, we've decided to trust this collection of public, commercial CAs, and for anything beyond that you're either going to have to know something about X.509 hierarchical PKI, or someone who does will have to hold your hand". They require user interaction when anything out of the ordinary happens, and the UX and UIM for that interaction has historically been a disaster (basically training users to click through warnings). Of late browsers have moved to failling safe with override provisions, but it's still not great UIM.

That's fine for some things, but it doesn't help with servers and it falls over for non-interactive use (or even interactive but non-GUI), or for anything where PKI gets more complicated.

> > Frankly, what I'd like is fewer people using OpenSSL at all. Not necessarily fewer applications, but fewer *people*.
> > Cryptography and security are inherently difficult; TLS is particularly bad, because of its history, configurability,
> > interoperability demands, and horrendously broken PKI. It's an area for experts. I'd like the barrier to entry to be
> > *higher*, so we'd see fewer people posting messages like "I tried to write a server using OpenSSL but I don't 
> > understand cipher suites". 

> What should they use instead?

Libraries and programs written by people who *do* understand cryptography.

There are plenty of car manufacturers who don't design and build their own engines. House builders rarely mill their own wood or construct their own windows and doors. Surgeons aren't responsible for building their own X-ray machines or even sharpening their own scalpels. Few authors build their own computers or write their own word processors. Why do programmers need to be in control of so much of their own software stacks?

> And why should callers have to understand cipher suites at any deep level?

For the same reason electricians need to understand electricity.

I don't know how long you've been reading openssl-users. I've been subscribed to it since 2000. I've read a lot of messages from people who understood very little about SSL/TLS. They didn't understand what cipher suites *are* (I'm not asking for any "deep" understanding of the ciphers themselves - though familiarity with known vulnerabilities should be required). They didn't understand the SSL/TLS protocols. They didn't understand X.509 and the hierarchical PKI that's nearly always used with TLS. Often, they didn't understand TCP, which is itself a problem. They weren't keeping up with TLS-related news, which is a *big* problem, and even if they did, they wouldn't know enough to understand it.

Those people should not have been using OpenSSL.

Those are all correctable problems, of course; most of those people were, presumably, completely capable of learning those things. But they didn't, probably because they didn't understand that it's a necessary part of the job if you want to write code that calls OpenSSL. Or if they did, they weren't given the resources to do so. Or they were lazy, human nature being what it is.

> Why should they need to know any more than "there are multiple algorithms, and new algorithms are introduced
> occasionally, and old algorithms are defeated occasionally, but you may need old algorithms for interoperability, so
> you need to have a way to select which algorithms you accept"?? That's pretty much the limits of my mental model;
> what am I missing?

Urgh. I don't really have room (or permission) to post all of Ivan Ristic's /Bulletproof TLS/ book here.

Let's try this. "The C language has various operators and standard library functions, and new functions are introduced occasionally, and old functions are deprecated occasionally, but you may have code that uses old functions, so you need to pick what functions you'll use." Is that a good mental model for writing C programs?

TLS is hard. The OpenSSL API is hard. Making (relatively small) parts of TLS and OpenSSL easier by wrapping them in a client API or hosting applications in a third-party server is entirely possible, since many people (including me) have done it. But I don't see a lot of value in pushing that Easy Mode into OpenSSL itself. That's not where it belongs - layer abstractions and separate concerns. And it encourages the wrong behavior, which is using the OpenSSL API in the first place. That should be left to people who have the luxury (and exercise it) of studying the subject at length.

--
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From rsalz at akamai.com  Sat Dec  2 16:42:25 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 2 Dec 2017 16:42:25 +0000
Subject: [openssl-users] FIPS certification for openssl
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com>
References: <OF225AF5ED.252E8848-ON002581E7.00443BD9-652581E7.0044AE6A@notes.na.collabserv.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADD93A@prvxmb03.microfocus.com>
 <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com>
 <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com>
 <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net>
 <0D2E376C-E755-4105-B282-87F19F496092@akamai.com>
 <bb456b58-f0ac-662d-5327-a922e633858d@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADF474@prvxmb03.microfocus.com>
 <f8ef6644-7805-9122-6775-ab5a54a9cba7@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D84@prvxmb03.microfocus.com>
 <c16f8787-027a-d7e2-3d5c-4236855818c9@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com>
Message-ID: <A493B9C1-1ED2-4B0B-B1D0-D242D59DE120@akamai.com>


>    My personal priority list for OpenSSL is bug fixes and code cleanup (static and dynamic analysis of the 1.1.x codebase would be good, and one of these days I'll get around to doing it myself),

We do run coverity weekly, and anyone can sign up to see the results BTW


From rsalz at akamai.com  Sat Dec  2 16:54:28 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 2 Dec 2017 16:54:28 +0000
Subject: [openssl-users] Serial Number with OpenSSL
Message-ID: <92F19D46-8CDD-41DE-B2BF-38C617C18693@akamai.com>

  *   When I see SSL certificates, their serial number is like this : 0A:8D:9A:4Q:8X:1A:0B:88:18:1Z
Serial numbers are displayed as hex values, so my guess is you just typed that ?as an example? since Q X Z aren?t valid hex characters.  Or perhaps it was an extension (like device serial) that isn?t the ?real? serial number.

On master, you can specify a random serial number
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171202/13929f4b/attachment-0001.html>

From openssl at jordan.maileater.net  Sat Dec  2 18:39:18 2017
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Sat, 2 Dec 2017 10:39:18 -0800
Subject: [openssl-users] FIPS certification for openssl
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com>
References: <OF225AF5ED.252E8848-ON002581E7.00443BD9-652581E7.0044AE6A@notes.na.collabserv.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADD93A@prvxmb03.microfocus.com>
 <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com>
 <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com>
 <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net>
 <0D2E376C-E755-4105-B282-87F19F496092@akamai.com>
 <bb456b58-f0ac-662d-5327-a922e633858d@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADF474@prvxmb03.microfocus.com>
 <f8ef6644-7805-9122-6775-ab5a54a9cba7@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D84@prvxmb03.microfocus.com>
 <c16f8787-027a-d7e2-3d5c-4236855818c9@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com>
Message-ID: <611acd90-6a93-31af-ff8e-0a95876391d9@jordan.maileater.net>

On 12/2/2017 6:35 AM, Michael Wojcik wrote:
> My personal priority list for OpenSSL is bug fixes and code cleanup
> (static and dynamic analysis of the 1.1.x codebase would be good, and
> one of these days I'll get around to doing it myself), and continuing
> the TLSv1.3 implementation until that standard finally settles down.
> (I'm not much of a TLSv1.3 fan, but customers will demand it.) If
> there's spare time, the docs always need work. PKCS#12 support could
> be improved (though maybe it's better in 1.1.x). 

I would never, ever, object to putting bug fixes at the top of the list.

But at the same time we're talking about trying to prevent bugs in the
callers, and that's valuable too.

> A better question might be "why are the common cases common at all?". Why are so many people writing code that calls the OpenSSL API?

Because they know they need a secure connection, and they know that that
means TLS/SSL, and they know that the leading library for TLS/SSL is
OpenSSL, and nothing says "you should be using libFOO instead".? You
look for the key under the street light, because that's where the light is.

> [Emulating a browser is] fine for some things, but it doesn't help
> with servers and it falls over for non-interactive use (or even
> interactive but non-GUI), or for anything where PKI gets more
> complicated. 

And yet it's probably better than 95% of what you'll get from
non-experts rolling their own.

My work is almost entirely non-interactive during production.? So far,
I've been pretty happy with a model that says "emulate a browser during
initial interactive configuration, then use those settings during
production and light a yellow light when anything goes wrong".

(And yes, of course browsers aren't servers... there I'd say "Emulate
Apache httpd".)

>> What should they use instead [of OpenSSL]?
> Libraries and programs written by people who *do* understand cryptography.

It seems like our only disagreement is in who should supply those
libraries, whether OpenSSL should supply one or should leave it to others.

> Why do programmers need to be in control of so much of their own software stacks?

Totally agreed, they shouldn't.? They need to be guided into doing the
right thing.? It should be hard to do the wrong thing.? Everybody will
be happier.

>> Why should they need to know any more than "there are multiple algorithms, and new algorithms are introduced
>> occasionally, and old algorithms are defeated occasionally, but you may need old algorithms for interoperability, so
>> you need to have a way to select which algorithms you accept"?? That's pretty much the limits of my mental model;
>> what am I missing?
> Urgh. I don't really have room (or permission) to post all of Ivan Ristic's /Bulletproof TLS/ book here.
>
> Let's try this. "The C language has various operators and standard library functions, and new functions are introduced occasionally, and old functions are deprecated occasionally, but you may have code that uses old functions, so you need to pick what functions you'll use." Is that a good mental model for writing C programs?

I have a simplistic viewpoint, but the operators in C are mostly
distinct and do different things, while the cipher suites all do the
same things, differing only internally.? I don't know, nor do I want to
know, how algorithm X is different from algorithm Y, or what key lengths
are considered adequate this week.? If I write my application to
incorporate any of that knowledge, it will be wrong next year.? My
application needs to not care which algorithms it's using, and to be
trivially adaptable (preferably at runtime) as the situation changes
over the years.? Anything that I know about the actual algorithms will
probably make that picture worse, not better.? As you say, those
decisions need to be made by people who *do* understand these things...
which excludes 99% of developers.

Thanks for the thoughtful discussion.? I really appreciate it.

-- 
Jordan Brown, Oracle Solaris

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

From madwolf at openca.org  Sun Dec  3 18:37:56 2017
From: madwolf at openca.org (Dr. Pala)
Date: Sun, 3 Dec 2017 11:37:56 -0700
Subject: [openssl-users] ASN1 & Recursive Structures definition
In-Reply-To: <20171202.125408.1222423086056733693.levitte@openssl.org>
References: <2c480bc2-3367-38e9-f4d8-3e7b37e42cb8@openca.org>
 <20171202.002235.2206435799327755411.levitte@openssl.org>
 <d1eeba62-f25f-c984-dc77-94a150cf73c1@openca.org>
 <20171202.125408.1222423086056733693.levitte@openssl.org>
Message-ID: <0089b413-278e-34b1-32b3-2e71b48e5540@openca.org>

Hi Richard, all,

I tried to do the forward declaration also for the TEST_SIGNATURE 
together with the TEST one, but that did not really work :( It is still 
complaining about the use of 'sizeof' on an incomplete type. In 
particular, the two errors are:

    src/ocspv2/****: error: use of undeclared identifier 'TEST_it'
    ASN1_EXP_SEQUENCE_OF_OPT(TEST_TBS, otherTests, TEST, 5),
    ^

    and

    src/ocspv2/****: error: invalid application of 'sizeof' to an
    incomplete type 'const ASN1_TEMPLATE []'
    } ASN1_SEQUENCE_END(TEST_TBS)
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I guess I need to checkout the macros a bit more.. :D

Question: does anybody know if? there is any other structure already 
implemented in OpenSSL that resembles the one I am trying to do here? I 
tried to look for something similar, but no success.. :D

If there is no easy answer, I guess I will have to either change the 
envisioned approach (maybe introducing an intermediate data structure of 
some kind..?) or use the ASN1_ANY approach.

Cheers,
Max


On 12/2/17 4:54 AM, Richard Levitte wrote:
> In message <d1eeba62-f25f-c984-dc77-94a150cf73c1 at openca.org> on Fri, 1 Dec 2017 20:22:09 -0700, "Dr. Pala" <madwolf at openca.org> said:
>
> madwolf> Hi Richard,
> madwolf>
> madwolf> thanks :D That worked. I have a new challenge for you now. Here's what
> madwolf> I am trying to do:
> madwolf>
> madwolf> ASN1_SEQUENCE(TEST);
> madwolf> ASN1_SEQUENCE(TBS_TEST) = {
> madwolf>     ASN1_SIMPLE(TBS_TEST, version, ASN1_INTEGER),
> madwolf>     ASN1_EXP_SEQUENCE_OF_OPT(TBS_TEST, otherTests, TEST, 0)
> madwolf> } ASN1_SEQUENCE_END(TEST)
> madwolf>
> madwolf> IMPLEMENT_ASN1_FUNCTIONS(TBS_TEST) [**]
> madwolf>
> madwolf> ASN1_SEQUENCE(TEST) = {
> madwolf>     ASN1_SIMPLE(TEST, tbsTest, ASN1_INTEGER),
> madwolf>     ASN1_EXP_OPT(TEST, optionalSignature, TEST_SIGNATURE, 0)
> madwolf> } ASN1_SEQUENCE_END(TEST)
> madwolf>
> madwolf> IMPLEMENT_ASN1_FUNCTIONS(TEST) [**]
> madwolf>
> madwolf> In this case, the difference is that TBS_TEST has, inside the
> madwolf> otherTests that are of type TEST. The TEST is built out of a tbsTest
> madwolf> and an optionalSignature - but it is defined after TBS_TEST.
> madwolf>
> madwolf> What to do in this case ?
>
> It seems to me that you need to do some kind of forward declaration of
> TEST_SIGNATURE as well, before the construction of TEST.  (also, to be
> picky, you need to make sure that ASN1_SEQUENCE(TBS_TEST) is ended
> with ASN1_SEQUENCE_END(TBS_TEST), not ASN1_SEQUENCE_END(TEST))
>
> Cheers,
> Richard
>

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

From wizard2010 at gmail.com  Mon Dec  4 08:10:39 2017
From: wizard2010 at gmail.com (wizard2010 at gmail.com)
Date: Mon, 4 Dec 2017 08:10:39 +0000
Subject: [openssl-users] SSL alert number 48
In-Reply-To: <642397e5-68c2-f2fc-3b4e-5e9c867d6b17@nikhef.nl>
References: <CAEAeT_imeOGKfyrHjPbFeDfh-fdEDpGribdUnfavyVbHV7QyjQ@mail.gmail.com>
 <e8668c3b-2bde-647a-d2e7-9d1699ceb3ac@nikhef.nl>
 <CAEAeT_ijLEdUWnyFrANbD9swHZt=ctaA06DoBFrxmnJ5+qyQew@mail.gmail.com>
 <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl>
 <CAEAeT_gR0uxN3fGgZKo3J7NuGPY-5zW_nD7qquhMAykinrnJLg@mail.gmail.com>
 <642397e5-68c2-f2fc-3b4e-5e9c867d6b17@nikhef.nl>
Message-ID: <CAEAeT_i0wHff-=hyS5BsSyAY-0hwN+0cXzDzSz2R1PemShf=4Q@mail.gmail.com>

Hi ,

Please see in attach the files that I'm using.
I generate the certificates with the following commands:


   1. ## Create CA
   2. openssl genrsa -out ca.key 4096
   3. openssl req -new -x509 -days 365 -key ca.key -out ca.crt
   4. openssl x509 -in ca.crt -out ca.pem -outform PEM
   5.


   1. ## Create the Server Key and CSR
   2. openssl genrsa -out server.key 4096
   3. openssl req -new -key server.key -out server.csr
   4. openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key
   -set_serial 01 -out server.crt
   5. openssl x509 -in server.crt -out server.pem -outform PEM
   6.


   1. ## Create the Client Key and CSR
   2. openssl genrsa -out client.key 4096
   3. openssl req -new -key client.key -out client.csr
   4. openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key
   -set_serial 01 -out client.crt
   5. openssl x509 -in client.crt -out client.pem -outform PEM


I left the default value of each question that openssl ask when it's
creating the certificates like Country, City, CN, etc. Like this way:

openssl req -new -key server.key -out server.csr

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:

State or Province Name (full name) [Some-State]:

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:

Email Address []:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:


Thanks.
Kind regards.


On Thu, Nov 30, 2017 at 2:45 PM, Jan Just Keijser <janjust at nikhef.nl> wrote:

> Hi,
>
> On 29/11/17 14:37, wizard2010 at gmail.com wrote:
>
> Hi JJK,
>
> I test you function and I've got this result:
>
>> ok = 0
>> cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
>> ok = 1
>> cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
>
>
> Why I see this 2 time?
> When I create the certificates I didn't fill with any special information,
> just type enter in every question that is made. Did you think this could
> cause this issue?
>
>
> what you should have seen is the certificate stack, starting with the CA,
> and then the client cert, e.g.
>
> Connection accept...
> ok = 1
> cert DN: /C=US/O=Cookbook 2.4/CN=Cookbook 2.4 CA/emailAddress=openvpn@
> example.com
> ok = 1
> cert DN: /C=US/O=Cookbook 2.4/CN=client1
>
>
> so I suspect that your ca.crt on the server side is not specified
> correctly.
> You may also send me your ca.crt, server.{crt,key} and client.{crt,key}
> files privately, and I will run the same test using your set of
> certificates.
>
> HTH,
>
> JJK
>
>
>
>
> On Wed, Nov 29, 2017 at 8:56 AM, Jan Just Keijser <janjust at nikhef.nl>
> wrote:
>
>> Hi,
>>
>> On 28/11/17 11:03, wizard2010 at gmail.com wrote:
>>
>> Hi there.
>>
>> I guess my problem is really related to verify callback
>> on SSL_CTX_set_verify function.
>> I just add to my code a dummy callback returning 1 and everything works
>> properly.
>>
>>
>>> int verify_callback (int ok, X509_STORE_CTX *ctx);
>>> int verify_callback (int ok, X509_STORE_CTX *ctx)
>>> {
>>>     printf("Verification callback OK!\n");
>>>     return 1;
>>> }
>>> ...
>>> SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER |
>>> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback);
>>> ...
>>
>>
>> The problem is that error don't tell much information about what's really
>> going on or what's really missing.
>> Thanks for your help.
>>
>> Now you've effectively disabled all security :)
>>
>> Try adding this to the verify_callback
>>
>>
>> static int verify_callback(int ok, X509_STORE_CTX *ctx)
>> {
>>     X509           *cert = NULL;
>>     char           *cert_DN = NULL;
>>
>>     printf("ok = %d\n", ok);
>>     cert    = X509_STORE_CTX_get_current_cert(ctx);
>>     cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0
>> );
>>     printf( "cert DN: %s\n", cert_DN);
>>
>> }
>>
>>
>> that way, you will know whether your server is processing the right
>> certificate chain.
>>
>> HTH,
>>
>> JJK
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ca.crt
Type: application/pkix-cert
Size: 1919 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0008.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ca.key
Type: application/x-iwork-keynote-sffkey
Size: 3243 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0009.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ca.pem
Type: application/x-x509-ca-cert
Size: 1919 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0003.crt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.crt
Type: application/pkix-cert
Size: 1793 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0010.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.csr
Type: application/pkcs10
Size: 1651 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0011.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.key
Type: application/x-iwork-keynote-sffkey
Size: 3247 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0012.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.pem
Type: application/x-x509-ca-cert
Size: 1793 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0004.crt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.crt
Type: application/pkix-cert
Size: 1793 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0013.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.csr
Type: application/pkcs10
Size: 1651 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0014.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.key
Type: application/x-iwork-keynote-sffkey
Size: 3243 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0015.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.pem
Type: application/x-x509-ca-cert
Size: 1793 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/2141d286/attachment-0005.crt>

From levitte at openssl.org  Mon Dec  4 08:46:26 2017
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 04 Dec 2017 09:46:26 +0100 (CET)
Subject: [openssl-users] ASN1 & Recursive Structures definition
In-Reply-To: <0089b413-278e-34b1-32b3-2e71b48e5540@openca.org>
References: <d1eeba62-f25f-c984-dc77-94a150cf73c1@openca.org>
 <20171202.125408.1222423086056733693.levitte@openssl.org>
 <0089b413-278e-34b1-32b3-2e71b48e5540@openca.org>
Message-ID: <20171204.094626.490860663034305783.levitte@openssl.org>

Ah, sorry then, I may have been wrong.  The forward declaration that's
actually needed seems to be this (one for each applicable type):

    DECLARE_ASN1_ITEM(TEST)

(I'm digging through the ASN.1 stuff myself, slowly learning)

Cheers,
Richard

In message <0089b413-278e-34b1-32b3-2e71b48e5540 at openca.org> on Sun, 3 Dec 2017 11:37:56 -0700, "Dr. Pala" <madwolf at openca.org> said:

madwolf> Hi Richard, all,
madwolf> 
madwolf> I tried to do the forward declaration also for the TEST_SIGNATURE together with the TEST one, but
madwolf> that did not really work :( It is still complaining about the use of 'sizeof' on an incomplete type. In
madwolf> particular, the two errors are:
madwolf> 
madwolf>  src/ocspv2/****: error: use of undeclared identifier 'TEST_it'
madwolf>  ASN1_EXP_SEQUENCE_OF_OPT(TEST_TBS, otherTests, TEST, 5),
madwolf>  ^
madwolf> 
madwolf>  and
madwolf> 
madwolf>  src/ocspv2/****: error: invalid application of 'sizeof' to an incomplete type 'const
madwolf>  ASN1_TEMPLATE []'
madwolf>  } ASN1_SEQUENCE_END(TEST_TBS)
madwolf>  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
madwolf> 
madwolf> I guess I need to checkout the macros a bit more.. :D
madwolf> 
madwolf> Question: does anybody know if there is any other structure already implemented in OpenSSL that
madwolf> resembles the one I am trying to do here? I tried to look for something similar, but no success.. :D
madwolf> 
madwolf> If there is no easy answer, I guess I will have to either change the envisioned approach (maybe
madwolf> introducing an intermediate data structure of some kind..?) or use the ASN1_ANY approach.
madwolf> 
madwolf> Cheers,
madwolf> Max
madwolf> 
madwolf> On 12/2/17 4:54 AM, Richard Levitte wrote:
madwolf> 
madwolf>  In message <d1eeba62-f25f-c984-dc77-94a150cf73c1 at openca.org> on Fri, 1 Dec 2017 20:22:09 -0700,
madwolf>  "Dr. Pala" <madwolf at openca.org> said:
madwolf> 
madwolf> madwolf> Hi Richard,
madwolf> madwolf>
madwolf> madwolf> thanks :D That worked. I have a new challenge for you now. Here's what
madwolf> madwolf> I am trying to do:
madwolf> madwolf>
madwolf> madwolf> ASN1_SEQUENCE(TEST);
madwolf> madwolf> ASN1_SEQUENCE(TBS_TEST) = {
madwolf> madwolf>     ASN1_SIMPLE(TBS_TEST, version, ASN1_INTEGER),
madwolf> madwolf>     ASN1_EXP_SEQUENCE_OF_OPT(TBS_TEST, otherTests, TEST, 0)
madwolf> madwolf> } ASN1_SEQUENCE_END(TEST)
madwolf> madwolf>
madwolf> madwolf> IMPLEMENT_ASN1_FUNCTIONS(TBS_TEST) [**]
madwolf> madwolf>
madwolf> madwolf> ASN1_SEQUENCE(TEST) = {
madwolf> madwolf>     ASN1_SIMPLE(TEST, tbsTest, ASN1_INTEGER),
madwolf> madwolf>     ASN1_EXP_OPT(TEST, optionalSignature, TEST_SIGNATURE, 0)
madwolf> madwolf> } ASN1_SEQUENCE_END(TEST)
madwolf> madwolf>
madwolf> madwolf> IMPLEMENT_ASN1_FUNCTIONS(TEST) [**]
madwolf> madwolf>
madwolf> madwolf> In this case, the difference is that TBS_TEST has, inside the
madwolf> madwolf> otherTests that are of type TEST. The TEST is built out of a tbsTest
madwolf> madwolf> and an optionalSignature - but it is defined after TBS_TEST.
madwolf> madwolf>
madwolf> madwolf> What to do in this case ?
madwolf> 
madwolf> It seems to me that you need to do some kind of forward declaration of
madwolf> TEST_SIGNATURE as well, before the construction of TEST.  (also, to be
madwolf> picky, you need to make sure that ASN1_SEQUENCE(TBS_TEST) is ended
madwolf> with ASN1_SEQUENCE_END(TBS_TEST), not ASN1_SEQUENCE_END(TEST))
madwolf> 
madwolf> Cheers,
madwolf> Richard
madwolf> 

From aerowolf at gmail.com  Mon Dec  4 10:27:51 2017
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Mon, 4 Dec 2017 02:27:51 -0800
Subject: [openssl-users] SSL alert number 48
In-Reply-To: <CAEAeT_i0wHff-=hyS5BsSyAY-0hwN+0cXzDzSz2R1PemShf=4Q@mail.gmail.com>
References: <CAEAeT_imeOGKfyrHjPbFeDfh-fdEDpGribdUnfavyVbHV7QyjQ@mail.gmail.com>
 <e8668c3b-2bde-647a-d2e7-9d1699ceb3ac@nikhef.nl>
 <CAEAeT_ijLEdUWnyFrANbD9swHZt=ctaA06DoBFrxmnJ5+qyQew@mail.gmail.com>
 <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl>
 <CAEAeT_gR0uxN3fGgZKo3J7NuGPY-5zW_nD7qquhMAykinrnJLg@mail.gmail.com>
 <642397e5-68c2-f2fc-3b4e-5e9c867d6b17@nikhef.nl>
 <CAEAeT_i0wHff-=hyS5BsSyAY-0hwN+0cXzDzSz2R1PemShf=4Q@mail.gmail.com>
Message-ID: <CAPMEXDbdp2iuvi7Ee83DKZVOd-8WS9ABBAx9WN7mMDE6BnKMJQ@mail.gmail.com>

SSL alert number 48 is specified in the documents that define SSL/TLS.
It is the code for "unknown_ca", which means that verification failed
because it didn't get set up with the correct CA to verify against.
You might wish to look up SSL_CTX_load_verify_locations(3).  There may
also be other API calls which can load the context with certificates
to verify against.

You can get a list of the alert numbers from RFC 5246, available from
(among other places) https://www.ietf.org/rfc/rfc5246.txt (also
available as a PDF from https://www.ietf.org/rfc/rfc5246.txt.pdf).

-Kyle H

On Mon, Dec 4, 2017 at 12:10 AM,  <wizard2010 at gmail.com> wrote:
> Hi ,
>
> Please see in attach the files that I'm using.
> I generate the certificates with the following commands:
>
> ## Create CA
> openssl genrsa -out ca.key 4096
> openssl req -new -x509 -days 365 -key ca.key -out ca.crt
> openssl x509 -in ca.crt -out ca.pem -outform PEM
>
> ## Create the Server Key and CSR
> openssl genrsa -out server.key 4096
> openssl req -new -key server.key -out server.csr
> openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key
> -set_serial 01 -out server.crt
> openssl x509 -in server.crt -out server.pem -outform PEM
>
> ## Create the Client Key and CSR
> openssl genrsa -out client.key 4096
> openssl req -new -key client.key -out client.csr
> openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key
> -set_serial 01 -out client.crt
> openssl x509 -in client.crt -out client.pem -outform PEM
>
>
> I left the default value of each question that openssl ask when it's
> creating the certificates like Country, City, CN, etc. Like this way:
>>
>> openssl req -new -key server.key -out server.csr
>>
>> You are about to be asked to enter information that will be incorporated
>>
>> into your certificate request.
>>
>> What you are about to enter is what is called a Distinguished Name or a
>> DN.
>>
>> There are quite a few fields but you can leave some blank
>>
>> For some fields there will be a default value,
>>
>> If you enter '.', the field will be left blank.
>>
>> -----
>>
>> Country Name (2 letter code) [AU]:
>>
>> State or Province Name (full name) [Some-State]:
>>
>> Locality Name (eg, city) []:
>>
>> Organization Name (eg, company) [Internet Widgits Pty Ltd]:
>>
>> Organizational Unit Name (eg, section) []:
>>
>> Common Name (e.g. server FQDN or YOUR name) []:
>>
>> Email Address []:
>>
>> Please enter the following 'extra' attributes
>>
>> to be sent with your certificate request
>>
>> A challenge password []:
>>
>> An optional company name []:
>
>
> Thanks.
> Kind regards.
>
>
> On Thu, Nov 30, 2017 at 2:45 PM, Jan Just Keijser <janjust at nikhef.nl> wrote:
>>
>> Hi,
>>
>> On 29/11/17 14:37, wizard2010 at gmail.com wrote:
>>
>> Hi JJK,
>>
>> I test you function and I've got this result:
>>>
>>> ok = 0
>>> cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
>>> ok = 1
>>> cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
>>
>>
>> Why I see this 2 time?
>> When I create the certificates I didn't fill with any special information,
>> just type enter in every question that is made. Did you think this could
>> cause this issue?
>>
>>
>> what you should have seen is the certificate stack, starting with the CA,
>> and then the client cert, e.g.
>>
>> Connection accept...
>> ok = 1
>> cert DN: /C=US/O=Cookbook 2.4/CN=Cookbook 2.4
>> CA/emailAddress=openvpn at example.com
>> ok = 1
>> cert DN: /C=US/O=Cookbook 2.4/CN=client1
>>
>>
>> so I suspect that your ca.crt on the server side is not specified
>> correctly.
>> You may also send me your ca.crt, server.{crt,key} and client.{crt,key}
>> files privately, and I will run the same test using your set of
>> certificates.
>>
>> HTH,
>>
>> JJK
>>
>>
>>
>>
>> On Wed, Nov 29, 2017 at 8:56 AM, Jan Just Keijser <janjust at nikhef.nl>
>> wrote:
>>>
>>> Hi,
>>>
>>> On 28/11/17 11:03, wizard2010 at gmail.com wrote:
>>>
>>> Hi there.
>>>
>>> I guess my problem is really related to verify callback on
>>> SSL_CTX_set_verify function.
>>> I just add to my code a dummy callback returning 1 and everything works
>>> properly.
>>>
>>>>
>>>> int verify_callback (int ok, X509_STORE_CTX *ctx);
>>>> int verify_callback (int ok, X509_STORE_CTX *ctx)
>>>> {
>>>>     printf("Verification callback OK!\n");
>>>>     return 1;
>>>> }
>>>> ...
>>>> SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER |
>>>> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback);
>>>> ...
>>>
>>>
>>> The problem is that error don't tell much information about what's really
>>> going on or what's really missing.
>>> Thanks for your help.
>>>
>>> Now you've effectively disabled all security :)
>>>
>>> Try adding this to the verify_callback
>>>
>>>
>>> static int verify_callback(int ok, X509_STORE_CTX *ctx)
>>> {
>>>     X509           *cert = NULL;
>>>     char           *cert_DN = NULL;
>>>
>>>     printf("ok = %d\n", ok);
>>>     cert    = X509_STORE_CTX_get_current_cert(ctx);
>>>     cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0
>>> );
>>>     printf( "cert DN: %s\n", cert_DN);
>>>
>>> }
>>>
>>>
>>> that way, you will know whether your server is processing the right
>>> certificate chain.
>>>
>>> HTH,
>>>
>>> JJK
>>>
>>
>>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

From wizard2010 at gmail.com  Mon Dec  4 10:51:48 2017
From: wizard2010 at gmail.com (wizard2010 at gmail.com)
Date: Mon, 4 Dec 2017 10:51:48 +0000
Subject: [openssl-users] SSL alert number 48
In-Reply-To: <CAPMEXDbdp2iuvi7Ee83DKZVOd-8WS9ABBAx9WN7mMDE6BnKMJQ@mail.gmail.com>
References: <CAEAeT_imeOGKfyrHjPbFeDfh-fdEDpGribdUnfavyVbHV7QyjQ@mail.gmail.com>
 <e8668c3b-2bde-647a-d2e7-9d1699ceb3ac@nikhef.nl>
 <CAEAeT_ijLEdUWnyFrANbD9swHZt=ctaA06DoBFrxmnJ5+qyQew@mail.gmail.com>
 <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl>
 <CAEAeT_gR0uxN3fGgZKo3J7NuGPY-5zW_nD7qquhMAykinrnJLg@mail.gmail.com>
 <642397e5-68c2-f2fc-3b4e-5e9c867d6b17@nikhef.nl>
 <CAEAeT_i0wHff-=hyS5BsSyAY-0hwN+0cXzDzSz2R1PemShf=4Q@mail.gmail.com>
 <CAPMEXDbdp2iuvi7Ee83DKZVOd-8WS9ABBAx9WN7mMDE6BnKMJQ@mail.gmail.com>
Message-ID: <CAEAeT_iGVqxWoOSJozhD6Emf=8xa-Mqiat9wcCmT3cVOpr=iEg@mail.gmail.com>

On Mon, Dec 4, 2017 at 10:27 AM, Kyle Hamilton <aerowolf at gmail.com> wrote:

> SSL alert number 48 is specified in the documents that define SSL/TLS.
> It is the code for "unknown_ca", which means that verification failed
> because it didn't get set up with the correct CA to verify against.
> You might wish to look up SSL_CTX_load_verify_locations(3).  There may
> also be other API calls which can load the context with certificates
> to verify against.
>

Ok I understand that, but what could be wrong with the certificates that I
generate with the commands that I told in the previous message?

Kind regards.


>
> You can get a list of the alert numbers from RFC 5246, available from
> (among other places) https://www.ietf.org/rfc/rfc5246.txt (also
> available as a PDF from https://www.ietf.org/rfc/rfc5246.txt.pdf).
>
> -Kyle H
>
> On Mon, Dec 4, 2017 at 12:10 AM,  <wizard2010 at gmail.com> wrote:
> > Hi ,
> >
> > Please see in attach the files that I'm using.
> > I generate the certificates with the following commands:
> >
> > ## Create CA
> > openssl genrsa -out ca.key 4096
> > openssl req -new -x509 -days 365 -key ca.key -out ca.crt
> > openssl x509 -in ca.crt -out ca.pem -outform PEM
> >
> > ## Create the Server Key and CSR
> > openssl genrsa -out server.key 4096
> > openssl req -new -key server.key -out server.csr
> > openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key
> > -set_serial 01 -out server.crt
> > openssl x509 -in server.crt -out server.pem -outform PEM
> >
> > ## Create the Client Key and CSR
> > openssl genrsa -out client.key 4096
> > openssl req -new -key client.key -out client.csr
> > openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key
> > -set_serial 01 -out client.crt
> > openssl x509 -in client.crt -out client.pem -outform PEM
> >
> >
> > I left the default value of each question that openssl ask when it's
> > creating the certificates like Country, City, CN, etc. Like this way:
> >>
> >> openssl req -new -key server.key -out server.csr
> >>
> >> You are about to be asked to enter information that will be incorporated
> >>
> >> into your certificate request.
> >>
> >> What you are about to enter is what is called a Distinguished Name or a
> >> DN.
> >>
> >> There are quite a few fields but you can leave some blank
> >>
> >> For some fields there will be a default value,
> >>
> >> If you enter '.', the field will be left blank.
> >>
> >> -----
> >>
> >> Country Name (2 letter code) [AU]:
> >>
> >> State or Province Name (full name) [Some-State]:
> >>
> >> Locality Name (eg, city) []:
> >>
> >> Organization Name (eg, company) [Internet Widgits Pty Ltd]:
> >>
> >> Organizational Unit Name (eg, section) []:
> >>
> >> Common Name (e.g. server FQDN or YOUR name) []:
> >>
> >> Email Address []:
> >>
> >> Please enter the following 'extra' attributes
> >>
> >> to be sent with your certificate request
> >>
> >> A challenge password []:
> >>
> >> An optional company name []:
> >
> >
> > Thanks.
> > Kind regards.
> >
> >
> > On Thu, Nov 30, 2017 at 2:45 PM, Jan Just Keijser <janjust at nikhef.nl>
> wrote:
> >>
> >> Hi,
> >>
> >> On 29/11/17 14:37, wizard2010 at gmail.com wrote:
> >>
> >> Hi JJK,
> >>
> >> I test you function and I've got this result:
> >>>
> >>> ok = 0
> >>> cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
> >>> ok = 1
> >>> cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
> >>
> >>
> >> Why I see this 2 time?
> >> When I create the certificates I didn't fill with any special
> information,
> >> just type enter in every question that is made. Did you think this could
> >> cause this issue?
> >>
> >>
> >> what you should have seen is the certificate stack, starting with the
> CA,
> >> and then the client cert, e.g.
> >>
> >> Connection accept...
> >> ok = 1
> >> cert DN: /C=US/O=Cookbook 2.4/CN=Cookbook 2.4
> >> CA/emailAddress=openvpn at example.com
> >> ok = 1
> >> cert DN: /C=US/O=Cookbook 2.4/CN=client1
> >>
> >>
> >> so I suspect that your ca.crt on the server side is not specified
> >> correctly.
> >> You may also send me your ca.crt, server.{crt,key} and client.{crt,key}
> >> files privately, and I will run the same test using your set of
> >> certificates.
> >>
> >> HTH,
> >>
> >> JJK
> >>
> >>
> >>
> >>
> >> On Wed, Nov 29, 2017 at 8:56 AM, Jan Just Keijser <janjust at nikhef.nl>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On 28/11/17 11:03, wizard2010 at gmail.com wrote:
> >>>
> >>> Hi there.
> >>>
> >>> I guess my problem is really related to verify callback on
> >>> SSL_CTX_set_verify function.
> >>> I just add to my code a dummy callback returning 1 and everything works
> >>> properly.
> >>>
> >>>>
> >>>> int verify_callback (int ok, X509_STORE_CTX *ctx);
> >>>> int verify_callback (int ok, X509_STORE_CTX *ctx)
> >>>> {
> >>>>     printf("Verification callback OK!\n");
> >>>>     return 1;
> >>>> }
> >>>> ...
> >>>> SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER |
> >>>> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback);
> >>>> ...
> >>>
> >>>
> >>> The problem is that error don't tell much information about what's
> really
> >>> going on or what's really missing.
> >>> Thanks for your help.
> >>>
> >>> Now you've effectively disabled all security :)
> >>>
> >>> Try adding this to the verify_callback
> >>>
> >>>
> >>> static int verify_callback(int ok, X509_STORE_CTX *ctx)
> >>> {
> >>>     X509           *cert = NULL;
> >>>     char           *cert_DN = NULL;
> >>>
> >>>     printf("ok = %d\n", ok);
> >>>     cert    = X509_STORE_CTX_get_current_cert(ctx);
> >>>     cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0
> >>> );
> >>>     printf( "cert DN: %s\n", cert_DN);
> >>>
> >>> }
> >>>
> >>>
> >>> that way, you will know whether your server is processing the right
> >>> certificate chain.
> >>>
> >>> HTH,
> >>>
> >>> JJK
> >>>
> >>
> >>
> >
> >
> > --
> > 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/20171204/a99abff3/attachment-0001.html>

From Michael.Wojcik at microfocus.com  Mon Dec  4 13:38:43 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Mon, 4 Dec 2017 13:38:43 +0000
Subject: [openssl-users] FIPS certification for openssl
In-Reply-To: <A493B9C1-1ED2-4B0B-B1D0-D242D59DE120@akamai.com>
References: <OF225AF5ED.252E8848-ON002581E7.00443BD9-652581E7.0044AE6A@notes.na.collabserv.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADD93A@prvxmb03.microfocus.com>
 <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com>
 <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com>
 <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net>
 <0D2E376C-E755-4105-B282-87F19F496092@akamai.com>
 <bb456b58-f0ac-662d-5327-a922e633858d@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9ADF474@prvxmb03.microfocus.com>
 <f8ef6644-7805-9122-6775-ab5a54a9cba7@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D84@prvxmb03.microfocus.com>
 <c16f8787-027a-d7e2-3d5c-4236855818c9@jordan.maileater.net>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com>
 <A493B9C1-1ED2-4B0B-B1D0-D242D59DE120@akamai.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE18A1@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Salz, Rich via openssl-users
> Sent: Saturday, December 02, 2017 11:42
> 
> >    My personal priority list for OpenSSL is bug fixes and code cleanup (static
> > and dynamic analysis of the 1.1.x codebase would be good, and one of these
> > days I'll get around to doing it myself),
> 
> We do run coverity weekly, and anyone can sign up to see the results BTW

Oh, that's right. I knew that at one time (probably when it was announced), but I forgot.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 



From matt at openssl.org  Mon Dec  4 16:15:38 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 4 Dec 2017 16:15:38 +0000
Subject: [openssl-users] Forthcoming OpenSSL release
Message-ID: <d6807e49-5212-5517-e0e5-c6519cdce478@openssl.org>

Forthcoming OpenSSL release
===========================

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 1.0.2n. There will be no OpenSSL 1.1.0 release at
this time.

This release will be made available on 7th December 2017 between
approximately 1300-1700 UTC.

This is a security-fix release. The highest severity issue fixed in this
release is MODERATE.

Please also note that, as per our previous announcements, support for
1.0.1 ended on 31st December 2016.

Yours

The OpenSSL Project Team

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

From digant.kubavat at gmail.com  Tue Dec  5 04:54:14 2017
From: digant.kubavat at gmail.com (Devang Kubavat)
Date: Tue, 5 Dec 2017 10:24:14 +0530
Subject: [openssl-users] SSL Handshake with TPM using TPM Engine
Message-ID: <CAAtuADdmR89aW-T=GZTfcwBcHXeTz-yqPwbgscqxjsydKF=zwQ@mail.gmail.com>

Hi All,



*SSL handshake with TPM using TPM Engine: *I am generating the RSA keys in
TPM and private key will never come out from TPM

I want to do SSL handshake with this scenario.
Can you please point out me in SSL handshake which functions are using the
RSA private key? So that, I can register those functions in TPM Engine to
perform RSA private key related operation.

Is there any reference implementation for SSL handshake using TPM via TPM
Engine?

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

From bhat.jayalakshmi at gmail.com  Wed Dec  6 06:02:12 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Tue, 5 Dec 2017 23:02:12 -0700
Subject: [openssl-users] A question DH parameter generation and usage
Message-ID: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>

Hi,

We are planning to use DHE_RSA TLS ciphers into our product. I have few
questions on using DH parameter. We would like to use DH-2048.

our product includes both TLS client and server applications. Thus any time
there will be considerable number of active connectioons.

I believe we can use same DH parameter for all the server connections. Is
my understanding correct? Is there any risk in using same parameter for all
the server connections.

Another question is what is guidelines/document should be followed to
derive DH parameter.

Any input is appreciated.

Thanks and Regards
Jayalakshmi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171205/d0b6e9ec/attachment.html>

From bhat.jayalakshmi at gmail.com  Wed Dec  6 06:06:59 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Tue, 5 Dec 2017 23:06:59 -0700
Subject: [openssl-users] ECC ciphers in OpenSSL and Citricom Patent/License
	terms
Message-ID: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>

Hi,

I have a question on ECC ciphers implementaion in OpenSSL. I do see
README.ECC file in FIPS certfied OpenSSL crypto library. That says  The
OpenSSL Software Foundation has executed a sublicense agreement
entitled "Elliptic Curve Cryptography Patent License Agreement" with the
National Security Agency/ Central Security Service Commercial Solutions
Center (NCSC) dated 2010-11-04.

However OpenSSL library does not include this file. Does it mean to use ECC
ciphers from OpenSSL does the end user needs to get the license from
Citricom?

Thanks and Regards
Jayalakshmi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171205/f6e5c4e8/attachment.html>

From paulyang.inf at gmail.com  Wed Dec  6 07:13:09 2017
From: paulyang.inf at gmail.com (Paul Yang)
Date: Wed, 6 Dec 2017 15:13:09 +0800
Subject: [openssl-users] [openssl-dev] A question DH parameter
	generation and usage
In-Reply-To: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
Message-ID: <C182BB4E-CB93-4A78-A659-49D5A9C9DA72@gmail.com>

For DHE_RSA, you first need a pair of RSA certificate/key for signing. And you if want to use specific DH parameters, you can use the SSL_CTX_set_tmp_dh API, there is documentation describing how to use this function.

DH parameter could be generated by OpenSSL in many ways, one of the common way is by using the openssl-dhparam command line tool. Check the -help option of that command.

BTW: seems this email should be sent to openssl-users list only...

> On 6 Dec 2017, at 14:02, Jayalakshmi bhat <bhat.jayalakshmi at gmail.com> wrote:
> 
> Hi,
> 
> We are planning to use DHE_RSA TLS ciphers into our product. I have few questions on using DH parameter. We would like to use DH-2048.
> 
> our product includes both TLS client and server applications. Thus any time there will be considerable number of active connectioons.
> 
> I believe we can use same DH parameter for all the server connections. Is my understanding correct? Is there any risk in using same parameter for all the server connections.
> 
> Another question is what is guidelines/document should be followed to derive DH parameter.
> 
> Any input is appreciated.
> 
> Thanks and Regards
> Jayalakshmi.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171206/9025c5ce/attachment.sig>

From jb-openssl at wisemo.com  Wed Dec  6 07:48:26 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 6 Dec 2017 08:48:26 +0100
Subject: [openssl-users] A question DH parameter generation and usage
In-Reply-To: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
Message-ID: <98536b7d-4006-188c-85b0-53014e0d3340@wisemo.com>

On 06/12/2017 07:02, Jayalakshmi bhat wrote:
> Hi,
>
> We are planning to use DHE_RSA TLS ciphers into our product. I have 
> few questions on using DH parameter. We would like to use DH-2048.
>
> our product includes both TLS client and server applications. Thus any 
> time there will be considerable number of active connectioons.
>
> I believe we can use same DH parameter for all the server connections. 
> Is my understanding correct? Is there any risk in using same parameter 
> for all the server connections.
>
> Another question is what is guidelines/document should be followed to 
> derive DH parameter.
>
> Any input is appreciated.
>
>
In TLS and SSL 3 (current versions, not sure about GoogleTLS 1.3),
DHE parameters are chosen exclusively by the server, so most rules
will be about servers.

Current best practice on clients is to reject parameters of less
than 1000 bits, parameters with fewer bits than they pretend (e.g.
parameters claiming to be 1024 bits, but the most significant 32
bits are all 0, making them really less than 993 bits), parameters
that are glaringly non-prime (e.g. even numbers) and parameters
that cause the DHE calculation to result in an unreasonably number
such as 1 (indicating rigged parameters).? I hope that OpenSSL
client code already does such checks by default, otherwise someone
should point out how to make it do so.

Current best practice on servers is to use DHE parameters such as
those generated by openssl dhparam, or the equivalent API function.

Current best practice on general purpose servers is to use at least
2048 bit DH parameters except when talking to clients that can't do
that, such as the TLS code in Oracle Java 6.? Going above 2048 bits
is good, but some common clients don't work significantly above
that number (for example, some versions of the Mozilla NSS code
have a built in maximum of 2236 bits).

Current best practice on servers is to use DHE parameters that are
used by few other servers, at least in a given timespan.? Thus for
servers that will be deployed in small numbers, just generate your
own parameters at build time using
 ?? openssl dhparam -C xxxx > dhxxxx.inc
then include dhxxxx.inc in your source code.? For servers that will
be deployed in large numbers, load the dh parameters from files in
the format generated by
 ? openssl dhparam xxxx > dhxxxx.pem
and include scripts or other code that will replace the file
contents daily or weekly (overwriting the old parameters only after
the new ones are ready).? The exim mail server does this if you
follow the instructions.

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 googleersatz at oliverniebuhr.de  Wed Dec  6 08:24:20 2017
From: googleersatz at oliverniebuhr.de (Oliver Niebuhr)
Date: Wed, 6 Dec 2017 09:24:20 +0100
Subject: [openssl-users] VS2017 15.5 hangs indefinitely with Blake2b.c
Message-ID: <7981b2e4-2bd4-8e60-e50c-bb39681525ff@oliverniebuhr.de>

Hello.

I am not sure if it is a VS Compiler Bug or a Bug in OpenSSL.

When the Compiler reaches 'Blake2b.c', it creates the 'Blake2b.obj' and
then hangs indefinitely.

CPU usage for CL stays at 27-28 Percent. Used RAM stays at 34-35 Megabyte.

OpenSSL Version: 1.1.0 Git up2date, Static and Dynamic build
Windows: Windows 10, X64, FCU, up2date
Windows 10 SDK: 16299
VS Compiler Version: 14.11 and 14.12, running from VS native CMD Line
NASM: 2.13.02 (also happens without NASM)
Perl Version: Strawberry Perl 5.26.1.1
Perl Configure:
no-comp no-rc5 no-idea no-mdc2 no-tls1 no-tls1-method no-tls1_1
no-tls1_1-method no-dtls no-dtls1-method no-dtls1_2 no-dtls1_2-method
no-deprecated no-weak-ssl-ciphers VC-WIN64A
--prefix=%SystemDrive%\openssl11x64\
--openssldir=%SystemDrive%\openssl11x64\ && nmake

When I add 'no-blake2' OpenSSL compiles fine.

Does anyone else have this Issue? Last build I did was at 23rd November
and then today. So I am not sure which commit (if at all??) probably
introduces this Problem.

BTW: Unrelated to this: Since 2 or 3 Months, the Fuzz Test always ends
with "Error: wstat10 (2560, 0x0)" (Sorry dont remember the full Error -
compiling something else right now). All other Tests are ok. Can I keep
ignoring this or should I create a BR on Github?

Thanks!
Oliver

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

From bhat.jayalakshmi at gmail.com  Wed Dec  6 10:57:19 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Wed, 6 Dec 2017 03:57:19 -0700
Subject: [openssl-users] A question DH parameter generation and usage
In-Reply-To: <98536b7d-4006-188c-85b0-53014e0d3340@wisemo.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
 <98536b7d-4006-188c-85b0-53014e0d3340@wisemo.com>
Message-ID: <CALq8Rv+HS9A7qYvf+1ac_p_LrVWiotFT4dPz+BjUhDnjYDTO7A@mail.gmail.com>

Hi Jakob and Paul,

Thank you so much for the reply. We have the RSA certificates. I wanted to
understand how generally DH parameters are generated. Thanks for the
detailed answers.

Regards
Jayalakshmi

On Wed, Dec 6, 2017 at 12:48 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:

> On 06/12/2017 07:02, Jayalakshmi bhat wrote:
>
>> Hi,
>>
>> We are planning to use DHE_RSA TLS ciphers into our product. I have few
>> questions on using DH parameter. We would like to use DH-2048.
>>
>> our product includes both TLS client and server applications. Thus any
>> time there will be considerable number of active connectioons.
>>
>> I believe we can use same DH parameter for all the server connections. Is
>> my understanding correct? Is there any risk in using same parameter for all
>> the server connections.
>>
>> Another question is what is guidelines/document should be followed to
>> derive DH parameter.
>>
>> Any input is appreciated.
>>
>>
>> In TLS and SSL 3 (current versions, not sure about GoogleTLS 1.3),
> DHE parameters are chosen exclusively by the server, so most rules
> will be about servers.
>
> Current best practice on clients is to reject parameters of less
> than 1000 bits, parameters with fewer bits than they pretend (e.g.
> parameters claiming to be 1024 bits, but the most significant 32
> bits are all 0, making them really less than 993 bits), parameters
> that are glaringly non-prime (e.g. even numbers) and parameters
> that cause the DHE calculation to result in an unreasonably number
> such as 1 (indicating rigged parameters).  I hope that OpenSSL
> client code already does such checks by default, otherwise someone
> should point out how to make it do so.
>
> Current best practice on servers is to use DHE parameters such as
> those generated by openssl dhparam, or the equivalent API function.
>
> Current best practice on general purpose servers is to use at least
> 2048 bit DH parameters except when talking to clients that can't do
> that, such as the TLS code in Oracle Java 6.  Going above 2048 bits
> is good, but some common clients don't work significantly above
> that number (for example, some versions of the Mozilla NSS code
> have a built in maximum of 2236 bits).
>
> Current best practice on servers is to use DHE parameters that are
> used by few other servers, at least in a given timespan.  Thus for
> servers that will be deployed in small numbers, just generate your
> own parameters at build time using
>    openssl dhparam -C xxxx > dhxxxx.inc
> then include dhxxxx.inc in your source code.  For servers that will
> be deployed in large numbers, load the dh parameters from files in
> the format generated by
>   openssl dhparam xxxx > dhxxxx.pem
> and include scripts or other code that will replace the file
> contents daily or weekly (overwriting the old parameters only after
> the new ones are ready).  The exim mail server does this if you
> follow the instructions.
>
> 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
>
> --
> 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/20171206/f9890e9b/attachment.html>

From matt at openssl.org  Wed Dec  6 12:06:17 2017
From: matt at openssl.org (Matt Caswell)
Date: Wed, 6 Dec 2017 12:06:17 +0000
Subject: [openssl-users] VS2017 15.5 hangs indefinitely with Blake2b.c
In-Reply-To: <7981b2e4-2bd4-8e60-e50c-bb39681525ff@oliverniebuhr.de>
References: <7981b2e4-2bd4-8e60-e50c-bb39681525ff@oliverniebuhr.de>
Message-ID: <40fde8c3-946d-d0e2-1831-67a13ed7f265@openssl.org>



On 06/12/17 08:24, Oliver Niebuhr wrote:
> Hello.
> 
> I am not sure if it is a VS Compiler Bug or a Bug in OpenSSL.
> 
> When the Compiler reaches 'Blake2b.c', it creates the 'Blake2b.obj' and
> then hangs indefinitely.
> 
> CPU usage for CL stays at 27-28 Percent. Used RAM stays at 34-35 Megabyte.
> 
> OpenSSL Version: 1.1.0 Git up2date, Static and Dynamic build
> Windows: Windows 10, X64, FCU, up2date
> Windows 10 SDK: 16299
> VS Compiler Version: 14.11 and 14.12, running from VS native CMD Line
> NASM: 2.13.02 (also happens without NASM)
> Perl Version: Strawberry Perl 5.26.1.1
> Perl Configure:
> no-comp no-rc5 no-idea no-mdc2 no-tls1 no-tls1-method no-tls1_1
> no-tls1_1-method no-dtls no-dtls1-method no-dtls1_2 no-dtls1_2-method
> no-deprecated no-weak-ssl-ciphers VC-WIN64A
> --prefix=%SystemDrive%\openssl11x64\
> --openssldir=%SystemDrive%\openssl11x64\ && nmake
> 
> When I add 'no-blake2' OpenSSL compiles fine.
> 
> Does anyone else have this Issue? Last build I did was at 23rd November
> and then today. So I am not sure which commit (if at all??) probably
> introduces this Problem.

There haven't been any changes to that file since May. AFAICT there also
haven't been any changes to any of the header files (directly or
indirectly included) in that time period. Did you update anything on the
compiler side?

In any case a compiler hang sounds very much like a compiler bug. No
matter what we write in our code it should not cause the compiler to
hang. That said we have made changes in the past to workaround such
issues if someone is able to figure out exactly what bit of the code it
is having trouble with.


> 
> BTW: Unrelated to this: Since 2 or 3 Months, the Fuzz Test always ends
> with "Error: wstat10 (2560, 0x0)" (Sorry dont remember the full Error -
> compiling something else right now). All other Tests are ok. Can I keep
> ignoring this or should I create a BR on Github?


Please raise this as an issue in github.

Matt


From googleersatz at oliverniebuhr.de  Wed Dec  6 13:43:12 2017
From: googleersatz at oliverniebuhr.de (Oliver Niebuhr)
Date: Wed, 6 Dec 2017 14:43:12 +0100
Subject: [openssl-users] VS2017 15.5 hangs indefinitely with Blake2b.c
In-Reply-To: <40fde8c3-946d-d0e2-1831-67a13ed7f265@openssl.org>
References: <7981b2e4-2bd4-8e60-e50c-bb39681525ff@oliverniebuhr.de>
 <40fde8c3-946d-d0e2-1831-67a13ed7f265@openssl.org>
Message-ID: <978da7e1-958a-22e4-d971-6326131ce1d1@oliverniebuhr.de>

Hi.

Like mentioned below, I updated the VS 2017 Compiler to 14.12 - but it
also happens with 14.11.

Problem is: There is No Error Message of any kind - CL.exe keeps running
(well more or less) indefinitely. It simply stops working.

It really seems like a Compiler Bug. But I am too OpenSSL noobish to be
able to tell what the Problem is from my end.

I will create a BR on Github.

Thanks!
Oliver

On 06/12/2017 13:06, Matt Caswell wrote:
> 
> 
> On 06/12/17 08:24, Oliver Niebuhr wrote:
>> Hello.
>>
>> I am not sure if it is a VS Compiler Bug or a Bug in OpenSSL.
>>
>> When the Compiler reaches 'Blake2b.c', it creates the 'Blake2b.obj' and
>> then hangs indefinitely.
>>
>> CPU usage for CL stays at 27-28 Percent. Used RAM stays at 34-35 Megabyte.
>>
>> OpenSSL Version: 1.1.0 Git up2date, Static and Dynamic build
>> Windows: Windows 10, X64, FCU, up2date
>> Windows 10 SDK: 16299
>> VS Compiler Version: 14.11 and 14.12, running from VS native CMD Line
>> NASM: 2.13.02 (also happens without NASM)
>> Perl Version: Strawberry Perl 5.26.1.1
>> Perl Configure:
>> no-comp no-rc5 no-idea no-mdc2 no-tls1 no-tls1-method no-tls1_1
>> no-tls1_1-method no-dtls no-dtls1-method no-dtls1_2 no-dtls1_2-method
>> no-deprecated no-weak-ssl-ciphers VC-WIN64A
>> --prefix=%SystemDrive%\openssl11x64\
>> --openssldir=%SystemDrive%\openssl11x64\ && nmake
>>
>> When I add 'no-blake2' OpenSSL compiles fine.
>>
>> Does anyone else have this Issue? Last build I did was at 23rd November
>> and then today. So I am not sure which commit (if at all??) probably
>> introduces this Problem.
> 
> There haven't been any changes to that file since May. AFAICT there also
> haven't been any changes to any of the header files (directly or
> indirectly included) in that time period. Did you update anything on the
> compiler side?
> 
> In any case a compiler hang sounds very much like a compiler bug. No
> matter what we write in our code it should not cause the compiler to
> hang. That said we have made changes in the past to workaround such
> issues if someone is able to figure out exactly what bit of the code it
> is having trouble with.
> 
> 
>>
>> BTW: Unrelated to this: Since 2 or 3 Months, the Fuzz Test always ends
>> with "Error: wstat10 (2560, 0x0)" (Sorry dont remember the full Error -
>> compiling something else right now). All other Tests are ok. Can I keep
>> ignoring this or should I create a BR on Github?
> 
> 
> Please raise this as an issue in github.
> 
> Matt
> 

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

From rsalz at akamai.com  Wed Dec  6 13:50:07 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 6 Dec 2017 13:50:07 +0000
Subject: [openssl-users] [openssl-dev] A question DH parameter
	generation and usage
In-Reply-To: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
Message-ID: <DCCF2F22-BA18-4983-993D-355FDAD022BE@akamai.com>

You can re-use the keys, but then you get no forward secrecy, and sessions generated with one connection are vulnerable to another.

Why are you using DH?  Unless you have compelling reasons (interop with legacy), you really should use ECDHE.

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

From Michael.Wojcik at microfocus.com  Wed Dec  6 13:51:47 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 6 Dec 2017 13:51:47 +0000
Subject: [openssl-users] A question DH parameter generation and usage
In-Reply-To: <CALq8Rv+HS9A7qYvf+1ac_p_LrVWiotFT4dPz+BjUhDnjYDTO7A@mail.gmail.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
 <98536b7d-4006-188c-85b0-53014e0d3340@wisemo.com>
 <CALq8Rv+HS9A7qYvf+1ac_p_LrVWiotFT4dPz+BjUhDnjYDTO7A@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E54@prvxmb03.microfocus.com>

For TLSv1.3, servers are no longer allowed to specify arbitrary DH groups (for finite-field or EC DH). They must use one of the named groups. So for 1.3, there's no point in generating your own groups; conforming implementations can't use them.

For finite-field DH, those are the groups specified by RFC 7919. For ECDH there's a list in the draft TLSv1.3 spec (see section 4.2.8.2), which is available at the usual places.

For TLS prior to 1.3, I agree with Jakob, whose recommendations are essentially the same as the original set coming from the WeakDH researchers. Since the publication of RFC 7919, some people have been recommending using only those groups, because they're believed to be trustworthy; I don't find that a compelling argument. But it's likely that TLSv1.3 (and its successors, presumably continuing the ban on arbitrary groups) will eventually come to dominate, making the question irrelevant in practice.

In short: Use "openssl dhparam" to generate a suitable group or groups, or use the group or groups of appropriate size from RFC 7919. Hard-code these in your server.

Note: If you use OpenSSL 1.0.x and you use the DH parameter callback, be aware that the callback isn't invoked in a useful manner by OpenSSL. (It always asks for a 1024-bit group, unless an export cipher suite was selected, which should never happen.) In fact, now that export ciphers have gone the way of the dodo, the best thing to do is probably just set a single group of your preferred size in all your SSL_CTX structures and forget about the callback.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From Michael.Wojcik at microfocus.com  Wed Dec  6 13:51:52 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 6 Dec 2017 13:51:52 +0000
Subject: [openssl-users] ECC ciphers in OpenSSL and Citricom
 Patent/License	terms
In-Reply-To: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>
References: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E81@prvxmb03.microfocus.com>

This probably should just have gone to openssl-users. Please don't copy every question to openssl-dev.

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jayalakshmi bhat
> Sent: Wednesday, December 06, 2017 01:07

> Does it mean to use ECC ciphers from OpenSSL does the end user needs to get the license from Citricom??

Consult a lawyer. Opinions on this topic differ wildly, it has a long and vexed history, and legal advice from random people on the Internet isn't worth what you pay for it.

Certicom was purchased by Blackberry years ago; they are the current holder of the ECC patents obtained by Certicom, to the best of my knowledge.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


From Michael.Wojcik at microfocus.com  Wed Dec  6 14:07:04 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 6 Dec 2017 14:07:04 +0000
Subject: [openssl-users] VS2017 15.5 hangs indefinitely with Blake2b.c
In-Reply-To: <978da7e1-958a-22e4-d971-6326131ce1d1@oliverniebuhr.de>
References: <7981b2e4-2bd4-8e60-e50c-bb39681525ff@oliverniebuhr.de>
 <40fde8c3-946d-d0e2-1831-67a13ed7f265@openssl.org>
 <978da7e1-958a-22e4-d971-6326131ce1d1@oliverniebuhr.de>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2FB0@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Oliver Niebuhr
> Sent: Wednesday, December 06, 2017 08:43
>
> Like mentioned below, I updated the VS 2017 Compiler to 14.12 - but it
> also happens with 14.11.

I don't know where those version numbers come from (Microsoft's dev toolchain versioning remains a mystery to me), but I'm using VS2017, running "cl" with no parameters says 19.11.25547, and I just compiled blake2b.c with no issues.

Now, this is blake2b.c from the Argon2 reference implementation - I don't know if it's been changed at all in the OpenSSL sources. And I'm not building OpenSSL in this case (it's a diffferent project that happens to include Argon2), so it's entirely possible I'm using different compiler options. But there's another data point, anyway.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From Michael.Wojcik at microfocus.com  Wed Dec  6 14:07:04 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 6 Dec 2017 14:07:04 +0000
Subject: [openssl-users] [openssl-dev] A question DH
	parameter	generation and usage
In-Reply-To: <DCCF2F22-BA18-4983-993D-355FDAD022BE@akamai.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
 <DCCF2F22-BA18-4983-993D-355FDAD022BE@akamai.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2FB3@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-users
> Sent: Wednesday, December 06, 2017 08:50

> You can re-use the keys, but then you get no forward secrecy, and sessions generated with one connection are
> vulnerable to another.

If you reuse keys, yes; but you still get PFS if you only reuse the same group and generate ephemeral keys (assuming sufficient group strength, where "sufficient" depends on the size of the group and its value to well-resourced attackers). I thought that was what the original poster was asking about.

> Why are you using DH?? Unless you have compelling reasons (interop with legacy), you really should use ECDHE.

Interop would be the usual reason. And since supporting DHE properly is a small fixed cost (generate a group or pick one from RFC 7919, hard-code it, and set it in each SSL_CTX), you might as well do it, no?

But I agree that the ECDHE suites are generally preferable when the client supports them. I know there's some NSA FUD around ECC since they pulled it from the Suite B recommendations in 2015.[1] I still think the published evidence supports using ECC, though. On the other hand, and per today's other thread on the subject, there may be legal concerns around the use of ECC.


[1] Matt Green has a nice discussion of this, including a link to the great paper Koblitz and Menezes wrote about it, here: https://blog.cryptographyengineering.com/2015/10/22/a-riddle-wrapped-in-curve/

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From bhat.jayalakshmi at gmail.com  Wed Dec  6 17:54:15 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Wed, 6 Dec 2017 23:24:15 +0530
Subject: [openssl-users] ECC ciphers in OpenSSL and Citricom
 Patent/License terms
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E81@prvxmb03.microfocus.com>
References: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E81@prvxmb03.microfocus.com>
Message-ID: <CALq8RvKvYv+bu3eMv2EyBNG9G=Dw5KJQHDX9f6QyyJr4YzGbuw@mail.gmail.com>

Hi Michael

Thanks for the input.

Regards
Jaya

On Wed, Dec 6, 2017 at 7:21 PM, Michael Wojcik <
Michael.Wojcik at microfocus.com> wrote:

> This probably should just have gone to openssl-users. Please don't copy
> every question to openssl-dev.
>
> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Jayalakshmi bhat
> > Sent: Wednesday, December 06, 2017 01:07
>
> > Does it mean to use ECC ciphers from OpenSSL does the end user needs to
> get the license from Citricom?
>
> Consult a lawyer. Opinions on this topic differ wildly, it has a long and
> vexed history, and legal advice from random people on the Internet isn't
> worth what you pay for it.
>
> Certicom was purchased by Blackberry years ago; they are the current
> holder of the ECC patents obtained by Certicom, to the best of my knowledge.
>
> --
> 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/20171206/4332d24b/attachment.html>

From pratyush.parimal at gmail.com  Wed Dec  6 17:54:59 2017
From: pratyush.parimal at gmail.com (pratyush parimal)
Date: Wed, 6 Dec 2017 12:54:59 -0500
Subject: [openssl-users] Disable SSL_ERROR_WANT_READ / WRITE ?
Message-ID: <CALvRNOHYqRONi4znBPSYVnuaLzmdKjdpshxZOT37N1PHgssnXw@mail.gmail.com>

Hi all,

I see a lot of questions and answers about how to
handle SSL_ERROR_WANT_READ / WRITE during SSL_read/write, and I understand
that the error is returned when the SSL library needs to do a handshake in
the middle of read/write operation, so we need to repeat the call when the
appropriate event happens.

But what I don't understand is, why does the library need to re-do the
handshake? If I set up my program so go through the SSL_connect/accept
calls properly (and handle SSL_ERROR_WANT_READ/WRITE in there properly) and
do the handshake successfully in the beginning itself, then why does the
library need to do a handshake again?

If I'm happy with my initial handshake, is there a way to disable
subsequent handshaking for that socket?

Thanks,
Pratyush.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171206/382929df/attachment.html>

From bhat.jayalakshmi at gmail.com  Wed Dec  6 17:58:34 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Wed, 6 Dec 2017 23:28:34 +0530
Subject: [openssl-users] [openssl-dev] A question DH parameter
 generation and usage
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2FB3@prvxmb03.microfocus.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
 <DCCF2F22-BA18-4983-993D-355FDAD022BE@akamai.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2FB3@prvxmb03.microfocus.com>
Message-ID: <CALq8RvJaEuAU8UcDk15bz2JL53ZKdOwk48zUqz_hhWA8aRVTFA@mail.gmail.com>

Hi Michael,

Thanks for very detailed answers. This will surely help me to investigate
further.

Regards
Jaya

On Wed, Dec 6, 2017 at 7:37 PM, Michael Wojcik <
Michael.Wojcik at microfocus.com> wrote:

> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Salz, Rich via openssl-users
> > Sent: Wednesday, December 06, 2017 08:50
>
> > You can re-use the keys, but then you get no forward secrecy, and
> sessions generated with one connection are
> > vulnerable to another.
>
> If you reuse keys, yes; but you still get PFS if you only reuse the same
> group and generate ephemeral keys (assuming sufficient group strength,
> where "sufficient" depends on the size of the group and its value to
> well-resourced attackers). I thought that was what the original poster was
> asking about.
>
> > Why are you using DH?  Unless you have compelling reasons (interop with
> legacy), you really should use ECDHE.
>
> Interop would be the usual reason. And since supporting DHE properly is a
> small fixed cost (generate a group or pick one from RFC 7919, hard-code it,
> and set it in each SSL_CTX), you might as well do it, no?
>
> But I agree that the ECDHE suites are generally preferable when the client
> supports them. I know there's some NSA FUD around ECC since they pulled it
> from the Suite B recommendations in 2015.[1] I still think the published
> evidence supports using ECC, though. On the other hand, and per today's
> other thread on the subject, there may be legal concerns around the use of
> ECC.
>
>
> [1] Matt Green has a nice discussion of this, including a link to the
> great paper Koblitz and Menezes wrote about it, here: https://blog.
> cryptographyengineering.com/2015/10/22/a-riddle-wrapped-in-curve/
>
> --
> 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/20171206/6a2bf804/attachment-0001.html>

From bhat.jayalakshmi at gmail.com  Wed Dec  6 18:04:53 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Wed, 6 Dec 2017 23:34:53 +0530
Subject: [openssl-users] [openssl-dev] A question DH parameter
 generation and usage
In-Reply-To: <DCCF2F22-BA18-4983-993D-355FDAD022BE@akamai.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
 <DCCF2F22-BA18-4983-993D-355FDAD022BE@akamai.com>
Message-ID: <CALq8RvL_XctJyNLdqNBwa5KEHeBhF_m9PLw1HxLUwh61zXQunQ@mail.gmail.com>

Hi Rich,

Thanks for the reply. We are planning to use  DHE_RSA based ciphers.

Regards
Jaya

On Wed, Dec 6, 2017 at 7:20 PM, Salz, Rich via openssl-users <
openssl-users at openssl.org> wrote:

> You can re-use the keys, but then you get no forward secrecy, and sessions
> generated with one connection are vulnerable to another.
>
>
>
> Why are you using DH?  Unless you have compelling reasons (interop with
> legacy), you really should use ECDHE.
>
>
>
> --
> 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/20171206/340f71b9/attachment.html>

From openssl-users at dukhovni.org  Wed Dec  6 18:21:14 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 6 Dec 2017 13:21:14 -0500
Subject: [openssl-users] A question DH parameter generation and usage
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E54@prvxmb03.microfocus.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
 <98536b7d-4006-188c-85b0-53014e0d3340@wisemo.com>
 <CALq8Rv+HS9A7qYvf+1ac_p_LrVWiotFT4dPz+BjUhDnjYDTO7A@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E54@prvxmb03.microfocus.com>
Message-ID: <447982C3-43B8-4843-97ED-8672C8FC88EC@dukhovni.org>



> On Dec 6, 2017, at 8:51 AM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
> 
> 
> Note: If you use OpenSSL 1.0.x and you use the DH parameter callback, be aware that the callback isn't invoked in a useful manner by OpenSSL. (It always asks for a 1024-bit group, unless an export cipher suite was selected, which should never happen.)

This is misleading.  The callback does not really ask for a 1024-bit group,
rather it passes one of two key-size hints "512" for export ciphers and 1024
for non-export ciphers.  Therefore, one can return any reasonable group size
instead of 1024 bits.  See for example:

   https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_dh.c#L227

where the "1024-bit" group returned by the tmp_dh callback is a 2048-bit group.

The text at:

   http://www.postfix.org/FORWARD_SECRECY_README.html#dfn_fs
   http://www.postfix.org/FORWARD_SECRECY_README.html#tls_fs

may be helpful to some users not familiar with forward secrecy in TLS.


> In fact, now that export ciphers have gone the way of the dodo, the best thing to do is probably just set a single group of your preferred size in all your SSL_CTX structures and forget about the callback.

Sure, provided one is sure that this will not lead to (DH) private key re-use.
In sufficiently recent OpenSSL releases single DH use is the default and IIRC
cannot be disabled.  But older releases may more reliably avoid DH key re-use
when the group is provided via the tmp_dh callback.

-- 
	Viktor.


From Michael.Wojcik at microfocus.com  Wed Dec  6 19:25:51 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 6 Dec 2017 19:25:51 +0000
Subject: [openssl-users] Disable SSL_ERROR_WANT_READ / WRITE ?
In-Reply-To: <CALvRNOHYqRONi4znBPSYVnuaLzmdKjdpshxZOT37N1PHgssnXw@mail.gmail.com>
References: <CALvRNOHYqRONi4znBPSYVnuaLzmdKjdpshxZOT37N1PHgssnXw@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE37C8@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of pratyush parimal
> Sent: Wednesday, December 06, 2017 12:55

> But what I don't understand is, why does the library need to re-do the handshake?

I don't wish to sound rude, but this is answered right in the OpenSSL documentation for the SSL error codes: "This is mainly because TLS/SSL handshakes may occur at any time during the protocol (initiated by either the client or the server)".

*Either side* can initiate a new handshake. Unless you control the TLS implementations on both sides, you can't guarantee there won't be new handshakes.

Or at least that used to be the case. TLSv1.3 got rid of renegotiation, so if you have a TLSv1.3 connection, it will never renegotiate.

However, you could still get at least SSL_ERROR_WANT_WRITE. Why? Because the peer could send something that your side has to respond to. For example, it could erroneously try to renegotiate, and now you need to send an alert.

WANT_READ / WANT_WRITE are part of life with TLS. You'll just have to handle them. Complicated protocols are complicated.

If you're wondering why renegotiation happens in pre-TLSv1.3 versions, you can find various articles online suggesting some of the more plausible (though probably not terribly common) scenarios. Probably the most common is needing to re-key because enough data has been transmitted that a passive attacker could derive some information about the key. It's also possible that the initial connection did not involve a client certificate, but now one side or the other has decided the client should send one. I've never seen that happen but I've seen it suggested.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From Michael.Wojcik at microfocus.com  Wed Dec  6 19:25:53 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 6 Dec 2017 19:25:53 +0000
Subject: [openssl-users] A question DH parameter generation and usage
In-Reply-To: <447982C3-43B8-4843-97ED-8672C8FC88EC@dukhovni.org>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
 <98536b7d-4006-188c-85b0-53014e0d3340@wisemo.com>
 <CALq8Rv+HS9A7qYvf+1ac_p_LrVWiotFT4dPz+BjUhDnjYDTO7A@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E54@prvxmb03.microfocus.com>
 <447982C3-43B8-4843-97ED-8672C8FC88EC@dukhovni.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE37CF@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Wednesday, December 06, 2017 13:21
> 
> > On Dec 6, 2017, at 8:51 AM, Michael Wojcik
> <Michael.Wojcik at microfocus.com> wrote:
> >
> >
> > Note: If you use OpenSSL 1.0.x and you use the DH parameter callback, be
> > aware that the callback isn't invoked in a useful manner by OpenSSL. (It
> > always asks for a 1024-bit group, unless an export cipher suite was selected,
> > which should never happen.)
> 
> This is misleading.  The callback does not really ask for a 1024-bit group,
> rather it passes one of two key-size hints "512" for export ciphers and 1024
> for non-export ciphers.  Therefore, one can return any reasonable group size
> instead of 1024 bits.

Yes, that's what I meant. Sorry if I was unclear. (We have code that still uses the callback, but passes back a group of size configurable by the administrator, and defaulting to 2048 bits. As the OpenSSL docs now recommend, we ignore the size and export parameters to the callback.)

> > In fact, now that export ciphers have gone the way of the dodo, the best
> > thing to do is probably just set a single group of your preferred size in all your
> > SSL_CTX structures and forget about the callback.
> 
> Sure, provided one is sure that this will not lead to (DH) private key re-use.
> In sufficiently recent OpenSSL releases single DH use is the default and IIRC
> cannot be disabled.  But older releases may more reliably avoid DH key re-
> use when the group is provided via the tmp_dh callback.

Oh, that's right. There's some option to set to tell OpenSSL 1.0.2 to tell it not to reuse DH keys, isn't there. Let's see... it's SSL_OP_SINGLE_DH_USE. But the man page for SSL_CTX_set_tmp_dh and SSL_CTX_set_tmp_dh_callback (and the SSL-specific versions) seems to imply that SSL_OP_SINGLE_DH_USE isn't necessary if either of those functions were used.

In any case, since 1.0.2f, SSL_OP_SINGLE_DH_USE is always on and cannot be disabled (CVE-2016-0701). That's probably why I'd forgotten about it.

In sum: The simplest thing is to choose a single DH group that meets your requirements (probably at least 2048 bits, and either coming from RFC 7919 or a good run of openssl dhparam), then set that in each new context with SLS_CTX_set_tmp_dh.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From rsalz at akamai.com  Wed Dec  6 20:22:15 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 6 Dec 2017 20:22:15 +0000
Subject: [openssl-users] Disable SSL_ERROR_WANT_READ / WRITE ?
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE37C8@prvxmb03.microfocus.com>
References: <CALvRNOHYqRONi4znBPSYVnuaLzmdKjdpshxZOT37N1PHgssnXw@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE37C8@prvxmb03.microfocus.com>
Message-ID: <F5AD243D-216A-4199-8227-B0E49F5F10C0@akamai.com>

?    Or at least that used to be the case. TLSv1.3 got rid of renegotiation, so if you have a TLSv1.3 connection, it will never renegotiate.
    
But it could ask for a certificate, which would trigger SSL_WANT_WRITE



From googleersatz at oliverniebuhr.de  Thu Dec  7 04:38:05 2017
From: googleersatz at oliverniebuhr.de (Oliver Niebuhr)
Date: Thu, 7 Dec 2017 05:38:05 +0100
Subject: [openssl-users] VS2017 15.5 hangs indefinitely with Blake2b.c
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2FB0@prvxmb03.microfocus.com>
References: <7981b2e4-2bd4-8e60-e50c-bb39681525ff@oliverniebuhr.de>
 <40fde8c3-946d-d0e2-1831-67a13ed7f265@openssl.org>
 <978da7e1-958a-22e4-d971-6326131ce1d1@oliverniebuhr.de>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2FB0@prvxmb03.microfocus.com>
Message-ID: <27ed1ca7-6ba6-2f0b-d0bb-f35a373aa6f7@oliverniebuhr.de>

Morning.

Yeah my fault. I mixed up CL and Link Version Numbers:
Link Version is 14.12.25830.2 and
CL Version 19.12.25830.2 but
Compiler Tool Set Version is 14.12

You have to love their Versioning Scheme ;)

BTW: It turned out that the VS SSA-Optimizer is at fault here! After
disabling it with '/d2SSAOptimizer-' blake2b.c compiles fine.

Seems like a Bug with this Tool Set Version.

I created a BR:
https://github.com/openssl/openssl/issues/4859

Should I create a BR at the VS Forum too?

Have a nice Day everyone
Oliver

On 06/12/2017 15:07, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Oliver Niebuhr
>> Sent: Wednesday, December 06, 2017 08:43
>>
>> Like mentioned below, I updated the VS 2017 Compiler to 14.12 - but it
>> also happens with 14.11.
> 
> I don't know where those version numbers come from (Microsoft's dev toolchain versioning remains a mystery to me), but I'm using VS2017, running "cl" with no parameters says 19.11.25547, and I just compiled blake2b.c with no issues.
> 
> Now, this is blake2b.c from the Argon2 reference implementation - I don't know if it's been changed at all in the OpenSSL sources. And I'm not building OpenSSL in this case (it's a diffferent project that happens to include Argon2), so it's entirely possible I'm using different compiler options. But there's another data point, anyway.
> 

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

From jb-openssl at wisemo.com  Thu Dec  7 06:25:40 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 7 Dec 2017 07:25:40 +0100
Subject: [openssl-users] ECC ciphers in OpenSSL and Citricom
 Patent/License terms
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E81@prvxmb03.microfocus.com>
References: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E81@prvxmb03.microfocus.com>
Message-ID: <4a8bab67-8e7d-af37-6ee0-6bbb9bf62269@wisemo.com>

On 06/12/2017 14:51, Michael Wojcik wrote:
> This probably should just have gone to openssl-users. Please don't copy every question to openssl-dev.
>
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jayalakshmi bhat
>> Sent: Wednesday, December 06, 2017 01:07
>> Does it mean to use ECC ciphers from OpenSSL does the end user needs to get the license from Citricom?
> Consult a lawyer. Opinions on this topic differ wildly, it has a long and vexed history, and legal advice from random people on the Internet isn't worth what you pay for it.
>
> Certicom was purchased by Blackberry years ago; they are the current holder of the ECC patents obtained by Certicom, to the best of my knowledge.
>
I believe what most people want, rather than the unconfirmed opinion of
a random local patent lawyer is public answers to the following:

****************************

Answers by the OpenSSL team (I have tried topin this out into easily
answered questions that someone on the team should already know):

- Why is the README.ECC file not included in the regular OpenSSL
 ?tarballs?

- Has the OpenSSL project or foundation received any kind of firm legal
 ?opinion (or even better a judicial or contractual opinion) as to the
 ?question if the license referenced in the README.ECC in the FIPS
 ?tarballs applies to the ECC code in the regular OpenSSL tarballs.

- Has the OpenSSL project or foundation received any kind of firm legal
 ?opinion (or better) as to the question if the license referenced in
 ?FIPS README.ECC applies to non-validated builds of the FIPS tarball
 ?(such as modified builds).

- Has the OpenSSL project or foundation received any kind of firm legal
 ?opinion (or better) if the license referenced in the FIPS README.ECC
 ?applies to uses of the validated FIPS blob in code that does not (and
 ?is not in fact) claim to be covered by the FIPS validation (such as a
 ?modified OpenSSL that invokes the ECC code in the blob even in
 ?non-FIPS mode).

- Is there a technically safe way to copy the ECC code from the FIPS
 ?tarball to a build of non-FIPS OpenSSL?

****************************

Answers by Certicom/Blackberry as patent holders (I have split this into
questions that Certicom/Blackberry should be able to easily answer based
on their own policies, except perhaps the first one):

Note that while the answers and questions below may resemble lawsuit
related questions such as "claim construction charts", it is being asked
outside such context for the purpose of easing compliance with existing
license/sublicense contracts, and to facilitate respect for their
intellectual property, either by acting within granted licenses, obtaining
additional licenses where needed or abstaining from using the patented
technology without a valid license.

As CC/BB may know, OpenSSL is a widely used software library making public
statements a more efficient means of handling this rather than each and
every commercial OpenSSL user entering into near-identical individual
private negotiations.

- Which CC/BB patents (numbers and maybe claims) are applicable to the
 ?recent 1.0.2*, 1.1.0* and git head branches?? For clarity, the answers
 ?should probably identify specific files and file versions, to protect
 ?CC/BB from accidental estoppel regarding the use of additional CC/BB
 ?patented technology in files they have not examined.? Note that this
 ?answer will probably form the basis for the answers to the questions
 ?below.

- Does CC/BB suggest/require that products using any such CC/BB patented
 ?technology through the OpenSSL licensing mark their licensed products
 ?with?any particular patent notices?

- Does CC/BB demand or not an additional patent license for invocation
of the regular OpenSSL ECC code by the OpenSSL SSL/TLS code in non-FIPS
 ?scenarios, if so when and which.

- Does CC/BB demand or not an additional patent license for invocation
 ?of the regular OpenSSL ECC code in other scenarios, if so when and which.

- Does CC/BB demand or not an additional patent license for use of the
 ?regular OpenSSL ECC code for curves and or algorithms not standardized
 ?in the NIST FIPS documents?

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 jb-openssl at wisemo.com  Thu Dec  7 06:44:20 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 7 Dec 2017 07:44:20 +0100
Subject: [openssl-users] A question DH parameter generation and usage
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE37CF@prvxmb03.microfocus.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
 <98536b7d-4006-188c-85b0-53014e0d3340@wisemo.com>
 <CALq8Rv+HS9A7qYvf+1ac_p_LrVWiotFT4dPz+BjUhDnjYDTO7A@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E54@prvxmb03.microfocus.com>
 <447982C3-43B8-4843-97ED-8672C8FC88EC@dukhovni.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE37CF@prvxmb03.microfocus.com>
Message-ID: <42a0fc86-59e8-2fba-a3ba-7b35e1585a2e@wisemo.com>

On 06/12/2017 20:25, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Viktor Dukhovni
>> Sent: Wednesday, December 06, 2017 13:21
>>
>>> On Dec 6, 2017, at 8:51 AM, Michael Wojcik
>> <Michael.Wojcik at microfocus.com> wrote:
>>>
>>> Note: If you use OpenSSL 1.0.x and you use the DH parameter callback, be
>>> aware that the callback isn't invoked in a useful manner by OpenSSL. (It
>>> always asks for a 1024-bit group, unless an export cipher suite was selected,
>>> which should never happen.)
>> This is misleading.  The callback does not really ask for a 1024-bit group,
>> rather it passes one of two key-size hints "512" for export ciphers and 1024
>> for non-export ciphers.  Therefore, one can return any reasonable group size
>> instead of 1024 bits.
> Yes, that's what I meant. Sorry if I was unclear. (We have code that still uses the callback, but passes back a group of size configurable by the administrator, and defaulting to 2048 bits. As the OpenSSL docs now recommend, we ignore the size and export parameters to the callback.)
>
>>> In fact, now that export ciphers have gone the way of the dodo, the best
>>> thing to do is probably just set a single group of your preferred size in all your
>>> SSL_CTX structures and forget about the callback.
>> Sure, provided one is sure that this will not lead to (DH) private key re-use.
>> In sufficiently recent OpenSSL releases single DH use is the default and IIRC
>> cannot be disabled.  But older releases may more reliably avoid DH key re-
>> use when the group is provided via the tmp_dh callback.
> Oh, that's right. There's some option to set to tell OpenSSL 1.0.2 to tell it not to reuse DH keys, isn't there. Let's see... it's SSL_OP_SINGLE_DH_USE. But the man page for SSL_CTX_set_tmp_dh and SSL_CTX_set_tmp_dh_callback (and the SSL-specific versions) seems to imply that SSL_OP_SINGLE_DH_USE isn't necessary if either of those functions were used.
>
> In any case, since 1.0.2f, SSL_OP_SINGLE_DH_USE is always on and cannot be disabled (CVE-2016-0701). That's probably why I'd forgotten about it.
>
> In sum: The simplest thing is to choose a single DH group that meets your requirements (probably at least 2048 bits, and either coming from RFC 7919 or a good run of openssl dhparam), then set that in each new context with SLS_CTX_set_tmp_dh.
>
Actually in some of my code, I have found that the callback can
still be useful by examining the SSL session argument to
heuristically identify likely client side DH size capability and
thus choose between modernDH parameter sizes.

P.S. Forcing use of common DH parameters in TLS 1.3 would directly
make all TLS 1.3 implementations vulnerable to LogJam. That would
be absurd.

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 matt at openssl.org  Thu Dec  7 10:25:55 2017
From: matt at openssl.org (Matt Caswell)
Date: Thu, 7 Dec 2017 10:25:55 +0000
Subject: [openssl-users] VS2017 15.5 hangs indefinitely with Blake2b.c
In-Reply-To: <27ed1ca7-6ba6-2f0b-d0bb-f35a373aa6f7@oliverniebuhr.de>
References: <7981b2e4-2bd4-8e60-e50c-bb39681525ff@oliverniebuhr.de>
 <40fde8c3-946d-d0e2-1831-67a13ed7f265@openssl.org>
 <978da7e1-958a-22e4-d971-6326131ce1d1@oliverniebuhr.de>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2FB0@prvxmb03.microfocus.com>
 <27ed1ca7-6ba6-2f0b-d0bb-f35a373aa6f7@oliverniebuhr.de>
Message-ID: <04a7f886-650b-daf8-576b-d0579060a63d@openssl.org>



On 07/12/17 04:38, Oliver Niebuhr wrote:
> BTW: It turned out that the VS SSA-Optimizer is at fault here! After
> disabling it with '/d2SSAOptimizer-' blake2b.c compiles fine.
>
> Seems like a Bug with this Tool Set Version.
>
> I created a BR:
> https://github.com/openssl/openssl/issues/4859
>
> Should I create a BR at the VS Forum too?

That would be a good idea!

Thanks

Matt


>
> Have a nice Day everyone
> Oliver
>
> On 06/12/2017 15:07, Michael Wojcik wrote:
>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>>> Of Oliver Niebuhr
>>> Sent: Wednesday, December 06, 2017 08:43
>>>
>>> Like mentioned below, I updated the VS 2017 Compiler to 14.12 - but it
>>> also happens with 14.11.
>> I don't know where those version numbers come from (Microsoft's dev toolchain versioning remains a mystery to me), but I'm using VS2017, running "cl" with no parameters says 19.11.25547, and I just compiled blake2b.c with no issues.
>>
>> Now, this is blake2b.c from the Argon2 reference implementation - I don't know if it's been changed at all in the OpenSSL sources. And I'm not building OpenSSL in this case (it's a diffferent project that happens to include Argon2), so it's entirely possible I'm using different compiler options. But there's another data point, anyway.
>>
>
>

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

From janjust at nikhef.nl  Thu Dec  7 11:24:07 2017
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Thu, 7 Dec 2017 12:24:07 +0100
Subject: [openssl-users] SSL alert number 48
In-Reply-To: <CAEAeT_i0wHff-=hyS5BsSyAY-0hwN+0cXzDzSz2R1PemShf=4Q@mail.gmail.com>
References: <CAEAeT_imeOGKfyrHjPbFeDfh-fdEDpGribdUnfavyVbHV7QyjQ@mail.gmail.com>
 <e8668c3b-2bde-647a-d2e7-9d1699ceb3ac@nikhef.nl>
 <CAEAeT_ijLEdUWnyFrANbD9swHZt=ctaA06DoBFrxmnJ5+qyQew@mail.gmail.com>
 <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl>
 <CAEAeT_gR0uxN3fGgZKo3J7NuGPY-5zW_nD7qquhMAykinrnJLg@mail.gmail.com>
 <642397e5-68c2-f2fc-3b4e-5e9c867d6b17@nikhef.nl>
 <CAEAeT_i0wHff-=hyS5BsSyAY-0hwN+0cXzDzSz2R1PemShf=4Q@mail.gmail.com>
Message-ID: <5e3168c5-1731-88e9-fd3e-153cd6ba8b4a@nikhef.nl>

Hi,

On 04/12/17 09:10, wizard2010 at gmail.com wrote:
> Hi ,
>
> Please see in attach the files that I'm using.

I've just taken a look at your certificates and they've not been 
generated correctly:

$ openssl x509 -subject -issuer -noout -in ca.crt -dates -serial
subject= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
issuer= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
notBefore=Nov 27 11:52:34 2017 GMT
notAfter=Nov 27 11:52:34 2018 GMT
serial=A1E0F7319AAD90C0

$ openssl x509 -subject -issuer -noout -in client.crt -dates -serial
subject= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
issuer= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
notBefore=Nov 27 11:53:16 2017 GMT
notAfter=Nov 27 11:53:16 2018 GMT
serial=01

$ openssl x509 -subject -issuer -noout -in server.crt -dates -serial
subject= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
issuer= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
notBefore=Nov 27 11:52:55 2017 GMT
notAfter=Nov 27 11:52:55 2018 GMT
serial=01


that is, the subject and issuer of the CA, server and client certs are 
all the same ; also, the serial number of both client and server 
certificates are the same.
You will need to alter the way you generate your certificates so that 
there is a clear distinction between CA, server and client cert.

HTH,

JJK


> I generate the certificates with the following commands:
>
> 1.
>     ## Create CA
> 2.
>     openssl genrsa -out?ca.key 4096
> 3.
>     openssl req -new -x509 -days 365 -key?ca.key -out?ca.crt
> 4.
>     openssl x509 -in?ca.crt -out?ca.pem -outform?PEM
> 5.
>
> 1.
>     ## Create the Server Key and CSR
> 2.
>     openssl genrsa -out?server.key 4096
> 3.
>     openssl req -new -key?server.key -out?server.csr
> 4.
>     openssl x509 -req -days 365 -in?server.csr -CA?ca.crt
>     -CAkey?ca.key -set_serial 01 -out?server.crt
> 5.
>     openssl x509 -in?server.crt -out?server.pem -outform?PEM
> 6.
>
> 1.
>     ## Create the Client Key and CSR
> 2.
>     openssl genrsa -out?client.key 4096
> 3.
>     openssl req -new -key?client.key -out?client.csr
> 4.
>     openssl x509 -req -days 365 -in?client.csr -CA?ca.crt
>     -CAkey?ca.key -set_serial 01 -out?client.crt
> 5.
>     openssl x509 -in?client.crt -out?client.pem -outform?PEM
>
>
> I left the default value of each question that openssl ask when it's 
> creating the certificates like Country, City, CN, etc. Like this way:
>
>         openssl req -new -key server.key -out server.csr
>
>         You are about to be asked to enter information that will be
>         incorporated
>
>         into your certificate request.
>
>         What you are about to enter is what is called a Distinguished
>         Name or a DN.
>
>         There are quite a few fields but you can leave some blank
>
>         For some fields there will be a default value,
>
>         If you enter '.', the field will be left blank.
>
>         -----
>
>         Country Name (2 letter code) [AU]:
>
>         State or Province Name (full name) [Some-State]:
>
>         Locality Name (eg, city) []:
>
>         Organization Name (eg, company) [Internet Widgits Pty Ltd]:
>
>         Organizational Unit Name (eg, section) []:
>
>         Common Name (e.g. server FQDN or YOUR name) []:
>
>         Email Address []:
>
>         Please enter the following 'extra' attributes
>
>         to be sent with your certificate request
>
>         A challenge password []:
>
>         An optional company name []:
>
> Thanks.
> Kind regards.
>
>
> On Thu, Nov 30, 2017 at 2:45 PM, Jan Just Keijser <janjust at nikhef.nl 
> <mailto:janjust at nikhef.nl>> wrote:
>
>     Hi,
>
>     On 29/11/17 14:37, wizard2010 at gmail.com
>     <mailto:wizard2010 at gmail.com> wrote:
>>     Hi JJK,
>>
>>     I test you function and I've got this result:
>>
>>         ok = 0
>>         cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
>>         ok = 1
>>         cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
>>
>>
>>     Why I see this 2 time?
>>     When I create the certificates I didn't fill with any special
>>     information, just type enter in every question that is made. Did
>>     you think this could cause this issue?
>>
>
>     what you should have seen is the certificate stack, starting with
>     the CA, and then the client cert, e.g.
>
>     Connection accept...
>     ok = 1
>     cert DN: /C=US/O=Cookbook 2.4/CN=Cookbook 2.4
>     CA/emailAddress=openvpn at example.com
>     <mailto:CA/emailAddress=openvpn at example.com>
>     ok = 1
>     cert DN: /C=US/O=Cookbook 2.4/CN=client1
>
>
>     so I suspect that your ca.crt on the server side is not specified
>     correctly.
>     You may also send me your ca.crt, server.{crt,key} and
>     client.{crt,key} files privately, and I will run the same test
>     using your set of certificates.
>
>     HTH,
>
>     JJK
>
>
>
>>
>>     On Wed, Nov 29, 2017 at 8:56 AM, Jan Just Keijser
>>     <janjust at nikhef.nl <mailto:janjust at nikhef.nl>> wrote:
>>
>>         Hi,
>>
>>         On 28/11/17 11:03, wizard2010 at gmail.com
>>         <mailto:wizard2010 at gmail.com> wrote:
>>>         Hi there.
>>>
>>>         I guess my problem is really related to verify callback
>>>         on?SSL_CTX_set_verify function.
>>>         I just add to my code a dummy callback returning 1 and
>>>         everything works properly.
>>>
>>>
>>>             int verify_callback (int ok, X509_STORE_CTX *ctx);
>>>             int verify_callback (int ok, X509_STORE_CTX *ctx)
>>>             {
>>>             printf("Verification callback OK!\n");
>>>             return 1;
>>>             }
>>>             ...
>>>             SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER |
>>>             SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback);
>>>             ...
>>>
>>>
>>>         The problem is that error don't tell much information about
>>>         what's really going on or what's really missing.
>>>         Thanks for your help.
>>>
>>         Now you've effectively disabled all security :)
>>
>>         Try adding this to the verify_callback
>>
>>
>>         static int verify_callback(int ok, X509_STORE_CTX *ctx)
>>         {
>>         ??? X509?????????? *cert = NULL;
>>         ??? char?????????? *cert_DN = NULL;
>>
>>         ??? printf("ok = %d\n", ok);
>>         ??? cert??? = X509_STORE_CTX_get_current_cert(ctx);
>>         ??? cert_DN = X509_NAME_oneline( X509_get_subject_name( cert
>>         ), NULL, 0 );
>>         ??? printf( "cert DN: %s\n", cert_DN);
>>
>>         }
>>
>>
>>         that way, you will know whether your server is processing the
>>         right certificate chain.
>>
>>         HTH,
>>
>>         JJK
>>
>>
>
>

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

From chris.gray at kiffer.be  Thu Dec  7 11:57:36 2017
From: chris.gray at kiffer.be (chris.gray at kiffer.be)
Date: Thu, 7 Dec 2017 11:57:36 -0000
Subject: [openssl-users] ENGINE API and a compromised client or server
Message-ID: <fa3e1c0f61ef552b94b227a0f2227866.squirrel@koningbalthazar.be>

Hi all,

On a project I am working on we are wrestling with the problem of
preventing discovery of the private key, in a consumer device. I have been
advocating the use of the ENGINE API as a general model which can be used
to provide the best isolation possible on the customer's chosen hardware:
 * at a minimum no direct accessibility of the private key file (or
dedicated flash region) from the internet-facing process;
 * better still if internet-facing process runs in an LXC (esp. if
unprivileged);
 * ideally of course true SHM ($$$);
without needing to maintain multiple codebases.

Some colleagues have expressed concern that API methods such as
RSA_(public,private]_[en,de]crypt could be used by a compromised
client/server to launch a chosen-plaintext attack. (For the record we are
also using ECDSA, so this question is not purely RSA-specific). I am not
unduly worried about the _public_ functions because we should be able to
insist that a decent padding algorithm is used and then we are pretty
safe, right? I am more nervous about RSA_public_encrypt, which I think is
needed by TLS and which only seems to support RSA_PKCS1_PADDING (not
good). Is this a feasible attack vector?

Note that we are not only talking about servers here, rather we currently
have only one internet-facing server (HTTPS) and a growing number of
XXX-over-TLS clients, so if anything these are a greater source of
concern.

Any pointers are very welcome!

Chris Gray



From rsalz at akamai.com  Thu Dec  7 12:39:18 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 7 Dec 2017 12:39:18 +0000
Subject: [openssl-users] ECC ciphers in OpenSSL and Citricom
 Patent/License terms
In-Reply-To: <4a8bab67-8e7d-af37-6ee0-6bbb9bf62269@wisemo.com>
References: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E81@prvxmb03.microfocus.com>
 <4a8bab67-8e7d-af37-6ee0-6bbb9bf62269@wisemo.com>
Message-ID: <CC7BE721-65E1-41EC-BC1B-2D0745E605F0@akamai.com>

README.ECC has never been part of 1.0.2 and is always part of the the 1.1.0 tarballs; do you have evidence otherwise?

I don?t think the team is going to answer any questions beyond what is already in the distrubtuion and website except to say that the license is NOT limited to the FIPS releases.
 


From jb-openssl at wisemo.com  Thu Dec  7 13:41:03 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 7 Dec 2017 14:41:03 +0100
Subject: [openssl-users] ECC ciphers in OpenSSL and Citricom
 Patent/License terms
In-Reply-To: <CC7BE721-65E1-41EC-BC1B-2D0745E605F0@akamai.com>
References: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E81@prvxmb03.microfocus.com>
 <4a8bab67-8e7d-af37-6ee0-6bbb9bf62269@wisemo.com>
 <CC7BE721-65E1-41EC-BC1B-2D0745E605F0@akamai.com>
Message-ID: <e7169dc4-c573-6e8b-049e-8a5d5931895d@wisemo.com>

On 07/12/2017 13:39, Salz, Rich via openssl-users wrote:
> README.ECC has never been part of 1.0.2 and is always part of the the 1.1.0 tarballs; do you have evidence otherwise?
>
> I don?t think the team is going to answer any questions beyond what is already in the distrubtuion and website except to say that the license is NOT limited to the FIPS releases.
>   
>
The OP claimed the file was only in the FIPS tarballs, and not in the
OpenSSL tarballs.? My questions were based on that.

And I would still say that "consult a lawyer" is a useless answer,
especially as most OpenSSL users will be in the same legal situation,
and lawyers opinions on patent matters are frequently found by courts
to be wrong anyway.

Saying "in the distribution and website" is also quite vague and
thus another example of a non-answer.

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 Michael.Wojcik at microfocus.com  Thu Dec  7 13:54:32 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 7 Dec 2017 13:54:32 +0000
Subject: [openssl-users] Disable SSL_ERROR_WANT_READ / WRITE ?
In-Reply-To: <F5AD243D-216A-4199-8227-B0E49F5F10C0@akamai.com>
References: <CALvRNOHYqRONi4znBPSYVnuaLzmdKjdpshxZOT37N1PHgssnXw@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE37C8@prvxmb03.microfocus.com>
 <F5AD243D-216A-4199-8227-B0E49F5F10C0@akamai.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE3B93@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Salz, Rich via openssl-users
> Sent: Wednesday, December 06, 2017 15:22
> 
> ?    Or at least that used to be the case. TLSv1.3 got rid of renegotiation, so if
> you have a TLSv1.3 connection, it will never renegotiate.
> 
> But it could ask for a certificate, which would trigger SSL_WANT_WRITE

Yeah. I alluded to that later in my message, though not very clearly.

The main point is that you have to handle WANT_x.

I also forgot to mention that Eric Rescorla's book calls renegotiation "rehandshaking", so someone trying to understand this process (in SSL/TLS versions prior to 1.3) might also want to look for that term.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From Michael.Wojcik at microfocus.com  Thu Dec  7 13:54:33 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 7 Dec 2017 13:54:33 +0000
Subject: [openssl-users] A question DH parameter generation and usage
In-Reply-To: <42a0fc86-59e8-2fba-a3ba-7b35e1585a2e@wisemo.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
 <98536b7d-4006-188c-85b0-53014e0d3340@wisemo.com>
 <CALq8Rv+HS9A7qYvf+1ac_p_LrVWiotFT4dPz+BjUhDnjYDTO7A@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E54@prvxmb03.microfocus.com>
 <447982C3-43B8-4843-97ED-8672C8FC88EC@dukhovni.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE37CF@prvxmb03.microfocus.com>
 <42a0fc86-59e8-2fba-a3ba-7b35e1585a2e@wisemo.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE3B9B@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Jakob Bohm
> Sent: Thursday, December 07, 2017 01:44
> >
> Actually in some of my code, I have found that the callback can
> still be useful by examining the SSL session argument to
> heuristically identify likely client side DH size capability and
> thus choose between modernDH parameter sizes.

Interesting idea. We might look into doing something similar someday.

> P.S. Forcing use of common DH parameters in TLS 1.3 would directly
> make all TLS 1.3 implementations vulnerable to LogJam. That would
> be absurd.

That's what TLSv1.3 does, as of the latest I-D (and several previous revisions).

Technically, it's not vulnerable to LogJam - LogJam is a downgrade attack, to a 512-bit "export" group, and the smallest group in RFC 7919 is 2048 bits. Using the same parameters across all implementations makes TLSv1.3 theoretically vulnerable to the WeakDH part of the LogJam/WeakDH attack class, but the presumption is that for even well-resourced adversaries a 2048-bit group is intractable. The WeakDH paper suggests breaking a 1024-bit group is feasible, but 2048 is obviously far more expensive. (The exact relationship isn't straightforward to determine, but it's exponential.)

For the paranoid, RFC 7919 / TLSv1.3 give you groups up to 8192 bits.

I am myself not entirely keen on this aspect of TLSv1.3, but this version of TLS has had much more cryptological analysis and engineering than any previous one. I'm sure this issue was discussed at length.

I've seen more than one recommendation to use RFC 7919 groups, rather than arbitrary ones, even for older TLS versions. This is a change from the original WeakDH recommendations. (The "Imperfect Forward Secrecy" paper came out in October 2015, and RFC 7919 in August 2016.)

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 



From openssl at openssl.org  Thu Dec  7 13:55:43 2017
From: openssl at openssl.org (OpenSSL)
Date: Thu, 7 Dec 2017 13:55:43 +0000
Subject: [openssl-users] OpenSSL version 1.0.2n published
Message-ID: <20171207135543.GA23228@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.0.2n released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2n of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2n is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.0.2n.tar.gz
      Size: 5375802
      SHA1 checksum: 0ca2957869206de193603eca6d89f532f61680b1
      SHA256 checksum: 370babb75f278c39e0c50e8c4e7493bc0f18db6867478341a832a982fd15a8fe

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.2n.tar.gz
    openssl sha256 openssl-1.0.2n.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaKT/tAAoJENnE0m0OYESR/JMH/jME2y7j63xd1JX1A41mgKiC
y9ps1niQw6QVH50r2IR0bZc9EpM9WEF0zERjCPwvh/tCn2IS/40uGzdHps8aexV1
3p7F3oAyXfG3xPyY3p14zfRP+9YvatbVT28HVnhGmruUonS9p6H+4zQN4hd8LZQO
tMZ5XtdmTbULdnlD6znBVECcUN2C+LQgaGZ5WCx8Wh8b7Wo3VT50+Jwv/VtmgLAf
csQKJlD7qNQq9xZ+fMGAlWuAIeGPM4ck+bbvx2ZclVMJh98rPWMd9HniNWrtMkM4
y4z7cu7hLKlroFpgJKH9kWxlDDCSWE3pxb9RLidff1K3HFps5NDc41Rk8tYqcVU=
=CjjY
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Dec  7 13:59:08 2017
From: openssl at openssl.org (OpenSSL)
Date: Thu, 7 Dec 2017 13:59:08 +0000
Subject: [openssl-users] OpenSSL Security Advisory
Message-ID: <20171207135908.GA26965@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


OpenSSL Security Advisory [07 Dec 2017]
========================================

Read/write after SSL object in error state (CVE-2017-3737)
==========================================================

Severity: Moderate

OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
mechanism. The intent was that if a fatal error occurred during a handshake then
OpenSSL would move into the error state and would immediately fail if you
attempted to continue the handshake. This works as designed for the explicit
handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()),
however due to a bug it does not work correctly if SSL_read() or SSL_write() is
called directly. In that scenario, if the handshake fails then a fatal error
will be returned in the initial function call. If SSL_read()/SSL_write() is
subsequently called by the application for the same SSL object then it will
succeed and the data is passed without being decrypted/encrypted directly from
the SSL/TLS record layer.

In order to exploit this issue an application bug would have to be present that
resulted in a call to SSL_read()/SSL_write() being issued after having already
received a fatal error.

This issue does not affect OpenSSL 1.1.0.

OpenSSL 1.0.2 users should upgrade to 1.0.2n

This issue was reported to OpenSSL on 10th November 2017 by David Benjamin
(Google). The fix was proposed by David Benjamin and implemented by Matt Caswell
of the OpenSSL development team.

rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738)
=========================================================

Severity: Low

There is an overflow bug in the AVX2 Montgomery multiplication procedure
used in exponentiation with 1024-bit moduli. No EC algorithms are affected.
Analysis suggests that attacks against RSA and DSA as a result of this defect
would be very difficult to perform and are not believed likely. Attacks
against DH1024 are considered just feasible, because most of the work
necessary to deduce information about a private key may be performed offline.
The amount of resources required for such an attack would be significant.
However, for an attack on TLS to be meaningful, the server would have to share
the DH1024 private key among multiple clients, which is no longer an option
since CVE-2016-0701.

This only affects processors that support the AVX2 but not ADX extensions
like Intel Haswell (4th generation).

Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732
and CVE-2015-3193.

Due to the low severity of this issue we are not issuing a new release of
OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it
becomes available. The fix is also available in commit e502cc86d in the OpenSSL
git repository.

OpenSSL 1.0.2 users should upgrade to 1.0.2n

This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin
(Google). The issue was originally found via the OSS-Fuzz project. The fix was
developed by Andy Polyakov of the OpenSSL development team.

Note
====

Support for version 1.0.1 ended on 31st December 2016. Support for versions
0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer
receiving security updates.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20171207.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaKUFJAAoJENnE0m0OYESRp1UH/1Z8hBb1dM82Lnn3b0pQ1LjF
xBqs0cBFax6z8gelZzUI3CEJe78n3YB6jJiyCDOvrsrb9dx4kGvt97R9x9Np6glh
/cL98I1mVwLdLciE1WeBPBFDijp5Bii4pz3q4StFGmh9g9cQ70onz8OO0RB9GSS5
dpbRcbOZLcyt3Lnqmnx86SLAdGgF635SO0EE10txDXjgEUK3Zo+gT+/jelwoNLXT
mtYfqgXp6+Eqa08Qq3Nmrgqz4azhFLD5szixmnXQwbP+OpiT+zpNXsV5qqemWFn9
aV2qzDJJtrpObaPXSqKCBUA7C1qYmj9OmeaDUVJ29vS1mm09hs18if954ib6nbw=
=MmWs
-----END PGP SIGNATURE-----

From Michael.Wojcik at microfocus.com  Thu Dec  7 14:05:32 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 7 Dec 2017 14:05:32 +0000
Subject: [openssl-users] ECC ciphers in OpenSSL and Citricom
 Patent/License terms
In-Reply-To: <e7169dc4-c573-6e8b-049e-8a5d5931895d@wisemo.com>
References: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E81@prvxmb03.microfocus.com>
 <4a8bab67-8e7d-af37-6ee0-6bbb9bf62269@wisemo.com>
 <CC7BE721-65E1-41EC-BC1B-2D0745E605F0@akamai.com>
 <e7169dc4-c573-6e8b-049e-8a5d5931895d@wisemo.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE3D1B@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Jakob Bohm
> Sent: Thursday, December 07, 2017 08:41
> To: openssl-users at openssl.org
> 
> And I would still say that "consult a lawyer" is a useless answer,
> especially as most OpenSSL users will be in the same legal situation,
> and lawyers opinions on patent matters are frequently found by courts
> to be wrong anyway.

Well, I suppose we'll have to disagree on that point. Speaking hypothetically, if I were the product owner for a commercial software product that used OpenSSL, I would most certainly be raising the question with corporate counsel.

This is a complex and fraught area, and the OpenSSL Foundation is not able (and I'm sure not inclined to try) to indemnify OpenSSL users against infringement claims. To a large extent it doesn't matter what they say. A license file in the OpenSSL distribution is not likely to discourage an IP owner from claiming infringement if they're so inclined. At that point "local" lawyers will be involved whether you like it or not.

I also don't believe that "most OpenSSL users will be in the same legal situation". Here again, patent law is complicated. And more importantly, well-heeled users are much more likely targets of actual infringement claims, which is a very different situation indeed.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


 

From rsalz at akamai.com  Thu Dec  7 16:02:28 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 7 Dec 2017 16:02:28 +0000
Subject: [openssl-users] ECC ciphers in OpenSSL and Citricom
 Patent/License terms
In-Reply-To: <e7169dc4-c573-6e8b-049e-8a5d5931895d@wisemo.com>
References: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E81@prvxmb03.microfocus.com>
 <4a8bab67-8e7d-af37-6ee0-6bbb9bf62269@wisemo.com>
 <CC7BE721-65E1-41EC-BC1B-2D0745E605F0@akamai.com>
 <e7169dc4-c573-6e8b-049e-8a5d5931895d@wisemo.com>
Message-ID: <61F08138-E3C6-42A0-BA2A-AE8641F9D6C3@akamai.com>

? The OP claimed the file was only in the FIPS tarballs, and not in the
    OpenSSL tarballs.  My questions were based on that.
    
So the OP is wrong. 

? Saying "in the distribution and website" is also quite vague and
    thus another example of a non-answer.
    
No it?s not.  The OpenSSL distributions, starting with 1.1.0 have a README.ECC file that points to a license on the Website.  

We are an open source project, we do not provide legal advice.  This is consistent, we have never given patent advice, nor crypto import or export advice.



From jb-openssl at wisemo.com  Thu Dec  7 17:01:09 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 7 Dec 2017 18:01:09 +0100
Subject: [openssl-users] ECC ciphers in OpenSSL and Citricom
 Patent/License terms
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AE3D1B@prvxmb03.microfocus.com>
References: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E81@prvxmb03.microfocus.com>
 <4a8bab67-8e7d-af37-6ee0-6bbb9bf62269@wisemo.com>
 <CC7BE721-65E1-41EC-BC1B-2D0745E605F0@akamai.com>
 <e7169dc4-c573-6e8b-049e-8a5d5931895d@wisemo.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE3D1B@prvxmb03.microfocus.com>
Message-ID: <391b820c-b1c6-e569-2d57-ea92e173b2ca@wisemo.com>

On 07/12/2017 15:05, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Jakob Bohm
>> Sent: Thursday, December 07, 2017 08:41
>> To: openssl-users at openssl.org
>>
>> And I would still say that "consult a lawyer" is a useless answer,
>> especially as most OpenSSL users will be in the same legal situation,
>> and lawyers opinions on patent matters are frequently found by courts
>> to be wrong anyway.
> Well, I suppose we'll have to disagree on that point. Speaking hypothetically, if I were the product owner for a commercial software product that used OpenSSL, I would most certainly be raising the question with corporate counsel.
>
> This is a complex and fraught area, and the OpenSSL Foundation is not able (and I'm sure not inclined to try) to indemnify OpenSSL users against infringement claims. To a large extent it doesn't matter what they say. A license file in the OpenSSL distribution is not likely to discourage an IP owner from claiming infringement if they're so inclined. At that point "local" lawyers will be involved whether you like it or not.
Of cause OpenSSL cannot indemnify users.? This is why my actual
questions to the OpenSSL project were mostly about what 3rd party
assurances that the project had received and could pass on.? For
example written patent license statements by Sun/Oracle (in
conjunction with their 2002 ECC contribution), waivers by
CertiCom etc.

Even if some companies will want to run everything by their
corporate council, corporate council can make much more useful
statements if they can start from some legal documents and
statements rather than having the lawyers try to pour over C
code and published patents.

> I also don't believe that "most OpenSSL users will be in the same legal situation". Here again, patent law is complicated. And more importantly, well-heeled users are much more likely targets of actual infringement claims, which is a very different situation indeed.
>
Point is, that in this global world, most producers are potentially
exposed in lots of "foreign" jurisdictions, and most corporate
counsel, while potentially well-heeled in general patent law, are
unlikely to have specific knowledge of the various patents, licenses
and waivers applicable to ECC crypto.

Being able to say "we only ship to customers in China and outer Mongolia,
and under those local laws there is no risk" is a lot rarer than "we ship
globally except a few problematic destinations, we don't want to be
hauled to the Eastern district of Texas by Certicom, so we want to
know if we have contractual assurances that Certicom is OK with using
OpenSSL builds that have the ECC code enabled"

That latter situation happens to also be the situation of the OpenSSL
project itself, except the degree of being a litigation magnet, thus the
likelihood that the project has obtained some legal documents that can
be passed on, making no independent promises other than those being true
and accurate copies of documents signed by their outside authors.

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 Andrew_Porter at bmc.com  Thu Dec  7 16:55:17 2017
From: Andrew_Porter at bmc.com (Porter, Andrew)
Date: Thu, 7 Dec 2017 16:55:17 +0000
Subject: [openssl-users] "make test" error for release 1.0.2n
Message-ID: <68bc4b7e10664528ba7ebf7c1f432c8c@phx-exmbprd-02.adprod.bmc.com>

My "make test" for today's 1.0.2n release is getting an error at the very last (I think)
"test_bad_dtls" step. This is FIPS-enabled, built with the 2.0.12 FIPS module. With the
Previous 1.0.2m release the "test_bad_dtls" step silently completed but with 1.0.2n I get:

test_bad_dtls
../util/shlib_wrap.sh ./bad_dtls_test
test_fatalerr
../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem ../apps/server.pem
SSL_accept() failed -1, 1
47220303776416:error:140800FF:SSL routines:ssl3_accept:unknown state:s3_srvr.c:869:
make[1]: Leaving directory `/data1/xd/openssl-1.0.2n/test'
OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a
OpenSSL 1.0.2n-fips  7 Dec 2017
built on: reproducible build, date unspecified
platform: linux-x86_64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: gcc -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
 -I/usr/local/ssl/fips-2.0/include -DRC4_ASM -DSHA1_ASM -DSHA256_ASM
 -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM
 -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM

Probably I don't care, since my application isn't using DTLS, but I'd just like a confirmation
that this is OK.

- Thanks, Andrew Porter

From openssl-users at dukhovni.org  Thu Dec  7 18:40:44 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 7 Dec 2017 13:40:44 -0500
Subject: [openssl-users] [openssl-dev] OpenSSL version 1.0.2n published
In-Reply-To: <20171207135543.GA23228@openssl.org>
References: <20171207135543.GA23228@openssl.org>
Message-ID: <3F998BAE-8C11-4ED0-ADB5-046E978ECDF9@dukhovni.org>



> On Dec 7, 2017, at 8:55 AM, OpenSSL <openssl at openssl.org> wrote:
> 
>   OpenSSL - The Open Source toolkit for SSL/TLS
>   https://www.openssl.org/
> 
>   The OpenSSL project team is pleased to announce the release of
>   version 1.0.2n of our open source toolkit for SSL/TLS. For details
>   of changes and known issues see the release notes at:
> 
>        https://www.openssl.org/news/openssl-1.0.2-notes.html

It is perhaps useful to expand on one sentence in the CHANGE log:

 Changes between 1.0.2m and 1.0.2n [7 Dec 2017]

  *) Read/write after SSL object in error state

     OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
     mechanism. The intent was that if a fatal error occurred during a handshake
     then OpenSSL would move into the error state and would immediately fail if
     you attempted to continue the handshake. This works as designed for the
     explicit handshake functions (SSL_do_handshake(), SSL_accept() and
     SSL_connect()), however due to a bug it does not work correctly if
     SSL_read() or SSL_write() is called directly. ...

What "directly" means at the end of the quoted text is "directly, without
first performing an explicit handshake".  In that case the handshake is
an implicit side-effect of the first read or write call, and it was in
that case that the "error state" mechanism did not behave as intended.

-- 
	Viktor.


From matt at openssl.org  Fri Dec  8 00:12:45 2017
From: matt at openssl.org (Matt Caswell)
Date: Fri, 8 Dec 2017 00:12:45 +0000
Subject: [openssl-users] "make test" error for release 1.0.2n
In-Reply-To: <68bc4b7e10664528ba7ebf7c1f432c8c@phx-exmbprd-02.adprod.bmc.com>
References: <68bc4b7e10664528ba7ebf7c1f432c8c@phx-exmbprd-02.adprod.bmc.com>
Message-ID: <8d6a7abd-5d5a-88f1-1e8c-6bffc43b9576@openssl.org>



On 07/12/17 16:55, Porter, Andrew wrote:
> My "make test" for today's 1.0.2n release is getting an error at the very last (I think)
> "test_bad_dtls" step. This is FIPS-enabled, built with the 2.0.12 FIPS module. With the
> Previous 1.0.2m release the "test_bad_dtls" step silently completed but with 1.0.2n I get:
> 
> test_bad_dtls
> ../util/shlib_wrap.sh ./bad_dtls_test
> test_fatalerr
> ../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem ../apps/server.pem
> SSL_accept() failed -1, 1
> 47220303776416:error:140800FF:SSL routines:ssl3_accept:unknown state:s3_srvr.c:869:
> make[1]: Leaving directory `/data1/xd/openssl-1.0.2n/test'
> OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a
> OpenSSL 1.0.2n-fips  7 Dec 2017
> built on: reproducible build, date unspecified
> platform: linux-x86_64
> options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
> compiler: gcc -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
> -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
>  -I/usr/local/ssl/fips-2.0/include -DRC4_ASM -DSHA1_ASM -DSHA256_ASM
>  -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM
>  -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> 
> Probably I don't care, since my application isn't using DTLS, but I'd just like a confirmation
> that this is OK.

This is coming from "test_fatalerr" not "test_bad_dtls". This question
came up on the openssl-dev list as well. I'll give the same answer I
gave there:

The 1.0.2 test framework is very noisy (its much better in 1.1.0). There
are a whole bunch of tests that output "failures" and "errors" which are
actually normal operation (because they are testing failure and error
conditions). The above is normal output from a successful test. The
important thing is if the overall "make test" process completes
successfully or exits with an error.

Matt


From director at openca.org  Fri Dec  8 03:41:39 2017
From: director at openca.org (Dr. Pala)
Date: Thu, 7 Dec 2017 22:41:39 -0500
Subject: [openssl-users] Windows OpenSSL's FIPS Binaries
Message-ID: <717bb4d6-7fc2-6ede-61ee-67fff82acd5e@openca.org>

Hi all,

does anybody know if there are downloadable binaries of openssl-fips 
and/or openssl-fips-ecp (2.0.16 or earlier) for Windows ?

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171207/c59abc1b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hnnkpeldjinaeeom.png
Type: image/png
Size: 3146 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171207/c59abc1b/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3994 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171207/c59abc1b/attachment-0001.bin>

From bhat.jayalakshmi at gmail.com  Mon Dec 11 05:32:16 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Mon, 11 Dec 2017 11:02:16 +0530
Subject: [openssl-users] ECC ciphers in OpenSSL and Citricom
 Patent/License terms
In-Reply-To: <391b820c-b1c6-e569-2d57-ea92e173b2ca@wisemo.com>
References: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE2E81@prvxmb03.microfocus.com>
 <4a8bab67-8e7d-af37-6ee0-6bbb9bf62269@wisemo.com>
 <CC7BE721-65E1-41EC-BC1B-2D0745E605F0@akamai.com>
 <e7169dc4-c573-6e8b-049e-8a5d5931895d@wisemo.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AE3D1B@prvxmb03.microfocus.com>
 <391b820c-b1c6-e569-2d57-ea92e173b2ca@wisemo.com>
Message-ID: <CALq8RvLk=gu0tiVdK5AVQc9ysAZL16zU9DcaApppT5eY2qLSZQ@mail.gmail.com>

Hi All,

Thanks for the inputs, This gives me a good understanding on these ciphers
usage.

Thanks and Regards
Jayalakshmi

On Thu, Dec 7, 2017 at 10:31 PM, Jakob Bohm <jb-openssl at wisemo.com> wrote:

> On 07/12/2017 15:05, Michael Wojcik wrote:
>
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>>> Of Jakob Bohm
>>> Sent: Thursday, December 07, 2017 08:41
>>> To: openssl-users at openssl.org
>>>
>>> And I would still say that "consult a lawyer" is a useless answer,
>>> especially as most OpenSSL users will be in the same legal situation,
>>> and lawyers opinions on patent matters are frequently found by courts
>>> to be wrong anyway.
>>>
>> Well, I suppose we'll have to disagree on that point. Speaking
>> hypothetically, if I were the product owner for a commercial software
>> product that used OpenSSL, I would most certainly be raising the question
>> with corporate counsel.
>>
>> This is a complex and fraught area, and the OpenSSL Foundation is not
>> able (and I'm sure not inclined to try) to indemnify OpenSSL users against
>> infringement claims. To a large extent it doesn't matter what they say. A
>> license file in the OpenSSL distribution is not likely to discourage an IP
>> owner from claiming infringement if they're so inclined. At that point
>> "local" lawyers will be involved whether you like it or not.
>>
> Of cause OpenSSL cannot indemnify users.  This is why my actual
> questions to the OpenSSL project were mostly about what 3rd party
> assurances that the project had received and could pass on.  For
> example written patent license statements by Sun/Oracle (in
> conjunction with their 2002 ECC contribution), waivers by
> CertiCom etc.
>
> Even if some companies will want to run everything by their
> corporate council, corporate council can make much more useful
> statements if they can start from some legal documents and
> statements rather than having the lawyers try to pour over C
> code and published patents.
>
> I also don't believe that "most OpenSSL users will be in the same legal
>> situation". Here again, patent law is complicated. And more importantly,
>> well-heeled users are much more likely targets of actual infringement
>> claims, which is a very different situation indeed.
>>
>> Point is, that in this global world, most producers are potentially
> exposed in lots of "foreign" jurisdictions, and most corporate
> counsel, while potentially well-heeled in general patent law, are
> unlikely to have specific knowledge of the various patents, licenses
> and waivers applicable to ECC crypto.
>
> Being able to say "we only ship to customers in China and outer Mongolia,
> and under those local laws there is no risk" is a lot rarer than "we ship
> globally except a few problematic destinations, we don't want to be
> hauled to the Eastern district of Texas by Certicom, so we want to
> know if we have contractual assurances that Certicom is OK with using
> OpenSSL builds that have the ECC code enabled"
>
> That latter situation happens to also be the situation of the OpenSSL
> project itself, except the degree of being a litigation magnet, thus the
> likelihood that the project has obtained some legal documents that can
> be passed on, making no independent promises other than those being true
> and accurate copies of documents signed by their outside authors.
>
> 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
>
> --
> 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/20171211/a682b214/attachment.html>

From director at openca.org  Mon Dec 11 22:06:48 2017
From: director at openca.org (Dr. Pala)
Date: Mon, 11 Dec 2017 15:06:48 -0700
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
Message-ID: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>

Hi all,

I am trying to verify a certificate and provide the possibility to 
directly trust an intermediate CA's certificate (not self-signed). After 
setting up the STORE and STORE_CTX and add the intermediate CA to the 
trusted certificates, when I use the "X509_verify_cert(ctx)" I get the 
usual "unable to get issuer certificate" - which would be fine for a 
"non-trusted" cert, but I would expect that to not be an issue for a 
trusted certificate.

Therefore, my question is what is the best method to have that behavior ?

I tried to use the certificate callback to do that, but there is no 
function to get the trusted certificates' stack (i.e., there is a 
X509_STORE_CTX_get0_untrusted() but there is no equivalent for the 
trusted certificates' stack) - so I could not verify if the current 
certificate (in the verify callback call) is in the trusted stack or not...

Maybe there are flags / trust settings that can be used instead ?

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171211/c2272008/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doefdnpajoggmgfb.png
Type: image/png
Size: 3146 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171211/c2272008/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3994 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171211/c2272008/attachment.bin>

From openssl-users at dukhovni.org  Mon Dec 11 22:18:53 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Dec 2017 17:18:53 -0500
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
Message-ID: <931F7E2E-BA60-4016-8626-45DDF3F01BB6@dukhovni.org>



> On Dec 11, 2017, at 5:06 PM, Dr. Pala <director at openca.org> wrote:
> 
> Hi all,
> 
> I am trying to verify a certificate and provide the possibility to directly trust an intermediate CA's certificate (not self-signed). After setting up the STORE and STORE_CTX and add the intermediate CA to the trusted certificates, when I use the "X509_verify_cert(ctx)" I get the usual "unable to get issuer certificate" - which would be fine for a "non-trusted" cert, but I would expect that to not be an issue for a trusted certificate.
> 
> Therefore, my question is what is the best method to have that behavior ?
> 
> I tried to use the certificate callback to do that, but there is no function to get the trusted certificates' stack (i.e., there is a X509_STORE_CTX_get0_untrusted() but there is no equivalent for the trusted certificates' stack) - so I could not verify if the current certificate (in the verify callback call) is in the trusted stack or not...
> 
> Maybe there are flags / trust settings that can be used instead ?

It seems we've neglected to document the X509_V_FLAG_PARTIAL_CHAIN
flag, which can be passed to X509_VERIFY_PARAM_set_flags() to
permit intermediate trust-anchors.

https://www.openssl.org/docs/man1.0.2/crypto/X509_VERIFY_PARAM_set_flags.html
https://www.openssl.org/docs/man1.1.0/crypto/X509_VERIFY_PARAM_set_flags.html


-- 
-- 
	Viktor.


From madwolf at openca.org  Mon Dec 11 23:03:51 2017
From: madwolf at openca.org (Dr. Pala)
Date: Mon, 11 Dec 2017 16:03:51 -0700
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <931F7E2E-BA60-4016-8626-45DDF3F01BB6@dukhovni.org>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
 <931F7E2E-BA60-4016-8626-45DDF3F01BB6@dukhovni.org>
Message-ID: <f21661d3-f0d0-8902-ffcd-dfd9b1fe41e3@openca.org>

Hi Victor,

thanks :D I just tried to set it and I get a different error now : 22 
(certificate chain too long)... I suspect it is a side effect of using 
the? X509_V_FLAG_PARTIAL_CHAIN flag... ? (no chain restrictions are set 
in the certificates themselves...), but I have not dug into the vfy code 
yet...

... any suggestion on how to fix this ? Do you think it is actually a 
bug ? ... or am I missing some other configs / setting I should have 
done for the verify param ?

Cheers,
Max


On 12/11/17 3:18 PM, Viktor Dukhovni wrote:
>
>> On Dec 11, 2017, at 5:06 PM, Dr. Pala <director at openca.org> wrote:
>>
>> Hi all,
>>
>> I am trying to verify a certificate and provide the possibility to directly trust an intermediate CA's certificate (not self-signed). After setting up the STORE and STORE_CTX and add the intermediate CA to the trusted certificates, when I use the "X509_verify_cert(ctx)" I get the usual "unable to get issuer certificate" - which would be fine for a "non-trusted" cert, but I would expect that to not be an issue for a trusted certificate.
>>
>> Therefore, my question is what is the best method to have that behavior ?
>>
>> I tried to use the certificate callback to do that, but there is no function to get the trusted certificates' stack (i.e., there is a X509_STORE_CTX_get0_untrusted() but there is no equivalent for the trusted certificates' stack) - so I could not verify if the current certificate (in the verify callback call) is in the trusted stack or not...
>>
>> Maybe there are flags / trust settings that can be used instead ?
> It seems we've neglected to document the X509_V_FLAG_PARTIAL_CHAIN
> flag, which can be passed to X509_VERIFY_PARAM_set_flags() to
> permit intermediate trust-anchors.
>
> https://www.openssl.org/docs/man1.0.2/crypto/X509_VERIFY_PARAM_set_flags.html
> https://www.openssl.org/docs/man1.1.0/crypto/X509_VERIFY_PARAM_set_flags.html
>
>


From openssl-users at dukhovni.org  Mon Dec 11 23:18:14 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Dec 2017 18:18:14 -0500
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <f21661d3-f0d0-8902-ffcd-dfd9b1fe41e3@openca.org>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
 <931F7E2E-BA60-4016-8626-45DDF3F01BB6@dukhovni.org>
 <f21661d3-f0d0-8902-ffcd-dfd9b1fe41e3@openca.org>
Message-ID: <30B1FCD4-95F6-4D95-B971-1A751C8FF8D5@dukhovni.org>



> On Dec 11, 2017, at 6:03 PM, Dr. Pala <madwolf at openca.org> wrote:
> 
> thanks :D I just tried to set it and I get a different error now : 22 (certificate chain too long)... I suspect it is a side effect of using the  X509_V_FLAG_PARTIAL_CHAIN flag... ? (no chain restrictions are set in the certificates themselves...), but I have not dug into the vfy code yet...

Perhaps you ended up creating a parameter structure with a
depth limit that's too small.  Just configuring partial
chains will never yield a chain that is longer than it
otherwise would be.  In fact you generally get shorter
chains.  So, no this is not a result of using the
new flag, but may be a result of how you're going about
setting the flag.

> ... any suggestion on how to fix this ? Do you think it is actually a bug ? ... or am I missing some other configs / setting I should have done for the verify param ?

You should obtain a reference to the existing parameters
from the context, and modify these to add the new flag.

-- 
	Viktor.


From d3ck0r at gmail.com  Mon Dec 11 23:20:21 2017
From: d3ck0r at gmail.com (J Decker)
Date: Mon, 11 Dec 2017 15:20:21 -0800
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <f21661d3-f0d0-8902-ffcd-dfd9b1fe41e3@openca.org>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
 <931F7E2E-BA60-4016-8626-45DDF3F01BB6@dukhovni.org>
 <f21661d3-f0d0-8902-ffcd-dfd9b1fe41e3@openca.org>
Message-ID: <CAA2GJqXxF6ebr1BBCx-H2p-NghXW2QfTMF1A5OQe-eqM6HoMZA@mail.gmail.com>

I'm pretty sure you need the root also, not just the intermedia ca...
I use a custom generated chain... I encode the root cert in the
application, and then pass it when inintializing the client socket.

This bit of code takes the root cert and adds it to the SSL_CTX the client
socket is created from....
https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L704
( if no root passed, it loads root certs from windows store; haven't
finished linux load cert store)

THis is where the cert chain is verified....
https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L264

looking at that, I guess I should split that if and fail if it fails to get
the peer certificate...

On Mon, Dec 11, 2017 at 3:03 PM, Dr. Pala <madwolf at openca.org> wrote:

> Hi Victor,
>
> thanks :D I just tried to set it and I get a different error now : 22
> (certificate chain too long)... I suspect it is a side effect of using the
> X509_V_FLAG_PARTIAL_CHAIN flag... ? (no chain restrictions are set in the
> certificates themselves...), but I have not dug into the vfy code yet...
>
> ... any suggestion on how to fix this ? Do you think it is actually a bug
> ? ... or am I missing some other configs / setting I should have done for
> the verify param ?
>
> Cheers,
> Max
>
>
> On 12/11/17 3:18 PM, Viktor Dukhovni wrote:
>
>>
>> On Dec 11, 2017, at 5:06 PM, Dr. Pala <director at openca.org> wrote:
>>>
>>> Hi all,
>>>
>>> I am trying to verify a certificate and provide the possibility to
>>> directly trust an intermediate CA's certificate (not self-signed). After
>>> setting up the STORE and STORE_CTX and add the intermediate CA to the
>>> trusted certificates, when I use the "X509_verify_cert(ctx)" I get the
>>> usual "unable to get issuer certificate" - which would be fine for a
>>> "non-trusted" cert, but I would expect that to not be an issue for a
>>> trusted certificate.
>>>
>>> Therefore, my question is what is the best method to have that behavior ?
>>>
>>> I tried to use the certificate callback to do that, but there is no
>>> function to get the trusted certificates' stack (i.e., there is a
>>> X509_STORE_CTX_get0_untrusted() but there is no equivalent for the
>>> trusted certificates' stack) - so I could not verify if the current
>>> certificate (in the verify callback call) is in the trusted stack or not...
>>>
>>> Maybe there are flags / trust settings that can be used instead ?
>>>
>> It seems we've neglected to document the X509_V_FLAG_PARTIAL_CHAIN
>> flag, which can be passed to X509_VERIFY_PARAM_set_flags() to
>> permit intermediate trust-anchors.
>>
>> https://www.openssl.org/docs/man1.0.2/crypto/X509_VERIFY_PAR
>> AM_set_flags.html
>> https://www.openssl.org/docs/man1.1.0/crypto/X509_VERIFY_PAR
>> AM_set_flags.html
>>
>>
>>
> --
> 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/20171211/dcb5d714/attachment.html>

From mcr at sandelman.ca  Mon Dec 11 23:27:39 2017
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 11 Dec 2017 18:27:39 -0500
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
Message-ID: <20132.1513034859@obiwan.sandelman.ca>


I believe that I ran into a similar problem where by I could not pin
('trust') an intermediate certificate (which was not self-signed) for the
purposes of verifying a CMS/PKCS7 object.

I don't have a solution, and I believe that work is required.

Dr. Pala <director at openca.org> wrote:
    > I am trying to verify a certificate and provide the possibility to
    > directly trust an intermediate CA's certificate (not self-signed).
    > After setting up the STORE and STORE_CTX and add the intermediate CA to
    > the trusted certificates, when I use the "X509_verify_cert(ctx)" I get
    > the usual "unable to get issuer certificate" - which would be fine for
    > a "non-trusted" cert, but I would expect that to not be an issue for a
    > trusted certificate.

    > Therefore, my question is what is the best method to have that behavior
    > ?

    > I tried to use the certificate callback to do that, but there is no
    > function to get the trusted certificates' stack (i.e., there is a
    > X509_STORE_CTX_get0_untrusted() but there is no equivalent for the
    > trusted certificates' stack) - so I could not verify if the current
    > certificate (in the verify callback call) is in the trusted stack or
    > not...

    > Maybe there are flags / trust settings that can be used instead ?

    > Cheers, Max

    > --
    > Best Regards, Massimiliano Pala, Ph.D.  OpenCA Labs Director OpenCA
    > Logo



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


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171211/3e080c4f/attachment.sig>

From openssl-users at dukhovni.org  Mon Dec 11 23:28:35 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Dec 2017 18:28:35 -0500
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <CAA2GJqXxF6ebr1BBCx-H2p-NghXW2QfTMF1A5OQe-eqM6HoMZA@mail.gmail.com>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
 <931F7E2E-BA60-4016-8626-45DDF3F01BB6@dukhovni.org>
 <f21661d3-f0d0-8902-ffcd-dfd9b1fe41e3@openca.org>
 <CAA2GJqXxF6ebr1BBCx-H2p-NghXW2QfTMF1A5OQe-eqM6HoMZA@mail.gmail.com>
Message-ID: <B0C23668-3562-444D-ADA5-7239D40CC29E@dukhovni.org>



> On Dec 11, 2017, at 6:20 PM, J Decker <d3ck0r at gmail.com> wrote:
> 
> I'm pretty sure you need the root also, not just the intermedia ca...

The purpose of X509_V_FLAG_PARTIAL_CHAIN is to make it possible
to make do with just the intermediate certificate in the trust
store.  So, no, the root is not always required.

-- 
	Viktor.


From openssl-users at dukhovni.org  Mon Dec 11 23:54:22 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Dec 2017 18:54:22 -0500
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <20132.1513034859@obiwan.sandelman.ca>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
 <20132.1513034859@obiwan.sandelman.ca>
Message-ID: <E312EF2D-CAD5-4800-AFCF-1A6661BB82C3@dukhovni.org>



> On Dec 11, 2017, at 6:27 PM, Michael Richardson <mcr at sandelman.ca> wrote:
> 
> I believe that I ran into a similar problem where by I could not pin
> ('trust') an intermediate certificate (which was not self-signed) for the
> purposes of verifying a CMS/PKCS7 object.
> 
> I don't have a solution, and I believe that work is required.

As I already mentioned a few times, the new X509_V_FLAG_PARTIAL_CHAIN
flag added in 1.0.2 addresses this issue.

To get pinning provide a trust store with just the pinned issuer CA,
and X509_V_FLAG_PARTIAL_CHAIN set.

With OpenSSL 1.1.0 one can also implement pinning by computing a TLSA
record for the pinned CA, and using OpenSSL's DANE support.  OpenSSL
does not do the DNS lookups to find TLSA records, that's up to the
application, so the TLSA records can be entirely synthetic (e.g.
derived from suitable hashes of a pinned CA cert or its public key).

-- 
	Viktor.


From madwolf at openca.org  Tue Dec 12 00:35:05 2017
From: madwolf at openca.org (Dr. Pala)
Date: Mon, 11 Dec 2017 17:35:05 -0700
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <30B1FCD4-95F6-4D95-B971-1A751C8FF8D5@dukhovni.org>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
 <931F7E2E-BA60-4016-8626-45DDF3F01BB6@dukhovni.org>
 <f21661d3-f0d0-8902-ffcd-dfd9b1fe41e3@openca.org>
 <30B1FCD4-95F6-4D95-B971-1A751C8FF8D5@dukhovni.org>
Message-ID: <0f853021-96b1-bfb4-52b1-4c8710175550@openca.org>

Hi Victor,

On 12/11/17 4:18 PM, Viktor Dukhovni wrote:
> [...]
>
> Perhaps you ended up creating a parameter structure with a
> depth limit that's too small.? Just configuring partial
> chains will never yield a chain that is longer than it
> otherwise would be.? In fact you generally get shorter
> chains.? So, no this is not a result of using the
> new flag, but may be a result of how you're going about
> setting the flag.
I actually do not set anything but the flag in the verify parameter, 
that is (error checking removed for clarity):

    param = X509_VERIFY_PARAM_new();
    X509_STORE_CTX_set0_param(ctx, param);
    X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_PARTIAL_CHAIN);
    X509_STORE_CTX_set0_trusted_stack(ctx, trustedCerts); //
    trustedCerts has only the SubCA
    ret = X509_verify_cert(ctx);

    fprintf(stderr, "[%s:%d] ctx->error = %d (%s)\n\n", __FILE__, __LINE__,
     ??? ??? X509_STORE_CTX_get_error(ctx),
    X509_verify_cert_error_string(X509_STORE_CTX_get_error(ctx)));

With this setting, I get the error.. which is the strange part as you 
said (the chain can not be longer :D). Maybe the code thinks that if you 
have a SubCA then you should have an additional level.. and since you do 
not have it, it sends the error... ???
>> ... any suggestion on how to fix this ? Do you think it is actually a bug ? ... or am I missing some other configs / setting I should have done for the verify param ?
> You should obtain a reference to the existing parameters
> from the context, and modify these to add the new flag.
>
Well.. considering the code structure, the flags should be ok (since I 
just set it and then use it right away...) ???

Thanks,
Max

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

From madwolf at openca.org  Tue Dec 12 00:41:35 2017
From: madwolf at openca.org (Dr. Pala)
Date: Mon, 11 Dec 2017 17:41:35 -0700
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <E312EF2D-CAD5-4800-AFCF-1A6661BB82C3@dukhovni.org>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
 <20132.1513034859@obiwan.sandelman.ca>
 <E312EF2D-CAD5-4800-AFCF-1A6661BB82C3@dukhovni.org>
Message-ID: <c248ef48-6d77-ecf1-530c-7e89da629397@openca.org>

Hi Victor,

does it matter that we are not in the TLS case (maybe the code is 
different in the SSL_CTX ) ? I am just trying to validate the chain with 
the TA set to the SubCA... :D

IMHO, the correct (or, better, the expected) behavior (from a 
developer's standpoint) would be to trust keys in the trusted 
certificates list, no matter if they are in the form of a Self-Signed or 
non-Self-Signed certificate - after all, it is a Trust Anchor --> just a 
Public Key :D

Just my 2 cents...

Cheers,
Max


On 12/11/17 4:54 PM, Viktor Dukhovni wrote:
>
>> On Dec 11, 2017, at 6:27 PM, Michael Richardson <mcr at sandelman.ca> wrote:
>>
>> I believe that I ran into a similar problem where by I could not pin
>> ('trust') an intermediate certificate (which was not self-signed) for the
>> purposes of verifying a CMS/PKCS7 object.
>>
>> I don't have a solution, and I believe that work is required.
> As I already mentioned a few times, the new X509_V_FLAG_PARTIAL_CHAIN
> flag added in 1.0.2 addresses this issue.
>
> To get pinning provide a trust store with just the pinned issuer CA,
> and X509_V_FLAG_PARTIAL_CHAIN set.
>
> With OpenSSL 1.1.0 one can also implement pinning by computing a TLSA
> record for the pinned CA, and using OpenSSL's DANE support.  OpenSSL
> does not do the DNS lookups to find TLSA records, that's up to the
> application, so the TLSA records can be entirely synthetic (e.g.
> derived from suitable hashes of a pinned CA cert or its public key).
>


From openssl-users at dukhovni.org  Tue Dec 12 00:45:29 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Dec 2017 19:45:29 -0500
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <0f853021-96b1-bfb4-52b1-4c8710175550@openca.org>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
 <931F7E2E-BA60-4016-8626-45DDF3F01BB6@dukhovni.org>
 <f21661d3-f0d0-8902-ffcd-dfd9b1fe41e3@openca.org>
 <30B1FCD4-95F6-4D95-B971-1A751C8FF8D5@dukhovni.org>
 <0f853021-96b1-bfb4-52b1-4c8710175550@openca.org>
Message-ID: <A089ED29-C4D5-4894-B22A-CFD808921F9A@dukhovni.org>



> On Dec 11, 2017, at 7:35 PM, Dr. Pala <madwolf at openca.org> wrote:
> 
>> Perhaps you ended up creating a parameter structure with a
>> depth limit that's too small.  Just configuring partial
>> chains will never yield a chain that is longer than it
>> otherwise would be.  In fact you generally get shorter
>> chains.  So, no this is not a result of using the
>> new flag, but may be a result of how you're going about
>> setting the flag.

> I actually do not set anything but the flag in the verify parameter, that is (error checking removed for clarity):
> param = X509_VERIFY_PARAM_new();
> X509_STORE_CTX_set0_param(ctx, param);
> X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_PARTIAL_CHAIN);

There's the problem, you're creating new parameters, instead of
modifying the default parameters.

Instead, you must call:

	param = X509_STORE_CTX_get0_param(ctx);
        X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_PARTIAL_CHAIN);

> With this setting, I get the error..

Not surprising, the parameters you created don't have the default depth
setting.

> which is the strange part as you said (the chain can not be longer :D). Maybe the code thinks that if you have a SubCA then you should have an additional level.. and since you do not have it, it sends the error... ???
>>> ... any suggestion on how to fix this ? Do you think it is actually a bug ? ... or am I missing some other configs / setting I should have done for the verify param ?
>>> 
>> You should obtain a reference to the existing parameters
>> from the context, and modify these to add the new flag.
>> 
>> 
> Well.. considering the code structure, the flags should be ok
> (since I just set it and then use it right away...) ???

Actually, no.  You're losing all the verification parameter initialization
done by X509_STORE_CTX_new():

    ctx->param = X509_VERIFY_PARAM_new();
    if (!ctx->param) {
        X509err(X509_F_X509_STORE_CTX_INIT, ERR_R_MALLOC_FAILURE);
        return 0;
    }

    /*
     * Inherit callbacks and flags from X509_STORE if not set use defaults.
     */
    if (store)
        ret = X509_VERIFY_PARAM_inherit(ctx->param, store->param);
    else
        ctx->param->inh_flags |= X509_VP_FLAG_DEFAULT | X509_VP_FLAG_ONCE;

    if (store) {
        ctx->verify_cb = store->verify_cb;
        /* Seems to always be 0 in OpenSSL, else must be idempotent */
        ctx->cleanup = store->cleanup;
    } else
        ctx->cleanup = 0;

    if (ret)
        ret = X509_VERIFY_PARAM_inherit(ctx->param,
                                        X509_VERIFY_PARAM_lookup("default"));

-- 
	Viktor.


From openssl-users at dukhovni.org  Tue Dec 12 01:04:30 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Dec 2017 20:04:30 -0500
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <c248ef48-6d77-ecf1-530c-7e89da629397@openca.org>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
 <20132.1513034859@obiwan.sandelman.ca>
 <E312EF2D-CAD5-4800-AFCF-1A6661BB82C3@dukhovni.org>
 <c248ef48-6d77-ecf1-530c-7e89da629397@openca.org>
Message-ID: <7575CCBC-7548-4BC3-9D78-47D82427E304@dukhovni.org>



> On Dec 11, 2017, at 7:41 PM, Dr. Pala <madwolf at openca.org> wrote:
> 
> Does it matter that we are not in the TLS case?

No, the issue is not TLS-specific.

> IMHO, the correct (or, better, the expected) behavior (from a developer's standpoint) would be to trust keys in the trusted certificates list, no matter if they are in the form of a Self-Signed or non-Self-Signed certificate - after all, it is a Trust Anchor --> just a Public Key :D

Intermediate CAs in the trust store were historically used just
to augment the peer's chain in case they were left out, and not
necessarily to signal independent trust in the intermediate CA.

The new flag makes it possible to indicate that you fully trust
also the intermediate CAs in the trust store.

With OpenSSL 1.1.0 or later, you can also decorate intermediate
CAs with explicit auxiliary trust EKUs and instead of storing
a regular X509 "CERTIFICATE" store a "TRUSTED CERTIFICATE".
Such intermediate CAs will work also for applications that don't
set X509_V_FLAG_PARTIAL_CHAIN.  That, together with the change
to default X509_V_FLAG_TRUSTED_FIRST, makes it possible to deploy
trusted intermediates with no application code changes.

Which reminds me, with OpenSSL 1.0.2 you should also set
X509_V_FLAG_TRUSTED_FIRST.  We did not backport that default
change to the stable 1.0.2 release out of caution, but it is
I think a more sensible default behaviour.

-- 
-- 
	Viktor.


From madwolf at openca.org  Tue Dec 12 01:15:00 2017
From: madwolf at openca.org (Dr. Pala)
Date: Mon, 11 Dec 2017 18:15:00 -0700
Subject: [openssl-users] Certificate Verify and non-root Trust Anchors
In-Reply-To: <A089ED29-C4D5-4894-B22A-CFD808921F9A@dukhovni.org>
References: <db086de2-efaf-1e72-8a54-db165a290290@openca.org>
 <931F7E2E-BA60-4016-8626-45DDF3F01BB6@dukhovni.org>
 <f21661d3-f0d0-8902-ffcd-dfd9b1fe41e3@openca.org>
 <30B1FCD4-95F6-4D95-B971-1A751C8FF8D5@dukhovni.org>
 <0f853021-96b1-bfb4-52b1-4c8710175550@openca.org>
 <A089ED29-C4D5-4894-B22A-CFD808921F9A@dukhovni.org>
Message-ID: <69374209-0166-9411-745d-6dafe5fedaf4@openca.org>

Hi Victor,

Ahhhh... that is why :D I wrongly assumed that the newly created 
parameters would hold the same initialization. This approach works!

Thanks again!

Cheers,
Max

On 12/11/17 5:45 PM, Viktor Dukhovni wrote:
>
>> On Dec 11, 2017, at 7:35 PM, Dr. Pala <madwolf at openca.org> wrote:
>>
>>> Perhaps you ended up creating a parameter structure with a
>>> depth limit that's too small.  Just configuring partial
>>> chains will never yield a chain that is longer than it
>>> otherwise would be.  In fact you generally get shorter
>>> chains.  So, no this is not a result of using the
>>> new flag, but may be a result of how you're going about
>>> setting the flag.
>> I actually do not set anything but the flag in the verify parameter, that is (error checking removed for clarity):
>> param = X509_VERIFY_PARAM_new();
>> X509_STORE_CTX_set0_param(ctx, param);
>> X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_PARTIAL_CHAIN);
> There's the problem, you're creating new parameters, instead of
> modifying the default parameters.
>
> Instead, you must call:
>
> 	param = X509_STORE_CTX_get0_param(ctx);
>          X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_PARTIAL_CHAIN);
>
>> With this setting, I get the error..
> Not surprising, the parameters you created don't have the default depth
> setting.
>
>> which is the strange part as you said (the chain can not be longer :D). Maybe the code thinks that if you have a SubCA then you should have an additional level.. and since you do not have it, it sends the error... ???
>>>> ... any suggestion on how to fix this ? Do you think it is actually a bug ? ... or am I missing some other configs / setting I should have done for the verify param ?
>>>>
>>> You should obtain a reference to the existing parameters
>>> from the context, and modify these to add the new flag.
>>>
>>>
>> Well.. considering the code structure, the flags should be ok
>> (since I just set it and then use it right away...) ???
> Actually, no.  You're losing all the verification parameter initialization
> done by X509_STORE_CTX_new():
>
>      ctx->param = X509_VERIFY_PARAM_new();
>      if (!ctx->param) {
>          X509err(X509_F_X509_STORE_CTX_INIT, ERR_R_MALLOC_FAILURE);
>          return 0;
>      }
>
>      /*
>       * Inherit callbacks and flags from X509_STORE if not set use defaults.
>       */
>      if (store)
>          ret = X509_VERIFY_PARAM_inherit(ctx->param, store->param);
>      else
>          ctx->param->inh_flags |= X509_VP_FLAG_DEFAULT | X509_VP_FLAG_ONCE;
>
>      if (store) {
>          ctx->verify_cb = store->verify_cb;
>          /* Seems to always be 0 in OpenSSL, else must be idempotent */
>          ctx->cleanup = store->cleanup;
>      } else
>          ctx->cleanup = 0;
>
>      if (ret)
>          ret = X509_VERIFY_PARAM_inherit(ctx->param,
>                                          X509_VERIFY_PARAM_lookup("default"));
>


From mshirley at nsslabs.com  Wed Dec 13 18:09:01 2017
From: mshirley at nsslabs.com (Michael Shirley)
Date: Wed, 13 Dec 2017 18:09:01 +0000
Subject: [openssl-users] Multiple parallel connections in s_server?
Message-ID: <B2BCC706-0880-4CE3-8E51-F01412B88104@contoso.com>

Apologies if this has been answered before somewhere, but I could not find a reference to it in the docs:
Is s_server capable of handling multiple client connections in parallel, or is processing of each connection serial? For example, if I open a connection to s_server with one client by completing a TCP 3-way handshake, but pause before sending a client hello to initiate the SSL handshake, and then I open another connection from a different client. Will s_server hold the second session without proceeding through the SSL handshake with a server hello message until the first connection completes?

Thanks,
-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171213/7476624f/attachment.html>

From rsalz at akamai.com  Wed Dec 13 22:37:19 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 13 Dec 2017 22:37:19 +0000
Subject: [openssl-users] Multiple parallel connections in s_server?
Message-ID: <CF0F0B8C-B244-417D-9EF9-AF68A63BA5C7@akamai.com>

The s_server program is not multi-threaded, it does one connection at a time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171213/888dd2fd/attachment-0001.html>

From mynidiravichandra at gmail.com  Thu Dec 14 12:38:34 2017
From: mynidiravichandra at gmail.com (Ravichandra)
Date: Thu, 14 Dec 2017 18:08:34 +0530
Subject: [openssl-users] Measure OpenSSL DHE performance
Message-ID: <CADsCSeT46vU35_hP86vziiwGQ8SeJgBFwZzHSQ7Wb7xEpbFm4w@mail.gmail.com>

Hi,
  I am trying to measure performance of DH operations in OpenSSL. I see
that OpenSSL speed application doesn't support measuring DH performance. Is
there a way to measure DH performance using some openssl application?

Thanks
Ravichandra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171214/04ccafb8/attachment.html>

From kgoldman at us.ibm.com  Thu Dec 14 18:11:21 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 14 Dec 2017 13:11:21 -0500
Subject: [openssl-users] Certificate for RSA 2048 key says 2058
Message-ID: <p0uert$mbm$1@blaine.gmane.org>

I generate a key and self signed certificate like this:

 > openssl genrsa -out cakey.pem -aes256 -passout pass:rrrr 2048
 > openssl req -new -x509 -key cakey.pem -out cacert.pem -days 3650

When I dump the certificate, I see
	....
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
                 Public-Key: (2058 bit)
                 Modulus:
                     02:b1:4c:dd:59:4d:72:8d:93:4b:e5:07:89:53:f7:
	....

Why 2058 - 10 extra bits?  I know that, at times, ASN.1 DER needs an 
extra byte to make a number positive, but 10 bits?


From openssl-users at dukhovni.org  Thu Dec 14 18:34:41 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 14 Dec 2017 13:34:41 -0500
Subject: [openssl-users] Certificate for RSA 2048 key says 2058
In-Reply-To: <p0uert$mbm$1@blaine.gmane.org>
References: <p0uert$mbm$1@blaine.gmane.org>
Message-ID: <D4D7B2F0-AEBA-4054-A88E-67AB6DCF1687@dukhovni.org>



> On Dec 14, 2017, at 1:11 PM, Ken Goldman <kgoldman at us.ibm.com> wrote:
> 
> I generate a key and self signed certificate like this:
> 
> > openssl genrsa -out cakey.pem -aes256 -passout pass:rrrr 2048
> > openssl req -new -x509 -key cakey.pem -out cacert.pem -days 3650
> 
> When I dump the certificate, I see
> 	....
>        Subject Public Key Info:
>            Public Key Algorithm: rsaEncryption
>                Public-Key: (2058 bit)
>                Modulus:
>                    02:b1:4c:dd:59:4d:72:8d:93:4b:e5:07:89:53:f7:
> 	....
> 
> Why 2058 - 10 extra bits?  I know that, at times, ASN.1 DER needs an extra byte to make a number positive, but 10 bits?

What version of OpenSSL is this?  When I try this with OpenSSL 1.1.0 I get:

$ openssl version 
OpenSSL 1.1.0h-dev  xx XXX xxxx

$ for i in $(seq 20); do openssl req -nodes -new -x509 -newkey rsa:2048 -keyout cakey.pem -out cacert.pem -days 3650 -subj "/CN=Root CA" 2>/dev/null; openssl x509 -text -in cacert.pem | grep 'Public-Key:'; done
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)
                Public-Key: (2048 bit)

Same results with master from git.

-- 
	Viktor.


From grace.priscilla at gmail.com  Fri Dec 15 09:53:54 2017
From: grace.priscilla at gmail.com (Grace Priscilla Jero)
Date: Fri, 15 Dec 2017 15:23:54 +0530
Subject: [openssl-users] Issue on DTLS over UDP
Message-ID: <CAGfOHcVQVPnBwHYy0jXC3zRNZcsdhSJ6mRA1P4gmPdOJbdO_Zg@mail.gmail.com>

Hi All,

We are having an issue with DTLS on UDP.

The scenario is that, when a client of DTLS version 1.2 is trying to
connect to a server which is at version DTLS 1.0 the SSL_accept
continuously loops with error 2. The ALERT is not processed.
Is this a known bug?

Because of the loop, the application is unable to process new changes.

Thanks,
Grace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171215/27f1c42a/attachment.html>

From colony.three at protonmail.ch  Sun Dec 17 23:46:38 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Sun, 17 Dec 2017 18:46:38 -0500
Subject: [openssl-users] Lattice Ciphers
Message-ID: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>

I find that Firefox refuses to do any ephemeral ciphers whatsoever.  What the heck?  Why am I surprised.  Somebody paid them.

If you follow Schnieder, elliptic curve is not an option.

I know you guys are severely underfunded, but is there any chance that lattice encryption will be coming soon?  I've searched until my face turned blue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171217/b3e5bfb6/attachment.html>

From rsalz at akamai.com  Sun Dec 17 23:58:08 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 17 Dec 2017 23:58:08 +0000
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
Message-ID: <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>

  *   I find that Firefox refuses to do any ephemeral ciphers whatsoever.  What the heck?  Why am I surprised.  Somebody paid them.

I don?t know what server you are testing against, but FF does ECDHE all the time with no problems.



  *   If you follow Schnieder, elliptic curve is not an option.

That?s interesting, you have a reference for that?



  *   I know you guys are severely underfunded, but is there any chance that lattice encryption will be coming soon?  I've searched until my face turned blue.

We will most likely follow the IETF recommendation and see what the NIST post-quantum work comes up with.  That?s my personal opinion, not necessarily that of the whole time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171217/cccc7589/attachment-0001.html>

From aerowolf at gmail.com  Mon Dec 18 01:24:17 2017
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Sun, 17 Dec 2017 17:24:17 -0800
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
Message-ID: <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>

On Sun, Dec 17, 2017 at 3:58 PM, Salz, Rich via openssl-users
<openssl-users at openssl.org> wrote:

>> If you follow Schnieder, elliptic curve is not an option.
>
> That?s interesting, you have a reference for that?

I'm guessing OP's referring to "Applied Cryptography, 2nd Edition".
There was one page on elliptical curve cryptography, and it didn't
give any real information on what it was, what problem it uses (the
discrete logarithm problem), how it's used, or how DH is adapted to
use it.  The book was pretty much entirely against software patents,
and because ECC had been freshly patented it seemed to be much more
scary about the topic than it should have been.

-Kyle H

From colony.three at protonmail.ch  Mon Dec 18 06:38:51 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Mon, 18 Dec 2017 01:38:51 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
 <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>
Message-ID: <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>

> - I find that Firefox refuses to do any ephemeral ciphers whatsoever.  What the heck?  Why am I surprised.  Somebody paid them.
>
> I don?t know what server you are testing against, but FF does ECDHE all the time with no problems.

I should have said, "I find that Firefox refuses to do any ephemeral ciphers whatsoever, which are not elliptic curve. (referring to DHE, EDH, et al)  What the heck?  Why am I surprised.  Somebody paid them.   Firefox insists on EC."

> - If you follow Schnieder, elliptic curve is not an option.
>
> That?s interesting, you have a reference for that?

Certainly.  Below.

> - I know you guys are severely underfunded, but is there any chance that lattice encryption will be coming soon?  I've searched until my face turned blue.
>
> We will most likely follow the IETF recommendation and see what the NIST post-quantum work comes up with.  That?s my personal opinion, not necessarily that of the whole time.

In August 2015, the NSA announced that it is planning to introduce a list of approved crypto methods that would resist quantum computers.  In April 2017, NIST naturally followed suit, starting a public vetting process which will last 4 to 6 years.  Needless to say, I am hoping that there will be lattice open-source alternatives which are not based on NIST algos.  I do enterprise infosec, and if the NSA can do it, KGB probably has similar methods, not to mention Russian, Israeli, & Chinese haqxors, the Norks, corporate operations, and so on.  Any crypto weakening, whether through flaw or Intent, is the wrong thing.

G**gle's [Eric Schmidt says](https://en.wikipedia.org/wiki/Eric_Schmidt#Privacy), "If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place.  This is a profoundly undemocratic attitude.  What would Thomas Paine, or Ben Franklin, or Patrick Henry say to this?

> On Sun, Dec 17, 2017 at 3:58 PM, Salz, Rich via openssl-users
>
> openssl-users at openssl.org wrote:
>
>>> If you follow Schnieder, elliptic curve is not an option.
>>
>> That?s interesting, you have a reference for that?
>>
>> I'm guessing OP's referring to "Applied Cryptography, 2nd Edition".
>> There was one page on elliptical curve cryptography, and it didn't
>> give any real information on what it was, what problem it uses (the
>> discrete logarithm problem), how it's used, or how DH is adapted to
>> use it. The book was pretty much entirely against software patents,
>> and because ECC had been freshly patented it seemed to be much more
>> scary about the topic than it should have been.

No:  https://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance ... and many more Schnier articles.  He puts out a monthly newsletter.

The NSA actually provided the elliptic curves for NIST's standards.  And the Snowden docs now show that those curves are related.

(Unfortunately Schnier's own website doesn't take his advice for some reason -- he's busy)

Also Apache is not actually enforcing server-ordering of ciphers BTW, but NginX does.

PS - does OpenSSL get funding from the DoD?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/75e4a552/attachment.html>

From rsalz at akamai.com  Mon Dec 18 12:56:45 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 18 Dec 2017 12:56:45 +0000
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
 <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
Message-ID: <1E374546-F832-4F6C-96C4-32CA901A05F5@akamai.com>

Okay, FF does ECDHE not DHE/EDH.  The whole industry does that, and most are using X25519 which was developed by Dan Bernstein.

The Guardian article you referenced didn?t even have the word curve in it.  My question ? do you have a reference that shows Schneier says not to use elliptic curve ? was not answered.

  *   The NSA actually provided the elliptic curves for NIST's standards.  And the Snowden docs now show that those curves are related.
No they do not show that the curves are related.  And BTW, NIST just put 25519 and 448 into their recommended list.

  *   PS - does OpenSSL get funding from the DoD?
Not that we know of, not at the present time.  Various branches did help fund FIPS work in the past.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/459f0230/attachment-0001.html>

From noloader at gmail.com  Mon Dec 18 13:39:57 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 18 Dec 2017 08:39:57 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
 <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
Message-ID: <CAH8yC8m3d+buLoMLzi0GMsf0N-kSmmaAetRrroAaxu=eG3DYHQ@mail.gmail.com>

On Mon, Dec 18, 2017 at 1:38 AM, Colony.three via openssl-users
<openssl-users at openssl.org> wrote:
>
> G**gle's Eric Schmidt says, "If you have something that you don't want
> anyone to know, maybe you shouldn't be doing it in the first place.  This is
> a profoundly undemocratic attitude.  What would Thomas Paine, or Ben
> Franklin, or Patrick Henry say to this?

Off-topic, but... I was angry when I first read that, too.

Later I realized that was the best warning Google and Schmidt could
give. He basically told you government has infiltrated their systems,
and you should avoid their systems if security and privacy matters.

It is not just Google, but Google is the only one who has warned you.
Government has infiltrated other systems, including Apple, Amazon,
Microsoft, Saleforce, Rackspace and friends. You should be angry the
others have not warned you :)

Just avoid Google, Microsoft, Amazon and friends if your security and
privacy matters.

Jeff

From colony.three at protonmail.ch  Mon Dec 18 16:26:21 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Mon, 18 Dec 2017 11:26:21 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
 <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
 <1E374546-F832-4F6C-96C4-32CA901A05F5@akamai.com>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
Message-ID: <MhHFiNzUVYeSM90-yNhBlFcat-i2WGur4hMJJEVoGi2HGi7GCtD6aV6RzVnTjhzJvwru7pfJoIrzdzuW9cCJFw==@protonmail.ch>

>> Okay, FF does ECDHE not DHE/EDH.  The whole industry does that, and most are using X25519 which was developed by Dan Bernstein.
>
> FF [claims it does DHE/EDH](https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29), but it does not actually, in practice.  It does either EC, or RSA.  I've tested it. (v52)  This does not look like an accident.
>
>>  The Guardian article you referenced didn?t even have the word curve in it.  My question ? do you have a reference that shows Schneier says not to use elliptic curve ? was not answered.
>
> You don't have to read the article if you don't want to.
> "Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can."
>
>> - The NSA actually provided the elliptic curves for NIST's standards.  And the Snowden docs now show that those curves are related.
>>
>> No they do not show that the curves are related.  And BTW, NIST just put 25519 and 448 into their recommended list.
>
> By its nature (secrecy), nothing public will prove the curves are related.  But Snowden documents show that they are.  And related curves have an inherent shortcut to cracking, which any well-funded haqxor or state-sponsored entity will have access to.
>
> From: noloader at gmail.com
>
>>> Later I realized that was the best warning Google and Schmidt could
>>> give. He basically told you government has infiltrated their systems,
>>> and you should avoid their systems if security and privacy matters.
>
> What great PR, that it's become almost instinctive for people to ascribe benevolance to G**gle.  I believe that Schmidt was telling us his true position though.
>
> The one I am angry with is Mozilla, for not giving us a choice.  Chrome is a choice?!  Safari is a choice?!  IE is a choice?!  No.  They are not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/c44d3e97/attachment.html>

From colony.three at protonmail.ch  Mon Dec 18 16:47:14 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Mon, 18 Dec 2017 11:47:14 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
 <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
 <1E374546-F832-4F6C-96C4-32CA901A05F5@akamai.com>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
Message-ID: <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>

> - FF [claims it does DHE/EDH](https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.mozilla.org_Security_Server-5FSide-5FTLS-23Intermediate-5Fcompatibility-5F.28default.29&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=XJoX203uiiC98n6L2888TI9zC37FTWeD7taNoV50GDE&s=v0qGxpAFrqvTmiNnI5_Cl-Yd-tKrA-FDw6jO-lERXjY&e=), but it does not actually, in practice.  It does either EC, or RSA.  I've tested it. (v52)  This does not look like an accident.
>
>  Have you find a server that does DHE/EDH, and only that, that FF cannot connect to?

I've set mine to test this comprehensively. (Apache and NginX)  With Apache Firefox -ignores- server-prescribed ciphers and chooses an EC.  NginX does properly prevail with the algo.  Was this an accident, Apache?

And Firefox simply can not make a connexion when the only choices are the DHE/EDH algos -- which they say they can do [here](https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29).

> - "Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can."
>
> I missed that, thanks.  And for non-NSA curves that aren?t influenced?

As with Schnier, I don't trust any EC.  It's a shame.  I am looking forward to [independent lattice](https://policyreview.info/articles/news/post-snowden-cryptography-and-network-security/390). (Not that Mozilla, will implement it)  For now I'm set to DHE/EDH (fruitlessly) and RSA (AES).  RSA is cracked by a very few, but this is the decision I've made.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/5e921354/attachment.html>

From alan.buxey at gmail.com  Mon Dec 18 17:12:09 2017
From: alan.buxey at gmail.com (Alan Buxey)
Date: Mon, 18 Dec 2017 17:12:09 +0000
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
 <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
 <1E374546-F832-4F6C-96C4-32CA901A05F5@akamai.com>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
Message-ID: <CAOVYXj-k1r_SmxhcyhJDNxKpjOJ7FbbQC5YXNBust2OyE5TiXw@mail.gmail.com>

Have you submitted a bug report for Apache (not honouring server config
cipher order) if one doesn't exist?

As for resistant to quantum computers, given the current aim is for systems
that can calculate things that would currently take the age of the universe
to calculate, resistance is futile ;)

alan

On 18 Dec 2017 4:47 pm, "Colony.three via openssl-users" <
openssl-users at openssl.org> wrote:

>
>
>    - FF claims it does DHE/EDH
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.mozilla.org_Security_Server-5FSide-5FTLS-23Intermediate-5Fcompatibility-5F.28default.29&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=XJoX203uiiC98n6L2888TI9zC37FTWeD7taNoV50GDE&s=v0qGxpAFrqvTmiNnI5_Cl-Yd-tKrA-FDw6jO-lERXjY&e=>,
>    but it does not actually, in practice.  It does either EC, or RSA.  I've
>    tested it. (v52)  This does not look like an accident.
>
>  Have you find a server that does DHE/EDH, and only that, that FF cannot
> connect to?
>
>
> I've set mine to test this comprehensively. (Apache and NginX)  With
> Apache Firefox -ignores- server-prescribed ciphers and chooses an EC.
> NginX does properly prevail with the algo.  Was this an accident, Apache?
>
> And Firefox simply can not make a connexion when the only choices are the
> DHE/EDH algos -- which they say they can do here
> <https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29>
> .
>
>
>
>    - "*Prefer conventional discrete-log-based systems over elliptic-curve
>    systems; the latter have constants that the NSA influences when they can.*
>    "
>
> I missed that, thanks.  And for non-NSA curves that aren?t influenced?
>
>
> As with Schnier, I don't trust any EC.  It's a shame.  I am looking
> forward to independent lattice
> <https://policyreview.info/articles/news/post-snowden-cryptography-and-network-security/390>.
> (Not that Mozilla, will implement it)  For now I'm set to DHE/EDH
> (fruitlessly) and RSA (AES).  RSA is cracked by a very few, but this is the
> decision I've made.
>
>
> --
> 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/20171218/e1324cfd/attachment-0001.html>

From michael at stroeder.com  Mon Dec 18 17:13:59 2017
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 18 Dec 2017 18:13:59 +0100
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
 <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
 <1E374546-F832-4F6C-96C4-32CA901A05F5@akamai.com>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
Message-ID: <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>

Colony.three via openssl-users wrote:
> I've set mine to test this comprehensively. (Apache and NginX)? With
> Apache Firefox -ignores- server-prescribed ciphers and chooses an EC.?
> NginX does properly prevail with the algo.? Was this an accident, Apache?

I'd suggest to read the Apache httpd docs first:

https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhonorcipherorder

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/5a6ee146/attachment.bin>

From colony.three at protonmail.ch  Mon Dec 18 17:38:22 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Mon, 18 Dec 2017 12:38:22 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <CAOVYXj-k1r_SmxhcyhJDNxKpjOJ7FbbQC5YXNBust2OyE5TiXw@mail.gmail.com>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
 <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
 <1E374546-F832-4F6C-96C4-32CA901A05F5@akamai.com>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
 <CAOVYXj-k1r_SmxhcyhJDNxKpjOJ7FbbQC5YXNBust2OyE5TiXw@mail.gmail.com>
Message-ID: <Tfh039ZMKz1DwoxFYefOahsRtgvnRmoac9LCfNE_4cR-AruM03PIPb4UP7AXr3fEMGOFtmTmFATeCK3ptKXUPQ==@protonmail.ch>

> Have you submitted a bug report for Apache (not honouring server config cipher order) if one doesn't exist?

That never works.

> As for resistant to quantum computers, given the current aim is for systems that can calculate things that would currently take the age of the universe to calculate, resistance is futile ;)

I never allow the perfect, to become the enemy of the good.

I am looking forward to lattice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/c06c2d77/attachment.html>

From colony.three at protonmail.ch  Mon Dec 18 17:59:02 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Mon, 18 Dec 2017 12:59:02 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
 <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
 <1E374546-F832-4F6C-96C4-32CA901A05F5@akamai.com>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
 <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>
Message-ID: <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>

> Colony.three via openssl-users wrote:
>
>> I've set mine to test this comprehensively. (Apache and NginX)  With
>> Apache Firefox -ignores- server-prescribed ciphers and chooses an EC.
>> NginX does properly prevail with the algo.  Was this an accident, Apache?
>>
>> I'd suggest to read the Apache httpd docs first:
>>
>> https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhonorcipherorder

So you think I didn't use this.

For those who are aware, I implied this by intentionally using the word 'insist' WRT NginX.  I could have overtly said what proper options I'd used for every case in every instance, but I was hoping  ppl here would see.

This is why I believe this is not an accident.

Hear about the [HP keylogging case](http://www.bbc.com/news/technology-42309371) recently?  Do you think a keylogger is actually used in testing of a keyboard driver, in practice?

How about you actually try  SSLHonorCipherOrder on in Apache, Michael, and try the different cipher combinations?  Let us know how it works out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/a1eafc4b/attachment.html>

From aerowolf at gmail.com  Mon Dec 18 19:13:03 2017
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Mon, 18 Dec 2017 11:13:03 -0800
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <201E5E69-6540-4387-80A2-9E30B256A1E9@akamai.com>
 <CAPMEXDZZX=bFYvOxP4tT0DusTai0c7rHfDDTsLT5jwd7Hoo6WA@mail.gmail.com>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
 <1E374546-F832-4F6C-96C4-32CA901A05F5@akamai.com>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
 <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>
 <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
Message-ID: <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=x0Wk8nfH32vXPuYPA@mail.gmail.com>

On Mon, Dec 18, 2017 at 9:59 AM, Colony.three via openssl-users
<openssl-users at openssl.org> wrote:
>
> Hear about the HP keylogging case recently?  Do you think a keylogger is
> actually used in testing of a keyboard driver, in practice?

Yes.

More specifically, it's used to ensure that the scancodes that should
be detected when a particular key is hit or released are actually
detected when that key is hit or released.  It's also useful for
identifying how a particular keyboard has failed, to see which
scancodes aren't being transmitted properly.

That said, it's not something that should be left in a production
driver.  It's more suited for a development/diagnostics station than a
general-purpose system.

(Eeesh.  And my friends call *me* "paranoid".)

-Kyle H

From colony.three at protonmail.ch  Mon Dec 18 19:50:09 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Mon, 18 Dec 2017 14:50:09 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=x0Wk8nfH32vXPuYPA@mail.gmail.com>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
 <1E374546-F832-4F6C-96C4-32CA901A05F5@akamai.com>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
 <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>
 <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
 <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=x0Wk8nfH32vXPuYPA@mail.gmail.com>
Message-ID: <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>

> On Mon, Dec 18, 2017 at 9:59 AM, Colony.three via openssl-users
> openssl-users at openssl.org wrote:
>
>> Hear about the HP keylogging case recently? Do you think a keylogger is
>> actually used in testing of a keyboard driver, in practice?
>>
>> Yes.
>>
>> More specifically, it's used to ensure that the scancodes that should
>> be detected when a particular key is hit or released are actually
>> detected when that key is hit or released. It's also useful for
>> identifying how a particular keyboard has failed, to see which
>> scancodes aren't being transmitted properly.
>>
>> That said, it's not something that should be left in a production
>> driver. It's more suited for a development/diagnostics station than a
>> general-purpose system.

Actually no.  Microseconds count, when testing a keyboard driver.  It's easy to imagine that a keylogger could be used, that's why the cover story worked on so many.  But in actual practice it's not useful.

>> (Eeesh. And my friends call me "paranoid".)

It's easy to characterize this as paranoia.  Unless you are paying attention to -facts- as the feedstock.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/2c09c839/attachment-0001.html>

From colony.three at protonmail.ch  Mon Dec 18 19:54:23 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Mon, 18 Dec 2017 14:54:23 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
 <1E374546-F832-4F6C-96C4-32CA901A05F5@akamai.com>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
 <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>
 <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
 <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=x0Wk8nfH32vXPuYPA@mail.gmail.com>
 <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>
Message-ID: <n8fvrQscaey46QHjskVnOKnjK22xTZcLBo23yVIEHoDNhbEDaHrIz0tmJQoILKbqL9fCMMF4r5YlvG9bgtb6yg==@protonmail.ch>

>> On Mon, Dec 18, 2017 at 9:59 AM, Colony.three via openssl-users
>> openssl-users at openssl.org wrote:
>>
>>> Hear about the HP keylogging case recently? Do you think a keylogger is
>>> actually used in testing of a keyboard driver, in practice?
>>>
>>> Yes.
>>>
>>> More specifically, it's used to ensure that the scancodes that should
>>> be detected when a particular key is hit or released are actually
>>> detected when that key is hit or released. It's also useful for
>>> identifying how a particular keyboard has failed, to see which
>>> scancodes aren't being transmitted properly.
>>>
>>> That said, it's not something that should be left in a production
>>> driver. It's more suited for a development/diagnostics station than a
>>> general-purpose system.
>
> Actually no.  Microseconds count, when testing a keyboard driver.  It's easy to imagine that a keylogger could be used, that's why the cover story worked on so many.  But in actual practice it's not useful.
>
>>> (Eeesh. And my friends call me "paranoid".)
>
> It's easy to characterize this as paranoia.  Unless you are paying attention to -facts- as the feedstock.

I should have said, "It's easy --and fun-- to characterize this as paranoia."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/94df5342/attachment.html>

From jb-openssl at wisemo.com  Mon Dec 18 20:41:24 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 18 Dec 2017 21:41:24 +0100
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <3nYwCgXmGfOve7ZN7fbBeb2CJxOP5oLGM0Wt9kckV33Yec8jGqQBtWAexbXMDhYhikMunmdGHSfW4EFOEFLu4w==@protonmail.ch>
 <1E374546-F832-4F6C-96C4-32CA901A05F5@akamai.com>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
 <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>
 <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
 <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=x0Wk8nfH32vXPuYPA@mail.gmail.com>
 <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>
Message-ID: <ab11b9d2-20bd-6bf7-0055-1c8e90112792@wisemo.com>

On 18/12/2017 20:50, Colony.three via openssl-users wrote:
>
>> On Mon, Dec 18, 2017 at 9:59 AM, Colony.three via openssl-users
>> openssl-users at openssl.org <mailto:openssl-users at openssl.org>wrote:
>>
>>     Hear about the HP keylogging case recently? Do you think a
>>     keylogger is
>>     actually used in testing of a keyboard driver, in practice?
>>
>>     Yes.
>>
>>     More specifically, it's used to ensure that the scancodes that should
>>     be detected when a particular key is hit or released are actually
>>     detected when that key is hit or released. It's also useful for
>>     identifying how a particular keyboard has failed, to see which
>>     scancodes aren't being transmitted properly.
>>
>>     That said, it's not something that should be left in a production
>>     driver. It's more suited for a development/diagnostics station than a
>>     general-purpose system.
>>
>
> Actually no.? Microseconds count, when testing a keyboard driver.? 
> It's easy to imagine that a keylogger could be used, that's why the 
> cover story worked on so many.? But in actual practice it's not useful.
>
>
>>     (Eeesh. And my friends call /me/"paranoid".)
>>
>
> It's easy to characterize this as paranoia.? Unless you are paying 
> attention to -facts- as the feedstock.
>
For your information, I actually tracked down the original report
about this (and posted some corrections in a comment to the
researcher):

1. This was not HP's keyboard driver.? This was Synaptics' touch
 ? pad driver (SynTP.sys).

2. The code in question was apparently the common classic issue
 ? that the driver checks if a hotkey related to the touchpad is
 ? pressed, and has a test feature to help each laptop manufacturer
 ? check if they configured the correct (laptop-specific) scan code
 ? for that hotkey by using a special test driver that logs the keys
 ? that match/don't match the configured one.? On a number of
 ? occasions HP (and maybe others) have sent such test drivers to end
 ? users instead of the drivers without the debug feature.

3. In this case, no keys were logged unless someone (or something)
 ? with admin rights on the laptop did extra steps to turn on the
 ? feature and to read back the results.? Any malicious code with
 ? those rights could just install its own logging without depending
 ? on that particular wrong driver being installed.

So to me, that particular issue falls into the less serious tier of:
Possible misuse if other things go wrong first, upgrade when ready as
a defense in depth.

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 colony.three at protonmail.ch  Mon Dec 18 21:28:10 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Mon, 18 Dec 2017 16:28:10 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <ab11b9d2-20bd-6bf7-0055-1c8e90112792@wisemo.com>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
 <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>
 <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
 <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=x0Wk8nfH32vXPuYPA@mail.gmail.com>
 <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>
 <ab11b9d2-20bd-6bf7-0055-1c8e90112792@wisemo.com>
Message-ID: <ZCr3EKIkOdOahvcO06djcF2WYSKfnq3Y007B9_Z_O7noPbIBccPQAf21mqsiAy0gkgcjwX05GjlbSanfKhgzUA==@protonmail.ch>

.

> For your information, I actually tracked down the original report
> about this (and posted some corrections in a comment to the
> researcher):
>
> - This was not HP's keyboard driver.  This was Synaptics' touch
>   pad driver (SynTP.sys).

Never said it is HP's driver.  But understand, that it only went in to HP machines.

As far as we know.  That, I have said.

> - The code in question was apparently the common classic issue
>   that the driver checks if a hotkey related to the touchpad is
>   pressed, and has a test feature to help each laptop manufacturer
>   check if they configured the correct (laptop-specific) scan code
>   for that hotkey by using a special test driver that logs the keys
>   that match/don't match the configured one.  On a number of
>   occasions HP (and maybe others) have sent such test drivers to end
>   users instead of the drivers without the debug feature.

A keylogger is not useful in this case, particularly as timing is an acute issue.  At the most basic, when they want what you portray, a utility like evtest.

> - In this case, no keys were logged unless someone (or something)
>   with admin rights on the laptop did extra steps to turn on the
>   feature and to read back the results.  Any malicious code with
>   those rights could just install its own logging without depending
>   on that particular wrong driver being installed,
> -  So to me, that particular issue falls into the less serious tier of:
> Possible misuse if other things go wrong first, upgrade when ready as
> a defense in depth.
> -  Jakob

Correct, it is not turned on by default.  Never said otherwise.  But it can be manually.

So far I've raised three independent issues in this thread, and have been fought on all three.  I am bored now with trying to raise awareness, so let's just all agree that nobody wants to hear it.  You do your thing and I'll do mine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/f3de7bac/attachment.html>

From colony.three at protonmail.ch  Mon Dec 18 21:35:39 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Mon, 18 Dec 2017 16:35:39 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <ZCr3EKIkOdOahvcO06djcF2WYSKfnq3Y007B9_Z_O7noPbIBccPQAf21mqsiAy0gkgcjwX05GjlbSanfKhgzUA==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
 <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>
 <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
 <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=x0Wk8nfH32vXPuYPA@mail.gmail.com>
 <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>
 <ab11b9d2-20bd-6bf7-0055-1c8e90112792@wisemo.com>
 <ZCr3EKIkOdOahvcO06djcF2WYSKfnq3Y007B9_Z_O7noPbIBccPQAf21mqsiAy0gkgcjwX05GjlbSanfKhgzUA==@protonmail.ch>
Message-ID: <8wh3p9Qvu3kgKaTWc0uo7JaeJhni2eXJkUZoYwcRBZH2lsXnHj-M_WDMWmpOyx8oqX85oqzuLG6TPTSRY4taeg==@protonmail.ch>

PS, Jakob I'm getting on your email:  "This email has failed its domain's authentication requirements. It may be spoofed or improperly forwarded!"

The reason is:  HEADER_FROM_DIFFERENT_DOMAINS,T_DKIM_INVALID
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/02596f9f/attachment.html>

From jb-openssl at wisemo.com  Mon Dec 18 22:35:55 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 18 Dec 2017 23:35:55 +0100
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <8wh3p9Qvu3kgKaTWc0uo7JaeJhni2eXJkUZoYwcRBZH2lsXnHj-M_WDMWmpOyx8oqX85oqzuLG6TPTSRY4taeg==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <FB98B91C-848A-4FBD-BF69-6C4834C1681E@akamai.com>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
 <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>
 <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
 <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=x0Wk8nfH32vXPuYPA@mail.gmail.com>
 <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>
 <ab11b9d2-20bd-6bf7-0055-1c8e90112792@wisemo.com>
 <ZCr3EKIkOdOahvcO06djcF2WYSKfnq3Y007B9_Z_O7noPbIBccPQAf21mqsiAy0gkgcjwX05GjlbSanfKhgzUA==@protonmail.ch>
 <8wh3p9Qvu3kgKaTWc0uo7JaeJhni2eXJkUZoYwcRBZH2lsXnHj-M_WDMWmpOyx8oqX85oqzuLG6TPTSRY4taeg==@protonmail.ch>
Message-ID: <96b75e33-ad0a-86fc-5503-5d258b323e63@wisemo.com>

On 18/12/2017 22:35, Colony.three via openssl-users wrote:
> PS, Jakob I'm getting on your email:? "This email has failed its 
> domain's authentication requirements. It may be spoofed or improperly 
> forwarded!"
>
> The reason is: HEADER_FROM_DIFFERENT_DOMAINS,T_DKIM_INVALID
>
Can you send me the full headers, so I can debug?

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 colony.three at protonmail.ch  Tue Dec 19 01:10:18 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Mon, 18 Dec 2017 20:10:18 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <96b75e33-ad0a-86fc-5503-5d258b323e63@wisemo.com>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>
 <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
 <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=x0Wk8nfH32vXPuYPA@mail.gmail.com>
 <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>
 <ab11b9d2-20bd-6bf7-0055-1c8e90112792@wisemo.com>
 <ZCr3EKIkOdOahvcO06djcF2WYSKfnq3Y007B9_Z_O7noPbIBccPQAf21mqsiAy0gkgcjwX05GjlbSanfKhgzUA==@protonmail.ch>
 <8wh3p9Qvu3kgKaTWc0uo7JaeJhni2eXJkUZoYwcRBZH2lsXnHj-M_WDMWmpOyx8oqX85oqzuLG6TPTSRY4taeg==@protonmail.ch>
 <96b75e33-ad0a-86fc-5503-5d258b323e63@wisemo.com>
Message-ID: <vKuL9hzZJzmt5PgEClfDtu8LdkacVIcKGk-t2qR_eRjv4O_Sqzyol-vhVsznYUH1xnnpgBLf3OQ-_YhbdsA94g==@protonmail.ch>

On 18/12/2017 22:35, Colony.three via openssl-users wrote:

>> PS, Jakob I'm getting on your email:  "This email has failed its
>> domain's authentication requirements. It may be spoofed or improperly
>> forwarded!"
>> The reason is: HEADER_FROM_DIFFERENT_DOMAINS,T_DKIM_INVALID
>
> Can you send me the full headers, so I can debug?
>
> Enjoy
>
> Jakob

Return-Path: <
openssl-users-bounces at openssl.org
>
X-Original-To:
colony.three at protonmail.ch
Delivered-To:
colony.three at protonmail.ch
Received: from mta.openssl.org (xmpp.openssl.org [194.97.150.230]) (using TLSv1.2 with
 cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by
 mail6i.protonmail.ch (Postfix) with ESMTPS id 635D4E2F for <
colony.three at protonmail.ch
>;
 Mon, 18 Dec 2017 17:36:53 -0500 (EST)
Received: from mta.openssl.org (localhost [IPv6:::1]) by mta.openssl.org (Postfix) with
 ESMTP id 870BAE6ECC; Mon, 18 Dec 2017 22:36:01 +0000 (UTC)
Received: by mta.openssl.org (Postfix, from userid 106) id D5E38E6EBF; Mon, 18 Dec 2017
 22:35:57 +0000 (UTC)
Received: from smtpv6n-hq2.wisemo.com (smtpv6n-hq2.wisemo.com [IPv6:2a01:4f0:4018::24b])
 (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate
 requested) by mta.openssl.org (Postfix) with ESMTPS id CB89CE6EBF for
 <
openssl-users at openssl.org
>; Mon, 18 Dec 2017 22:35:56 +0000 (UTC)
Received: from jb0008.i.wisemo.com ([2a01:4f0:4018:f0:fabc:12ff:fe78:9014]) by
 mailout.i.wisemo.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80)
 (envelope-from <
jb-openssl at wisemo.com
>) id 1eR40p-0000jg-Kf for
openssl-users at openssl.org
; Mon, 18 Dec 2017 23:35:55 +0100
Authentication-Results: mail6i.protonmail.ch; dmarc=fail (p=none dis=none)
 header.from=wisemo.com
Authentication-Results: mail6i.protonmail.ch; spf=none
 smtp.mailfrom=
openssl-users-bounces at openssl.org
Authentication-Results: mail6i.protonmail.ch; dkim=fail reason="signature verification
 failed" (2048-bit key) header.d=wisemo.com header.i=@wisemo.com header.b="FD31MWS4"
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on maili.protonmail.ch
X-Spam-Level: **
X-Spam-Status: No, score=2.3 required=4.0 tests=DKIM_SIGNED,
 HEADER_FROM_DIFFERENT_DOMAINS,T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=no
 autolearn_force=no version=3.4.0
Dkim-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wisemo.com; s=v2016;

 h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject;
 bh=rWDo5ZVDxE3Y8t96X0ktB8yt0P5rzC+4PmeG1upOaRI=;

 b=FD31MWS4Qjwk0h1d1L5sBiACNSThWYoMRmzye4hP5+hIDqU+9bGRAyLvYqCPDVEhGMpCfOO2h7Jffkp32kSgZ4F8r8a0IO9MVkX65S4t5mIah5d3/vyZFxyOtAhSByJy6yWd32vUlG5JuuECt96sz/kg7hWOcUCGs1OOnTSi5/PJZwOBIwf6ZiATElTUrM+jAecoKw0ErgUmZ6po2J4A+9nBILmn5vYLSS/FklVIKZEUuNBW8f2fs3uNo/DYUCXNlIaB3wVP4A5XV7uOVOJBiQ3i5njunAxqZJdRJs0cXSjPZ2Km3ciELCRVqi9K6CDPwnL7eVwJNdhj77UTDCBQDQ==;
To: "Colony.three via openssl-users" <
openssl-users at openssl.org
>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
 <
FB98B91C-848A-4FBD-BF69-6C4834C1681E at akamai.com
>
 <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
 <
d703c037-9143-d3f6-7271-181c627a0839 at stroeder.com
>
 <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
 <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=
x0Wk8nfH32vXPuYPA at mail.gmail.com
>
 <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>
 <
ab11b9d2-20bd-6bf7-0055-1c8e90112792 at wisemo.com
>
 <ZCr3EKIkOdOahvcO06djcF2WYSKfnq3Y007B9_Z_O7noPbIBccPQAf21mqsiAy0gkgcjwX05GjlbSanfKhgzUA==@protonmail.ch>
 <8wh3p9Qvu3kgKaTWc0uo7JaeJhni2eXJkUZoYwcRBZH2lsXnHj-M_WDMWmpOyx8oqX85oqzuLG6TPTSRY4taeg==@protonmail.ch>
From: Jakob Bohm <
jb-openssl at wisemo.com
>
Organization: WiseMo A/S
Message-Id: <
96b75e33-ad0a-86fc-5503-5d258b323e63 at wisemo.com
>
Date: Mon, 18 Dec 2017 23:35:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
Mime-Version: 1.0
In-Reply-To: <8wh3p9Qvu3kgKaTWc0uo7JaeJhni2eXJkUZoYwcRBZH2lsXnHj-M_WDMWmpOyx8oqX85oqzuLG6TPTSRY4taeg==@protonmail.ch>
Content-Language: en-US
Subject: Re: [openssl-users] Lattice Ciphers
X-Beenthere:
openssl-users at openssl.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <openssl-users.openssl.org>
List-Unsubscribe: <
https://mta.openssl.org/mailman/options/openssl-users
>,
 <mailto:
openssl-users-request at openssl.org
?subject=unsubscribe>
List-Archive: <
http://mta.openssl.org/pipermail/openssl-users/
>
List-Post: <mailto:
openssl-users at openssl.org
>
List-Help: <mailto:
openssl-users-request at openssl.org
?subject=help>
List-Subscribe: <
https://mta.openssl.org/mailman/listinfo/openssl-users
>,
 <mailto:
openssl-users-request at openssl.org
?subject=subscribe>
Reply-To:
openssl-users at openssl.org
Content-Transfer-Encoding: base64
Content-Type: text/plain
Errors-To:
openssl-users-bounces at openssl.org
Sender: "openssl-users" <
openssl-users-bounces at openssl.org
>
X-Pm-Origin: external
X-Pm-Transfer-Encryption: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

-----BEGIN PGP MESSAGE-----
Version: ProtonMail
Comment:
https://protonmail.com
wcBMAzwC5QO/8k+jAQf9FkgEHuki7bMnfO/ejGZoQmeottQ83i5FLbE10vkf
LwRIwRnmY2YLiIBum22373mXXJaG//GO862luKTnRxBCJNQFqetCKFygsi4+
eGqxgxgmy6Wuxj2CLLKgOTOCVwTej/p/z2aOPwyd3wVAEtQXMyEbnufWU7fS
JbY4QfSIb/T90BfyYly5Ndu0z9LSicRWd3dfG70KZvXxYBcQu3/Unp3AJnlj
9YPZ41r6PsSq7pHzgRtJS/DgrHVBln6kxkSeXLOFSg8SjWIsfDk2kb0VJtzV
ehX2kEBCrxNtqX/TGuC1vKHf9cKkZ5QZ2se5FiTMqAdgOyi/Hbpf+GOctfAA
HNLCWAEdkg7p+FGceEv9E1XWDuadQ3jovSfl3/wrCNnB8tL18c3lHrX+Qpbh
u1rUAiaf/rNtG1CeeM15iRo/RTOi9GolFdxBhUk1tyao8Kxk3aYm2gigwRZB
optV8yBm5pniV4oe6N5V/4hFrU09aJ8cryUZdRPLImXAxpHJTEUWq2Rtprqd
2mJf6XbqUbMFC6ClVWBkDlznnZuQhsFp1t/zhKDrafjLMhsqK71UCIxPlcTk
VR99IuePHyfhUJyJ46h5J7ZaSiomhUgmhgLliQJMzsyXdp5hvzjlnK1GZdFT
Er8gxvMJDfHu9Pwu/9TWHKZXngaWB1ZV7U8VEZDhVWUreD910IaGxOMSjsRI
dLIKMgJtt61UZSgdievELVOqgrWc4TGKI/jU3E9jD78U+B5ebQOz++urBlTh
RFOuMriqeAPBZvcqbv3sIrUpEekKlT5JB66lVA5sS+t+QCpgdyN4SXw9GmTS
GugkK9ojC7J7lE9afK6gLNfmpDq7vvuDBCMdtAruQ/2uwPtD3w2aiYkAqW1n
ybuWLbgyGXnvIABnlxUxZkoMujkCO1v+wN2mpdLlqR1xZdvoZHWsZIC5WFLc
yy8aU0KjNRwIg73PCRjif4SvSFpowuxOv25QgEPMO7vyp9N3XRK46ZiGFlFs
a7A3iKRaTjFcHCcl2rvHw9U0GT2tEgDkEqmiGfi/ZAGIS1muuVGpsmV+jL3Y
Ift2yYBArIeXWl0t+WfZtTivFRIbQFAxUasLyVGh9suaUnHtXjmFdF03Iheh
JB1Lp11T8EHnHq8w0padURLlXq/I1fUN9KAbmVckAwqbsVQXgxf34Ou4+9CD
q4yEDMqjlYawJCrQCIedu4by2XQloiPDTf3O7VbGg5aqLSwxQI++qUmvxbKU
iWHU0Ku3BhI7FtPFrUbBlK2MNIxZFKDxncOEo9a44RMY81LZqpnRL6YxjBQs
HnDDPRsYKYWrLzAeRi690W4nlz5Fby046DT7bCSegEfI3OT3q3CJKc11R/V0
2kddFVQ1x0XKPYbnnEiZU2Q6WthtnmjqaptdbwnyZg==
=I5VP
-----END PGP MESSAGE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/de83c522/attachment.html>

From colony.three at protonmail.ch  Tue Dec 19 01:25:52 2017
From: colony.three at protonmail.ch (Colony.three)
Date: Mon, 18 Dec 2017 20:25:52 -0500
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
Message-ID: <g_AK4EB1C0K3gevVKKCgkzIredE9SikVjpFrvaJsMun2nCgJ6_kYbzMPj2L1rZGXvhnBkF6eXGLecKG_m3ZuqQ==@protonmail.ch>

> I find that Firefox refuses to do any ephemeral ciphers whatsoever.  What the heck?  Why am I surprised.  Somebody paid them.
>
> If you follow Schnieder, elliptic curve is not an option.
>
> I know you guys are severely underfunded, but is there any chance that lattice encryption will be coming soon?  I've searched until my face turned blue.

VPN is doing it now:  https://wiki.strongswan.org/projects/strongswan/wiki/Bliss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171218/407d6746/attachment.html>

From jb-openssl at wisemo.com  Tue Dec 19 03:38:04 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 19 Dec 2017 04:38:04 +0100
Subject: [openssl-users] Lattice Ciphers
In-Reply-To: <vKuL9hzZJzmt5PgEClfDtu8LdkacVIcKGk-t2qR_eRjv4O_Sqzyol-vhVsznYUH1xnnpgBLf3OQ-_YhbdsA94g==@protonmail.ch>
References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
 <d703c037-9143-d3f6-7271-181c627a0839@stroeder.com>
 <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
 <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=x0Wk8nfH32vXPuYPA@mail.gmail.com>
 <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>
 <ab11b9d2-20bd-6bf7-0055-1c8e90112792@wisemo.com>
 <ZCr3EKIkOdOahvcO06djcF2WYSKfnq3Y007B9_Z_O7noPbIBccPQAf21mqsiAy0gkgcjwX05GjlbSanfKhgzUA==@protonmail.ch>
 <8wh3p9Qvu3kgKaTWc0uo7JaeJhni2eXJkUZoYwcRBZH2lsXnHj-M_WDMWmpOyx8oqX85oqzuLG6TPTSRY4taeg==@protonmail.ch>
 <96b75e33-ad0a-86fc-5503-5d258b323e63@wisemo.com>
 <vKuL9hzZJzmt5PgEClfDtu8LdkacVIcKGk-t2qR_eRjv4O_Sqzyol-vhVsznYUH1xnnpgBLf3OQ-_YhbdsA94g==@protonmail.ch>
Message-ID: <4cb5907b-cb8e-e615-c873-f161025f55f2@wisemo.com>

On 19/12/2017 02:10, Colony.three via openssl-users wrote:
> On 18/12/2017 22:35, Colony.three via openssl-users wrote:
>>
>>     PS, Jakob I'm getting on your email:? "This email has failed its
>>     domain's authentication requirements. It may be spoofed or improperly
>>     forwarded!"
>>     The reason is: HEADER_FROM_DIFFERENT_DOMAINS,T_DKIM_INVALID
>>
>>
>>     Can you send me the full headers, so I can debug?
>>
>>     Enjoy
>>
>>     Jakob
>>
>
>
>
>
> Return-Path: <openssl-users-bounces at openssl.org 
> <mailto:openssl-users-bounces at openssl.org>>
> X-Original-To:colony.three at protonmail.ch <mailto:colony.three at protonmail.ch>
> Delivered-To:colony.three at protonmail.ch <mailto:colony.three at protonmail.ch>
> Received: from mta.openssl.org (xmpp.openssl.org [194.97.150.230]) (using TLSv1.2 with
>   cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by
>   mail6i.protonmail.ch (Postfix) with ESMTPS id 635D4E2F for <colony.three at protonmail.ch <mailto:colony.three at protonmail.ch>>;
>   Mon, 18 Dec 2017 17:36:53 -0500 (EST)
> Received: from mta.openssl.org (localhost [IPv6:::1]) by mta.openssl.org (Postfix) with
>   ESMTP id 870BAE6ECC; Mon, 18 Dec 2017 22:36:01 +0000 (UTC)
> Received: by mta.openssl.org (Postfix, from userid 106) id D5E38E6EBF; Mon, 18 Dec 2017
>   22:35:57 +0000 (UTC)
> Received: from smtpv6n-hq2.wisemo.com (smtpv6n-hq2.wisemo.com [IPv6:2a01:4f0:4018::24b])
>   (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate
>   requested) by mta.openssl.org (Postfix) with ESMTPS id CB89CE6EBF for
>   <openssl-users at openssl.org <mailto:openssl-users at openssl.org>>; Mon, 18 Dec 2017 22:35:56 +0000 (UTC)
> Received: from jb0008.i.wisemo.com ([2a01:4f0:4018:f0:fabc:12ff:fe78:9014]) by
>   mailout.i.wisemo.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80)
>   (envelope-from <jb-openssl at wisemo.com <mailto:jb-openssl at wisemo.com>>) id 1eR40p-0000jg-Kf for
>   openssl-users at openssl.org <mailto:openssl-users at openssl.org>; Mon, 18 Dec 2017 23:35:55 +0100
> Authentication-Results: mail6i.protonmail.ch; dmarc=fail (p=none dis=none)
>   header.from=wisemo.com
> Authentication-Results: mail6i.protonmail.ch; spf=none
>   smtp.mailfrom=openssl-users-bounces at openssl.org 
> <mailto:openssl-users-bounces at openssl.org>
> Authentication-Results: mail6i.protonmail.ch; dkim=fail reason="signature verification
>   failed" (2048-bit key) header.d=wisemo.com header.i=@wisemo.com header.b="FD31MWS4"
> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on maili.protonmail.ch
> X-Spam-Level: **
> X-Spam-Status: No, score=2.3 required=4.0 tests=DKIM_SIGNED,
>   HEADER_FROM_DIFFERENT_DOMAINS,T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=no
>   autolearn_force=no version=3.4.0
> Dkim-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wisemo.com; s=v2016;
>   
>   h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject;
>   bh=rWDo5ZVDxE3Y8t96X0ktB8yt0P5rzC+4PmeG1upOaRI=;
>   
>   b=FD31MWS4Qjwk0h1d1L5sBiACNSThWYoMRmzye4hP5+hIDqU+9bGRAyLvYqCPDVEhGMpCfOO2h7Jffkp32kSgZ4F8r8a0IO9MVkX65S4t5mIah5d3/vyZFxyOtAhSByJy6yWd32vUlG5JuuECt96sz/kg7hWOcUCGs1OOnTSi5/PJZwOBIwf6ZiATElTUrM+jAecoKw0ErgUmZ6po2J4A+9nBILmn5vYLSS/FklVIKZEUuNBW8f2fs3uNo/DYUCXNlIaB3wVP4A5XV7uOVOJBiQ3i5njunAxqZJdRJs0cXSjPZ2Km3ciELCRVqi9K6CDPwnL7eVwJNdhj77UTDCBQDQ==;
> To: "Colony.three via openssl-users" <openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
> References: <4mvmY5QeDcVaNTb3ESs174N_UTtbj0PYXYaGzuIpm0eTtX3xSH_z3OJVtCKZpxpiVGjE6dRE8wnTQUnyj3ybWQ==@protonmail.ch>
>   <iLXsZEIGCyDQ7PA3vbE1mG-BCXI4yZVydgetIvzw8w5_rb8VyJk4GNLJ9cY1_reZaRVYjtHWNafcgefw-8hZzA==@protonmail.ch>
>   <FB98B91C-848A-4FBD-BF69-6C4834C1681E at akamai.com 
> <mailto:FB98B91C-848A-4FBD-BF69-6C4834C1681E at akamai.com>>
>   <XkpqXD-saUFlJ8cjEp_hPRISBbRTcrBCUutUjm_IaP4qI_68snhQxr27V21WQTqhgf3KcUPFF_buBQTBW1ySlQ==@protonmail.ch>
>   <d703c037-9143-d3f6-7271-181c627a0839 at stroeder.com 
> <mailto:d703c037-9143-d3f6-7271-181c627a0839 at stroeder.com>>
>   <cq_perMl191NMJQZuSGIJSuv2KWWx22mDyV93xzmLVfXfuLTuI3jZk6BrQouX-tsZyRL8RfiKyLjWZsFKjYxMw==@protonmail.ch>
>   <CAPMEXDZrFtkXCDfXEmJuZ7=idEGSb_ZU=x0Wk8nfH32vXPuYPA at mail.gmail.com <mailto:x0Wk8nfH32vXPuYPA at mail.gmail.com>>
>   <tYZ8CMgRzX9XL9vchoHzPI-SwzpT07inLZHPr-M7_61KokxDjRVuD1rtBIHMDW-xlEj_VOEtTDcFrf3vHNNAZQ==@protonmail.ch>
>   <ab11b9d2-20bd-6bf7-0055-1c8e90112792 at wisemo.com 
> <mailto:ab11b9d2-20bd-6bf7-0055-1c8e90112792 at wisemo.com>>
>   <ZCr3EKIkOdOahvcO06djcF2WYSKfnq3Y007B9_Z_O7noPbIBccPQAf21mqsiAy0gkgcjwX05GjlbSanfKhgzUA==@protonmail.ch>
>   <8wh3p9Qvu3kgKaTWc0uo7JaeJhni2eXJkUZoYwcRBZH2lsXnHj-M_WDMWmpOyx8oqX85oqzuLG6TPTSRY4taeg==@protonmail.ch>
> From: Jakob Bohm <jb-openssl at wisemo.com <mailto:jb-openssl at wisemo.com>>
> Organization: WiseMo A/S
> Message-Id: <96b75e33-ad0a-86fc-5503-5d258b323e63 at wisemo.com 
> <mailto:96b75e33-ad0a-86fc-5503-5d258b323e63 at wisemo.com>>
> Date: Mon, 18 Dec 2017 23:35:55 +0100
> User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
> Mime-Version: 1.0
> In-Reply-To: <8wh3p9Qvu3kgKaTWc0uo7JaeJhni2eXJkUZoYwcRBZH2lsXnHj-M_WDMWmpOyx8oqX85oqzuLG6TPTSRY4taeg==@protonmail.ch>
> Content-Language: en-US
> Subject: Re: [openssl-users] Lattice Ciphers
> X-Beenthere:openssl-users at openssl.org <mailto:openssl-users at openssl.org>
> X-Mailman-Version: 2.1.18
> Precedence: list
> List-Id: <openssl-users.openssl.org>
> List-Unsubscribe: <https://mta.openssl.org/mailman/options/openssl-users>,
>   <mailto:openssl-users-request at openssl.org 
> <mailto:openssl-users-request at openssl.org>?subject=unsubscribe>
> List-Archive: <http://mta.openssl.org/pipermail/openssl-users/>
> List-Post: <mailto:openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
> List-Help: <mailto:openssl-users-request at openssl.org 
> <mailto:openssl-users-request at openssl.org>?subject=help>
> List-Subscribe: <https://mta.openssl.org/mailman/listinfo/openssl-users>,
>   <mailto:openssl-users-request at openssl.org 
> <mailto:openssl-users-request at openssl.org>?subject=subscribe>
> Reply-To:openssl-users at openssl.org <mailto:openssl-users at openssl.org>
> Content-Transfer-Encoding: base64
> Content-Type: text/plain
> Errors-To:openssl-users-bounces at openssl.org 
> <mailto:openssl-users-bounces at openssl.org>
> Sender: "openssl-users" <openssl-users-bounces at openssl.org 
> <mailto:openssl-users-bounces at openssl.org>>
> X-Pm-Origin: external
> X-Pm-Transfer-Encryption: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>
>
Aha, this looks like https://bugs.launchpad.net/bugs/1539384

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 asteja.chowdary.ece13 at itbhu.ac.in  Tue Dec 19 13:43:00 2017
From: asteja.chowdary.ece13 at itbhu.ac.in (Sai Teja Chowdary)
Date: Tue, 19 Dec 2017 19:13:00 +0530
Subject: [openssl-users] FW: Help to understand WPACKET API
In-Reply-To: <5a2a8e0d.1650620a.1b91f.9efd@mx.google.com>
References: <5a2a8e0d.1650620a.1b91f.9efd@mx.google.com>
Message-ID: <5a391764.cb4e650a.9ba2b.8f7d@mx.google.com>


Hi,
I am trying to tweak openssl-master client to test a tls1.3 enabled server.

I want to club the client certificate, client key exchange , change cipher spec and certificate verify into single handshake message.( So that the record shows up as multiple handshake messages).

OpenSSL Version : OpenSSL 1.1.1-dev? xx XXX xxxx.

After going through the code I understand the new tls1.3 implemented OpenSSL code is using WPACKET API to frame the records. I need help in understanding what the following functions do. I am new to the mailing list, thanks in advance.

WPACKET_start_sub_packet_
WPACKET_allocate_bytes
WPACKET_sub_allocate_bytes__
WPACKET_reserve_bytes
WPACKET_start_sub_packet_len__
WPACKET_sub_memcpy__

Basically what does the word _sub_ mean in these functions and how do that differ from the non sub function say
Difference between WPACKET_sub_memcpy__ and WPACKET_memcpy__

Please feel free to reply if something is not understandable.
Sent from Mail for Windows 10

Thanks
Sate.

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

From janjust at nikhef.nl  Tue Dec 19 13:43:42 2017
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Tue, 19 Dec 2017 14:43:42 +0100
Subject: [openssl-users] SSL alert number 48
In-Reply-To: <CAEAeT_h_E+1KkBBJvUHiEpkZaVsmHDhhRyrJ-7xxDHXrgaFgSA@mail.gmail.com>
References: <CAEAeT_imeOGKfyrHjPbFeDfh-fdEDpGribdUnfavyVbHV7QyjQ@mail.gmail.com>
 <e8668c3b-2bde-647a-d2e7-9d1699ceb3ac@nikhef.nl>
 <CAEAeT_ijLEdUWnyFrANbD9swHZt=ctaA06DoBFrxmnJ5+qyQew@mail.gmail.com>
 <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl>
 <CAEAeT_gR0uxN3fGgZKo3J7NuGPY-5zW_nD7qquhMAykinrnJLg@mail.gmail.com>
 <642397e5-68c2-f2fc-3b4e-5e9c867d6b17@nikhef.nl>
 <CAEAeT_i0wHff-=hyS5BsSyAY-0hwN+0cXzDzSz2R1PemShf=4Q@mail.gmail.com>
 <5e3168c5-1731-88e9-fd3e-153cd6ba8b4a@nikhef.nl>
 <CAEAeT_h_E+1KkBBJvUHiEpkZaVsmHDhhRyrJ-7xxDHXrgaFgSA@mail.gmail.com>
Message-ID: <70858a99-bbf7-d748-3095-057ac354d882@nikhef.nl>

Hi,

On 12/12/17 11:06, wizard2010 at gmail.com wrote:
> Hi.
>
> Ok, I agree with you that the way I generate the certificates could 
> not be the right one, but now I change the way and the problem remains.
> Please check the way I'm creating the certificates. I create a ROOT-CA 
> entity and a INTERMEDIATE-CA that is responsible to generate the 
> CLIENT and SERVER certificates.
> This is the script [ https://pastebin.com/bw6j5AZz ] that I'm using to 
> create this small PKI example
>
you're changing the game as you go along -- now you want an intermediate 
CA all of a sudden ;)
Still, with the certs you've sent this time I can get it to work, with a 
minor code change: instead of using
 ? SSL_CTX_use_certificate_chain_file(...)
I am using
 ? SSL_CTX_use_certificate_chain_file(ssl_server_ctx, SSL_SERVER_RSA_CERT)

then make sure that RSA_CA_CRT points to root-ca.crt and that 
SERVER_RSA_CRT points to server.pem, which contains the intermediate CA 
as a stacked cert; on the client side, use your stacked client.pem file 
as well. In that case I can connect to your server program using
 ? openssl s_client -connect 127.0.0.1:4444 -CAfile root-ca.crt -cert 
client.pem -key client.key

HTH,

JJK


From Michael.Fainstein at ecitele.com  Tue Dec 19 15:41:14 2017
From: Michael.Fainstein at ecitele.com (Michael Fainstein)
Date: Tue, 19 Dec 2017 15:41:14 +0000
Subject: [openssl-users] FIPS 2.0 build_tests using cross for ppc64
Message-ID: <VI1PR0301MB2429359AE369975152D93056EE0F0@VI1PR0301MB2429.eurprd03.prod.outlook.com>

I am trying to build test suite using cross environment on Linux x86-64 for ppc64.

Without setting FIPS_SIG I am getting error
../fips/fipsld: line 186: ./fips_hmactest: cannot execute binary file

With FIPS_SIG=`pwd`/util/incore I am getting error from incore:
ELF64 is supported only natively at util/incore line 45.

My target can't support native build environment, so I must use cross.
Is there any way to fix those errors?

Thanks,
Michael

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171219/070a24ef/attachment.html>

From rsalz at akamai.com  Tue Dec 19 16:17:39 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 19 Dec 2017 16:17:39 +0000
Subject: [openssl-users] FIPS 2.0 build_tests using cross for ppc64
Message-ID: <F0D42525-8FD3-4A12-A233-CBD83570F571@akamai.com>

  *   My target can?t support native build environment, so I must use cross.
  *   Is there any way to fix those errors?

If you make any changes to the FIPS build procedure, then the result is not FIPS validated.  I think the build procedure does not support cross-compiling very well, because it expects to execute the built programs on the building host ? it needs some things to run ?natively? to get the digest of the built library so it can be incorporated into its power-on checks.

So you?ll have to do your own validation, hire a lab, etc.  Or wait until the project releases a new module.  That *might* support cross-compiling better, or it might not.

Sorry we don?t have better news.


  *   This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.

BTW, let your mgmt. know that this kind of disclaimer is obnoxious and impossible to enforce when posting to a public mailing list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171219/e7faca8f/attachment-0001.html>

From ananthaneni.saitejachowdary at citrix.com  Wed Dec 20 05:41:25 2017
From: ananthaneni.saitejachowdary at citrix.com (Ananthaneni Saitejachowdary)
Date: Wed, 20 Dec 2017 05:41:25 +0000
Subject: [openssl-users] Help to understand WPACKET API
Message-ID: <abbea7ec5ff74104b7869e33794c86c1@SINPEX02CL02.citrite.net>

Hi,
I am trying to tweak openssl-master client to test a tls1.3 enabled server.

I want to club the client certificate, client key exchange , change cipher spec and certificate verify into single handshake message.( So that the record shows up as multiple handshake messages).

OpenSSL Version : OpenSSL 1.1.1-dev  xx XXX xxxx.

After going through the code I understand the new tls1.3 implemented OpenSSL code is using WPACKET API to frame the records. I need help in understanding what the following functions do. I am new to the mailing list, thanks in advance.

WPACKET_start_sub_packet_
WPACKET_allocate_bytes
WPACKET_sub_allocate_bytes__
WPACKET_reserve_bytes
WPACKET_start_sub_packet_len__
WPACKET_sub_memcpy__

Basically what does the word _sub_ mean in these functions and how do that differ from the non sub function say
Difference between WPACKET_sub_memcpy__ and WPACKET_memcpy__

Please feel free to reply if something is not understandable.

Thanks
Sate.

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

From haris.phnx at gmail.com  Wed Dec 20 06:21:39 2017
From: haris.phnx at gmail.com (haris iqbal)
Date: Wed, 20 Dec 2017 11:51:39 +0530
Subject: [openssl-users] Bleichenbacher Vulnerability
Message-ID: <CAE_WKMxfFZdhVgYzy6_KwxM+o+NTpBARF-3VUK5et+VVyXDMPg@mail.gmail.com>

Hi,

I was wondering when exactly (the version) was the OpenSSL library
patched for the Bleichenbacher Vulnerability?

Since the Bleichenbacher Vulnerability had a number of variations,
most recently ROBOT being one of them, I wanted to know whether
OpenSSL is immune to this attack because of a patch sometime in the
past, or it is always been immune.

Wanted to know this, since my custom application uses an older version
of OpenSSL, and I wanted to be sure that it is not affected.

-- 

With regards,

Md Haris Iqbal,
Contact: +91 8861996962

From mksarav at gmail.com  Wed Dec 20 06:45:57 2017
From: mksarav at gmail.com (M K Saravanan)
Date: Wed, 20 Dec 2017 14:45:57 +0800
Subject: [openssl-users] Bleichenbacher Vulnerability
In-Reply-To: <CAE_WKMxfFZdhVgYzy6_KwxM+o+NTpBARF-3VUK5et+VVyXDMPg@mail.gmail.com>
References: <CAE_WKMxfFZdhVgYzy6_KwxM+o+NTpBARF-3VUK5et+VVyXDMPg@mail.gmail.com>
Message-ID: <CAG5P2e_K4BTMgdxgE_z0-79HAKSLuPfzVmA54=ZmdHik+AA9SQ@mail.gmail.com>

On 20 December 2017 at 14:21, haris iqbal <haris.phnx at gmail.com> wrote:
> Wanted to know this, since my custom application uses an older version
> of OpenSSL, and I wanted to be sure that it is not affected.

Not answering your original question.  But you can test it using one
of the following tools:

========
The following tools have checks that will cover ROBOT:

testssl.sh has a test closely modelled after our own one. A snapshot
is available, it's not yet part of a release. It also supports SNI and
STARTTLS, which our test does not.

TLS-Attacker already contained Bleichenbacher checks before our
research, version 2.2 was extended with additional checks to cover all
ROBOT variations.

SSLLabs has added a check in their development version.

Tripwire IP360 added detection for vulnerable F5 devices in ASPL-753
which was released in coordination with F5's public advisory. Generic
detection of Bleichenbacher oracles will be released in coordination
with this publication.

tlsfuzzer has an extensive test script for Bleichenbacher vulns,
though it will also complain about misbehaving servers that are not
necessarily vulnerable.

SSLyze added support for ROBOT detection after our disclosure.
=========
Ref: https://robotattack.org/

-- mks --

From antiac at gmail.com  Wed Dec 20 10:07:01 2017
From: antiac at gmail.com (Antonio Iacono)
Date: Wed, 20 Dec 2017 11:07:01 +0100
Subject: [openssl-users] Fwd: Create a signed file from detached signature
	and clear file content
In-Reply-To: <CAPN6PESKB6fOFBv7y_PJjH=BXbwv2o35AkY1EMLd6DOBUHS7wA@mail.gmail.com>
References: <CAPN6PESKB6fOFBv7y_PJjH=BXbwv2o35AkY1EMLd6DOBUHS7wA@mail.gmail.com>
Message-ID: <CAPN6PER+DPbJUNsgiaw=xu3TNof4PadHCbfs+D-zCW8-C3MSMA@mail.gmail.com>

Hi,
assuming I have the following:
- data.txt
- data.p7s (the detached signature)

Can I generate the bundled (p7m) signed file ?

I tried:

content = BIO_new_file("data.txt", "rb");
signature = BIO_new_file("data.p7s", "rb");
p7 = d2i_PKCS7_bio(signature, NULL);
PKCS7_set_detached(p7, 0);
bundled = BIO_new_file("bundled.p7m", "wb");
i2d_PKCS7_bio_stream(bundled, p7, content, 0);

but the generated file (bundled.p7m) is identical to the signature file
(data.p7s)

Thanks,
Antonio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171220/3e22b123/attachment.html>

From hanno at hboeck.de  Wed Dec 20 11:13:12 2017
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Wed, 20 Dec 2017 12:13:12 +0100
Subject: [openssl-users] Bleichenbacher Vulnerability
In-Reply-To: <CAE_WKMxfFZdhVgYzy6_KwxM+o+NTpBARF-3VUK5et+VVyXDMPg@mail.gmail.com>
References: <CAE_WKMxfFZdhVgYzy6_KwxM+o+NTpBARF-3VUK5et+VVyXDMPg@mail.gmail.com>
Message-ID: <20171220121312.09132fd3@pc1>

Hi,

On Wed, 20 Dec 2017 11:51:39 +0530
haris iqbal <haris.phnx at gmail.com> wrote:

> I was wondering when exactly (the version) was the OpenSSL library
> patched for the Bleichenbacher Vulnerability?

It was probably fixed some time in the late 90s. However according to
https://www.openssl.org/news/changelog.html

the countermeasures were accidentally removed in some 0.9.6 version.

However there also was a 2012/2013 timing version of the attack fixed
here:
https://github.com/openssl/openssl/commit/adb46dbc6dd7347750df2468c93e8c34bcb93a4b

We also observed some old Openssl 0.9.8g crashing when we ran
bleichenbacher scans against it, but we haven't entirely analyzed this.

> Wanted to know this, since my custom application uses an older version
> of OpenSSL, and I wanted to be sure that it is not affected.

Don't do this. Switch to a supported version. There's no way you will
plausibly keep this secure. Bleichenbacher attacks may be the least of
your worries.



-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

From keshavkrishna88 at gmail.com  Wed Dec 20 12:50:16 2017
From: keshavkrishna88 at gmail.com (Keshava Krishna Bhat K)
Date: Wed, 20 Dec 2017 18:20:16 +0530
Subject: [openssl-users] How to respond to TLS heartbeat in openssl
Message-ID: <CAHDZOcMHyKrwO9aTAvrLhyXnKjm6A_z92HS_VSxWbeqk=t-x4Q@mail.gmail.com>

Hi All,

I am writing a TLS server that responds to a incoming TLS heartbeat
request. I am using OpenSSL 1.0.2g .
But I am not able to get the server respond to a hearbeat request.
Any clue on what I am missing?
The code snippets are here https://stackoverflow.com/
questions/47902283/how-to-respond-to-tls-heartbeat-in-openssl .

I also got a clue that the version of openssl I am using might have
hearbeats disabled. But how do I check if heartbeats are enabled in OpenSSL
1.0.2g?

Regards,
Keshava.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171220/817ae848/attachment.html>

From bmoeller at acm.org  Wed Dec 20 16:16:33 2017
From: bmoeller at acm.org (Bodo Moeller)
Date: Wed, 20 Dec 2017 17:16:33 +0100
Subject: [openssl-users] Bleichenbacher Vulnerability
In-Reply-To: <20171220121312.09132fd3@pc1>
References: <CAE_WKMxfFZdhVgYzy6_KwxM+o+NTpBARF-3VUK5et+VVyXDMPg@mail.gmail.com>
 <20171220121312.09132fd3@pc1>
Message-ID: <CADMpkcJcGzFemc+6bG-G5usFyv44yqKPWjCXBqwQRzzip72new@mail.gmail.com>

Hanno B?ck <hanno at hboeck.de>:

> I was wondering when exactly (the version) was the OpenSSL library
> > patched for the Bleichenbacher Vulnerability?
>


> It was probably fixed some time in the late 90s. However according to
> https://www.openssl.org/news/changelog.html
>
> the countermeasures were accidentally removed in some 0.9.6 version.
>

The original countermeasure had been present back in SSLeay, but it also
had never actually worked at all until I accidentally removed it from
s3_srvr.c in 0.9.5 (not 0.9.6) and put it back in 0.9.6g with a fix. The
original implementation would have generated a randomized master secret but
then still ended the handshake with an error alert, thus achieving nothing.
The main takeaway from that is that good source code comments are
invaluable, because reverse-engineering the intentions underlying the code
can be particularly hard if said code doesn't actually do what it's
intended to do :-)

Of course, in the end the 0.9.6g fix didn't achieve too much (other than
adding a source code explaining what that randomization was all about),
because the RFC 2246 countermeasure was still subject to the
Kl?ma-Pokorn?-Rosa attack discovered later (and first addressed in 0.9.6j).
And of course, as you've already pointed out, that still left timing
attacks.

> Wanted to know this, since my custom application uses an older version
> > of OpenSSL, and I wanted to be sure that it is not affected.
>


> Don't do this. Switch to a supported version. There's no way you will
> plausibly keep this secure. Bleichenbacher attacks may be the least of
> your worries.


I completed agree. If you're using an "older version of OpenSSL", likely
it's subject to a few vulnerabilities with and without logos, and thus is
not what you should be running today.

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

From ananthaneni.saitejachowdary at citrix.com  Thu Dec 21 04:51:46 2017
From: ananthaneni.saitejachowdary at citrix.com (Ananthaneni Saitejachowdary)
Date: Thu, 21 Dec 2017 04:51:46 +0000
Subject: [openssl-users] How to make a digest or hash of sent messages
Message-ID: <68734edbdb7746e484eae70976819b43@SINPEX02CL02.citrite.net>

Hi,

I am want to send client certificate, client key exchange and client verify in a single handshake message which appears as multiple handshake messages in a single record. But to sent the client verify I need to first make a hash of previous messages(client certificate and client key exchange) to create the signature.

Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX xxxx that can do a proper transcript(digest or hash not clear). I tried using ssl3_finish_mac() on the message containing client certificate and client key exchange and then tried to generate the signature in certificate verify message.
But it is giving me a digest error. I am new to the mailing list want a bit of help to proceed forward stuck here. Please reply in case if anything is not clear.

Regards,
Saiteja

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

From haris.phnx at gmail.com  Thu Dec 21 05:53:48 2017
From: haris.phnx at gmail.com (haris iqbal)
Date: Thu, 21 Dec 2017 11:23:48 +0530
Subject: [openssl-users] Bleichenbacher Vulnerability
In-Reply-To: <CADMpkcJcGzFemc+6bG-G5usFyv44yqKPWjCXBqwQRzzip72new@mail.gmail.com>
References: <CAE_WKMxfFZdhVgYzy6_KwxM+o+NTpBARF-3VUK5et+VVyXDMPg@mail.gmail.com>
 <20171220121312.09132fd3@pc1>
 <CADMpkcJcGzFemc+6bG-G5usFyv44yqKPWjCXBqwQRzzip72new@mail.gmail.com>
Message-ID: <CAE_WKMwRzRF-e8t0hFHdcru9UvqxPco-jGYhxYSGYRCw6uqC7g@mail.gmail.com>

Thanks for the response.


> Don't do this. Switch to a supported version. There's no way you will
> plausibly keep this secure. Bleichenbacher attacks may be the least of
> your worries.

I am actually using version 1.0.1h.

>  And of course, as you've already pointed out, that still left timing attacks.

So, when was this timing attack fixed?

On Wed, Dec 20, 2017 at 9:46 PM, Bodo Moeller <bmoeller at acm.org> wrote:
> Hanno B?ck <hanno at hboeck.de>:
>
>> > I was wondering when exactly (the version) was the OpenSSL library
>> > patched for the Bleichenbacher Vulnerability?
>
>
>>
>> It was probably fixed some time in the late 90s. However according to
>> https://www.openssl.org/news/changelog.html
>>
>> the countermeasures were accidentally removed in some 0.9.6 version.
>
>
> The original countermeasure had been present back in SSLeay, but it also had
> never actually worked at all until I accidentally removed it from s3_srvr.c
> in 0.9.5 (not 0.9.6) and put it back in 0.9.6g with a fix. The original
> implementation would have generated a randomized master secret but then
> still ended the handshake with an error alert, thus achieving nothing. The
> main takeaway from that is that good source code comments are invaluable,
> because reverse-engineering the intentions underlying the code can be
> particularly hard if said code doesn't actually do what it's intended to do
> :-)
>
> Of course, in the end the 0.9.6g fix didn't achieve too much (other than
> adding a source code explaining what that randomization was all about),
> because the RFC 2246 countermeasure was still subject to the
> Kl?ma-Pokorn?-Rosa attack discovered later (and first addressed in 0.9.6j).
> And of course, as you've already pointed out, that still left timing
> attacks.
>
>> > Wanted to know this, since my custom application uses an older version
>> > of OpenSSL, and I wanted to be sure that it is not affected.
>
>
>>
>> Don't do this. Switch to a supported version. There's no way you will
>> plausibly keep this secure. Bleichenbacher attacks may be the least of
>> your worries.
>
>
> I completed agree. If you're using an "older version of OpenSSL", likely
> it's subject to a few vulnerabilities with and without logos, and thus is
> not what you should be running today.
>
> Bodo
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 

With regards,

Md Haris Iqbal,
Contact: +91 8861996962

From keshavkrishna88 at gmail.com  Thu Dec 21 06:19:46 2017
From: keshavkrishna88 at gmail.com (Keshava Krishna Bhat K)
Date: Thu, 21 Dec 2017 11:49:46 +0530
Subject: [openssl-users] How to respond to TLS heartbeat in openssl
In-Reply-To: <CAHDZOcMHyKrwO9aTAvrLhyXnKjm6A_z92HS_VSxWbeqk=t-x4Q@mail.gmail.com>
References: <CAHDZOcMHyKrwO9aTAvrLhyXnKjm6A_z92HS_VSxWbeqk=t-x4Q@mail.gmail.com>
Message-ID: <CAHDZOcONp-xB0VFGf+Q_VbQy-x+XeEWaAUkHh7_4rHcs8QsMxQ@mail.gmail.com>

Hi,

Is this controlled by the Makefile?

Regards,
Keshava.

On Wed, Dec 20, 2017 at 6:20 PM, Keshava Krishna Bhat K <
keshavkrishna88 at gmail.com> wrote:

> Hi All,
>
> I am writing a TLS server that responds to a incoming TLS heartbeat
> request. I am using OpenSSL 1.0.2g .
> But I am not able to get the server respond to a hearbeat request.
> Any clue on what I am missing?
> The code snippets are here https://stackoverflow.
> com/questions/47902283/how-to-respond-to-tls-heartbeat-in-openssl .
>
> I also got a clue that the version of openssl I am using might have
> hearbeats disabled. But how do I check if heartbeats are enabled in OpenSSL
> 1.0.2g?
>
> Regards,
> Keshava.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171221/81139bf2/attachment.html>

From ManWag at FastMail.FM  Thu Dec 21 11:42:52 2017
From: ManWag at FastMail.FM (Manuel Wagesreither)
Date: Thu, 21 Dec 2017 12:42:52 +0100
Subject: [openssl-users] Certificate gets verified OK over SSL-CLI,
	but not when using SSL-API
Message-ID: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>

Dear all,

I'm struggling with programatically verifying a certificate which is solely stored in memory, i. e. not on the file system. The certificate and the CA seem to be fine though, because when I extract them from memory and store them as a file, and use the `openssl verify`, verification is successful. Hence I suspect my code is faulty.

Unfortunately, I'm under the impression that validating certificates which exist solely in memory is a niche application. I was yet not able to find a comprehensive tutorial or even a code sample on the internet. Hence, I hope you can help me.

Below I'm posting my sample code. (I have stripped the certificate and CA raw data, tough.) It can be compiled an run under a GNU/Linux system.
When this code is run, OpenSSL emits a "certificate signature failure" with an error depth of 0.

Thanks a lot!
Manuel

============

#include <openssl/x509.h>
#include <stdexcept>
#include <iostream>

unsigned char g_authority[] = {	0x30, 0x82, 0x03, 0x00 /* and so on */ };
unsigned char g_cert[] = { 0x30, 0x82, 0x02, 0x9b /* and so on */ };

int main(int, char**)
{
	// This holds the return codes and gets reused for most function calls
	int rc = 0;

	// Make a new store
	X509_STORE *x509_store = X509_STORE_new();
	if (x509_store == NULL) {
		throw std::runtime_error("X509_STORE_new() failed");
	}

	// Load and convert the authoritys certificate to a compatible form
	X509 *auth_cert = NULL;
	{
		const unsigned char* auth_cert_ptr = g_authority;
		auth_cert = d2i_X509(NULL, &auth_cert_ptr, sizeof(g_authority));
		if (auth_cert == nullptr) {
			throw std::runtime_error("d2i_X509() failed for authoritys certificate");
		}
	}

	// Add the authoritys certificate to the store
	rc = X509_STORE_add_cert(x509_store, auth_cert);
	if (rc != 1) {
		throw std::runtime_error("X509_STORE_add_cert() failed");
	}

	// Make a new store context
	X509_STORE_CTX *x509_store_ctx = X509_STORE_CTX_new();
	if (x509_store_ctx == NULL) {
		throw std::runtime_error("X509_STORE_CTX_new() failed");
	}

	// Load and convert the certificate to be verified to a compatible form
	X509 *myself = NULL;
	{
		const unsigned char *my_cert_ptr = g_cert;
		myself = d2i_X509(NULL, &my_cert_ptr, sizeof(g_cert));
		if (myself == NULL) {
			throw std::runtime_error("d2i_X509() failed for own certificate");
		}
	}

	rc = X509_STORE_CTX_init(x509_store_ctx, x509_store, myself, NULL);
	if (rc != 1) {
		throw std::runtime_error("X509_STORE_CTX_init() failed");
	}

	rc = X509_verify_cert(x509_store_ctx);

	X509_STORE_free(x509_store);
	X509_STORE_CTX_free(x509_store_ctx);

	if (rc > 0) {
		std::cout << X509_verify_cert_error_string(X509_STORE_CTX_get_error(x509_store_ctx)) << std::endl;
		return 0;
	} else {
		std::cerr << X509_verify_cert_error_string(X509_STORE_CTX_get_error(x509_store_ctx)) << std::endl;
		std::cerr << "Error depth: " << X509_STORE_CTX_get_error_depth(x509_store_ctx) << std::endl;
		return 1;
	}
}

From ManWag at FastMail.FM  Thu Dec 21 12:47:53 2017
From: ManWag at FastMail.FM (Manuel Wagesreither)
Date: Thu, 21 Dec 2017 13:47:53 +0100
Subject: [openssl-users] Certificate gets verified OK over SSL-CLI,
 but not when using SSL-API
In-Reply-To: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
Message-ID: <1513860473.145406.1212316472.2885A3F9@webmail.messagingengine.com>

Dear all,

I forgot to mention that I'm using OpenSSL 1.0.2k.

Regards
Manuel

From warron.french at gmail.com  Thu Dec 21 13:36:26 2017
From: warron.french at gmail.com (warron.french)
Date: Thu, 21 Dec 2017 08:36:26 -0500
Subject: [openssl-users] Testing ports through firewall
Message-ID: <CAJdJdQm=aYhJccS1vq92RCMHaVc96x9UGYKdGYCNjN2MFMeHmA@mail.gmail.com>

Hello Community, and Merry Christmas/Happy Seasons Greetings,
   anyway, I need some help with understanding an openssl feature -
*s_server*.

I executed the following command:  openssl s_server -accept 21937 -www &
And immediately got the following output:
[1] 3286
[sysadm at wfrench-rhel6c-cit ~]$ Error opening server certificate private key
file server.pem
140679739017032:error:02001002:system library:fopen:No such file or
directory:bss_file.c:398:fopen('server.pem','r')
140679739017032:error:20074002:BIO routines:FILE_CTRL:system
lib:bss_file.c:400:
unable to load server certificate private key file

In order to test ports that are not encrypted with SSL/TLS do I still have
to generate a certificate and private key file (each)?

I would like to test ports from one machine using openssl s_client against
a remote machine on an opposing network, running a "listener", using
openssl s_server.

Perhaps I am way off?  I am not allowed to use openssl for this sort of
thing?
Any guidance would be greatly appreciated because I want to expand my
understanding of the openssl suite of commands and its offerings.


Have a nice day,
--------------------------
Warron French
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171221/d5aee417/attachment.html>

From jb-openssl at wisemo.com  Thu Dec 21 13:56:47 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 21 Dec 2017 14:56:47 +0100
Subject: [openssl-users] Testing ports through firewall
In-Reply-To: <CAJdJdQm=aYhJccS1vq92RCMHaVc96x9UGYKdGYCNjN2MFMeHmA@mail.gmail.com>
References: <CAJdJdQm=aYhJccS1vq92RCMHaVc96x9UGYKdGYCNjN2MFMeHmA@mail.gmail.com>
Message-ID: <ca29d244-81b7-5b65-4da1-d5167655f9d5@wisemo.com>

On 21/12/2017 14:36, warron.french wrote:
> Hello Community, and Merry Christmas/Happy Seasons Greetings,
> ?? anyway, I need some help with understanding an openssl feature - 
> *s_server*.
>
> I executed the following command: openssl s_server -accept 21937 -www &
> And immediately got the following output:
> [1] 3286
> [sysadm at wfrench-rhel6c-cit ~]$ Error opening server certificate 
> private key file server.pem
> 140679739017032:error:02001002:system library:fopen:No such file or 
> directory:bss_file.c:398:fopen('server.pem','r')
> 140679739017032:error:20074002:BIO routines:FILE_CTRL:system 
> lib:bss_file.c:400:
> unable to load server certificate private key file
>
> In order to test ports that are not encrypted with SSL/TLS do I still 
> have to generate a certificate and private key file (each)?
>
> I would like to test ports from one machine using openssl s_client 
> against a remote machine on an opposing network, running a "listener", 
> using openssl s_server.
>
> Perhaps I am way off?? I am not allowed to use openssl for this sort 
> of thing?
> Any guidance would be greatly appreciated because I want to expand my 
> understanding of the openssl suite of commands and its offerings.
>
>
Any normal SSL/TLS server needs a certificate.? For testing the
certificate doesn't have to be "real" (from a trusted public CA).
A dummy certificate for a server named "computer.example.com" can
be generated using the command:

openssl req -x509 -days 365 -newkey:rsa:2048 -nodes -keyout server.key 
-out server.pem -subj /CN=computer.example.com/O=test/C=US


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 asteja.chowdary.ece13 at iitbhu.ac.in  Thu Dec 21 15:30:00 2017
From: asteja.chowdary.ece13 at iitbhu.ac.in (Sai Teja Chowdary)
Date: Thu, 21 Dec 2017 21:00:00 +0530
Subject: [openssl-users] Testing ports through firewall
In-Reply-To: <CAJdJdQm=aYhJccS1vq92RCMHaVc96x9UGYKdGYCNjN2MFMeHmA@mail.gmail.com>
References: <CAJdJdQm=aYhJccS1vq92RCMHaVc96x9UGYKdGYCNjN2MFMeHmA@mail.gmail.com>
Message-ID: <CAKyT-XEbAe9jLztYWsT9_jEpTtwy=TQPr4S2gsR2qC-B2_vUuA@mail.gmail.com>

Hi,
You can test ports with OpenSSL. But you gotta need a certificate for your
s_server. You can generate a self signed certificate with openssl.
Try this

https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl

And place that file in the dir were you are running the s_server command,
or can use -cert argument to give the generated certificate.

And from the s_client connect to the port that you are listening with
s_server

Client:
openssl s_client -connect hostname:port

Server:
openssl s_server -accept PORT

Regards

Saiteja.

On 21-Dec-2017 7:07 PM, "warron.french" <warron.french at gmail.com> wrote:

> Hello Community, and Merry Christmas/Happy Seasons Greetings,
>    anyway, I need some help with understanding an openssl feature -
> *s_server*.
>
> I executed the following command:  openssl s_server -accept 21937 -www &
> And immediately got the following output:
> [1] 3286
> [sysadm at wfrench-rhel6c-cit ~]$ Error opening server certificate private
> key file server.pem
> 140679739017032:error:02001002:system library:fopen:No such file or
> directory:bss_file.c:398:fopen('server.pem','r')
> 140679739017032:error:20074002:BIO routines:FILE_CTRL:system
> lib:bss_file.c:400:
> unable to load server certificate private key file
>
> In order to test ports that are not encrypted with SSL/TLS do I still have
> to generate a certificate and private key file (each)?
>
> I would like to test ports from one machine using openssl s_client against
> a remote machine on an opposing network, running a "listener", using
> openssl s_server.
>
> Perhaps I am way off?  I am not allowed to use openssl for this sort of
> thing?
> Any guidance would be greatly appreciated because I want to expand my
> understanding of the openssl suite of commands and its offerings.
>
>
> Have a nice day,
> --------------------------
> Warron French
>
>
> --
> 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/20171221/d4465a35/attachment.html>

From asteja.chowdary.ece13 at iitbhu.ac.in  Thu Dec 21 15:45:33 2017
From: asteja.chowdary.ece13 at iitbhu.ac.in (Sai Teja Chowdary)
Date: Thu, 21 Dec 2017 21:15:33 +0530
Subject: [openssl-users] Follow up
In-Reply-To: <CAKyT-XHi=3Qj+Uif_S2E+qfY-6bObcq0WKcOM8bJvT-4d0+1kw@mail.gmail.com>
References: <CAKyT-XHaajCiSkRWhWvX-x+e67ayQZyAOxuDivdyke0gmu1aUg@mail.gmail.com>
 <CAKyT-XFMVB5Ytxvk+9KorQ03AB6chiK=SH7dzpR7mSQoWMbBPw@mail.gmail.com>
 <CAKyT-XE5b5HqghSKFxQMiXWuq6C1p7K3EptLUgNJhTa6guwZ7Q@mail.gmail.com>
 <CAKyT-XHi=3Qj+Uif_S2E+qfY-6bObcq0WKcOM8bJvT-4d0+1kw@mail.gmail.com>
Message-ID: <CAKyT-XGZRYROkfKg9ECEso2ePAiV+EqRxN1hEQ3EZfyU0GN+Wg@mail.gmail.com>

Hi all,
Marry Christmas!

Please take a look at my previous question, appreciate every bit of help
I'm stuck.
FYI the guy named ananthaneni saiteja chowdary and myself are same. This
email had a problem subscribing to the mailing list earlier hence the other
name.

Thanks
Saiteja.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171221/97a3da5f/attachment.html>

From gadphly at gmail.com  Thu Dec 21 17:01:27 2017
From: gadphly at gmail.com (Gelareh Taban)
Date: Thu, 21 Dec 2017 11:01:27 -0600
Subject: [openssl-users] Fwd: Padding for RSA signatures
In-Reply-To: <CALug0JZSti29jBAgL_utnw1jW85gzXOum9GG=uGpP6tyYmcdWw@mail.gmail.com>
References: <CALug0JZSti29jBAgL_utnw1jW85gzXOum9GG=uGpP6tyYmcdWw@mail.gmail.com>
Message-ID: <CALug0JZAfPWRJAVeAy32THfV2bP1QcvhfEbr61-MEA2-DWhfxg@mail.gmail.com>

Hi all,

I am playing around with RSA signatures with different padding options and
I have some questions.

I am trying to define different padding options and so am defining and
using a EVP_PKEY_CTX . However I am not sure if this padding is getting
used in the signature since  my Verify outputs OK regardless of which
option my Sign uses. Which leads to:

1 - Do I need to use a EVP_PKEY_CTX with the same options when doing
verify? If so, I assume I can't reuse the same PKey_Ctx and I have to
define another one. Right now even when I don't use any EVP_PKEY_CTX in
Verify, I still verify OK, which makes me question if the padding option
has been set.

2 - Is there a way to figure out what padding/hashing/etc option was used
for the Sign/verify operation? This way I can be sure what algorithm or
standard is being used.

3 - Do I need to set the hash function I am using in both EVP_PKEY_CTX  as
well as EVP_MD_CTX ? Or the latter is what defines this for the signing
option?

4 - In general, is there a way of making the Signature/Encryptions in
OpenSSL be deterministic for debugging/testing purposes?

5 - I noticed that there are two ways of determining the signature size:
(a) by calling EVP_PKEY_size(rsaKeypair) as I am doing below, as well as
(b) calling EVP_DigestSignFinal(md_ctx, nil, &sig_len) . Is one better than
the other?

My sample code is below for reference. It's in Swift (but it should still
be close enough to C to be readable). Also in Swift, some of the complex
macros in OpenSSL have to be broken down to be compilable hence my usage of
EVP_DigestUpdate instead of EVP_DigestVerifyUpdate .

Thanks in advance for any insight in the above.

cheers!
Gelareh


        let md_ctx = EVP_MD_CTX_create()

        let md_ctx_verify = EVP_MD_CTX_create()



        // To define padding option used in signature

        let pkey_ctx = EVP_PKEY_CTX_new(rsaKeypair, nil)



        // EVP_PKEY_CTX_set_rsa_padding(pkey_ctx, RSA_PKCS1_PADDING) -
complex macro needs to be replaced

        EVP_PKEY_CTX_ctrl(pkey_ctx, EVP_PKEY_RSA, -1,
EVP_PKEY_CTRL_RSA_PADDING, RSA_X931_PADDING, nil)


        // EVP_PKEY_CTX_set_signature_md() When should this be set?



        //  SIGN

        var rc = EVP_DigestSignInit(md_ctx, &pkey_ctx, EVP_sha256(), nil,
myRSA.rsaKeypair)

        // EVP_DigestSignUpdate(md_ctx, message, message.count)

        // Complex macro needs to be replaced

        rc = EVP_DigestUpdate(md_ctx, message, message.count)



        // allocate memory for signature

        var sig_len: Int = Int(EVP_PKEY_size(rsaKeypair))

        let sig = UnsafeMutablePointer<UInt8>.allocate(capacity: sig_len)


        rc = EVP_DigestSignFinal(md_ctx, sig, &sig_len)





        // VERIFY

        rc = EVP_DigestVerifyInit(md_ctx_verify, nil, EVP_sha256(), nil,
rsaKeypair)


        //        rc = EVP_DigestVerifyUpdate(md_ctx_verify, message,
message.count)

        rc = EVP_DigestUpdate(md_ctx_verify, message, message.count)



        rc = EVP_DigestVerifyFinal(md_ctx_verify, sig, sig_len)

        print("signature verified = \(rc == 1 ? "OK" : "FAIL")")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171221/116f93c3/attachment-0001.html>

From dnsands at sandia.gov  Thu Dec 21 18:27:09 2017
From: dnsands at sandia.gov (Sands, Daniel)
Date: Thu, 21 Dec 2017 18:27:09 +0000
Subject: [openssl-users] [EXTERNAL] Certificate gets verified OK over
 SSL-CLI, but not when using SSL-API
In-Reply-To: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
Message-ID: <1513880829.15053.34.camel@sandia.gov>

I'm a fellow SSL-USER and not an expert, but my verification flow goes
as follows:

X509_STORE_CTX_new()
X509_STORE_CTX_init(ctx,NULL,cert,NULL) <-- The certificate to verify
X509_STORE_CTX_trusted_stack(ctx,CACertificateStack) <-- Perhaps this
is the difference?
X509_verify_cert(ctx)


On Thu, 2017-12-21 at 12:42 +0100, Manuel Wagesreither wrote:
> Dear all,
> 
> I'm struggling with programatically verifying a certificate which is
> solely stored in memory, i. e. not on the file system. The
> certificate and the CA seem to be fine though, because when I extract
> them from memory and store them as a file, and use the `openssl
> verify`, verification is successful. Hence I suspect my code is
> faulty.
> 
> Unfortunately, I'm under the impression that validating certificates
> which exist solely in memory is a niche application. I was yet not
> able to find a comprehensive tutorial or even a code sample on the
> internet. Hence, I hope you can help me.
> 
> Below I'm posting my sample code. (I have stripped the certificate
> and CA raw data, tough.) It can be compiled an run under a GNU/Linux
> system.
> When this code is run, OpenSSL emits a "certificate signature
> failure" with an error depth of 0.
> 
> Thanks a lot!
> Manuel
> 
> ============
> 
> #include <openssl/x509.h>
> #include <stdexcept>
> #include <iostream>
> 
> unsigned char g_authority[] = {	0x30, 0x82, 0x03, 0x00 /* and
> so on */ };
> unsigned char g_cert[] = { 0x30, 0x82, 0x02, 0x9b /* and so on */ };
> 
> int main(int, char**)
> {
> 	// This holds the return codes and gets reused for most
> function calls
> 	int rc = 0;
> 
> 	// Make a new store
> 	X509_STORE *x509_store = X509_STORE_new();
> 	if (x509_store == NULL) {
> 		throw std::runtime_error("X509_STORE_new() failed");
> 	}
> 
> 	// Load and convert the authoritys certificate to a compatible
> form
> 	X509 *auth_cert = NULL;
> 	{
> 		const unsigned char* auth_cert_ptr = g_authority;
> 		auth_cert = d2i_X509(NULL, &auth_cert_ptr,
> sizeof(g_authority));
> 		if (auth_cert == nullptr) {
> 			throw std::runtime_error("d2i_X509() failed for
> authoritys certificate");
> 		}
> 	}
> 
> 	// Add the authoritys certificate to the store
> 	rc = X509_STORE_add_cert(x509_store, auth_cert);
> 	if (rc != 1) {
> 		throw std::runtime_error("X509_STORE_add_cert()
> failed");
> 	}
> 
> 	// Make a new store context
> 	X509_STORE_CTX *x509_store_ctx = X509_STORE_CTX_new();
> 	if (x509_store_ctx == NULL) {
> 		throw std::runtime_error("X509_STORE_CTX_new()
> failed");
> 	}
> 
> 	// Load and convert the certificate to be verified to a
> compatible form
> 	X509 *myself = NULL;
> 	{
> 		const unsigned char *my_cert_ptr = g_cert;
> 		myself = d2i_X509(NULL, &my_cert_ptr, sizeof(g_cert));
> 		if (myself == NULL) {
> 			throw std::runtime_error("d2i_X509() failed for
> own certificate");
> 		}
> 	}
> 
> 	rc = X509_STORE_CTX_init(x509_store_ctx, x509_store, myself,
> NULL);
> 	if (rc != 1) {
> 		throw std::runtime_error("X509_STORE_CTX_init()
> failed");
> 	}
> 
> 	rc = X509_verify_cert(x509_store_ctx);
> 
> 	X509_STORE_free(x509_store);
> 	X509_STORE_CTX_free(x509_store_ctx);
> 
> 	if (rc > 0) {
> 		std::cout <<
> X509_verify_cert_error_string(X509_STORE_CTX_get_error(x509_store_ctx
> )) << std::endl;
> 		return 0;
> 	} else {
> 		std::cerr <<
> X509_verify_cert_error_string(X509_STORE_CTX_get_error(x509_store_ctx
> )) << std::endl;
> 		std::cerr << "Error depth: " <<
> X509_STORE_CTX_get_error_depth(x509_store_ctx) << std::endl;
> 		return 1;
> 	}
> }

From keshavkrishna88 at gmail.com  Fri Dec 22 06:32:48 2017
From: keshavkrishna88 at gmail.com (Keshava Krishna Bhat K)
Date: Fri, 22 Dec 2017 12:02:48 +0530
Subject: [openssl-users] How to respond to TLS heartbeat in openssl
In-Reply-To: <CAHDZOcONp-xB0VFGf+Q_VbQy-x+XeEWaAUkHh7_4rHcs8QsMxQ@mail.gmail.com>
References: <CAHDZOcMHyKrwO9aTAvrLhyXnKjm6A_z92HS_VSxWbeqk=t-x4Q@mail.gmail.com>
 <CAHDZOcONp-xB0VFGf+Q_VbQy-x+XeEWaAUkHh7_4rHcs8QsMxQ@mail.gmail.com>
Message-ID: <CAHDZOcOhtxrbHsfqTts5RCFK1excJ6ZujFKCaPzVEDrSJCdC7g@mail.gmail.com>

Ok, I got to know that
 openssl version -a gives out the flags used while building openssl.
so the output of this was

OpenSSL 1.0.2g  1 Mar 2016
built on: reproducible build, date unspecified
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack
-Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM
-DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/usr/lib/ssl"

Since the putput above does not have OPENSSL_NO_HEARTBEATS, I assume
heartbeats are not disabled in the build.
So I am back to square one :( -> how do I make the server respond to a TLS
heartbeat request ? Do I have to read the packet and write it back ?

But code in the following file and method suggests this would done
automatically (but again I have a layman's knowledge on C, I could be wrong)
t1_lib.c tls1_process_heartbeat

Regards,
Keshava.

On Thu, Dec 21, 2017 at 11:49 AM, Keshava Krishna Bhat K <
keshavkrishna88 at gmail.com> wrote:

> Hi,
>
> Is this controlled by the Makefile?
>
> Regards,
> Keshava.
>
> On Wed, Dec 20, 2017 at 6:20 PM, Keshava Krishna Bhat K <
> keshavkrishna88 at gmail.com> wrote:
>
>> Hi All,
>>
>> I am writing a TLS server that responds to a incoming TLS heartbeat
>> request. I am using OpenSSL 1.0.2g .
>> But I am not able to get the server respond to a hearbeat request.
>> Any clue on what I am missing?
>> The code snippets are here https://stackoverflow.com
>> /questions/47902283/how-to-respond-to-tls-heartbeat-in-openssl .
>>
>> I also got a clue that the version of openssl I am using might have
>> hearbeats disabled. But how do I check if heartbeats are enabled in OpenSSL
>> 1.0.2g?
>>
>> Regards,
>> Keshava.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171222/8da07bee/attachment.html>

From noloader at gmail.com  Fri Dec 22 06:50:59 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 22 Dec 2017 01:50:59 -0500
Subject: [openssl-users] How to respond to TLS heartbeat in openssl
In-Reply-To: <CAHDZOcOhtxrbHsfqTts5RCFK1excJ6ZujFKCaPzVEDrSJCdC7g@mail.gmail.com>
References: <CAHDZOcMHyKrwO9aTAvrLhyXnKjm6A_z92HS_VSxWbeqk=t-x4Q@mail.gmail.com>
 <CAHDZOcONp-xB0VFGf+Q_VbQy-x+XeEWaAUkHh7_4rHcs8QsMxQ@mail.gmail.com>
 <CAHDZOcOhtxrbHsfqTts5RCFK1excJ6ZujFKCaPzVEDrSJCdC7g@mail.gmail.com>
Message-ID: <CAH8yC8k59D_UoN=4vXj7fd93Tt5dMXzga8y07PM1wdmSB7JLnQ@mail.gmail.com>

On Fri, Dec 22, 2017 at 1:32 AM, Keshava Krishna Bhat K
<keshavkrishna88 at gmail.com> wrote:
> Ok, I got to know that
>  openssl version -a gives out the flags used while building openssl.
> so the output of this was
>
> OpenSSL 1.0.2g  1 Mar 2016
> built on: reproducible build, date unspecified
> platform: debian-amd64
> options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
> compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS
> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack
> -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM
> -DGHASH_ASM -DECP_NISTZ256_ASM
> OPENSSLDIR: "/usr/lib/ssl"
>
> Since the putput above does not have OPENSSL_NO_HEARTBEATS, I assume
> heartbeats are not disabled in the build.
> So I am back to square one :( -> how do I make the server respond to a TLS
> heartbeat request ? Do I have to read the packet and write it back ?

You should also check <openssl/opensslconf.h> for OPENSSL_NO_HEARTBEATS.

$ cd openssl
$ grep -B 1 -A 1 HEART include/openssl/opensslconf.h
#endif
#ifndef OPENSSL_NO_HEARTBEATS
# define OPENSSL_NO_HEARTBEATS
#endif

Jeff

From keshavkrishna88 at gmail.com  Fri Dec 22 07:25:29 2017
From: keshavkrishna88 at gmail.com (Keshava Krishna Bhat K)
Date: Fri, 22 Dec 2017 12:55:29 +0530
Subject: [openssl-users] How to respond to TLS heartbeat in openssl
In-Reply-To: <CAH8yC8k59D_UoN=4vXj7fd93Tt5dMXzga8y07PM1wdmSB7JLnQ@mail.gmail.com>
References: <CAHDZOcMHyKrwO9aTAvrLhyXnKjm6A_z92HS_VSxWbeqk=t-x4Q@mail.gmail.com>
 <CAHDZOcONp-xB0VFGf+Q_VbQy-x+XeEWaAUkHh7_4rHcs8QsMxQ@mail.gmail.com>
 <CAHDZOcOhtxrbHsfqTts5RCFK1excJ6ZujFKCaPzVEDrSJCdC7g@mail.gmail.com>
 <CAH8yC8k59D_UoN=4vXj7fd93Tt5dMXzga8y07PM1wdmSB7JLnQ@mail.gmail.com>
Message-ID: <CAHDZOcMW7t8PrH7bPHhxRZnHibWSJxEsbi=onxuv4O8qA9xD2g@mail.gmail.com>

Hi Jeff,

I checked in the git repo (tags/OpenSSL_1_0_2g), opnesslconf.h does not
have OPENSSL_NO_HEARTBEATS the above definition in 1.0.2g.
So I think its enabled.

Regards,
Keshava.

On Fri, Dec 22, 2017 at 12:20 PM, Jeffrey Walton <noloader at gmail.com> wrote:

> On Fri, Dec 22, 2017 at 1:32 AM, Keshava Krishna Bhat K
> <keshavkrishna88 at gmail.com> wrote:
> > Ok, I got to know that
> >  openssl version -a gives out the flags used while building openssl.
> > so the output of this was
> >
> > OpenSSL 1.0.2g  1 Mar 2016
> > built on: reproducible build, date unspecified
> > platform: debian-amd64
> > options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
> > compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS
> > -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2
> > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> > -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro
> -Wa,--noexecstack
> > -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
> > -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
> > -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM
> > -DGHASH_ASM -DECP_NISTZ256_ASM
> > OPENSSLDIR: "/usr/lib/ssl"
> >
> > Since the putput above does not have OPENSSL_NO_HEARTBEATS, I assume
> > heartbeats are not disabled in the build.
> > So I am back to square one :( -> how do I make the server respond to a
> TLS
> > heartbeat request ? Do I have to read the packet and write it back ?
>
> You should also check <openssl/opensslconf.h> for OPENSSL_NO_HEARTBEATS.
>
> $ cd openssl
> $ grep -B 1 -A 1 HEART include/openssl/opensslconf.h
> #endif
> #ifndef OPENSSL_NO_HEARTBEATS
> # define OPENSSL_NO_HEARTBEATS
> #endif
>
> Jeff
> --
> 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/20171222/5c10f881/attachment-0001.html>

From ManWag at FastMail.FM  Fri Dec 22 10:14:35 2017
From: ManWag at FastMail.FM (Manuel Wagesreither)
Date: Fri, 22 Dec 2017 11:14:35 +0100
Subject: [openssl-users] [EXTERNAL] Certificate gets verified OK over
 SSL-CLI, but not when using SSL-API
In-Reply-To: <1513880829.15053.34.camel@sandia.gov>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
 <1513880829.15053.34.camel@sandia.gov>
Message-ID: <1513937675.1354421.1213293648.5213F617@webmail.messagingengine.com>

Unfortunately this didn't work either. The end result is the same; OpenSSL still emits a "certificate signature failure" with an error depth of 0.

Regards,
Manuel


Am Do, 21. Dez 2017, um 19:27, schrieb Sands, Daniel:
> I'm a fellow SSL-USER and not an expert, but my verification flow goes
> as follows:
> 
> X509_STORE_CTX_new()
> X509_STORE_CTX_init(ctx,NULL,cert,NULL) <-- The certificate to verify
> X509_STORE_CTX_trusted_stack(ctx,CACertificateStack) <-- Perhaps this
> is the difference?
> X509_verify_cert(ctx)
> 
> 
> On Thu, 2017-12-21 at 12:42 +0100, Manuel Wagesreither wrote:
> > Dear all,
> > 
> > I'm struggling with programatically verifying a certificate which is
> > solely stored in memory, i. e. not on the file system. The
> > certificate and the CA seem to be fine though, because when I extract
> > them from memory and store them as a file, and use the `openssl
> > verify`, verification is successful. Hence I suspect my code is
> > faulty.
> > 
> > Unfortunately, I'm under the impression that validating certificates
> > which exist solely in memory is a niche application. I was yet not
> > able to find a comprehensive tutorial or even a code sample on the
> > internet. Hence, I hope you can help me.
> > 
> > Below I'm posting my sample code. (I have stripped the certificate
> > and CA raw data, tough.) It can be compiled an run under a GNU/Linux
> > system.
> > When this code is run, OpenSSL emits a "certificate signature
> > failure" with an error depth of 0.
> > 
> > Thanks a lot!
> > Manuel
> > 
> > ============
> > 
> > #include <openssl/x509.h>
> > #include <stdexcept>
> > #include <iostream>
> > 
> > unsigned char g_authority[] = {	0x30, 0x82, 0x03, 0x00 /* and
> > so on */ };
> > unsigned char g_cert[] = { 0x30, 0x82, 0x02, 0x9b /* and so on */ };
> > 
> > int main(int, char**)
> > {
> > 	// This holds the return codes and gets reused for most
> > function calls
> > 	int rc = 0;
> > 
> > 	// Make a new store
> > 	X509_STORE *x509_store = X509_STORE_new();
> > 	if (x509_store == NULL) {
> > 		throw std::runtime_error("X509_STORE_new() failed");
> > 	}
> > 
> > 	// Load and convert the authoritys certificate to a compatible
> > form
> > 	X509 *auth_cert = NULL;
> > 	{
> > 		const unsigned char* auth_cert_ptr = g_authority;
> > 		auth_cert = d2i_X509(NULL, &auth_cert_ptr,
> > sizeof(g_authority));
> > 		if (auth_cert == nullptr) {
> > 			throw std::runtime_error("d2i_X509() failed for
> > authoritys certificate");
> > 		}
> > 	}
> > 
> > 	// Add the authoritys certificate to the store
> > 	rc = X509_STORE_add_cert(x509_store, auth_cert);
> > 	if (rc != 1) {
> > 		throw std::runtime_error("X509_STORE_add_cert()
> > failed");
> > 	}
> > 
> > 	// Make a new store context
> > 	X509_STORE_CTX *x509_store_ctx = X509_STORE_CTX_new();
> > 	if (x509_store_ctx == NULL) {
> > 		throw std::runtime_error("X509_STORE_CTX_new()
> > failed");
> > 	}
> > 
> > 	// Load and convert the certificate to be verified to a
> > compatible form
> > 	X509 *myself = NULL;
> > 	{
> > 		const unsigned char *my_cert_ptr = g_cert;
> > 		myself = d2i_X509(NULL, &my_cert_ptr, sizeof(g_cert));
> > 		if (myself == NULL) {
> > 			throw std::runtime_error("d2i_X509() failed for
> > own certificate");
> > 		}
> > 	}
> > 
> > 	rc = X509_STORE_CTX_init(x509_store_ctx, x509_store, myself,
> > NULL);
> > 	if (rc != 1) {
> > 		throw std::runtime_error("X509_STORE_CTX_init()
> > failed");
> > 	}
> > 
> > 	rc = X509_verify_cert(x509_store_ctx);
> > 
> > 	X509_STORE_free(x509_store);
> > 	X509_STORE_CTX_free(x509_store_ctx);
> > 
> > 	if (rc > 0) {
> > 		std::cout <<
> > X509_verify_cert_error_string(X509_STORE_CTX_get_error(x509_store_ctx
> > )) << std::endl;
> > 		return 0;
> > 	} else {
> > 		std::cerr <<
> > X509_verify_cert_error_string(X509_STORE_CTX_get_error(x509_store_ctx
> > )) << std::endl;
> > 		std::cerr << "Error depth: " <<
> > X509_STORE_CTX_get_error_depth(x509_store_ctx) << std::endl;
> > 		return 1;
> > 	}
> > }
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From matt at openssl.org  Fri Dec 22 10:53:09 2017
From: matt at openssl.org (Matt Caswell)
Date: Fri, 22 Dec 2017 10:53:09 +0000
Subject: [openssl-users] FW: Help to understand WPACKET API
In-Reply-To: <5a391764.cb4e650a.9ba2b.8f7d@mx.google.com>
References: <5a2a8e0d.1650620a.1b91f.9efd@mx.google.com>
 <5a391764.cb4e650a.9ba2b.8f7d@mx.google.com>
Message-ID: <11137844-d0e2-112d-f1b4-4890b60e676e@openssl.org>



On 19/12/17 13:43, Sai Teja Chowdary wrote:
> After going through the code I understand the new tls1.3 implemented
> OpenSSL code is using WPACKET API to frame the records. I need help in
> understanding what the following functions do. I am new to the mailing
> list, thanks in advance.
> 
> ?
> 
> WPACKET_start_sub_packet_
> 
> WPACKET_allocate_bytes
> 
> WPACKET_sub_allocate_bytes__
> 
> WPACKET_reserve_bytes
> 
> WPACKET_start_sub_packet_len__
> 
> WPACKET_sub_memcpy__
> 
> ?
> 
> Basically what does the word _sub_ mean in these functions and how do
> that differ from the non sub function say
> 
> Difference between WPACKET_sub_memcpy__ and WPACKET_memcpy__

It is common in TLS for a block of data to be preceded by a length.
Depending on the context the number of length bytes might typically be
1, 2, 3 or 4. Such a block of data is considered a "sub" packet in the
WPACKET API. So:

int WPACKET_memcpy(WPACKET *pkt, const void *src, size_t len);

Copies len bytes of data from src into the pkt. Compare with:

#define WPACKET_sub_memcpy_u8(pkt, src, len) \
    WPACKET_sub_memcpy__((pkt), (src), (len), 1)

So WPACKET_sub_memcpy_u8 will also copy len bytes of data from src into
pkt but will precede it with 1 byte containing the value of len.


Matt

From j.graczyk at telic.de  Fri Dec 22 12:44:55 2017
From: j.graczyk at telic.de (Jan Graczyk)
Date: Fri, 22 Dec 2017 12:44:55 +0000
Subject: [openssl-users] Evaluation of OpenSSL stack software
Message-ID: <0AD3F71B283ED7469D76E28693EC1CA5EA6D21@EXCHANGE.CEPAG.local>

Hello OpenSSL-Users,

I am actually evaluating OpenSSL stack software to be possibly used in my company next generation products. We would like to have a secure connection between our device TCP/IP stack and web server which already has SSL server running. I am looking for a benchmarks of OpenSSL client running on ARM Cortex-M3 based processor. I would appreciate very much  feedback from you. Thank you.

Best Regards
Jan Graczyk
Embedded Software Developer - Embedded Software Poland
________________________________
Tel:           +48 535 045 515
Tel2:         +49-89-673460-635
E-Mail:     j.graczyk at telic.de<mailto:j.graczyk at telic.de>
Web:        www.telic.de<http://www.telic.de/>

Telic AG
Raiffeisenallee 12b
82041 Oberhaching
Germany

[cid:image003.png at 01D2336E.70B45010]

________________________________
Local Court Munich, Register Number: HRB 143 723 | Vorstandsvorsitzender: Dr. Ditmar Prigge; Vorstand: Frank Heineck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171222/73cf8afa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 13021 bytes
Desc: image001.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171222/73cf8afa/attachment-0001.png>

From rsalz at akamai.com  Fri Dec 22 13:06:20 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Dec 2017 13:06:20 +0000
Subject: [openssl-users] [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
Message-ID: <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>

Our intent is that all FREE functions can handle NULL.  If you find things missing or undocumented, please open an issue on GitHub.  Thanks!
 


From kgoldman at us.ibm.com  Fri Dec 22 14:13:02 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 22 Dec 2017 09:13:02 -0500
Subject: [openssl-users] [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
Message-ID: <p1j3pe$n3u$1@blaine.gmane.org>

On 12/22/2017 8:06 AM, Salz, Rich via openssl-users wrote:
> Our intent is that all FREE functions can handle NULL.  If you find
> things missing or undocumented, please open an issue on GitHub.
> Thanks!

It would be great if that was documented for all _free() functions.  I 
currently always code

	if (ptr!= NULL) free(ptr);

because the behavior isn't defined.

BTW, "can handle" should explicitly say what happens.  Perhaps use the C 
library text, which says:

	If ptr is NULL, no operation is performed.





From rsalz at akamai.com  Fri Dec 22 14:24:19 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Dec 2017 14:24:19 +0000
Subject: [openssl-users] [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <p1j3pe$n3u$1@blaine.gmane.org>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
 <p1j3pe$n3u$1@blaine.gmane.org>
Message-ID: <0E31DD35-A4A4-416A-A7F0-4D08CB123EFB@akamai.com>

>	if (ptr!= NULL) free(ptr);
  
That shouldn?t be necessary for OpenSSL.  If you find places where it is, please open an issue.
  
? BTW, "can handle" should explicitly say what happens.  Perhaps use the C 
    library text, which says:
    
    	If ptr is NULL, no operation is performed.
  
That is the wording we use.


From kurt at roeckx.be  Fri Dec 22 14:36:21 2017
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 22 Dec 2017 15:36:21 +0100
Subject: [openssl-users] [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
Message-ID: <20171222143621.GA26510@roeckx.be>

On Fri, Dec 22, 2017 at 01:06:20PM +0000, Salz, Rich via openssl-dev wrote:
> Our intent is that all FREE functions can handle NULL.  If you find things missing or undocumented, please open an issue on GitHub.  Thanks!

I think we fixed all such cases in 1.1.0, all *_free() functions
should handle NULL. I don't think we backported to changes to 1.0.2.


Kurt


From kgoldman at us.ibm.com  Fri Dec 22 14:30:19 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 22 Dec 2017 09:30:19 -0500
Subject: [openssl-users] [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <0E31DD35-A4A4-416A-A7F0-4D08CB123EFB@akamai.com>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
 <p1j3pe$n3u$1@blaine.gmane.org>
 <0E31DD35-A4A4-416A-A7F0-4D08CB123EFB@akamai.com>
Message-ID: <p1j4ps$q3g$1@blaine.gmane.org>

On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote:
>> 	if (ptr!= NULL) free(ptr);
>    
> That shouldn?t be necessary for OpenSSL.  If you find places where it is, please open an issue.
>    

OK.  I'll mention a few, but it's a global issue.

The code may handle NULL.  However, conservative users won't go by what 
the code happens to do today.  We have to go by the API documentation, 
which is the contract between the library and the user.  If the API is 
silent, we cautiously assume it's not guaranteed, and can change in the 
future.





From kurt at roeckx.be  Fri Dec 22 14:37:32 2017
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 22 Dec 2017 15:37:32 +0100
Subject: [openssl-users] [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <p1j4ps$q3g$1@blaine.gmane.org>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
 <p1j3pe$n3u$1@blaine.gmane.org>
 <0E31DD35-A4A4-416A-A7F0-4D08CB123EFB@akamai.com>
 <p1j4ps$q3g$1@blaine.gmane.org>
Message-ID: <20171222143731.GB26510@roeckx.be>

On Fri, Dec 22, 2017 at 09:30:19AM -0500, Ken Goldman wrote:
> On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote:
> > > 	if (ptr!= NULL) free(ptr);
> > That shouldn?t be necessary for OpenSSL.  If you find places where it is, please open an issue.
> 
> OK.  I'll mention a few, but it's a global issue.
> 
> The code may handle NULL.  However, conservative users won't go by what the
> code happens to do today.  We have to go by the API documentation, which is
> the contract between the library and the user.  If the API is silent, we
> cautiously assume it's not guaranteed, and can change in the future.

So feel free to document it as being able to handle NULL.


Kurt


From rsalz at akamai.com  Fri Dec 22 14:59:08 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Dec 2017 14:59:08 +0000
Subject: [openssl-users] [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <20171222143621.GA26510@roeckx.be>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
 <20171222143621.GA26510@roeckx.be>
Message-ID: <C4D6E729-81E6-4E1A-9165-178950CB2C24@akamai.com>


?     I think we fixed all such cases in 1.1.0, all *_free() functions
    should handle NULL. I don't think we backported to changes to 1.0.2.
    
Yes, and we fixed the documentation.  I backported all/most of them to 1.0.2 to make cherry-picking easier.  I don?t know if I changed the docs.


From rsalz at akamai.com  Fri Dec 22 15:17:42 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Dec 2017 15:17:42 +0000
Subject: [openssl-users] [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <p1j7f2$th4$1@blaine.gmane.org>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
 <20171222143621.GA26510@roeckx.be>
 <C4D6E729-81E6-4E1A-9165-178950CB2C24@akamai.com>
 <p1j7f2$th4$1@blaine.gmane.org>
Message-ID: <461F64FB-055E-4A19-B237-CABAC3DA9BA3@akamai.com>

?    So it's guaranteed for 1.1, mostly guaranteed for recent 1.0.2, but not
    guaranteed for older 1.0.2.
    
yes.


?     I also think it would be good to backport all to 1.0.2

Yes.  I believe I did that, but I am not absolutely 100% positive.


From janjust at nikhef.nl  Fri Dec 22 15:30:17 2017
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Fri, 22 Dec 2017 16:30:17 +0100
Subject: [openssl-users] [EXTERNAL] Certificate gets verified OK over
 SSL-CLI, but not when using SSL-API
In-Reply-To: <1513937675.1354421.1213293648.5213F617@webmail.messagingengine.com>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
 <1513880829.15053.34.camel@sandia.gov>
 <1513937675.1354421.1213293648.5213F617@webmail.messagingengine.com>
Message-ID: <8343a247-4dbe-2907-f536-0be2d913a9ec@nikhef.nl>

Hi,

On 22/12/17 11:14, Manuel Wagesreither wrote:
> Unfortunately this didn't work either. The end result is the same; OpenSSL still emits a "certificate signature failure" with an error depth of 0.
>
>
here's a stripped down version of my 'grid-proxy-verify.c' that verifies 
a certificate loaded from memory. My cert is included in the file. The 
CA used to verify the certificate is loaded from a directory, but the 
principle for reading a CA file from memory is the same:

char CAdata[] = "....";

if ( !(CA_bio = BIO_new_mem_buf(CAdata, -1) ) ) return ERR_get_error();

etc.
This code is a bit overkill - it will verify a stack of certificates, 
not just a single one, but I am sure you can rework it just to verify a 
single cert ;)


HTH,

JJK

====

#define _GNU_SOURCE

#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>

#include <sys/types.h>
#include <sys/stat.h>

#include <openssl/x509.h>
#include <openssl/x509v3.h>
#include <openssl/x509_vfy.h>
#include <openssl/crypto.h>
#include <openssl/err.h>
#include <openssl/pem.h>

#include <openssl/rsa.h>
#include <openssl/evp.h>
#include <openssl/bio.h>
#include <openssl/des.h>
#include <openssl/rand.h>

#include <openssl/buffer.h>
#include <openssl/objects.h>

#define L_ERROR  0  /* errors */
#define L_WARN   1  /* all unusual */
#define L_INFO   2  /* all status changes etc. */
#define L_DEBUG  3  /* all, including trace */

int    log_level = 1;

void Log( int msg_level, const char *msg, ...)
{
     va_list argp;

     if ( log_level >= msg_level )
     {
         if (msg_level == L_WARN )  fprintf( stderr, "Warning: " );
         if (msg_level == L_INFO )  fprintf( stderr, "Info:    " );
         if (msg_level == L_DEBUG ) fprintf( stderr, "Debug:   " );
         va_start( argp, msg );
         vfprintf( stderr, msg, argp );
         va_end( argp );
         fprintf( stderr, "\n" );
     }
}

void Error( const char *operation, const char *msg, ...)
{
     va_list argp;

     fprintf( stderr, "ERROR:  %s: ", operation );
     va_start( argp, msg );
     vfprintf( stderr, msg, argp );
     va_end( argp );
     fprintf( stderr, "\n" );
}


unsigned long read_memCert( STACK_OF(X509) **certstack )
{
     char                *oper = "Reading mem";

     STACK_OF(X509_INFO) *sk      = NULL;
     BIO                 *certbio = NULL;
     X509_INFO           *xi;
     unsigned long        err;

     char data[] = "\n\
-----BEGIN CERTIFICATE-----\n\
MIIE7zCCA9egAwIBAgICFF8wDQYJKoZIhvcNAQELBQAwUjELMAkGA1UEBhMCTkwx\n\
DzANBgNVBAoTBk5JS0hFRjEyMDAGA1UEAxMpTklLSEVGIG1lZGl1bS1zZWN1cml0\n\
eSBjZXJ0aWZpY2F0aW9uIGF1dGgwHhcNMTcwNTMxMDAwMDAwWhcNMTgwNTMxMTQ1\n\
NzQwWjBQMRIwEAYDVQQKEwlkdXRjaGdyaWQxDjAMBgNVBAoTBXVzZXJzMQ8wDQYD\n\
VQQKEwZuaWtoZWYxGTAXBgNVBAMTEEphbiBKdXN0IEtlaWpzZXIwggEiMA0GCSqG\n\
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUgM6fRU95Qs/qiquRpLqtLFX2EEooIFFm\n\
Jo0IxwpISgIq37HUgfbNBB97ZXaMDtrWrcJt1PbXIj7NCXsDJ4V6zueKwx3Dsr2W\n\
H5V9FvK6bj+vz3S1bOvG1EJUpnS81/Fmlawkd7bK7dXwuZVbUp7QcmzGuwmFO3/3\n\
h2sX5a1z7gkb3VZXIyFk2lz1W+bt4bgb6WNvcOZuXwbawsF4F6LZkaHJ6JwsuZMc\n\
/gIOhQYXD4+KPOG96/PRgpC7BBWcwfmg9fPNxp09QD6q9XEM9MN307BYQ7BWAgrq\n\
yUvhL69/+DIBCwkcUnzWxeZbcsfziHx/HUR251NybNsp6Mu+IdjJAgMBAAGjggHP\n\
MIIByzAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggr\n\
BgEFBQcDAgYIKwYBBQUHAwQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NhLmR1\n\
dGNoZ3JpZC5ubC9tZWRpdW0vY2FjcmwuZGVyMCgGA1UdIAQhMB8wDwYNKwYBBAHR\n\
QgQCAgEDAjAMBgoqhkiG90wFAgIBMB8GA1UdIwQYMBaAFFsFOpnG1SK9/ZSA/BGo\n\
0PFx1kukMB0GA1UdDgQWBBRrObKYCp8RcKwXn4kcHa6zFXpU7DARBglghkgBhvhC\n\
AQEEBAMCBaAwNAYJYIZIAYb4QgEIBCcWJWh0dHA6Ly9jYS5kdXRjaGdyaWQubmwv\n\
bWVkaXVtL3BvbGljeS8wgZ4GCWCGSAGG+EIBDQSBkBaBjUVFQyBpc3N1ZWQgdW5k\n\
ZXIgcG9saWN5IHZlcnNpb24gMy4yIC0gbGltaXRlZCBsaWFiaWxpdGllcyBhcHBs\n\
eSwgc2VlIGh0dHA6Ly9jYS5kdXRjaGdyaWQubmwvbWVkaXVtL3BvbGljeS8gLSBD\n\
ZXJ0aWZpY2F0ZSBUYWc6IDY5MDRhMTdkLTk0ODBjZTANBgkqhkiG9w0BAQsFAAOC\n\
AQEAeLFnQAYF4FWHJ0y+7T9bUtFoQLv6ZsqBlaSwlzuhpSMlOVvzOLvqlmLVdbk5\n\
nkEBu008FBTA2r9UysIhB00MxhypAxkhzIXxfslZBwtxdmZ0s0MBoIwLb6Lo3Td5\n\
ktFKra31KOlwdiAFZxmsi5Du4p+sY5uW5RNIsa9dxqccOd0+TOglARF/sF5xliHv\n\
x8y+qvVmiMBa0nZmvqO0OQfTb4oNbByGeeH6yQyQqxWpJwwdXx+Q4JJhZhXAJIOt\n\
Ze52sXps/K/1R3laqXaEW7xYZbragtgimbkMkPCHr6624ajslViyqI2efwlI1+em\n\
ueVU4EK03fp65Egd6Qs9yx5+VA==\n\
-----END CERTIFICATE-----\n\
";

     Log( L_DEBUG, "--- Welcome to the read_memCert function ---");

     *certstack = sk_X509_new_null();
     if (*certstack == NULL) return ERR_get_error();

     if ( !(certbio = BIO_new_mem_buf(data, -1) ) ) return ERR_get_error();

     Log( L_DEBUG, "Reading X509_INFO records" );
     if ( !(sk=PEM_X509_INFO_read_bio(certbio, NULL, NULL, NULL)) )
     {
         err = ERR_get_error();
         Error( oper, "No X509 records found" );
         BIO_free(certbio);
         sk_X509_INFO_free(sk);
         sk_X509_free(*certstack);
         *certstack = NULL;
         return err;
     }

     while (sk_X509_INFO_num(sk))
     {
         xi=sk_X509_INFO_shift(sk);
         if (xi->x509 != NULL)
         {
             sk_X509_push(*certstack, xi->x509);
             xi->x509=NULL;
         }
         X509_INFO_free(xi);
     }

     if (!sk_X509_num(*certstack))
     {
         err = ERR_get_error();
         Error( oper, "No certificates found" );
         BIO_free(certbio);
         sk_X509_INFO_free(sk);
         sk_X509_free(*certstack);
         *certstack = NULL;
         return err;
     }

     BIO_free(certbio);
     sk_X509_INFO_free(sk);

     return X509_V_OK;
}

static int mem_verify_callback(int ok, X509_STORE_CTX *ctx)
{
     unsigned long   errnum   = X509_STORE_CTX_get_error(ctx);
     int             errdepth = X509_STORE_CTX_get_error_depth(ctx);
     STACK_OF(X509) *certstack;
     X509           *cert = NULL;
     char           *cert_DN = NULL;

     Log( L_DEBUG, "--- Welcome to the mem_verify_callback function ---");

     cert    = X509_STORE_CTX_get_current_cert(ctx);
     cert_DN = X509_NAME_oneline( X509_get_subject_name( cert), NULL, 0);
     Log( L_DEBUG, "cert DN: %s", cert_DN );

     if (ok != 1)
     {
         Log( L_INFO, "mem_verify_callback: error message=%s",
                      X509_verify_cert_error_string (errnum));
     }

     free(cert_DN);

     return ok;
}


unsigned long mem_verifyCert( char * CA_DIR, STACK_OF(X509) *certstack )
{
     char           *oper = "Verifying certificate chain";

     X509_STORE     *store      = NULL;
     X509_LOOKUP    *lookup     = NULL;
     X509_STORE_CTX *verify_ctx = NULL;
     X509           *cert       = NULL;
     char           *cert_DN;
     char           *issuer_DN;
     int             i = 0;
     int             depth      = sk_X509_num( certstack );
     unsigned long   ret        = X509_V_OK;

     Log( L_DEBUG, "--- Welcome to the mem_verifyCert function ---");

     /* Initials must be good */
     if ( CA_DIR == NULL )
     {
         Error( oper, "No CA certificate directory specified." );
         return X509_V_ERR_APPLICATION_VERIFICATION;
     }
     if ( certstack == NULL )
     {
         Error( oper, "Certificate stack is empty." );
         return X509_V_ERR_APPLICATION_VERIFICATION;
     }

     Log( L_INFO, "Using CA Directory: %s", CA_DIR);

     Log( L_DEBUG, "X509_STORE_new");
     if (!(store = X509_STORE_new()))
     {
        Error( oper, "Could not create a X509 STORE." );
        return ERR_get_error();
     }

     Log( L_DEBUG, "X509_STORE_set_verify_cb_func");
     X509_STORE_set_verify_cb_func (store, mem_verify_callback);

     /* Executing the lookups to the CA and CRL files */
     Log( L_DEBUG, "X509_STORE_load_locations");
     if (X509_STORE_load_locations (store, NULL, CA_DIR) != 1)
     {
         Error( oper, "Could not load the CA directory.");
         return ERR_get_error();
     }

     Log( L_DEBUG, "X509_STORE_set_default_paths");
     if (X509_STORE_set_default_paths(store) != 1)
     {
         Error( oper, "Could not load the system wide CA certificates.");
         return ERR_get_error();
     }

     Log( L_DEBUG, "X509_STORE_add_lookup");
     if (!(lookup = X509_STORE_add_lookup (store, X509_LOOKUP_hash_dir())))
     {
         Error( oper, "Could not create X509_LOOKUP object.");
         return ERR_get_error();
     }

     Log( L_DEBUG, "X509_LOOKUP_add_dir");
     i=X509_LOOKUP_add_dir (lookup, CA_DIR, X509_FILETYPE_PEM);
     if (!i)
     {
         Error( oper, "Coult not add CA_DIR.");
         return ERR_get_error();
     }

     Log( L_DEBUG, "X509_STORE_CTX_new");
     /* Creating a verification context and initialize it */
     if (!(verify_ctx = X509_STORE_CTX_new()))
     {
         Error( oper, "Could not create a X509 STORE CTX (context).");
         return ERR_get_error();
     }

     for (i=depth-1; i >= 0; --i)
     {
         if ((cert = sk_X509_value(certstack, i)))
         {
             cert_DN   = 
X509_NAME_oneline(X509_get_subject_name(cert),NULL,0);
             issuer_DN = 
X509_NAME_oneline(X509_get_issuer_name(cert),NULL,0);

             Log( L_DEBUG, "DN[%d]:        %s", i, cert_DN );
             Log( L_DEBUG, "Issuer DN[%d]: %s", i, issuer_DN);

             free( cert_DN );
             free( issuer_DN );

         }
     }

     cert = sk_X509_value( certstack, 0 );
     cert_DN   = X509_NAME_oneline( X509_get_subject_name( cert ) , 
NULL, 0 );
     issuer_DN = X509_NAME_oneline( X509_get_issuer_name( cert )  , 
NULL, 0 );

     Log( L_INFO, "Certificate to verify:" );
     Log( L_INFO, "  DN:        %s", cert_DN );
     Log( L_INFO, "  Issuer DN: %s", issuer_DN );

     free( cert_DN );
     free( issuer_DN );

     Log( L_DEBUG, "X509_STORE_CTX_init" );
     if ( X509_STORE_CTX_init( verify_ctx, store, cert, certstack ) != 1 )
     {
         Error( oper, "Could not initialize verification context.");
         return ERR_get_error();
     }

     X509_STORE_CTX_set_purpose( verify_ctx, X509_PURPOSE_SSL_CLIENT );

     Log( L_DEBUG, "X509_verify");
     if ( (X509_verify_cert( verify_ctx ) ) != 1 )
     {
         ret = verify_ctx->error;
     }
     else
     {
         Log( L_INFO, "The verification of the certicate has succeeded.");
     }

     if ( verify_ctx ) X509_STORE_CTX_free( verify_ctx );
     if ( store )      X509_STORE_free( store );

     return ret;
}


int main( int argc, char **argv )
{
     char             *CA_dir = NULL;

     unsigned long     i, result = 0;
     char             *long_opt;
     struct stat       my_stat;
     STACK_OF(X509)   *certStack = NULL;

     OpenSSL_add_all_algorithms();
     ERR_load_crypto_strings();

     for (i = 1; i < argc; i++)
     {
         if ( (strlen(argv[i]) >= 2 ) && ( argv[i][0] == '-' ) )
         {
             switch (argv[i][1])
             {
                 case '-': long_opt = argv[i]+2;
                           if ( strcmp( long_opt, "debug") == 0 )
                               log_level++;
                           else if ( strcmp( long_opt, "quiet") == 0 )
                               log_level = 0;
                           else
                               fprintf( stderr, "Unknown option: %s\n", 
argv[i] );
                           break;
                 case 'd': log_level++;
                           break;
                 case 'q': log_level = 0;
                           break;
                 default:  fprintf( stderr, "Unknown option: %s\n", 
argv[i] );
             }
         }
     }

     /* First, find the trusted CA directory */
     CA_dir = getenv( "X509_CERT_DIR" );
     if ( CA_dir == NULL ) CA_dir = "/etc/grid-security/certificates/";

     Log ( L_DEBUG, "Testing CA directory %s", CA_dir );
     if ( (result = stat( CA_dir, &my_stat ) ) != 0 )
     {
         CA_dir = getenv( "HOME" );
         strcat( CA_dir, "/.globus/certificates/" );

         Log ( L_DEBUG, "Testing CA directory %s", CA_dir );
         result = stat( CA_dir, &my_stat );
     }
     if (result != 0 ) Log( L_WARN, "Trusted certificate directory not 
found!" );

     result = read_memCert( &certStack );
     if ( result == X509_V_OK )
     {
         result = mem_verifyCert( CA_dir, certStack );
         if ( result == X509_V_OK )
         {
             printf( "OK\n" );
         }
         else
             Error( "Verifying certificate chain", "%s\n",
                    X509_verify_cert_error_string( result ) );
     }
     else
         Error( "Reading memory", "%s\n",
                ERR_reason_error_string( result ) );

     sk_X509_pop_free( certStack, X509_free );

     /* make valgrind happy */
     ERR_remove_state(0);
     ERR_free_strings();
     EVP_cleanup();
     CRYPTO_cleanup_all_ex_data();

     return ( !( result == X509_V_OK ) );
}



From ManWag at FastMail.FM  Fri Dec 22 15:43:56 2017
From: ManWag at FastMail.FM (Manuel Wagesreither)
Date: Fri, 22 Dec 2017 16:43:56 +0100
Subject: [openssl-users] [EXTERNAL] Certificate gets verified OK over
 SSL-CLI, but not when using SSL-API
In-Reply-To: <1513937675.1354421.1213293648.5213F617@webmail.messagingengine.com>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
 <1513880829.15053.34.camel@sandia.gov>
 <1513937675.1354421.1213293648.5213F617@webmail.messagingengine.com>
Message-ID: <1513957436.467802.1213536808.6C09AB41@webmail.messagingengine.com>

Dear all,

I just found out that this problem only occurs when I'm linking the executable against libssl 1.0.1k. When linking against libssl 1.1.0f, the certificate does get validated fine.

Does anyone know possible reasons? Do these libssl versions differ in regard to certificate validation? I would like my code to work with libssl 1.0.1k preferably.

Regards,
Manuel

From rsalz at akamai.com  Fri Dec 22 16:06:21 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Dec 2017 16:06:21 +0000
Subject: [openssl-users] [EXTERNAL] Certificate gets verified OK over
 SSL-CLI, but not when using SSL-API
In-Reply-To: <1513957436.467802.1213536808.6C09AB41@webmail.messagingengine.com>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
 <1513880829.15053.34.camel@sandia.gov>
 <1513937675.1354421.1213293648.5213F617@webmail.messagingengine.com>
 <1513957436.467802.1213536808.6C09AB41@webmail.messagingengine.com>
Message-ID: <F6F0AB4D-2F44-4B8E-9DD6-CF37BE623BCC@akamai.com>

Yes, the certificate validation was fixed, and improved, in 1.1.0.

You should not use 1.0.1 if you can at all avoid it.  It has many bugs, probably security issues, and missing features.  Like, for example, cert validation.
 


From openssl-users at dukhovni.org  Fri Dec 22 16:17:36 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 22 Dec 2017 11:17:36 -0500
Subject: [openssl-users] [openssl-security] Openssl Vulnerability
	detected
In-Reply-To: <5AB9FF5A-DA08-4BE3-8DAA-3512BC81DCCA@akamai.com>
References: <5AB9FF5A-DA08-4BE3-8DAA-3512BC81DCCA@akamai.com>
Message-ID: <D052554D-AF0C-41EE-A41E-6A4D26170F00@dukhovni.org>



> On Dec 22, 2017, at 7:03 AM, Salz, Rich <rsalz at akamai.com> wrote:
> 
> Having said that, the answer is upgrade to a supported version, ideally 1.1.0

A better answer is typically to deploy the latest patched version from the
platform vendor.  And to not enable SSLv2 or SSLv3.  Most applications 
support configurable cipher strings.  If one wants to disable DES and 3DES
just set the cipherstring to:

	DEFAULT:!3DES:!LOW:!EXPORT

plus any other desired exclusions.

-- 
	Viktor.


From dnsands at sandia.gov  Fri Dec 22 19:31:35 2017
From: dnsands at sandia.gov (Sands, Daniel)
Date: Fri, 22 Dec 2017 19:31:35 +0000
Subject: [openssl-users] [EXTERNAL] Certificate gets verified OK over
 SSL-CLI, but not when using SSL-API
In-Reply-To: <1513937675.1354421.1213293648.5213F617@webmail.messagingengine.com>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
 <1513880829.15053.34.camel@sandia.gov>
 <1513937675.1354421.1213293648.5213F617@webmail.messagingengine.com>
Message-ID: <1513971095.15053.36.camel@sandia.gov>

On Fri, 2017-12-22 at 11:14 +0100, Manuel Wagesreither wrote:
> Unfortunately this didn't work either. The end result is the same;
> OpenSSL still emits a "certificate signature failure" with an error
> depth of 0.
> 
In light of what Salz said about verification, could we assume that the
openssl verify program that succeeded is based on the older library?

It could be that your CA cert is missing an extension that OSSL now
checks for, such as (spitballing here) that the certificate is valid
for certificate signing.

You could check by substituting other certificates in your program to
see if the code itself works, and also closely examine your own
certificates to make sure all the requirements are met.

From mcr at sandelman.ca  Fri Dec 22 22:09:38 2017
From: mcr at sandelman.ca (Michael Richardson)
Date: Fri, 22 Dec 2017 17:09:38 -0500
Subject: [openssl-users] Evaluation of OpenSSL stack software
In-Reply-To: <0AD3F71B283ED7469D76E28693EC1CA5EA6D21@EXCHANGE.CEPAG.local>
References: <0AD3F71B283ED7469D76E28693EC1CA5EA6D21@EXCHANGE.CEPAG.local>
Message-ID: <28004.1513980578@obiwan.sandelman.ca>


Jan Graczyk <j.graczyk at telic.de> wrote:
    > I am actually evaluating OpenSSL stack software to be possibly used in
    > my company next generation products. We would like to have a secure
    > connection between our device TCP/IP stack and web server which already
    > has SSL server running. I am looking for a benchmarks of OpenSSL client
    > running on ARM Cortex-M3 based processor. I would appreciate very much
    > feedback from you. Thank you.

I think you'll need to be far specific.

If you want to know bulk AES128 performance, then maybe this will help:
  https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/presentations/session7-vincent.pdf

What compiler?  What MHZ?  What kind of RAM?
The above paper uses mbedTLS (which used to be PolarSSL, but ARM bought it).
The bulk rates are likely comparable.  I don't have any data, but a google
searched found a variety of papers.
Fitting openssl into an M3's code space can be easy or hard depending on many factors. 

If you are concerned about setup times, then what method are you using to authenticate?
(RSA? ECDSA? PSK? Raw Public Key)

    > Best Regards
    > Jan Graczyk
    > Embedded Software Developer ? Embedded Software Poland

    > ----------------------------------------------------------------------
    > Tel: +48 535 045 515 Telic AG cid:imag
    > Tel2: +49-89-673460-635 Raiffeisenallee 12b
    > E-Mail: j.graczyk at telic.de82041 Oberhaching
    > Web: www.telic.de Germany cid:image003.png at 01D2336E.70B45010
    > ----------------------------------------------------------------------



-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171222/fc5e8767/attachment.sig>

From germain.lechapelain at lanvaux.fr  Fri Dec 22 15:20:20 2017
From: germain.lechapelain at lanvaux.fr (Germain Le Chapelain)
Date: Fri, 22 Dec 2017 15:20:20 +0000 (UTC)
Subject: [openssl-users] After calling SSL_Shutdown on client,
	server's SSL_get_shutdown still returns 0
Message-ID: <20171222152020.3B5F82CE2F2@germ.lanvaux.fr>

Hi!


Is this supposed to happen ?
I have a SSL Server writting to a client.

I was expecting that if, at a random time (user initiated) the client would call SSL_Shutdown,
then the Server would `see' the shutdown by calling SSL_get_shutdown

But that never happens.

If I keep calling Shutdown on the client, the second time it returns -1 (with ERRORSYSCALL I think)
I can keep reading the data from the server on the client with SSL_read until it decides to stop.

SSL_get_shutdown on the server keeps returning zero during that time.


Am I missunderstanding how this is supposed to work ?

Now, I am giving up and implementing a system where I have a second server on a separate port, 
which only waits for a connection from the client to know if it should stop transmitting and close 
the connection.


Thank you!


Germain

From d3ck0r at gmail.com  Sat Dec 23 03:06:13 2017
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 22 Dec 2017 19:06:13 -0800
Subject: [openssl-users] Sudden control data sent during large transfer.
Message-ID: <CAA2GJqUKguBWew-kCsx1nLL0XCYZQ0x4Jt-AUrf9UdbW_a6kJw@mail.gmail.com>

How can I know what/why openssl is sending control data?
I have this Node addon that uses TLS 1.2 to communicate.  I'm sending a
large file transfer (100M), which is chunked into 8100 byte blocks and sent
on websocket protocol.  It's additionally chunked into 4327 byte blocks
(which after encoding is 4356 bytes or 1452*3)  All of the data is encoded
into blocks and queued to transfer before I have a problem.
After some amount of data transfer OpenSSL starts sending 31 byte control
packets after basically each block received... when the other side receives
that data it doesn't do anything, but the ssl layer does stop giving me
completed packets (instead opting to generate 31 byte packets) when the
other side receives those, it doesn't do anything.... (doesn't generate
control sends back).

Ad I mentioned all of the pendijng data is already queued to send, so even
if I received a control packet and it generated a response it wouldn't get
received for quite some time.

I don't have control over what version of SSL is being used... but this
current test is 1.0.1m

It's variable by the time it starts sending 31 byte packets... Also depends
on the connection; although at this time I'm able to generate the problem
on localhost... I was able to transfer from a remote server to myself with
no issues...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171222/c94d608b/attachment.html>

From d3ck0r at gmail.com  Sat Dec 23 03:21:01 2017
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 22 Dec 2017 19:21:01 -0800
Subject: [openssl-users] Evaluation of OpenSSL stack software
In-Reply-To: <0AD3F71B283ED7469D76E28693EC1CA5EA6D21@EXCHANGE.CEPAG.local>
References: <0AD3F71B283ED7469D76E28693EC1CA5EA6D21@EXCHANGE.CEPAG.local>
Message-ID: <CAA2GJqVWoyOt2T93c5N+t0DEBeh-tSMwRn23_qN+6dDy_CMoBA@mail.gmail.com>

On Fri, Dec 22, 2017 at 4:44 AM, Jan Graczyk <j.graczyk at telic.de> wrote:

> Hello OpenSSL-Users,
>
>
>
> I am actually evaluating OpenSSL stack software to be possibly used in my
> company next generation products. We would like to have a secure connection
> between our device TCP/IP stack and web server which already has SSL server
> running. I am looking for a benchmarks of OpenSSL client running on ARM
> Cortex-M3 based processor. I would appreciate very much  feedback from you.
> Thank you.
>
>
>

I would also suggest check out LibreSSL which uses the same API as OpenSSL
but was easier to build (not requiring perl) and supports CMake.


> Best Regards
>
> *Jan Graczyk*
>
> Embedded Software Developer ? Embedded Software Poland
> ------------------------------
>
> Tel:           +48 535 045 515 <+48%20535%20045%20515>
>
> Tel2:         +49-89-673460-635 <+49%2089%20673460635>
>
> E-Mail:     j.graczyk at telic.de
>
> Web:        www.telic.de
>
> *Telic AG*
>
> Raiffeisenallee 12b
>
> 82041 Oberhaching
>
> Germany
>
> [image: cid:image003.png at 01D2336E.70B45010]
> ------------------------------
>
> Local Court Munich, Register Number: HRB 143 723 | Vorstandsvorsitzender:
> Dr. Ditmar Prigge; Vorstand: Frank Heineck
>
>
>
> --
> 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/20171222/cebe982a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 13021 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171222/cebe982a/attachment-0001.png>

From openssl-users at dukhovni.org  Sat Dec 23 03:23:06 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 22 Dec 2017 22:23:06 -0500
Subject: [openssl-users] Evaluation of OpenSSL stack software
In-Reply-To: <CAA2GJqVWoyOt2T93c5N+t0DEBeh-tSMwRn23_qN+6dDy_CMoBA@mail.gmail.com>
References: <0AD3F71B283ED7469D76E28693EC1CA5EA6D21@EXCHANGE.CEPAG.local>
 <CAA2GJqVWoyOt2T93c5N+t0DEBeh-tSMwRn23_qN+6dDy_CMoBA@mail.gmail.com>
Message-ID: <58B5A5E9-767D-41BA-8E1A-2898F5982F78@dukhovni.org>



> On Dec 22, 2017, at 10:21 PM, J Decker <d3ck0r at gmail.com> wrote:
> 
> I would also suggest check out LibreSSL which uses the same API as OpenSSL

Very similar to OpenSSL 1.0.2, plus its own extensions.  That's not exactly
"same".

-- 
	Viktor.


From d3ck0r at gmail.com  Sat Dec 23 04:33:32 2017
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 22 Dec 2017 20:33:32 -0800
Subject: [openssl-users] Evaluation of OpenSSL stack software
In-Reply-To: <58B5A5E9-767D-41BA-8E1A-2898F5982F78@dukhovni.org>
References: <0AD3F71B283ED7469D76E28693EC1CA5EA6D21@EXCHANGE.CEPAG.local>
 <CAA2GJqVWoyOt2T93c5N+t0DEBeh-tSMwRn23_qN+6dDy_CMoBA@mail.gmail.com>
 <58B5A5E9-767D-41BA-8E1A-2898F5982F78@dukhovni.org>
Message-ID: <CAA2GJqXyJ6Xtr7SxATqxpPNR9DkX51gHLNLR6vSG-9FOzMNsTg@mail.gmail.com>

On Fri, Dec 22, 2017 at 7:23 PM, Viktor Dukhovni <openssl-users at dukhovni.org
> wrote:

>
>
> > On Dec 22, 2017, at 10:21 PM, J Decker <d3ck0r at gmail.com> wrote:
> >
> > I would also suggest check out LibreSSL which uses the same API as
> OpenSSL
>
> Very similar to OpenSSL 1.0.2, plus its own extensions.  That's not exactly
> "same".
>

The same in that I can link/compile against either and not change any
application code... not speaking of internals, just the API.

>
> --
>         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/20171222/5cd33659/attachment.html>

From openssl-users at dukhovni.org  Sat Dec 23 04:40:26 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 22 Dec 2017 23:40:26 -0500
Subject: [openssl-users] Evaluation of OpenSSL stack software
In-Reply-To: <CAA2GJqXyJ6Xtr7SxATqxpPNR9DkX51gHLNLR6vSG-9FOzMNsTg@mail.gmail.com>
References: <0AD3F71B283ED7469D76E28693EC1CA5EA6D21@EXCHANGE.CEPAG.local>
 <CAA2GJqVWoyOt2T93c5N+t0DEBeh-tSMwRn23_qN+6dDy_CMoBA@mail.gmail.com>
 <58B5A5E9-767D-41BA-8E1A-2898F5982F78@dukhovni.org>
 <CAA2GJqXyJ6Xtr7SxATqxpPNR9DkX51gHLNLR6vSG-9FOzMNsTg@mail.gmail.com>
Message-ID: <CC7DA6CE-33E9-416A-9BE3-652C9E5ED9B0@dukhovni.org>



> On Dec 22, 2017, at 11:33 PM, J Decker <d3ck0r at gmail.com> wrote:
> 
> Very similar to OpenSSL 1.0.2, plus its own extensions.  That's not exactly
> "same".
> 
> The same in that I can link/compile against either and not change any application code... not speaking of internals, just the API. 

Well, that's not actually true.  There are API differences.  There
is a large common intersection that covers many legacy applications,
but newer features in each library are not present in the other.

-- 
-- 
	Viktor.


From d3ck0r at gmail.com  Sat Dec 23 04:47:14 2017
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 22 Dec 2017 20:47:14 -0800
Subject: [openssl-users] Evaluation of OpenSSL stack software
In-Reply-To: <CC7DA6CE-33E9-416A-9BE3-652C9E5ED9B0@dukhovni.org>
References: <0AD3F71B283ED7469D76E28693EC1CA5EA6D21@EXCHANGE.CEPAG.local>
 <CAA2GJqVWoyOt2T93c5N+t0DEBeh-tSMwRn23_qN+6dDy_CMoBA@mail.gmail.com>
 <58B5A5E9-767D-41BA-8E1A-2898F5982F78@dukhovni.org>
 <CAA2GJqXyJ6Xtr7SxATqxpPNR9DkX51gHLNLR6vSG-9FOzMNsTg@mail.gmail.com>
 <CC7DA6CE-33E9-416A-9BE3-652C9E5ED9B0@dukhovni.org>
Message-ID: <CAA2GJqWtUc_hASbNTSE=ugOEoGMpc9y9mGvGOyHbKSXhGEh0BA@mail.gmail.com>

On Fri, Dec 22, 2017 at 8:40 PM, Viktor Dukhovni <openssl-users at dukhovni.org
> wrote:

>
>
> > On Dec 22, 2017, at 11:33 PM, J Decker <d3ck0r at gmail.com> wrote:
> >
> > Very similar to OpenSSL 1.0.2, plus its own extensions.  That's not
> exactly
> > "same".
> >
> > The same in that I can link/compile against either and not change any
> application code... not speaking of internals, just the API.
>
> Well, that's not actually true.  There are API differences.  There
> is a large common intersection that covers many legacy applications,
> but newer features in each library are not present in the other.
>

Any many current applications.  This app was all done with recent docs on
recent version and I found 0 incompabilities.
I did run into a beta feature for 1.1.0 that was something about setting
the fragment size...
https://github.com/libressl-portable/portable/issues/214  but again that
wasn't in 1.0 stable openssl either so...


>
> --
> --
>         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/20171222/4b1438cd/attachment.html>

From openssl-users at dukhovni.org  Sat Dec 23 18:12:23 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 23 Dec 2017 13:12:23 -0500
Subject: [openssl-users] Certificate gets verified OK over SSL-CLI,
 but not when using SSL-API
In-Reply-To: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
Message-ID: <753F1A56-7CB1-46B5-A2CE-91FE21D564B4@dukhovni.org>



> On Dec 21, 2017, at 6:42 AM, Manuel Wagesreither <ManWag at FastMail.FM> wrote:
> 
> 
> #include <openssl/x509.h>
> #include <stdexcept>
> #include <iostream>
> 
> unsigned char g_authority[] = {	0x30, 0x82, 0x03, 0x00 /* and so on */ };
> unsigned char g_cert[] = { 0x30, 0x82, 0x02, 0x9b /* and so on */ };

Eliding the certificate data makes it very difficult to provide
meaningful feedback.

> 
> int main(int, char**)
> {
> 	// This holds the return codes and gets reused for most function calls
> 	int rc = 0;
> 
> 	// Make a new store
> 	X509_STORE *x509_store = X509_STORE_new();
> 	if (x509_store == NULL) {
> 		throw std::runtime_error("X509_STORE_new() failed");
> 	}
> 
> 	// Load and convert the authoritys certificate to a compatible form
> 	X509 *auth_cert = NULL;
> 	{
> 		const unsigned char* auth_cert_ptr = g_authority;
> 		auth_cert = d2i_X509(NULL, &auth_cert_ptr, sizeof(g_authority));
> 		if (auth_cert == nullptr) {
> 			throw std::runtime_error("d2i_X509() failed for authoritys certificate");
> 		}
> 	}
> 
> 	// Add the authoritys certificate to the store
> 	rc = X509_STORE_add_cert(x509_store, auth_cert);
> 	if (rc != 1) {
> 		throw std::runtime_error("X509_STORE_add_cert() failed");
> 	}
> 
> 	// Make a new store context
> 	X509_STORE_CTX *x509_store_ctx = X509_STORE_CTX_new();
> 	if (x509_store_ctx == NULL) {
> 		throw std::runtime_error("X509_STORE_CTX_new() failed");
> 	}
> 
> 	// Load and convert the certificate to be verified to a compatible form
> 	X509 *myself = NULL;
> 	{
> 		const unsigned char *my_cert_ptr = g_cert;
> 		myself = d2i_X509(NULL, &my_cert_ptr, sizeof(g_cert));
> 		if (myself == NULL) {
> 			throw std::runtime_error("d2i_X509() failed for own certificate");
> 		}
> 	}
> 
> 	rc = X509_STORE_CTX_init(x509_store_ctx, x509_store, myself, NULL);
> 	if (rc != 1) {
> 		throw std::runtime_error("X509_STORE_CTX_init() failed");
> 	}
> 
> 	rc = X509_verify_cert(x509_store_ctx);
> 
> 	X509_STORE_free(x509_store);
> 	X509_STORE_CTX_free(x509_store_ctx);

You're freeing x509_store_ctx too early, it is used below for error
reporting.

> 
> 	if (rc > 0) {
> 		std::cout << X509_verify_cert_error_string(X509_STORE_CTX_get_error(x509_store_ctx)) << std::endl;
> 		return 0;
> 	} else {
> 		std::cerr << X509_verify_cert_error_string(X509_STORE_CTX_get_error(x509_store_ctx)) << std::endl;
> 		std::cerr << "Error depth: " << X509_STORE_CTX_get_error_depth(x509_store_ctx) << std::endl;
> 		return 1;
> 	}
> }

Please re-post the source code with the *complete* certificate
data.

-- 
	Viktor.


From jb-openssl at wisemo.com  Mon Dec 25 21:38:34 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 25 Dec 2017 22:38:34 +0100
Subject: [openssl-users] Sudden control data sent during large transfer.
In-Reply-To: <CAA2GJqUKguBWew-kCsx1nLL0XCYZQ0x4Jt-AUrf9UdbW_a6kJw@mail.gmail.com>
References: <CAA2GJqUKguBWew-kCsx1nLL0XCYZQ0x4Jt-AUrf9UdbW_a6kJw@mail.gmail.com>
Message-ID: <b7767918-377b-1101-9817-148762517faa@wisemo.com>

On 23/12/2017 04:06, J Decker wrote:
> How can I know what/why openssl is sending control data?
> I have this Node addon that uses TLS 1.2 to communicate.? I'm sending 
> a large file transfer (100M), which is chunked into 8100 byte blocks 
> and sent on websocket protocol.? It's additionally chunked into 4327 
> byte blocks (which after encoding is 4356 bytes or 1452*3)? All of the 
> data is encoded into blocks and queued to transfer before I have a 
> problem.
> After some amount of data transfer OpenSSL starts sending 31 byte 
> control packets after basically each block received... when the other 
> side receives that data it doesn't do anything, but the ssl layer does 
> stop giving me completed packets (instead opting to generate 31 byte 
> packets) when the other side receives those, it doesn't do 
> anything.... (doesn't generate control sends back).
>
> Ad I mentioned all of the pendijng data is already queued to send, so 
> even if I received a control packet and it generated a response it 
> wouldn't get received for quite some time.
>
> I don't have control over what version of SSL is being used... but 
> this current test is 1.0.1m
>
> It's variable by the time it starts sending 31 byte packets... Also 
> depends on the connection; although at this time I'm able to generate 
> the problem on localhost... I was able to transfer from a remote 
> server to myself with no issues...
>
I think you need to be a lot more clear for anyone to understand your
problem.

What exactly do you mean by "control data"?

What is the layering of protocols here?
Is it:
 ?? bulk data => WebSockets => TLS => TCP => network
Or
 ?? bulk data => TLS => WebSockets => TLS => TCP => network

In what direction is the bulk data being sent: TLS client to TLS
server or TLS server to TLS client?

In what direction is the initial 31 byte "control packet" being
sent: TLS client to TLS server or TLS server to TLS client?

Also, if possible, could you report the (decrypted if applicable)
content of those initial 31 bytes?? Perhaps also the later 31 byte
packets (including their order of occurrence and direction of
transmission)?

Can you see what the "packets" are?

For example, are they TLS alert messages?

Are they TLS HelloRequest messages?


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 d3ck0r at gmail.com  Mon Dec 25 21:57:10 2017
From: d3ck0r at gmail.com (J Decker)
Date: Mon, 25 Dec 2017 13:57:10 -0800
Subject: [openssl-users] Sudden control data sent during large transfer.
In-Reply-To: <b7767918-377b-1101-9817-148762517faa@wisemo.com>
References: <CAA2GJqUKguBWew-kCsx1nLL0XCYZQ0x4Jt-AUrf9UdbW_a6kJw@mail.gmail.com>
 <b7767918-377b-1101-9817-148762517faa@wisemo.com>
Message-ID: <CAA2GJqXNYb3mrD_Wj3H9xT=io2tKqOqE8Wgazx_TNrzPt-7QBw@mail.gmail.com>

I found the real issue... recently I fixed a signed/unsigned comparison
warning by adding a (int) to the unsigned side, which made the result of
send() be compared differently, and was triggering when send() would return
-1 (with EAGAIN/WSAEWOULDBLOCK) would cause me to think it was a short send
( result < amount_to_send ) { /* sent less than full packet */ }  so I
ended up backing up the send offset by 1 byte instead of 0 bytes... this
was then injecting 1 extra byte into the TCP layer.


On Mon, Dec 25, 2017 at 1:38 PM, Jakob Bohm <jb-openssl at wisemo.com> wrote:

> On 23/12/2017 04:06, J Decker wrote:
>
>> How can I know what/why openssl is sending control data?
>>
>> It's variable by the time it starts sending 31 byte packets... Also
>> depends on the connection; although at this time I'm able to generate the
>> problem on localhost... I was able to transfer from a remote server to
>> myself with no issues...
>>
>> I think you need to be a lot more clear for anyone to understand your
> problem.
>
> What exactly do you mean by "control data"?
>

alerts/HelloRequest/renegotation?


>
> What is the layering of protocols here?
> Is it:
>    bulk data => WebSockets => TLS => TCP => network
>
> In what direction is the bulk data being sent: TLS client to TLS
> server or TLS server to TLS client?
>
server to client.

>
> In what direction is the initial 31 byte "control packet" being
> sent: TLS client to TLS server or TLS server to TLS client?
>
> client to server

> Also, if possible, could you report the (decrypted if applicable)
> content of those initial 31 bytes?  Perhaps also the later 31 byte
> packets (including their order of occurrence and direction of
> transmission)?
>
> Can you see what the "packets" are?
>

I wouldn't know the decrypted bytes because I would get them from the wbio
from the TLS Object.
Well that's kinda what I was more asking; can I somehow register a callback
for when alerts are generated so I can see what they are?  Otherwise I
really don't know.



>
> For example, are they TLS alert messages?
>
> Are they TLS HelloRequest messages?


>
> 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
>
> --
> 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/20171225/e8dd619d/attachment-0001.html>

From swapnilddeshpande at gmail.com  Tue Dec 26 03:44:58 2017
From: swapnilddeshpande at gmail.com (Swapnil Deshpande)
Date: Mon, 25 Dec 2017 19:44:58 -0800
Subject: [openssl-users]  OpenSSL SHA algorithm
Message-ID: <CANribhHxoFteaaRRPC+C2JuG3+jKuKLK-+PQbbsy9ZxJAF_L7g@mail.gmail.com>

Hi all,

Noob here. I recently discovered that the "-sha1" and "-sha" flags in the
"openssl dgst" command produce different outputs. I thought those were the
same algorithms but turns out they are not:

$ echo -n "password" | openssl dgst -sha

80072568beb3b2102325eb203f6d0ff92f5cef8e


$ echo -n "password" | openssl dgst -sha1

5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8


I am aware of SHA1 and the SHA-128 algorithm.


1. What algorithm is used to generate hash when I use the "-sha" option?

2. What could I have done to get this answer to #1 in a better way? I am
asking this because I tried to find what algorithm is being used through
the "help" option as well as trying to search via "man openssl" but
couldn't find anything. I also did a basic search for "openssl sha vs sha1"
and couldn't find any relevant results. If there was a better way to know
more about this option (say by reading some documentation), I'd be glad to
know about it.


Merry Christmas.


Regards,

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

From dclarke at blastwave.org  Tue Dec 26 04:25:53 2017
From: dclarke at blastwave.org (Dennis Clarke)
Date: Mon, 25 Dec 2017 23:25:53 -0500
Subject: [openssl-users] OpenSSL SHA algorithm
In-Reply-To: <CANribhHxoFteaaRRPC+C2JuG3+jKuKLK-+PQbbsy9ZxJAF_L7g@mail.gmail.com>
References: <CANribhHxoFteaaRRPC+C2JuG3+jKuKLK-+PQbbsy9ZxJAF_L7g@mail.gmail.com>
Message-ID: <5236e500-0f22-d549-3933-3fc250ece2bf@blastwave.org>

On 25/12/17 10:44 PM, Swapnil Deshpande wrote:
> Hi all,
> 
> Noob here. I recently discovered that the "-sha1" and "-sha" flags in 
> the "openssl dgst" command produce different outputs. I thought those 
> were the same algorithms but turns out they are not:
> 
> $ echo -n "password" | openssl dgst -sha
> 
> 80072568beb3b2102325eb203f6d0ff92f5cef8e
> 
> 
> $ echo -n "password" | openssl dgst -sha1
> 
> 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
> 



A quick google shows :

SHA0x01 80072568beb3b2102325eb203f6d0ff92f5cef8e:password
SHA0x02 63addb5d2099f2d9b44210063c6b9aa74b2d7017:password
SHA0x03 a958d2144134061b83e164acb74de1d2fa9b1970:password
SHA0x04 a72a9711884c867812110bcfbb60fb87550e3810:password
SHA0x05 7d57e2c9ad5cbee4cd75e32814efb1a8dbc7384f:password

https://gist.github.com/rumikotakahashi/f3d377ff81e878f7fffb4b38cc9f4bf6

dc

From ananthaneni.saitejachowdary at citrix.com  Tue Dec 26 04:34:24 2017
From: ananthaneni.saitejachowdary at citrix.com (Ananthaneni Saitejachowdary)
Date: Tue, 26 Dec 2017 04:34:24 +0000
Subject: [openssl-users] FW: Help to understand WPACKET API
In-Reply-To: <11137844-d0e2-112d-f1b4-4890b60e676e@openssl.org>
References: <5a2a8e0d.1650620a.1b91f.9efd@mx.google.com>
 <5a391764.cb4e650a.9ba2b.8f7d@mx.google.com>
 <11137844-d0e2-112d-f1b4-4890b60e676e@openssl.org>
Message-ID: <53f26794199a440c8162de9f34ee6d02@SINPEX02CL02.citrite.net>

Thank you Matt, 

I understand that _u8,_u16. _u24 are the variants that helps us set the size of length field, that precedes the data.

-Saiteja.

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell
Sent: Friday, December 22, 2017 4:23 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] FW: Help to understand WPACKET API



On 19/12/17 13:43, Sai Teja Chowdary wrote:
> After going through the code I understand the new tls1.3 implemented 
> OpenSSL code is using WPACKET API to frame the records. I need help in 
> understanding what the following functions do. I am new to the mailing 
> list, thanks in advance.
> 
> ?
> 
> WPACKET_start_sub_packet_
> 
> WPACKET_allocate_bytes
> 
> WPACKET_sub_allocate_bytes__
> 
> WPACKET_reserve_bytes
> 
> WPACKET_start_sub_packet_len__
> 
> WPACKET_sub_memcpy__
> 
> ?
> 
> Basically what does the word _sub_ mean in these functions and how do 
> that differ from the non sub function say
> 
> Difference between WPACKET_sub_memcpy__ and WPACKET_memcpy__

It is common in TLS for a block of data to be preceded by a length.
Depending on the context the number of length bytes might typically be 1, 2, 3 or 4. Such a block of data is considered a "sub" packet in the WPACKET API. So:

int WPACKET_memcpy(WPACKET *pkt, const void *src, size_t len);

Copies len bytes of data from src into the pkt. Compare with:

#define WPACKET_sub_memcpy_u8(pkt, src, len) \
    WPACKET_sub_memcpy__((pkt), (src), (len), 1)

So WPACKET_sub_memcpy_u8 will also copy len bytes of data from src into pkt but will precede it with 1 byte containing the value of len.


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

From antiac at gmail.com  Tue Dec 26 11:44:22 2017
From: antiac at gmail.com (Antonio Iacono)
Date: Tue, 26 Dec 2017 12:44:22 +0100
Subject: [openssl-users] Create a signed file from detached signature
	and clear file content
In-Reply-To: <CAPN6PER+DPbJUNsgiaw=xu3TNof4PadHCbfs+D-zCW8-C3MSMA@mail.gmail.com>
References: <CAPN6PESKB6fOFBv7y_PJjH=BXbwv2o35AkY1EMLd6DOBUHS7wA@mail.gmail.com>
 <CAPN6PER+DPbJUNsgiaw=xu3TNof4PadHCbfs+D-zCW8-C3MSMA@mail.gmail.com>
Message-ID: <CAPN6PETXWqags_JN1UQbXyV2YibjtubSFRbm43ZENgGpc-9Rog@mail.gmail.com>

Hi,

I think I have solved. Maybe you can write better and in fewer lines anyway
this attached code works.

Antonio

2017-12-20 11:07 GMT+01:00 Antonio Iacono <antiac at gmail.com>:

>
> Hi,
> assuming I have the following:
> - data.txt
> - data.p7s (the detached signature)
>
> Can I generate the bundled (p7m) signed file ?
>
> I tried:
>
> content = BIO_new_file("data.txt", "rb");
> signature = BIO_new_file("data.p7s", "rb");
> p7 = d2i_PKCS7_bio(signature, NULL);
> PKCS7_set_detached(p7, 0);
> bundled = BIO_new_file("bundled.p7m", "wb");
> i2d_PKCS7_bio_stream(bundled, p7, content, 0);
>
> but the generated file (bundled.p7m) is identical to the signature file
> (data.p7s)
>
> Thanks,
> Antonio
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171226/4acf1a97/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildp7m.c
Type: text/x-csrc
Size: 2650 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171226/4acf1a97/attachment.c>

From asteja.chowdary.ece13 at itbhu.ac.in  Tue Dec 26 12:53:24 2017
From: asteja.chowdary.ece13 at itbhu.ac.in (Sai Teja Chowdary)
Date: Tue, 26 Dec 2017 18:23:24 +0530
Subject: [openssl-users] How to form a proper hash after writing something
 into SSL handshake.
Message-ID: <5a424644.8230620a.c89bf.4e27@mx.google.com>


Hi,

Happy Holidays everyone.

I want to send client certificate, client key exchange and client verify in a single handshake message which appears as multiple handshake messages in a single record. But to sent the client verify I need to first make a hash of previous messages(client certificate and client key exchange) to create the signature.

Can anyone help me to find the function in OpenSSL 1.1.1-dev? xx XXX xxxx (or right procedure that needs to be done before creating a certificate verify message)that can do a proper transcript(digest or hash not clear). I tried using ssl3_finish_mac() on the message containing client certificate and client key exchange and then tried to generate the signature in certificate verify message.
But it is giving me a digest error. I am new to the mailing list want a bit of help to proceed forward stuck here. Please reply in case if anything is not clear.

Here is a code snippet, how I am forming the data containing all client certificate , client key exchange and certificate verify messages inside write_state_machine().

if(WPACKET_init(&pkt, s->init_buf)){
//Client certificate formation
             if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL && !confunc(s,&pkt) || 		!ssl_close_construct_packet(s,&pkt,mt)){
                  printf("PROBLEM\n");
                }
             transition(s);  //transition to next state i.e client key exchange

             get_construct_message_f(s, &pkt, &confunc, &mt);
//client key exchange formation
             if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL && !confunc(s,&pkt) || 	!ssl_close_construct_packet(s,&pkt,mt)){
                   printf("AGAIN A PROBLEMO\n");
                }

//ssl3_finish_mac(s, &s->init_buf->data[s->init_off], s->init_num);
             st->write_state_work = post_work(s, st->write_state_work);
             transition(s);  // transition to next state i.e  certificate verify

             get_construct_message_f(s, &pkt, &confunc, &mt);
//certificate verify message formation.
             if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL && !confunc(s,&pkt) || 				 	 	!ssl_close_construct_packet(s,&pkt,mt)){
                   printf("AGAIN A PROBLEMO\n");
                }
             WPACKET_finish(&pkt);


Please take a look at it, appreciate every bit of help.

Regards,
Saiteja

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

From dcoombs at carillon.ca  Tue Dec 26 13:12:50 2017
From: dcoombs at carillon.ca (Dave Coombs)
Date: Tue, 26 Dec 2017 08:12:50 -0500
Subject: [openssl-users] OpenSSL SHA algorithm
In-Reply-To: <CANribhHxoFteaaRRPC+C2JuG3+jKuKLK-+PQbbsy9ZxJAF_L7g@mail.gmail.com>
References: <CANribhHxoFteaaRRPC+C2JuG3+jKuKLK-+PQbbsy9ZxJAF_L7g@mail.gmail.com>
Message-ID: <AF4B8B59-04D9-4979-B92B-B6A3DA5556FE@carillon.ca>

Hi,

Wikipedia has some information.

	https://en.wikipedia.org/wiki/Secure_Hash_Algorithms

What is produced by "dgst -sha" is what the above link is calling SHA-0 (originally just called SHA).

All the best,
  -Dave


> On Dec 25, 2017, at 22:44, Swapnil Deshpande <swapnilddeshpande at gmail.com> wrote:
> 
> Hi all,
> 
> Noob here. I recently discovered that the "-sha1" and "-sha" flags in the "openssl dgst" command produce different outputs. I thought those were the same algorithms but turns out they are not:
> 
> $ echo -n "password" | openssl dgst -sha
> 80072568beb3b2102325eb203f6d0ff92f5cef8e
> 
> $ echo -n "password" | openssl dgst -sha1
> 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
> 
> I am aware of SHA1 and the SHA-128 algorithm. 
> 
> 1. What algorithm is used to generate hash when I use the "-sha" option?
> 2. What could I have done to get this answer to #1 in a better way? I am asking this because I tried to find what algorithm is being used through the "help" option as well as trying to search via "man openssl" but couldn't find anything. I also did a basic search for "openssl sha vs sha1" and couldn't find any relevant results. If there was a better way to know more about this option (say by reading some documentation), I'd be glad to know about it. 
> 
> Merry Christmas. 
> 
> Regards,
> Swapnil
> -- 
> 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/20171226/e9633276/attachment.html>

From kurt at roeckx.be  Tue Dec 26 13:44:06 2017
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 26 Dec 2017 14:44:06 +0100
Subject: [openssl-users] OpenSSL SHA algorithm
In-Reply-To: <CANribhHxoFteaaRRPC+C2JuG3+jKuKLK-+PQbbsy9ZxJAF_L7g@mail.gmail.com>
References: <CANribhHxoFteaaRRPC+C2JuG3+jKuKLK-+PQbbsy9ZxJAF_L7g@mail.gmail.com>
Message-ID: <20171226134405.GA3966@roeckx.be>

On Mon, Dec 25, 2017 at 07:44:58PM -0800, Swapnil Deshpande wrote:
> Hi all,
> 
> Noob here. I recently discovered that the "-sha1" and "-sha" flags in the
> "openssl dgst" command produce different outputs. I thought those were the
> same algorithms but turns out they are not:
> 
> $ echo -n "password" | openssl dgst -sha
> 
> 80072568beb3b2102325eb203f6d0ff92f5cef8e
> 
> 
> $ echo -n "password" | openssl dgst -sha1
> 
> 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
> 
> 
> I am aware of SHA1 and the SHA-128 algorithm.
> 
> 
> 1. What algorithm is used to generate hash when I use the "-sha" option?

It's the original SHA algorithm, which people will now refer to as
SHA-0. It has some minor but important changes compared to SHA-1.

> 2. What could I have done to get this answer to #1 in a better way? I am
> asking this because I tried to find what algorithm is being used through
> the "help" option as well as trying to search via "man openssl" but
> couldn't find anything. I also did a basic search for "openssl sha vs sha1"
> and couldn't find any relevant results. If there was a better way to know
> more about this option (say by reading some documentation), I'd be glad to
> know about it.

I started a pull request:
https://github.com/openssl/openssl/pull/4979

There are probably other changes that should happen.


Kurt


From swapnilddeshpande at gmail.com  Tue Dec 26 17:52:28 2017
From: swapnilddeshpande at gmail.com (Swapnil Deshpande)
Date: Tue, 26 Dec 2017 09:52:28 -0800
Subject: [openssl-users] OpenSSL SHA algorithm
In-Reply-To: <20171226134405.GA3966@roeckx.be>
References: <CANribhHxoFteaaRRPC+C2JuG3+jKuKLK-+PQbbsy9ZxJAF_L7g@mail.gmail.com>
 <20171226134405.GA3966@roeckx.be>
Message-ID: <CANribhEO89bSTN35RdBTAV71C174QXO5tLV9f84FAyjZEO1PzQ@mail.gmail.com>

Thanks all, this has been really helpful.

On Tue, Dec 26, 2017 at 5:44 AM, Kurt Roeckx <kurt at roeckx.be> wrote:

> On Mon, Dec 25, 2017 at 07:44:58PM -0800, Swapnil Deshpande wrote:
> > Hi all,
> >
> > Noob here. I recently discovered that the "-sha1" and "-sha" flags in the
> > "openssl dgst" command produce different outputs. I thought those were
> the
> > same algorithms but turns out they are not:
> >
> > $ echo -n "password" | openssl dgst -sha
> >
> > 80072568beb3b2102325eb203f6d0ff92f5cef8e
> >
> >
> > $ echo -n "password" | openssl dgst -sha1
> >
> > 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
> >
> >
> > I am aware of SHA1 and the SHA-128 algorithm.
> >
> >
> > 1. What algorithm is used to generate hash when I use the "-sha" option?
>
> It's the original SHA algorithm, which people will now refer to as
> SHA-0. It has some minor but important changes compared to SHA-1.
>
> > 2. What could I have done to get this answer to #1 in a better way? I am
> > asking this because I tried to find what algorithm is being used through
> > the "help" option as well as trying to search via "man openssl" but
> > couldn't find anything. I also did a basic search for "openssl sha vs
> sha1"
> > and couldn't find any relevant results. If there was a better way to know
> > more about this option (say by reading some documentation), I'd be glad
> to
> > know about it.
>
> I started a pull request:
> https://github.com/openssl/openssl/pull/4979
>
> There are probably other changes that should happen.
>
>
> Kurt
>
> --
> 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/20171226/f07dfa22/attachment.html>

From karl at denninger.net  Tue Dec 26 18:38:32 2017
From: karl at denninger.net (Karl Denninger)
Date: Tue, 26 Dec 2017 12:38:32 -0600
Subject: [openssl-users] Question as to best options....
Message-ID: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>

So let's assume I have system A and B.

System A has some store of certificates and keys.? We'll assume they're
in either PEM or DER format and OpenSSL generated them.

System B is going to get passed one or both via a mechanism (e.g. over a
TLS connection that it has validated as being "ok" with appropriate
cipher and certificate chase, so it's reasonably convinced it's talking
to who it thinks it is), and then wishes to install them into executing
software so OpenSSL can use them for THAT system to do something with
(e.g. take connections from a third machine, sign objects, etc.)? I
already know how do the "do something" part with OpenSSL.? System B does
*NOT* want to store these persistently on the disk somewhere (even
transiently.)

What I'm trying to figure out is the "best" way to handle this.?
SSL_CTX_use_PrivateKey accepts a EVP_PKEY pointer,
SSL_CTX_use_PrivateKey_ASN1 takes an ASN1 structure of length len, but
what is parameter "pk" (not explained in the man page) and this assumes
I have an ASN.1.....

I would assume that doing wonky things with EVP_PKEY (like digging into
the structure once loaded, grabbing it and transmitting it) is a
severely bad idea as the structure may change (e.g. EVP_PKEY is intended
to be an opaque structure from a user code perspective.)

So that leaves the obvious question as "is there a decent way to convert
a PEM or DER private key file into ASN.1" using OpenSSL calls (from a
"C" program, not from the command line; we'll assume I have the key and
cert files already.)

TIA
--
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>

/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171226/ca5a3a2e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171226/ca5a3a2e/attachment-0001.bin>

From rsalz at akamai.com  Tue Dec 26 19:14:16 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 26 Dec 2017 19:14:16 +0000
Subject: [openssl-users] Question as to best options....
In-Reply-To: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
References: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
Message-ID: <E7D22FD2-598B-4D62-9346-4703F770391B@akamai.com>

So if you put locks around the SSL_CTX object when it?s used, then you can use the set private key call to update the key; and then all SSL_new objects afterwards will use the new credentials.  Does that meet your need?

> "is there a decent way to convert a PEM or DER private key file into ASN.1" using OpenSSL calls (from a "C" program, not from the command line; we'll assume I have the key and cert files already.)

I assume you mean ?native C structure? and not ASN1?  Because DER is just the ASN1 serialized, and PEM is base64 encoded DER with marker lines. ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171226/f9d78fbe/attachment.html>

From kurt at roeckx.be  Tue Dec 26 19:25:38 2017
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 26 Dec 2017 20:25:38 +0100
Subject: [openssl-users] Question as to best options....
In-Reply-To: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
References: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
Message-ID: <20171226192538.GA14058@roeckx.be>

On Tue, Dec 26, 2017 at 12:38:32PM -0600, Karl Denninger wrote:
> 
> What I'm trying to figure out is the "best" way to handle this.?
> SSL_CTX_use_PrivateKey accepts a EVP_PKEY pointer,
> SSL_CTX_use_PrivateKey_ASN1 takes an ASN1 structure of length len, but
> what is parameter "pk" (not explained in the man page) and this assumes
> I have an ASN.1.....

I assume you send the file in DER or PEM format over the SSL
connection. You then probably want to use d2i_PrivateKey() or
d2i_AutoPrivateKey() to turn that into an EVP_PKEY.


Kurt


From karl at denninger.net  Tue Dec 26 19:42:57 2017
From: karl at denninger.net (Karl Denninger)
Date: Tue, 26 Dec 2017 13:42:57 -0600
Subject: [openssl-users] Question as to best options....
In-Reply-To: <E7D22FD2-598B-4D62-9346-4703F770391B@akamai.com>
References: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
 <E7D22FD2-598B-4D62-9346-4703F770391B@akamai.com>
Message-ID: <c7c4cb92-6549-2fc4-4c52-ec85a6ab956b@denninger.net>


On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
>
> So if you put locks around the SSL_CTX object when it?s used, then you
> can use the set private key call to update the key; and then all
> SSL_new objects afterwards will use the new credentials.? Does that
> meet your need?
>
Yes, that I already know how to do.? The issue is how to get the key
from a PEM file into a format that I can feed it with set private key.?
There doesn't appear to be a means to "un-file-ify" the set private key
functions.
>
> > "is there a decent way to convert a PEM or DER private key file into
> ASN.1" using OpenSSL calls (from a "C" program, not from the command
> line; we'll assume I have the key and cert files already.)
>
> I assume you mean ?native C structure? and not ASN1?? Because DER is
> just the ASN1 serialized, and PEM is base64 encoded DER with marker
> lines. ?
>
>
>
So if I take a PEM private key file, strip the markers, and turn the
actual key's base64 into binary (assuming an RSA key, so there's no "EC
parameter" block in front) I now have an "opaque" unsigned character
array of length "len" (the decoded Base64) which
SSL_CTX_use_privateKey_ASN1 will accept?? (Assuming the key file is
unencrypted, of course.)

What is the parameter "pk" passed to the call in that instance (it's not
in the man page)

int SSL_CTX_use_PrivateKey_ASN1(int pk, SSL_CTX *ctx, unsigned char *d, long len);

And likewise, I can just bytewise load a DER file (e.g. read() it into a
memory buffer) and then pass that as it's simply a binary copy of the
Base64 contained within the markers (plus the EC parameters if it's an
ECDSA key)?

If so that makes it materially easier than I thought it would be....

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171226/4aca3bf8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171226/4aca3bf8/attachment.bin>

From kurt at roeckx.be  Tue Dec 26 20:07:29 2017
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 26 Dec 2017 21:07:29 +0100
Subject: [openssl-users] Question as to best options....
In-Reply-To: <c7c4cb92-6549-2fc4-4c52-ec85a6ab956b@denninger.net>
References: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
 <E7D22FD2-598B-4D62-9346-4703F770391B@akamai.com>
 <c7c4cb92-6549-2fc4-4c52-ec85a6ab956b@denninger.net>
Message-ID: <20171226200729.GA16584@roeckx.be>

On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
> 
> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
> >
> > So if you put locks around the SSL_CTX object when it?s used, then you
> > can use the set private key call to update the key; and then all
> > SSL_new objects afterwards will use the new credentials.? Does that
> > meet your need?
> >
> Yes, that I already know how to do.? The issue is how to get the key
> from a PEM file into a format that I can feed it with set private key.?
> There doesn't appear to be a means to "un-file-ify" the set private key
> functions.

You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
and write the file.

> > > "is there a decent way to convert a PEM or DER private key file into
> > ASN.1" using OpenSSL calls (from a "C" program, not from the command
> > line; we'll assume I have the key and cert files already.)
> >
> > I assume you mean ?native C structure? and not ASN1?? Because DER is
> > just the ASN1 serialized, and PEM is base64 encoded DER with marker
> > lines. ?
> >
> >
> >
> So if I take a PEM private key file, strip the markers, and turn the
> actual key's base64 into binary (assuming an RSA key, so there's no "EC
> parameter" block in front) I now have an "opaque" unsigned character
> array of length "len" (the decoded Base64) which
> SSL_CTX_use_privateKey_ASN1 will accept?? (Assuming the key file is
> unencrypted, of course.)
> 
> What is the parameter "pk" passed to the call in that instance (it's not
> in the man page)

>From the manpage:
SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_

So you would need to know that it's an RSA or EC key. If you used
d2i_AutoPrivateKey you don't need to know the type and get an
EVP_PKEY.


Kurt


From karl at denninger.net  Tue Dec 26 20:56:13 2017
From: karl at denninger.net (Karl Denninger)
Date: Tue, 26 Dec 2017 14:56:13 -0600
Subject: [openssl-users] Question as to best options....
In-Reply-To: <20171226200729.GA16584@roeckx.be>
References: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
 <E7D22FD2-598B-4D62-9346-4703F770391B@akamai.com>
 <c7c4cb92-6549-2fc4-4c52-ec85a6ab956b@denninger.net>
 <20171226200729.GA16584@roeckx.be>
Message-ID: <bcc72342-ef0c-ad58-ff14-9d897c45bd36@denninger.net>


On 12/26/2017 14:07, Kurt Roeckx wrote:
> On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
>> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
>>> So if you put locks around the SSL_CTX object when it?s used, then you
>>> can use the set private key call to update the key; and then all
>>> SSL_new objects afterwards will use the new credentials.? Does that
>>> meet your need?
>>>
>> Yes, that I already know how to do.? The issue is how to get the key
>> from a PEM file into a format that I can feed it with set private key.?
>> There doesn't appear to be a means to "un-file-ify" the set private key
>> functions.
> You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
> and write the file.
>
>>>> "is there a decent way to convert a PEM or DER private key file into
>>> ASN.1" using OpenSSL calls (from a "C" program, not from the command
>>> line; we'll assume I have the key and cert files already.)
>>>
>>> I assume you mean ?native C structure? and not ASN1?? Because DER is
>>> just the ASN1 serialized, and PEM is base64 encoded DER with marker
>>> lines. ?
>>>
>>>
>>>
>> So if I take a PEM private key file, strip the markers, and turn the
>> actual key's base64 into binary (assuming an RSA key, so there's no "EC
>> parameter" block in front) I now have an "opaque" unsigned character
>> array of length "len" (the decoded Base64) which
>> SSL_CTX_use_privateKey_ASN1 will accept?? (Assuming the key file is
>> unencrypted, of course.)
>>
>> What is the parameter "pk" passed to the call in that instance (it's not
>> in the man page)
> From the manpage:
> SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_
>
> So you would need to know that it's an RSA or EC key. If you used
> d2i_AutoPrivateKey you don't need to know the type and get an
> EVP_PKEY.
>
>
> Kurt
Thanks - I suspect I have enough to get things rolling :-)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171226/3e49bc88/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171226/3e49bc88/attachment.bin>

From kgoldman at us.ibm.com  Wed Dec 27 22:45:23 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Wed, 27 Dec 2017 17:45:23 -0500
Subject: [openssl-users] Certificate for RSA 2048 key says 2058
In-Reply-To: <D4D7B2F0-AEBA-4054-A88E-67AB6DCF1687@dukhovni.org>
References: <p0uert$mbm$1@blaine.gmane.org>
 <D4D7B2F0-AEBA-4054-A88E-67AB6DCF1687@dukhovni.org>
Message-ID: <p217ls$pad$1@blaine.gmane.org>

On 12/14/2017 1:34 PM, Viktor Dukhovni wrote:
> 
> 
>> On Dec 14, 2017, at 1:11 PM, Ken Goldman <kgoldman at us.ibm.com> wrote:
>>
>> I generate a key and self signed certificate like this:
>>
>>> openssl genrsa -out cakey.pem -aes256 -passout pass:rrrr 2048
>>> openssl req -new -x509 -key cakey.pem -out cacert.pem -days 3650
>>
>> When I dump the certificate, I see
>> 	....
>>         Subject Public Key Info:
>>             Public Key Algorithm: rsaEncryption
>>                 Public-Key: (2058 bit)
>>                 Modulus:
>>                     02:b1:4c:dd:59:4d:72:8d:93:4b:e5:07:89:53:f7:
>> 	....
>>
>> Why 2058 - 10 extra bits?  I know that, at times, ASN.1 DER needs an extra byte to make a number positive, but 10 bits?
> 
> What version of OpenSSL is this?  When I try this with OpenSSL 1.1.0 I get:
> 
> $ openssl version
> OpenSSL 1.1.0h-dev  xx XXX xxxx
> 
> $ for i in $(seq 20); do openssl req -nodes -new -x509 -newkey rsa:2048 -keyout cakey.pem -out cacert.pem -days 3650 -subj "/CN=Root CA" 2>/dev/null; openssl x509 -text -in cacert.pem | grep 'Public-Key:'; done
>                  Public-Key: (2048 bit)
>                  Public-Key: (2048 bit)
>                  Public-Key: (2048 bit)
> Same results with master from git.
> 

OpenSSL 1.0.1e-fips 11 Feb 2013 - and I get the same results as you for 
1000's of passes. So, apparently, something strange happened to the one
key that I generated for my CA.

It feels like some random leading zero case, but I can't reproduce it 
with another key.





From ManWag at FastMail.FM  Thu Dec 28 09:54:42 2017
From: ManWag at FastMail.FM (Manuel Wagesreither)
Date: Thu, 28 Dec 2017 10:54:42 +0100
Subject: [openssl-users] Certificate gets verified OK over SSL-CLI,
 but not when using SSL-API
In-Reply-To: <753F1A56-7CB1-46B5-A2CE-91FE21D564B4@dukhovni.org>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
 <753F1A56-7CB1-46B5-A2CE-91FE21D564B4@dukhovni.org>
Message-ID: <1514454882.736235.1217696856.0B3122EB@webmail.messagingengine.com>

Thanks for your feedback. Unfortunately I cannot include the certificate raw data as it may contain sensitive information. Also, I'm unable to replace them with self-made certificates as I don't know the parameters the original ones were created with in the first place. The original creators are inaccessible at the moment. If the problem persists, I will reproduce the problem with test certificates (whose raw data I can publish) in a few weeks.

From ManWag at FastMail.FM  Thu Dec 28 10:19:02 2017
From: ManWag at FastMail.FM (Manuel Wagesreither)
Date: Thu, 28 Dec 2017 11:19:02 +0100
Subject: [openssl-users] [EXTERNAL] Certificate gets verified OK over
 SSL-CLI, but not when using SSL-API
In-Reply-To: <1513971095.15053.36.camel@sandia.gov>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
 <1513880829.15053.34.camel@sandia.gov>
 <1513937675.1354421.1213293648.5213F617@webmail.messagingengine.com>
 <1513971095.15053.36.camel@sandia.gov>
Message-ID: <1514456342.741665.1217709496.408EB4A2@webmail.messagingengine.com>

Am Fr, 22. Dez 2017, um 20:31, schrieb Sands, Daniel:
> On Fri, 2017-12-22 at 11:14 +0100, Manuel Wagesreither wrote:
> > Unfortunately this didn't work either. The end result is the same;
> > OpenSSL still emits a "certificate signature failure" with an error
> > depth of 0.
> > 
> In light of what Salz said about verification, could we assume that the
> openssl verify program that succeeded is based on the older library?

Thanks for your feedback! Actually it's the other way round. Validation succeeds with the *new* library (libssl.so.1.1), and fails with the *old* one (libssl.so.1.0.0). This is true with the openssl verify program as well: `openssl verify` succeeds for OpenSSL 1.1.0f, and fails for OpenSSL 1.0.1g.

Hence, if at all, verification requirements must have been lowered in the new OpenSSL version. I'm just about to look for a list of criterias a certificate has to pass in order to validate successfully in the two OpenSSL versions.

From openssl-users at dukhovni.org  Thu Dec 28 15:57:12 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 28 Dec 2017 10:57:12 -0500
Subject: [openssl-users] Certificate gets verified OK over SSL-CLI,
 but not when using SSL-API
In-Reply-To: <1514454882.736235.1217696856.0B3122EB@webmail.messagingengine.com>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
 <753F1A56-7CB1-46B5-A2CE-91FE21D564B4@dukhovni.org>
 <1514454882.736235.1217696856.0B3122EB@webmail.messagingengine.com>
Message-ID: <51C83EC8-391D-4E6D-95A9-EC4AAB897F25@dukhovni.org>



> On Dec 28, 2017, at 4:54 AM, Manuel Wagesreither <ManWag at FastMail.FM> wrote:
> 
> Thanks for your feedback. Unfortunately I cannot include the certificate raw data as it may contain sensitive information. Also, I'm unable to replace them with self-made certificates as I don't know the parameters the original ones were created with in the first place. The original creators are inaccessible at the moment. If the problem persists, I will reproduce the problem with test certificates (whose raw data I can publish) in a few weeks.

You should be able to publish edited output of:

    openssl crl2pkcs7 -nocrl -certfile chain.pem |
	openssl pkcs7 -print_certs -text -noout

With any sensitive values hand-replaced with "censored-NNN"
where the "NNN" part uniquely corresponds to each original
value (same values get same "NNN", distinct values get
distinct "NNN").

The "chain.pem" file should have the leaf certificate first,
then its issuer, then the issuer of that certificate, ...
up to the trust anchor.  Please also make sure that the
chain in question passes (with OpenSSL 1.1.0 per your report)
is reported verified with:

    $ openssl verify -no-CApath -no-CAfile \
	-trusted root.pem -untrusted chain.pem \
	chain.pem

Where "root.pem" contains just the last certificate
from the chain.pem file.  Post the output of that
command for 1.1.0.  Please also report similar output
for 1.0.2, with the command modified to:

    $ capath=$(mktemp -d empty.XXXXXX)
    $ cafile=root.pem
    $ openssl verify -CApath $capath -CAfile root.pem \
	-trusted root.pem -untrusted chain.pem \
	chain.pem

Again, if anything in the output is sensitive, censor the
values, with "censoredNNN" matching the replacements in
the certificate chain.

-- 
	Viktor.


From rsalz at akamai.com  Thu Dec 28 16:32:33 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 28 Dec 2017 16:32:33 +0000
Subject: [openssl-users] [EXTERNAL] Certificate gets verified OK over
 SSL-CLI, but not when using SSL-API
In-Reply-To: <1514456342.741665.1217709496.408EB4A2@webmail.messagingengine.com>
References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com>
 <1513880829.15053.34.camel@sandia.gov>
 <1513937675.1354421.1213293648.5213F617@webmail.messagingengine.com>
 <1513971095.15053.36.camel@sandia.gov>
 <1514456342.741665.1217709496.408EB4A2@webmail.messagingengine.com>
Message-ID: <DDE1D9F1-EC86-4563-BCE0-2984C47449A6@akamai.com>

> Hence, if at all, verification requirements must have been lowered in the new OpenSSL version.

No, it is also the case that the new version now more correctly accepts some chains as valid that because of bugs, the old version did not.



From rsalz at akamai.com  Thu Dec 28 20:51:43 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 28 Dec 2017 20:51:43 +0000
Subject: [openssl-users] New usability feature
Message-ID: <06167A52-0835-47F8-AD2F-432AD5D927D6@akamai.com>

Having wrestled with this in the past, I want to point out that with commit https://github.com/openssl/openssl/commit/bfa470a4f64313651a35571883e235d3335054eb in master, it?s now possible to put a SAN field (or any extension) in a cert request via the command line; no special custom config or fancy ENV vars needed.

Hooray!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/99b9f322/attachment.html>

From beldmit at gmail.com  Thu Dec 28 21:34:23 2017
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 29 Dec 2017 00:34:23 +0300
Subject: [openssl-users] New usability feature
In-Reply-To: <06167A52-0835-47F8-AD2F-432AD5D927D6@akamai.com>
References: <06167A52-0835-47F8-AD2F-432AD5D927D6@akamai.com>
Message-ID: <CADqLbzLMQzE=gHWNR1CB4VEDG6j8oNuHthFOg9AZzEUt8OWMFw@mail.gmail.com>

Dear Rich,

Great news!
Does it work for certificates too?



On Thu, Dec 28, 2017 at 11:51 PM, Salz, Rich via openssl-users <
openssl-users at openssl.org> wrote:

> Having wrestled with this in the past, I want to point out that with
> commit https://github.com/openssl/openssl/commit/
> bfa470a4f64313651a35571883e235d3335054eb in master, it?s now possible to
> put a SAN field (or any extension) in a cert request via the command line;
> no special custom config or fancy ENV vars needed.
>
>
>
> Hooray!
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171229/e201ff5a/attachment.html>

From openssl-users at dukhovni.org  Thu Dec 28 21:43:28 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 28 Dec 2017 16:43:28 -0500
Subject: [openssl-users] New usability feature
In-Reply-To: <CADqLbzLMQzE=gHWNR1CB4VEDG6j8oNuHthFOg9AZzEUt8OWMFw@mail.gmail.com>
References: <06167A52-0835-47F8-AD2F-432AD5D927D6@akamai.com>
 <CADqLbzLMQzE=gHWNR1CB4VEDG6j8oNuHthFOg9AZzEUt8OWMFw@mail.gmail.com>
Message-ID: <F0151F34-4115-4716-8250-A46018CA499F@dukhovni.org>



> On Dec 28, 2017, at 4:34 PM, Dmitry Belyavsky <beldmit at gmail.com> wrote:
> 
> Great news!
> Does it work for certificates too?

The updated documentation says:

+=item B<-addext ext>    
+    
+Add a specific extension to the certificate (if the B<-x509> option is    
+present) or certificate request. The argument must have the form of    
+a key=value pair as it would appear in a config file.    
+    
+This option can be given multiple times.

So it should work for "openssl req -x509".  There should probably be
corresponding changes for "openssl x509 -req", which can be used for
more than just self-signed certs.

-- 
	Viktor.


From karl at denninger.net  Thu Dec 28 22:15:20 2017
From: karl at denninger.net (Karl Denninger)
Date: Thu, 28 Dec 2017 16:15:20 -0600
Subject: [openssl-users] Question as to best options....
In-Reply-To: <20171226200729.GA16584@roeckx.be>
References: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
 <E7D22FD2-598B-4D62-9346-4703F770391B@akamai.com>
 <c7c4cb92-6549-2fc4-4c52-ec85a6ab956b@denninger.net>
 <20171226200729.GA16584@roeckx.be>
Message-ID: <497540fe-1fcf-6c41-ffd7-f90bcf82dfba@denninger.net>

On 12/26/2017 14:07, Kurt Roeckx wrote:
> On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
>> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
>>> So if you put locks around the SSL_CTX object when it?s used, then you
>>> can use the set private key call to update the key; and then all
>>> SSL_new objects afterwards will use the new credentials.? Does that
>>> meet your need?
>>>
>> Yes, that I already know how to do.? The issue is how to get the key
>> from a PEM file into a format that I can feed it with set private key.?
>> There doesn't appear to be a means to "un-file-ify" the set private key
>> functions.
> You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
> and write the file.
>
>>>> "is there a decent way to convert a PEM or DER private key file into
>>> ASN.1" using OpenSSL calls (from a "C" program, not from the command
>>> line; we'll assume I have the key and cert files already.)
>>>
>>> I assume you mean ?native C structure? and not ASN1?? Because DER is
>>> just the ASN1 serialized, and PEM is base64 encoded DER with marker
>>> lines. ?
>>>
>>>
>>>
>> So if I take a PEM private key file, strip the markers, and turn the
>> actual key's base64 into binary (assuming an RSA key, so there's no "EC
>> parameter" block in front) I now have an "opaque" unsigned character
>> array of length "len" (the decoded Base64) which
>> SSL_CTX_use_privateKey_ASN1 will accept?? (Assuming the key file is
>> unencrypted, of course.)
>>
>> What is the parameter "pk" passed to the call in that instance (it's not
>> in the man page)
> From the manpage:
> SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_
>
> So you would need to know that it's an RSA or EC key. If you used
> d2i_AutoPrivateKey you don't need to know the type and get an
> EVP_PKEY.
>
>
> Kurt
Not sure what I'm doing wrong here but obviously its something!

certtemp = *char
certstore = unsigned char*? (Both with enough allocated memory to hold
the required data, of course)
const unsigned char *p;

certstore has the Base64 key in it (checked manually, I am reading it
properly from the key file with the barrier lines and line feeds omitted.)

?????? .......

??????? strcpy((char *) certstore, certtemp);
??????? p = certstore;
??????? key = d2i_AutoPrivateKey(NULL, &p, strlen(certtemp));
??????? if (key == NULL) {
??????????????? ERR_error_string(ERR_get_error(), tmp);
>>?????????? return(NULL);
??????? }

??????? ......

But I get

$4 = 0xbf3f9b90 "error:0D0680A8:asn1 encoding
routines:ASN1_CHECK_TLEN:wrong tag"
in tmp and a NULL key return from d2i_AutoPrivateKey at the ">>" breakpoint.

If I convert the base64 to binary first -- using the Base64 routine in
OpenSSL (which I know I've coded correctly as the code in question uses
it elsewhere to decode a MIME attachment) and pass a binary buffer and
the length of that buffer (instead of a base64 buffer and its length) I
still get NULL back for the EVP_PKEY structure and the same error text
in tmp.

If I load that same key file with (having put the path to the key file
in tmp) with:

if (SSL_CTX_use_PrivateKey_file(www_context, tmp, SSL_FILETYPE_PEM) < 0)
{.....

It loads and works.

What's even MORE odd is that if I do this with the SAME key data I just
loaded in base64 (knowing it's an RSA key):

?????? ? len = (strlen(certtemp) * 3) / 4 +1;
???????? cbin = decode_base64(certtemp, strlen(certtemp));
???????? if (SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, www_context,
cbin, len)) {
???????????? ERR_error_string(ERR_get_error(), tmp);
???????????? return(NULL);
???????? }

THAT loads (the use_PrivateKey_ASN1 call returns zero -- and thus
obviously likes what I passed it)

There's probably something obvious I'm missing on what I'm doing wrong
with the d2i call -- any quick hit pointers welcome....

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/2dfbf225/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/2dfbf225/attachment-0001.bin>

From rsalz at akamai.com  Thu Dec 28 22:16:36 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 28 Dec 2017 22:16:36 +0000
Subject: [openssl-users] New usability feature
In-Reply-To: <CADqLbzLMQzE=gHWNR1CB4VEDG6j8oNuHthFOg9AZzEUt8OWMFw@mail.gmail.com>
References: <06167A52-0835-47F8-AD2F-432AD5D927D6@akamai.com>
 <CADqLbzLMQzE=gHWNR1CB4VEDG6j8oNuHthFOg9AZzEUt8OWMFw@mail.gmail.com>
Message-ID: <F9B03EDE-DD42-4BFF-9A51-DEA56BF6995F@akamai.com>

No, but that would be simple to add if you are up for doing the PR.

For now, the cert config file would have to copy the extensions.

From: Dmitry Belyavsky <beldmit at gmail.com>
Date: Thursday, December 28, 2017 at 4:34 PM
To: Rich Salz <rsalz at akamai.com>, openssl-users <openssl-users at openssl.org>
Subject: Re: [openssl-users] New usability feature

Dear Rich,

Great news!
Does it work for certificates too?



On Thu, Dec 28, 2017 at 11:51 PM, Salz, Rich via openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>> wrote:
Having wrestled with this in the past, I want to point out that with commit https://github.com/openssl/openssl/commit/bfa470a4f64313651a35571883e235d3335054eb<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_commit_bfa470a4f64313651a35571883e235d3335054eb&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kwFmfqS4oltS0kNY6Ev3FtNy9LjWPB2tynsOoR6ccZE&s=B6JkHpzsLg1gEUPZRAhwturImxCDh83JZ_SrFL3O6xQ&e=> in master, it?s now possible to put a SAN field (or any extension) in a cert request via the command line; no special custom config or fancy ENV vars needed.

Hooray!

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kwFmfqS4oltS0kNY6Ev3FtNy9LjWPB2tynsOoR6ccZE&s=Aw2UclQoMOFuXQ51l92xnohoVlSWVOciIdI6JMp0PGU&e=>



--
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/dfcece62/attachment.html>

From omgalvan.86 at gmail.com  Thu Dec 28 22:18:37 2017
From: omgalvan.86 at gmail.com (Martin Galvan)
Date: Thu, 28 Dec 2017 19:18:37 -0300
Subject: [openssl-users] Can't build OpenSSL on Windows
Message-ID: <20171228221837.2608-1-martin@eclypsium.com>

Hi all,

I'm trying to build OpenSSL on Windows. I'm using the nmake that came with
Visual Studio 2017, NASM, ActivePerl and have installed the Test::More and
Test::Template modules. nmake, perl and nasm are all visible in my system Path
variable. This is what I'm seeing:

C:\Users\e1\openssl\source>perl Configure VC-WIN64A --prefix=\c\Users\e1\openssl\install-windows no-comp no-zlib
Configuring OpenSSL version 1.1.0g (0x1010007fL)
    no-asan         [default]  OPENSSL_NO_ASAN
    no-comp         [option]   OPENSSL_NO_COMP (skip dir)
    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
    no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
    no-egd          [default]  OPENSSL_NO_EGD
    no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
    no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-msan         [default]  OPENSSL_NO_MSAN
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
    no-ssl3         [default]  OPENSSL_NO_SSL3
    no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
    no-ubsan        [default]  OPENSSL_NO_UBSAN
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
    no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
    no-zlib         [option]
    no-zlib-dynamic [default]
Configuring for VC-WIN64A
CC            =cl
CFLAG         =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2
SHARED_CFLAG  =
DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM
LFLAG         =/nologo /debug
PLIB_LFLAG    =
EX_LIBS       =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
APPS_OBJ      =win32_init.o ../ms/applink.o
CPUID_OBJ     =x86_64cpuid.o
UPLINK_OBJ    =../ms/uplink.o uplink-x86_64.o
BN_ASM        =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
DES_ENC       =des_enc.o fcrypt_b.o
AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
BF_ENC        =bf_enc.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC       =rc5_enc.o
MD5_OBJ_ASM   =md5-x86_64.o
SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC      =cmll-x86_64.o cmll_misc.o
MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
PADLOCK_OBJ   =e_padlock-x86_64.o
CHACHA_ENC    =chacha-x86_64.o
POLY1305_OBJ  =poly1305-x86_64.o
BLAKE2_OBJ    =
PROCESSOR     =
RANLIB        =true
ARFLAGS       =/nologo
PERL          =C:\Perl64\bin\perl.exe

SIXTY_FOUR_BIT mode

Configured for VC-WIN64A.

And then:

C:\Users\e1\openssl\source>nmake

Microsoft (R) Program Maintenance Utility Version 14.11.25547.0
Copyright (C) Microsoft Corporation.  All rights reserved.

"Detected changed: ".\Configure" "Configurations\windows-makefile.tmpl" "Configurations\common.tmpl"
"build.info" "crypto\build.info" "ssl\build.info" "engines\build.info" "apps\build.info"
"test\build.info" "util\build.info" "tools\build.info" "fuzz\build.info" "crypto\objects\build.info"
"crypto\md4\build.info" "crypto\md5\build.info" "crypto\sha\build.info" "crypto\mdc2\build.info"
"crypto\hmac\build.info" "crypto\ripemd\build.info" "crypto\whrlpool\build.info"
"crypto\poly1305\build.info" "crypto\blake2\build.info" "crypto\des\build.info" "crypto\aes\build.info"
"crypto\rc2\build.info" "crypto\rc4\build.info" "crypto\idea\build.info" "crypto\bf\build.info"
"crypto\cast\build.info" "crypto\camellia\build.info" "crypto\seed\build.info" "crypto\chacha\build.info"
"crypto\modes\build.info" "crypto\bn\build.info" "crypto\ec\build.info" "crypto\rsa\build.info"
"crypto\dsa\build.info" "crypto\dh\build.info" "crypto\dso\build.info" "crypto\engine\build.info"
"crypto\buffer\build.info" "crypto\bio\build.info" "crypto\stack\build.info" "crypto\lhash\build.info"
"crypto\rand\build.info" "crypto\err\build.info" "crypto\evp\build.info" "crypto\asn1\build.info"
"crypto\pem\build.info" "crypto\x509\build.info" "crypto\x509v3\build.info" "crypto\conf\build.info"
"crypto\txt_db\build.info" "crypto\pkcs7\build.info" "crypto\pkcs12\build.info" "crypto\ocsp\build.info"
"crypto\ui\build.info" "crypto\cms\build.info" "crypto\ts\build.info" "crypto\srp\build.info"
"crypto\cmac\build.info" "crypto\ct\build.info" "crypto\async\build.info" "crypto\kdf\build.info"
"Configurations\00-base-templates.conf" "Configurations\10-main.conf""
"Reconfiguring..."
        "C:\Perl64\bin\perl.exe" ".\Configure" reconf
Reconfiguring with: VC-WIN64A --prefix=\c\Users\e1\openssl\install-windows no-comp no-zlib
    CC = cl
    BUILDFILE = makefile
Configuring OpenSSL version 1.1.0g (0x1010007fL)
    no-asan         [default]  OPENSSL_NO_ASAN
    no-comp         [option]   OPENSSL_NO_COMP (skip dir)
    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
    no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
    no-egd          [default]  OPENSSL_NO_EGD
    no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
    no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-msan         [default]  OPENSSL_NO_MSAN
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
    no-ssl3         [default]  OPENSSL_NO_SSL3
    no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
    no-ubsan        [default]  OPENSSL_NO_UBSAN
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
    no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
    no-zlib         [option]
    no-zlib-dynamic [default]
Configuring for VC-WIN64A
CC            =cl
CFLAG         =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2
SHARED_CFLAG  =
DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM
LFLAG         =/nologo /debug
PLIB_LFLAG    =
EX_LIBS       =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
APPS_OBJ      =win32_init.o ../ms/applink.o
CPUID_OBJ     =x86_64cpuid.o
UPLINK_OBJ    =../ms/uplink.o uplink-x86_64.o
BN_ASM        =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
DES_ENC       =des_enc.o fcrypt_b.o
AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
BF_ENC        =bf_enc.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC       =rc5_enc.o
MD5_OBJ_ASM   =md5-x86_64.o
SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC      =cmll-x86_64.o cmll_misc.o
MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
PADLOCK_OBJ   =e_padlock-x86_64.o
CHACHA_ENC    =chacha-x86_64.o
POLY1305_OBJ  =poly1305-x86_64.o
BLAKE2_OBJ    =
PROCESSOR     =
RANLIB        =true
ARFLAGS       =/nologo
PERL          =C:\Perl64\bin\perl.exe

SIXTY_FOUR_BIT mode

Configured for VC-WIN64A.
"**************************************************"
"***                                            ***"
"***   Please run the same make command again   ***"
"***                                            ***"
"**************************************************"
NMAKE : fatal error U1077: 'exit' : return code '0x1'
Stop.

What am I doing wrong?

From openssl-users at dukhovni.org  Thu Dec 28 22:24:16 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 28 Dec 2017 17:24:16 -0500
Subject: [openssl-users] New usability feature
In-Reply-To: <F9B03EDE-DD42-4BFF-9A51-DEA56BF6995F@akamai.com>
References: <06167A52-0835-47F8-AD2F-432AD5D927D6@akamai.com>
 <CADqLbzLMQzE=gHWNR1CB4VEDG6j8oNuHthFOg9AZzEUt8OWMFw@mail.gmail.com>
 <F9B03EDE-DD42-4BFF-9A51-DEA56BF6995F@akamai.com>
Message-ID: <1ED3F303-9E20-4EA9-9AD5-CE6D6DF1108D@dukhovni.org>



> On Dec 28, 2017, at 5:16 PM, Salz, Rich via openssl-users <openssl-users at openssl.org> wrote:
> 
> No, but that would be simple to add if you are up for doing the PR.

For the record, as mentioned in a previous post, this is already
available for self-signed certificates (via openssl req -x509).
What's missing is support for ca-issued certificates
(via openssl x509 -req).

-- 
	Viktor.


From karl at denninger.net  Thu Dec 28 22:57:09 2017
From: karl at denninger.net (Karl Denninger)
Date: Thu, 28 Dec 2017 16:57:09 -0600
Subject: [openssl-users] Question as to best options....
In-Reply-To: <497540fe-1fcf-6c41-ffd7-f90bcf82dfba@denninger.net>
References: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
 <E7D22FD2-598B-4D62-9346-4703F770391B@akamai.com>
 <c7c4cb92-6549-2fc4-4c52-ec85a6ab956b@denninger.net>
 <20171226200729.GA16584@roeckx.be>
 <497540fe-1fcf-6c41-ffd7-f90bcf82dfba@denninger.net>
Message-ID: <69cb7acd-a970-3a12-9cca-1067e99cec3b@denninger.net>

On 12/28/2017 16:15, Karl Denninger wrote:
> On 12/26/2017 14:07, Kurt Roeckx wrote:
>> On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
>>> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
>>>> So if you put locks around the SSL_CTX object when it?s used, then you
>>>> can use the set private key call to update the key; and then all
>>>> SSL_new objects afterwards will use the new credentials.? Does that
>>>> meet your need?
>>>>
>>> Yes, that I already know how to do.? The issue is how to get the key
>>> from a PEM file into a format that I can feed it with set private key.?
>>> There doesn't appear to be a means to "un-file-ify" the set private key
>>> functions.
>> You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
>> and write the file.
>>
>>>>> "is there a decent way to convert a PEM or DER private key file into
>>>> ASN.1" using OpenSSL calls (from a "C" program, not from the command
>>>> line; we'll assume I have the key and cert files already.)
>>>>
>>>> I assume you mean ?native C structure? and not ASN1?? Because DER is
>>>> just the ASN1 serialized, and PEM is base64 encoded DER with marker
>>>> lines. ?
>>>>
>>>>
>>>>
>>> So if I take a PEM private key file, strip the markers, and turn the
>>> actual key's base64 into binary (assuming an RSA key, so there's no "EC
>>> parameter" block in front) I now have an "opaque" unsigned character
>>> array of length "len" (the decoded Base64) which
>>> SSL_CTX_use_privateKey_ASN1 will accept?? (Assuming the key file is
>>> unencrypted, of course.)
>>>
>>> What is the parameter "pk" passed to the call in that instance (it's not
>>> in the man page)
>> From the manpage:
>> SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_
>>
>> So you would need to know that it's an RSA or EC key. If you used
>> d2i_AutoPrivateKey you don't need to know the type and get an
>> EVP_PKEY.
>>
>>
>> Kurt
> Not sure what I'm doing wrong here but obviously its something!
>
> certtemp = *char
> certstore = unsigned char*? (Both with enough allocated memory to hold
> the required data, of course)
> const unsigned char *p;
>
> certstore has the Base64 key in it (checked manually, I am reading it
> properly from the key file with the barrier lines and line feeds omitted.)
>
> ?????? .......
>
> ??????? strcpy((char *) certstore, certtemp);
> ??????? p = certstore;
> ??????? key = d2i_AutoPrivateKey(NULL, &p, strlen(certtemp));
> ??????? if (key == NULL) {
> ??????????????? ERR_error_string(ERR_get_error(), tmp);
> >>?????????? return(NULL);
> ??????? }
>
> ??????? ......
>
> But I get
>
> $4 = 0xbf3f9b90 "error:0D0680A8:asn1 encoding
> routines:ASN1_CHECK_TLEN:wrong tag"
> in tmp and a NULL key return from d2i_AutoPrivateKey at the ">>"
> breakpoint.
>
> If I convert the base64 to binary first -- using the Base64 routine in
> OpenSSL (which I know I've coded correctly as the code in question
> uses it elsewhere to decode a MIME attachment) and pass a binary
> buffer and the length of that buffer (instead of a base64 buffer and
> its length) I still get NULL back for the EVP_PKEY structure and the
> same error text in tmp.
>
> If I load that same key file with (having put the path to the key file
> in tmp) with:
>
> if (SSL_CTX_use_PrivateKey_file(www_context, tmp, SSL_FILETYPE_PEM) <
> 0) {.....
>
> It loads and works.
>
> What's even MORE odd is that if I do this with the SAME key data I
> just loaded in base64 (knowing it's an RSA key):
>
> ?????? ? len = (strlen(certtemp) * 3) / 4 +1;
> ???????? cbin = decode_base64(certtemp, strlen(certtemp));
> ???????? if (SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, www_context,
> cbin, len)) {
> ???????????? ERR_error_string(ERR_get_error(), tmp);
> ???????????? return(NULL);
> ???????? }
>
> THAT loads (the use_PrivateKey_ASN1 call returns zero -- and thus
> obviously likes what I passed it)
>
> There's probably something obvious I'm missing on what I'm doing wrong
> with the d2i call -- any quick hit pointers welcome....
>
> -- 
> Karl Denninger
> karl at denninger.net <mailto:karl at denninger.net>
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
>
>
Ok, never mind, it appears to take the key but then when I check for
coherence between the key and certificate it says they don't match.....
so apparently it does NOT like the key load in ASN1, even though it
doesn't complain about it when I call the "use" function.

Hmmmm....

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/7a440f06/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/7a440f06/attachment-0001.bin>

From karl at denninger.net  Fri Dec 29 00:11:02 2017
From: karl at denninger.net (Karl Denninger)
Date: Thu, 28 Dec 2017 18:11:02 -0600
Subject: [openssl-users] Question as to best options....
In-Reply-To: <69cb7acd-a970-3a12-9cca-1067e99cec3b@denninger.net>
References: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
 <E7D22FD2-598B-4D62-9346-4703F770391B@akamai.com>
 <c7c4cb92-6549-2fc4-4c52-ec85a6ab956b@denninger.net>
 <20171226200729.GA16584@roeckx.be>
 <497540fe-1fcf-6c41-ffd7-f90bcf82dfba@denninger.net>
 <69cb7acd-a970-3a12-9cca-1067e99cec3b@denninger.net>
Message-ID: <a64ad8f7-4d01-3598-3d06-eacbb0815b85@denninger.net>

On 12/28/2017 16:57, Karl Denninger wrote:
> On 12/28/2017 16:15, Karl Denninger wrote:
>> On 12/26/2017 14:07, Kurt Roeckx wrote:
>>> On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
>>>> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
>>>>> So if you put locks around the SSL_CTX object when it?s used, then you
>>>>> can use the set private key call to update the key; and then all
>>>>> SSL_new objects afterwards will use the new credentials.? Does that
>>>>> meet your need?
>>>>>
>>>> Yes, that I already know how to do.? The issue is how to get the key
>>>> from a PEM file into a format that I can feed it with set private key.?
>>>> There doesn't appear to be a means to "un-file-ify" the set private key
>>>> functions.
>>> You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
>>> and write the file.
>>>
>>>>>> "is there a decent way to convert a PEM or DER private key file into
>>>>> ASN.1" using OpenSSL calls (from a "C" program, not from the command
>>>>> line; we'll assume I have the key and cert files already.)
>>>>>
>>>>> I assume you mean ?native C structure? and not ASN1?? Because DER is
>>>>> just the ASN1 serialized, and PEM is base64 encoded DER with marker
>>>>> lines. ?
>>>>>
>>>>>
>>>>>
>>>> So if I take a PEM private key file, strip the markers, and turn the
>>>> actual key's base64 into binary (assuming an RSA key, so there's no "EC
>>>> parameter" block in front) I now have an "opaque" unsigned character
>>>> array of length "len" (the decoded Base64) which
>>>> SSL_CTX_use_privateKey_ASN1 will accept?? (Assuming the key file is
>>>> unencrypted, of course.)
>>>>
>>>> What is the parameter "pk" passed to the call in that instance (it's not
>>>> in the man page)
>>> From the manpage:
>>> SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_
>>>
>>> So you would need to know that it's an RSA or EC key. If you used
>>> d2i_AutoPrivateKey you don't need to know the type and get an
>>> EVP_PKEY.
>>>
>>>
>>> Kurt
>> Not sure what I'm doing wrong here but obviously its something!
>>
>> certtemp = *char
>> certstore = unsigned char*? (Both with enough allocated memory to
>> hold the required data, of course)
>> const unsigned char *p;
>>
>> certstore has the Base64 key in it (checked manually, I am reading it
>> properly from the key file with the barrier lines and line feeds
>> omitted.)
>>
>> ?????? .......
>>
>> ??????? strcpy((char *) certstore, certtemp);
>> ??????? p = certstore;
>> ??????? key = d2i_AutoPrivateKey(NULL, &p, strlen(certtemp));
>> ??????? if (key == NULL) {
>> ??????????????? ERR_error_string(ERR_get_error(), tmp);
>> >>?????????? return(NULL);
>> ??????? }
>>
>> ??????? ......
>>
>> But I get
>>
>> $4 = 0xbf3f9b90 "error:0D0680A8:asn1 encoding
>> routines:ASN1_CHECK_TLEN:wrong tag"
>> in tmp and a NULL key return from d2i_AutoPrivateKey at the ">>"
>> breakpoint.
>>
>> If I convert the base64 to binary first -- using the Base64 routine
>> in OpenSSL (which I know I've coded correctly as the code in question
>> uses it elsewhere to decode a MIME attachment) and pass a binary
>> buffer and the length of that buffer (instead of a base64 buffer and
>> its length) I still get NULL back for the EVP_PKEY structure and the
>> same error text in tmp.
>>
>> If I load that same key file with (having put the path to the key
>> file in tmp) with:
>>
>> if (SSL_CTX_use_PrivateKey_file(www_context, tmp, SSL_FILETYPE_PEM) <
>> 0) {.....
>>
>> It loads and works.
>>
>> What's even MORE odd is that if I do this with the SAME key data I
>> just loaded in base64 (knowing it's an RSA key):
>>
>> ?????? ? len = (strlen(certtemp) * 3) / 4 +1;
>> ???????? cbin = decode_base64(certtemp, strlen(certtemp));
>> ???????? if (SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, www_context,
>> cbin, len)) {
>> ???????????? ERR_error_string(ERR_get_error(), tmp);
>> ???????????? return(NULL);
>> ???????? }
>>
>> THAT loads (the use_PrivateKey_ASN1 call returns zero -- and thus
>> obviously likes what I passed it)
>>
>> There's probably something obvious I'm missing on what I'm doing
>> wrong with the d2i call -- any quick hit pointers welcome....
>>
>> -- 
>> Karl Denninger
>> karl at denninger.net <mailto:karl at denninger.net>
>> /The Market Ticker/
>> /[S/MIME encrypted email preferred]/
>>
>>
> Ok, never mind, it appears to take the key but then when I check for
> coherence between the key and certificate it says they don't
> match..... so apparently it does NOT like the key load in ASN1, even
> though it doesn't complain about it when I call the "use" function.
>
> Hmmmm....
>
Maybe I'm onto something here....

If I take a PEM-encoded RSA private key file and convert it to binary
(using b64decode) what I get is not the same thing as I get from
"openssl rsa -inform pem -in key -outform der -out key.der".

But.... I thought from the previous discussion a PEM file was simply a
base64 rendition of the binary in a DER file....? Doesn't look that way.

So what does d2i_AutoPrivateKey actually want as input?? The straight-up
encoded key (out of the "key" file -- that is, read into a memory buffer
the entire thing including the barrier lines, and pass it THAT), just
the base64 encoded part (which I tried, and fails), or??? And what do
the ASN1 format calls to set certs and keys want?? I assume THAT wants
the DER file (binary), but I thought a PEM Base64 component, converted
to binary, WAS a DER file?? What I see here is that they're not the same.

This is pretty-clearly where I'm going wrong; I assume I can ASN1-load
the DER files from the previous, but I'd much prefer to be able to parse
.PEM files instead (since they're human readable) and somewhere I've
gone wrong with that one

What did I miss? :-)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/2e0dc849/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/2e0dc849/attachment.bin>

From rsalz at akamai.com  Fri Dec 29 00:31:47 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 29 Dec 2017 00:31:47 +0000
Subject: [openssl-users] Question as to best options....
In-Reply-To: <a64ad8f7-4d01-3598-3d06-eacbb0815b85@denninger.net>
References: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
 <E7D22FD2-598B-4D62-9346-4703F770391B@akamai.com>
 <c7c4cb92-6549-2fc4-4c52-ec85a6ab956b@denninger.net>
 <20171226200729.GA16584@roeckx.be>
 <497540fe-1fcf-6c41-ffd7-f90bcf82dfba@denninger.net>
 <69cb7acd-a970-3a12-9cca-1067e99cec3b@denninger.net>
 <a64ad8f7-4d01-3598-3d06-eacbb0815b85@denninger.net>
Message-ID: <F984D00C-5F57-482B-898F-558B346BF613@akamai.com>

It is hard to follow this thread with all the indenting.

>  If I take a PEM-encoded RSA private key file and convert it to binary (using b64decode) what I get is not the same thing as I get from "openssl rsa -inform pem -in key -outform der -out key.der".

How do you convert it?  Did you strip off the ---BEGIN and END tags?  Then it absolutely should have been the same thing.
An internal structure, such as an RSA object, can be converted to DER using d2i_RSA.  DER is useful because it is a ?flat? format, whereas the internal object is useful in the C code.  Make sense?  DER files are useful if you already know what the filetype is.  The d2i_ and i2d_ functions convert between internal (C structures, with pointers etc) to DER encoding.  They basically work on buffers, only.
PEM files are base64 encoded DER, with BEGIN and END tags that specify what the middle-part is.  It is useful because it is human readable. Also the PEM_read_xxxx functions will check what is expected to what the file says it is.
Most objects have PEM_read and PEM_write functions as well.  They are not necessarily obvious from scanning the header files, because they are declared and implemented as macro?s, as it?s common code with just a pointer to an internal description of what the ASN1/DER looks like.
The documentation on the master branch does a much better, and more complete, job of explaining this.
The function I think you want is PEM_read_PrivateKey.


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

From karl at denninger.net  Fri Dec 29 01:17:36 2017
From: karl at denninger.net (Karl Denninger)
Date: Thu, 28 Dec 2017 19:17:36 -0600
Subject: [openssl-users] Question as to best options....
In-Reply-To: <F984D00C-5F57-482B-898F-558B346BF613@akamai.com>
References: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
 <E7D22FD2-598B-4D62-9346-4703F770391B@akamai.com>
 <c7c4cb92-6549-2fc4-4c52-ec85a6ab956b@denninger.net>
 <20171226200729.GA16584@roeckx.be>
 <497540fe-1fcf-6c41-ffd7-f90bcf82dfba@denninger.net>
 <69cb7acd-a970-3a12-9cca-1067e99cec3b@denninger.net>
 <a64ad8f7-4d01-3598-3d06-eacbb0815b85@denninger.net>
 <F984D00C-5F57-482B-898F-558B346BF613@akamai.com>
Message-ID: <3de023dd-b198-57be-88c8-db410a4eb605@denninger.net>


On 12/28/2017 18:31, Salz, Rich via openssl-users wrote:
>
> It is hard to follow this thread with all the indenting.
>
> ?
>
> >? If I take a PEM-encoded RSA private key file and convert it to
> binary (using b64decode) what I get is not the same thing as I get
> from "openssl rsa -inform pem -in key -outform der -out key.der".
>
> How do you convert it?? Did you strip off the ---BEGIN and END tags??
> Then it absolutely should have been the same thing.
>
Yes, I certainly did.? And it's not the same thing.

Proof:

root at Test-MCP:/usr/local/etc/HD-MCP/ssl/x # diff key.pem test.key
0a1
> -----BEGIN PRIVATE KEY-----
26a28
> -----END PRIVATE KEY-----
root at Test-MCP:/usr/local/etc/HD-MCP/ssl/x # ls -al
total 16
drwxr-xr-x? 2 root?? wheel?? 512 Dec 28 18:36 .
drwx------? 3 hdmcp? wheel?? 512 Dec 28 18:33 ..
-rw-------? 1 root?? wheel? 1654 Dec 28 18:33 key.pem
-rw-------? 1 root?? wheel? 1708 Dec 28 18:35 test.key

Only difference is the barrier lines in the test.key file (which have to
be there for openssl or it throws up.)? Now we run:

root at Test-MCP:/usr/local/etc/HD-MCP/ssl/x # openssl rsa -inform pem -in
test.key -outform der -out key.der
writing RSA key
root at Test-MCP:/usr/local/etc/HD-MCP/ssl/x # b64decode -r key.pem >
key.bin?????
root at Test-MCP:/usr/local/etc/HD-MCP/ssl/x # ls -la
total 24
drwxr-xr-x? 2 root?? wheel?? 512 Dec 28 18:37 .
drwx------? 3 hdmcp? wheel?? 512 Dec 28 18:33 ..
-rw-r--r--? 1 root?? wheel? 1219 Dec 28 18:37 key.bin
-rw-r--r--? 1 root?? wheel? 1193 Dec 28 18:37 key.der
-rw-------? 1 root?? wheel? 1654 Dec 28 18:33 key.pem
-rw-------? 1 root?? wheel? 1708 Dec 28 18:35 test.key
root at Test-MCP:/usr/local/etc/HD-MCP/ssl/x #

Those output files (key.bin and key.der) are not the same -- they're
different within the first few bytes on examination with od -t x1, not
just on length (e.g. trash at the end)

If I load key.der into a binary buffer and run d2i_AutoPrivateKey
against it I get a valid EVP_PKEY buffer back and no error.

I'll chase this down further, but I think the easiest way may be to just
run DER files, since those work... :-)

> An internal structure, such as an RSA object, can be converted to DER
> using d2i_RSA.? DER is useful because it is a ?flat? format, whereas
> the internal object is useful in the C code.? Make sense?? DER files
> are useful if you already know what the filetype is.? The d2i_ and
> i2d_ functions convert between internal (C structures, with pointers
> etc) to DER encoding.? They basically work on buffers, only.
>

> PEM files are base64 encoded DER, with BEGIN and END tags that specify
> what the middle-part is.? It is useful because it is human readable.
> Also the PEM_read_xxxx functions will check what is expected to what
> the file says it is.
>
> Most objects have PEM_read and PEM_write functions as well.? They are
> not necessarily obvious from scanning the header files, because they
> are declared and implemented as macro?s, as it?s common code with just
> a pointer to an internal description of what the ASN1/DER looks like.
>
> The documentation on the master branch does a much better, and more
> complete, job of explaining this.
>
> The function I think you want is PEM_read_PrivateKey.
>
I'll look in there; my assumption was that I could trivially convert a
PEM file into an internal DER representation by stripping the flag lines
from the front and rear and then decoding the base64 piece.....

Thanks; I'll figger it out :-)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/cbbf4a2b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/cbbf4a2b/attachment.bin>

From rsalz at akamai.com  Fri Dec 29 01:20:42 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 29 Dec 2017 01:20:42 +0000
Subject: [openssl-users] Question as to best options....
In-Reply-To: <3de023dd-b198-57be-88c8-db410a4eb605@denninger.net>
References: <a7314155-699d-1d4e-3f24-1aa8ac4de8ac@denninger.net>
 <E7D22FD2-598B-4D62-9346-4703F770391B@akamai.com>
 <c7c4cb92-6549-2fc4-4c52-ec85a6ab956b@denninger.net>
 <20171226200729.GA16584@roeckx.be>
 <497540fe-1fcf-6c41-ffd7-f90bcf82dfba@denninger.net>
 <69cb7acd-a970-3a12-9cca-1067e99cec3b@denninger.net>
 <a64ad8f7-4d01-3598-3d06-eacbb0815b85@denninger.net>
 <F984D00C-5F57-482B-898F-558B346BF613@akamai.com>
 <3de023dd-b198-57be-88c8-db410a4eb605@denninger.net>
Message-ID: <CFE2FFC4-743A-427C-BF29-F2D1D88E7938@akamai.com>

The difference is ?auto private key? versus ?RSA private key.?

> -----BEGIN PRIVATE KEY-----

This is a private key wrapped in a PKCS8 container with a key-type identifier.


root at Test-MCP:/usr/local/etc/HD-MCP/ssl/x # openssl rsa -inform pem -in test.key -outform der -out key.der
writing RSA key

This just writes the DER of the RSA key.  Different thing.

Try dumping the der files with asn1dump


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

From kudzu at tenebras.com  Fri Dec 29 05:07:53 2017
From: kudzu at tenebras.com (Michael Sierchio)
Date: Thu, 28 Dec 2017 21:07:53 -0800
Subject: [openssl-users] How to form a proper hash after writing
 something into SSL handshake.
In-Reply-To: <5a424644.8230620a.c89bf.4e27@mx.google.com>
References: <5a424644.8230620a.c89bf.4e27@mx.google.com>
Message-ID: <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>

Comic Sans. Need I say more?

On Tue, Dec 26, 2017 at 4:53 AM, Sai Teja Chowdary <
asteja.chowdary.ece13 at itbhu.ac.in> wrote:

>
>
> Hi,
>
>
>
> Happy Holidays everyone.
>
>
>
> I want to send client certificate, client key exchange and client verify
> in a single handshake message which appears as multiple handshake messages
> in a single record. But to sent the client verify I need to first make a
> hash of previous messages(client certificate and client key exchange) to
> create the signature.
>
>
>
> Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX xxxx
> (or right procedure that needs to be done before creating a certificate
> verify message)that can do a proper transcript(digest or hash not clear). I
> tried using *ssl3_finish_mac() *on the message containing client
> certificate and client key exchange and then tried to generate the
> signature in certificate verify message.
>
> But it is giving me a digest error. I am new to the mailing list want a
> bit of help to proceed forward stuck here. Please reply in case if anything
> is not clear.
>
>
>
> Here is a code snippet, how I am forming the data containing all client
> certificate , client key exchange and certificate verify messages inside
> write_state_machine().
>
>
>
> if(WPACKET_init(&pkt, s->init_buf)){
>
> //Client certificate formation
>
>              if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL
> && !confunc(s,&pkt) ||         !ssl_close_construct_packet(s,&pkt,mt)){
>
>                   printf("PROBLEM\n");
>
>                 }
>
>              transition(s);  //transition to next state i.e client key
> exchange
>
>
>
>              get_construct_message_f(s, &pkt, &confunc, &mt);
>
> //client key exchange formation
>
>              if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL
> && !confunc(s,&pkt) ||         !ssl_close_construct_packet(s,&pkt,mt)){
>
>                    printf("AGAIN A PROBLEMO\n");
>
>                 }
>
>
>
> //ssl3_finish_mac(s, &s->init_buf->data[s->init_off], s->init_num);
>
>              st->write_state_work = post_work(s, st->write_state_work);
>
>              transition(s);  // transition to next state i.e  certificate
> verify
>
>
>
>              get_construct_message_f(s, &pkt, &confunc, &mt);
>
> //certificate verify message formation.
>
>              if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL
> && !confunc(s,&pkt) ||
> !ssl_close_construct_packet(s,&pkt,mt)){
>
>                    printf("AGAIN A PROBLEMO\n");
>
>                 }
>
>              WPACKET_finish(&pkt);
>
>
>
>
>
> Please take a look at it, appreciate every bit of help.
>
>
>
> Regards,
>
> Saiteja
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
"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/20171228/3dcf099c/attachment.html>

From levitte at openssl.org  Thu Dec 28 23:06:41 2017
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 29 Dec 2017 00:06:41 +0100 (CET)
Subject: [openssl-users] Can't build OpenSSL on Windows
In-Reply-To: <20171228221837.2608-1-martin@eclypsium.com>
References: <20171228221837.2608-1-martin@eclypsium.com>
Message-ID: <20171229.000641.1297349608194041259.levitte@openssl.org>

In message <20171228221837.2608-1-martin at eclypsium.com> on Thu, 28 Dec 2017 19:18:37 -0300, Martin Galvan <omgalvan.86 at gmail.com> said:

omgalvan.86> Hi all,
omgalvan.86> 
omgalvan.86> I'm trying to build OpenSSL on Windows. I'm using the nmake that came with
omgalvan.86> Visual Studio 2017, NASM, ActivePerl and have installed the Test::More and
omgalvan.86> Test::Template modules. nmake, perl and nasm are all visible in my system Path
omgalvan.86> variable. This is what I'm seeing:
omgalvan.86> 
omgalvan.86> C:\Users\e1\openssl\source>perl Configure VC-WIN64A --prefix=\c\Users\e1\openssl\install-windows no-comp no-zlib
omgalvan.86> Configuring OpenSSL version 1.1.0g (0x1010007fL)
omgalvan.86>     no-asan         [default]  OPENSSL_NO_ASAN
omgalvan.86>     no-comp         [option]   OPENSSL_NO_COMP (skip dir)
omgalvan.86>     no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
omgalvan.86>     no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
omgalvan.86>     no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
omgalvan.86>     no-egd          [default]  OPENSSL_NO_EGD
omgalvan.86>     no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
omgalvan.86>     no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
omgalvan.86>     no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
omgalvan.86>     no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
omgalvan.86>     no-msan         [default]  OPENSSL_NO_MSAN
omgalvan.86>     no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
omgalvan.86>     no-sctp         [default]  OPENSSL_NO_SCTP
omgalvan.86>     no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
omgalvan.86>     no-ssl3         [default]  OPENSSL_NO_SSL3
omgalvan.86>     no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
omgalvan.86>     no-ubsan        [default]  OPENSSL_NO_UBSAN
omgalvan.86>     no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
omgalvan.86>     no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
omgalvan.86>     no-zlib         [option]
omgalvan.86>     no-zlib-dynamic [default]
omgalvan.86> Configuring for VC-WIN64A
omgalvan.86> CC            =cl
omgalvan.86> CFLAG         =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2
omgalvan.86> SHARED_CFLAG  =
omgalvan.86> DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM
omgalvan.86> LFLAG         =/nologo /debug
omgalvan.86> PLIB_LFLAG    =
omgalvan.86> EX_LIBS       =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
omgalvan.86> APPS_OBJ      =win32_init.o ../ms/applink.o
omgalvan.86> CPUID_OBJ     =x86_64cpuid.o
omgalvan.86> UPLINK_OBJ    =../ms/uplink.o uplink-x86_64.o
omgalvan.86> BN_ASM        =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
omgalvan.86> EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
omgalvan.86> DES_ENC       =des_enc.o fcrypt_b.o
omgalvan.86> AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
omgalvan.86> BF_ENC        =bf_enc.o
omgalvan.86> CAST_ENC      =c_enc.o
omgalvan.86> RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
omgalvan.86> RC5_ENC       =rc5_enc.o
omgalvan.86> MD5_OBJ_ASM   =md5-x86_64.o
omgalvan.86> SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o
omgalvan.86> RMD160_OBJ_ASM=
omgalvan.86> CMLL_ENC      =cmll-x86_64.o cmll_misc.o
omgalvan.86> MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
omgalvan.86> PADLOCK_OBJ   =e_padlock-x86_64.o
omgalvan.86> CHACHA_ENC    =chacha-x86_64.o
omgalvan.86> POLY1305_OBJ  =poly1305-x86_64.o
omgalvan.86> BLAKE2_OBJ    =
omgalvan.86> PROCESSOR     =
omgalvan.86> RANLIB        =true
omgalvan.86> ARFLAGS       =/nologo
omgalvan.86> PERL          =C:\Perl64\bin\perl.exe
omgalvan.86> 
omgalvan.86> SIXTY_FOUR_BIT mode
omgalvan.86> 
omgalvan.86> Configured for VC-WIN64A.
omgalvan.86> 
omgalvan.86> And then:
omgalvan.86> 
omgalvan.86> C:\Users\e1\openssl\source>nmake
omgalvan.86> 
omgalvan.86> Microsoft (R) Program Maintenance Utility Version 14.11.25547.0
omgalvan.86> Copyright (C) Microsoft Corporation.  All rights reserved.
omgalvan.86> 
omgalvan.86> "Detected changed: ".\Configure" "Configurations\windows-makefile.tmpl" "Configurations\common.tmpl"
omgalvan.86> "build.info" "crypto\build.info" "ssl\build.info" "engines\build.info" "apps\build.info"
omgalvan.86> "test\build.info" "util\build.info" "tools\build.info" "fuzz\build.info" "crypto\objects\build.info"
omgalvan.86> "crypto\md4\build.info" "crypto\md5\build.info" "crypto\sha\build.info" "crypto\mdc2\build.info"
omgalvan.86> "crypto\hmac\build.info" "crypto\ripemd\build.info" "crypto\whrlpool\build.info"
omgalvan.86> "crypto\poly1305\build.info" "crypto\blake2\build.info" "crypto\des\build.info" "crypto\aes\build.info"
omgalvan.86> "crypto\rc2\build.info" "crypto\rc4\build.info" "crypto\idea\build.info" "crypto\bf\build.info"
omgalvan.86> "crypto\cast\build.info" "crypto\camellia\build.info" "crypto\seed\build.info" "crypto\chacha\build.info"
omgalvan.86> "crypto\modes\build.info" "crypto\bn\build.info" "crypto\ec\build.info" "crypto\rsa\build.info"
omgalvan.86> "crypto\dsa\build.info" "crypto\dh\build.info" "crypto\dso\build.info" "crypto\engine\build.info"
omgalvan.86> "crypto\buffer\build.info" "crypto\bio\build.info" "crypto\stack\build.info" "crypto\lhash\build.info"
omgalvan.86> "crypto\rand\build.info" "crypto\err\build.info" "crypto\evp\build.info" "crypto\asn1\build.info"
omgalvan.86> "crypto\pem\build.info" "crypto\x509\build.info" "crypto\x509v3\build.info" "crypto\conf\build.info"
omgalvan.86> "crypto\txt_db\build.info" "crypto\pkcs7\build.info" "crypto\pkcs12\build.info" "crypto\ocsp\build.info"
omgalvan.86> "crypto\ui\build.info" "crypto\cms\build.info" "crypto\ts\build.info" "crypto\srp\build.info"
omgalvan.86> "crypto\cmac\build.info" "crypto\ct\build.info" "crypto\async\build.info" "crypto\kdf\build.info"
omgalvan.86> "Configurations\00-base-templates.conf" "Configurations\10-main.conf""
omgalvan.86> "Reconfiguring..."
omgalvan.86>         "C:\Perl64\bin\perl.exe" ".\Configure" reconf
omgalvan.86> Reconfiguring with: VC-WIN64A --prefix=\c\Users\e1\openssl\install-windows no-comp no-zlib
omgalvan.86>     CC = cl
omgalvan.86>     BUILDFILE = makefile
omgalvan.86> Configuring OpenSSL version 1.1.0g (0x1010007fL)
omgalvan.86>     no-asan         [default]  OPENSSL_NO_ASAN
omgalvan.86>     no-comp         [option]   OPENSSL_NO_COMP (skip dir)
omgalvan.86>     no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
omgalvan.86>     no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
omgalvan.86>     no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
omgalvan.86>     no-egd          [default]  OPENSSL_NO_EGD
omgalvan.86>     no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
omgalvan.86>     no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
omgalvan.86>     no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
omgalvan.86>     no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
omgalvan.86>     no-msan         [default]  OPENSSL_NO_MSAN
omgalvan.86>     no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
omgalvan.86>     no-sctp         [default]  OPENSSL_NO_SCTP
omgalvan.86>     no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
omgalvan.86>     no-ssl3         [default]  OPENSSL_NO_SSL3
omgalvan.86>     no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
omgalvan.86>     no-ubsan        [default]  OPENSSL_NO_UBSAN
omgalvan.86>     no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
omgalvan.86>     no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
omgalvan.86>     no-zlib         [option]
omgalvan.86>     no-zlib-dynamic [default]
omgalvan.86> Configuring for VC-WIN64A
omgalvan.86> CC            =cl
omgalvan.86> CFLAG         =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2
omgalvan.86> SHARED_CFLAG  =
omgalvan.86> DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM
omgalvan.86> LFLAG         =/nologo /debug
omgalvan.86> PLIB_LFLAG    =
omgalvan.86> EX_LIBS       =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
omgalvan.86> APPS_OBJ      =win32_init.o ../ms/applink.o
omgalvan.86> CPUID_OBJ     =x86_64cpuid.o
omgalvan.86> UPLINK_OBJ    =../ms/uplink.o uplink-x86_64.o
omgalvan.86> BN_ASM        =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
omgalvan.86> EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
omgalvan.86> DES_ENC       =des_enc.o fcrypt_b.o
omgalvan.86> AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
omgalvan.86> BF_ENC        =bf_enc.o
omgalvan.86> CAST_ENC      =c_enc.o
omgalvan.86> RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
omgalvan.86> RC5_ENC       =rc5_enc.o
omgalvan.86> MD5_OBJ_ASM   =md5-x86_64.o
omgalvan.86> SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o
omgalvan.86> RMD160_OBJ_ASM=
omgalvan.86> CMLL_ENC      =cmll-x86_64.o cmll_misc.o
omgalvan.86> MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
omgalvan.86> PADLOCK_OBJ   =e_padlock-x86_64.o
omgalvan.86> CHACHA_ENC    =chacha-x86_64.o
omgalvan.86> POLY1305_OBJ  =poly1305-x86_64.o
omgalvan.86> BLAKE2_OBJ    =
omgalvan.86> PROCESSOR     =
omgalvan.86> RANLIB        =true
omgalvan.86> ARFLAGS       =/nologo
omgalvan.86> PERL          =C:\Perl64\bin\perl.exe
omgalvan.86> 
omgalvan.86> SIXTY_FOUR_BIT mode
omgalvan.86> 
omgalvan.86> Configured for VC-WIN64A.
omgalvan.86> "**************************************************"
omgalvan.86> "***                                            ***"
omgalvan.86> "***   Please run the same make command again   ***"
omgalvan.86> "***                                            ***"
omgalvan.86> "**************************************************"
omgalvan.86> NMAKE : fatal error U1077: 'exit' : return code '0x1'
omgalvan.86> Stop.
omgalvan.86> 
omgalvan.86> What am I doing wrong?

Nothing, I think...

what's happening is that there's a rule that looks like this in the
makefile:

    configdata.pm : .\Configure ...

That's the one that's getting triggered for some reason, and that's
because one of those listed dependencies is newer than configdata.pm

You simply need to do exactly what you're told, i.e. run 'nmake'
again.

If that happens again and again, then you have a problem.  If I were
in your shoes, I'd look pretty hard at file time stamps to see if I
could figure it out from there.

Cheers,
Richard

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

From asteja.chowdary.ece13 at itbhu.ac.in  Fri Dec 29 13:14:24 2017
From: asteja.chowdary.ece13 at itbhu.ac.in (Sai Teja Chowdary)
Date: Fri, 29 Dec 2017 18:44:24 +0530
Subject: [openssl-users] How to form a proper hash after writing
 somethinginto SSL handshake.
In-Reply-To: <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>
References: <5a424644.8230620a.c89bf.4e27@mx.google.com>
 <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>
Message-ID: <5a463fb0.5412620a.a6c3a.b009@mx.google.com>


Why? What is the problem with Comic Sans. I like it!

You can say more if you have something useful.

Thanks

Saiteja.

From: Michael Sierchio
Sent: Friday, December 29, 2017 10:38 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.


Comic Sans. Need I say more?

On Tue, Dec 26, 2017 at 4:53 AM, Sai Teja Chowdary <asteja.chowdary.ece13 at itbhu.ac.in> wrote:
?
Hi,
?
Happy Holidays everyone.
?
I want to send client certificate, client key exchange and client verify in a single handshake message which appears as multiple handshake messages in a single record. But to sent the client verify I need to first make a hash of previous messages(client certificate and client key exchange) to create the signature.
?
Can anyone help me to find the function in OpenSSL 1.1.1-dev? xx XXX xxxx (or right procedure that needs to be done before creating a certificate verify message)that can do a proper transcript(digest or hash not clear). I tried using ssl3_finish_mac() on the message containing client certificate and client key exchange and then tried to generate the signature in certificate verify message.
But it is giving me a digest error. I am new to the mailing list want a bit of help to proceed forward stuck here. Please reply in case if anything is not clear.
?
Here is a code snippet, how I am forming the data containing all client certificate , client key exchange and certificate verify messages inside write_state_machine().
?
if(WPACKET_init(&pkt, s->init_buf)){
//Client certificate formation
???????????? if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL && !confunc(s,&pkt) || ??????? !ssl_close_construct_packet(s,&pkt,mt)){
? ????????????????printf("PROBLEM\n");
??????????????? }
???????????? transition(s);? //transition to next state i.e client key exchange
?
???????????? get_construct_message_f(s, &pkt, &confunc, &mt);
//client key exchange formation
???????? ????if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL && !confunc(s,&pkt) || ??????? !ssl_close_construct_packet(s,&pkt,mt)){
?????????????????? printf("AGAIN A PROBLEMO\n");
??????????????? }
?
//ssl3_finish_mac(s, &s->init_buf->data[s->init_off], s->init_num);
???????????? st->write_state_work = post_work(s, st->write_state_work);
???????????? transition(s); ?// transition to next state i.e ?certificate verify
?
???????????? get_construct_message_f(s, &pkt, &confunc, &mt);
//certificate verify message formation.
???????????? if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL && !confunc(s,&pkt) || ??????????????????????? ??????? ???????? !ssl_close_construct_packet(s,&pkt,mt)){
?????????????????? printf("AGAIN A PROBLEMO\n");
??????????????? }
???????????? WPACKET_finish(&pkt);
?
?
Please take a look at it, appreciate every bit of help.
?
Regards,
Saiteja
?

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




-- 
"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/20171229/0492a6f2/attachment.html>

From martygalyean at gmail.com  Fri Dec 29 14:00:00 2017
From: martygalyean at gmail.com (Marty G)
Date: Fri, 29 Dec 2017 09:00:00 -0500
Subject: [openssl-users] How to form a proper hash after writing
 somethinginto SSL handshake.
In-Reply-To: <5a463fb0.5412620a.a6c3a.b009@mx.google.com>
References: <5a424644.8230620a.c89bf.4e27@mx.google.com>
 <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>
 <5a463fb0.5412620a.a6c3a.b009@mx.google.com>
Message-ID: <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>

For the same reason one doesn't wear a halloween costume to a technical 
meeting, Comic Sans is looked down upon when used outside comics and 
day-care centers.? It is considered a snub to use it in non-trivial 
settings.

Much as lifting up your middle finger has no inherent meaning per se, 
but once one realizes that it definitely has meaning to others and one 
lifts one's middle finger to others anyway, it can only be assumed that 
one has intended to send the message others have assigned to it.? So, 
for whatever vague societal reasons, comic sans has become equivalent to 
wearing a speedo to a formal wedding, giggling hysterically during one's 
performance review, or skipping around the track in a tu-tu and 
clownface during the 440 meter track event at the Olympics.? Those are 
the breaks!? Sorry for your loss of a connotation free comic sans.? I 
feel your pain.? Herd dynamics can be brutal and bleak.

http://knowyourmeme.com/memes/comic-sans
"...While adequate for certain industry sectors like childcare and 
entertainment, its usage in business or professional settings has been 
criticized by many aesthetic-conscious Internet users, who say Comic 
Sans conveys silliness and irreverence that is hardly suitable for 
serious matters....:

On 12/29/2017 08:14 AM, Sai Teja Chowdary wrote:
>
> Why? What is the problem with Comic Sans. I like it!
>
> You can say more if you have something useful.
>
> Thanks
>
> Saiteja.
>
> *From: *Michael Sierchio <mailto:kudzu at tenebras.com>
> *Sent: *Friday, December 29, 2017 10:38 AM
> *To: *openssl-users at openssl.org <mailto:openssl-users at openssl.org>
> *Subject: *Re: [openssl-users] How to form a proper hash after writing 
> somethinginto SSL handshake.
>
> Comic Sans. Need I say more?
>
> On Tue, Dec 26, 2017 at 4:53 AM, Sai Teja Chowdary 
> <asteja.chowdary.ece13 at itbhu.ac.in 
> <mailto:asteja.chowdary.ece13 at itbhu.ac.in>> wrote:
>
>     Hi,
>
>     Happy Holidays everyone.
>
>     I want to send client certificate, client key exchange and client
>     verify in a single handshake message which appears as multiple
>     handshake messages in a single record. But to sent the client
>     verify I need to first make a hash of previous messages(client
>     certificate and client key exchange) to create the signature.
>
>     Can anyone help me to find the function in OpenSSL 1.1.1-dev? xx
>     XXX xxxx (or right procedure that needs to be done before creating
>     a certificate verify message)that can do a proper
>     transcript(digest or hash not clear). I tried using
>     *ssl3_finish_mac() *on the message containing client certificate
>     and client key exchange and then tried to generate the signature
>     in certificate verify message.
>
>     But it is giving me a digest error. I am new to the mailing list
>     want a bit of help to proceed forward stuck here. Please reply in
>     case if anything is not clear.
>
>     Here is a code snippet, how I am forming the data containing all
>     client certificate , client key exchange and certificate verify
>     messages inside write_state_machine().
>
>     if(WPACKET_init(&pkt, s->init_buf)){
>
>     //Client certificate formation
>
>     if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL &&
>     !confunc(s,&pkt) || !ssl_close_construct_packet(s,&pkt,mt)){
>
>     ????????????????printf("PROBLEM\n");
>
>     ??????????????? }
>
>     ???????????? transition(s); //transition to next state i.e client
>     key exchange
>
>     get_construct_message_f(s, &pkt, &confunc, &mt);
>
>     //client key exchange formation
>
>     ????if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL &&
>     !confunc(s,&pkt) || !ssl_close_construct_packet(s,&pkt,mt)){
>
>     ?????????????????? printf("AGAIN A PROBLEMO\n");
>
>     ??????????????? }
>
>     //ssl3_finish_mac(s, &s->init_buf->data[s->init_off], s->init_num);
>
>     st->write_state_work = post_work(s, st->write_state_work);
>
>     ???????????? transition(s); ?// transition to next state i.e
>     ?certificate verify
>
>     get_construct_message_f(s, &pkt, &confunc, &mt);
>
>     //certificate verify message formation.
>
>     if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL &&
>     !confunc(s,&pkt) || !ssl_close_construct_packet(s,&pkt,mt)){
>
>     ?????????????????? printf("AGAIN A PROBLEMO\n");
>
>     ??????????????? }
>
>     WPACKET_finish(&pkt);
>
>     Please take a look at it, appreciate every bit of help.
>
>     Regards,
>
>     Saiteja
>
>
>     --
>     openssl-users mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> -- 
>
> "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/20171229/fac803bd/attachment-0001.html>

From omgalvan.86 at gmail.com  Fri Dec 29 14:11:48 2017
From: omgalvan.86 at gmail.com (Martin Galvan)
Date: Fri, 29 Dec 2017 11:11:48 -0300
Subject: [openssl-users] Can't build OpenSSL on Windows
In-Reply-To: <20171229.000641.1297349608194041259.levitte@openssl.org>
References: <20171229.000641.1297349608194041259.levitte@openssl.org>
Message-ID: <20171229141148.4302-1-martin@eclypsium.com>

Hi Richard,

> You simply need to do exactly what you're told, i.e. run 'nmake'
> again.
>
> If that happens again and again, then you have a problem.  If I were
> in your shoes, I'd look pretty hard at file time stamps to see if I
> could figure it out from there.

I ran it several times and saw the same thing every time. What file timestamps
do I have to look at? What should I figure out from there?

I forgot to mention, I'm on Windows 10, and am building for VC-WIN64A. I also
set a non-standard --prefix when running configure (it's an existing folder
I can write to).

From omgalvan.86 at gmail.com  Fri Dec 29 14:59:27 2017
From: omgalvan.86 at gmail.com (Martin Galvan)
Date: Fri, 29 Dec 2017 11:59:27 -0300
Subject: [openssl-users] Can't build OpenSSL on Windows
In-Reply-To: <20171229.000641.1297349608194041259.levitte@openssl.org>
References: <20171229.000641.1297349608194041259.levitte@openssl.org>
Message-ID: <20171229145927.2201-1-martin@eclypsium.com>

Well, after a couple more tries it seems to be working now. I don't get the
same error as before, but rather a complaint about stddef.h not being found.
I'm guessing that's more of a Visual Studio problem, so I'll look into that.

Thanks.

From gadphly at gmail.com  Fri Dec 29 15:20:35 2017
From: gadphly at gmail.com (Gelareh Taban)
Date: Fri, 29 Dec 2017 08:20:35 -0700
Subject: [openssl-users] Padding for RSA signatures
Message-ID: <CALug0JYww2iwD8MxuODgVH1BwE6ZVw+N-9nMoqK5=swLP7piYA@mail.gmail.com>

Hi all,

Any help would be *much* appreciated. I am playing around with RSA
signatures with different padding options and I have some questions.

I am trying to define different padding options and so am defining and
using a EVP_PKEY_CTX . However I am not sure if this padding is getting
used in the signature since  my Verify outputs OK regardless of which
option my Sign uses. Which leads to:

1 - Do I need to use a EVP_PKEY_CTX with the same options when doing
verify? If so, I assume I can't reuse the same PKey_Ctx and I have to
define another one. Right now even when I don't use any EVP_PKEY_CTX in
Verify, I still verify OK, which makes me question if the padding option
has been set.

2 - Is there a way to figure out what padding/hashing/etc option was used
for the Sign/verify operation? This way I can be sure what algorithm or
standard is being used.

3 - Do I need to set the hash function I am using in both EVP_PKEY_CTX  as
well as EVP_MD_CTX ? Or the latter is what defines this for the signing
option?

4 - In general, is there a way of making the Signature/Encryptions in
OpenSSL be deterministic for debugging/testing purposes?

5 - I noticed that there are two ways of determining the signature size:
(a) by calling EVP_PKEY_size(rsaKeypair) as I am doing below, as well as
(b) calling EVP_DigestSignFinal(md_ctx, nil, &sig_len) . Is one better than
the other?

My sample code is below for reference. It's in Swift (but it should still
be close enough to C to be readable). Also in Swift, some of the complex
macros in OpenSSL have to be broken down to be compilable hence my usage of
EVP_DigestUpdate instead of EVP_DigestVerifyUpdate .

Thanks in advance for any insight in the above.

cheers!
Gelareh


        let md_ctx = EVP_MD_CTX_create()

        let md_ctx_verify = EVP_MD_CTX_create()



        // To define padding option used in signature

        let pkey_ctx = EVP_PKEY_CTX_new(rsaKeypair, nil)



        // EVP_PKEY_CTX_set_rsa_padding(pkey_ctx, RSA_PKCS1_PADDING) -
complex macro needs to be replaced

        EVP_PKEY_CTX_ctrl(pkey_ctx, EVP_PKEY_RSA, -1,
EVP_PKEY_CTRL_RSA_PADDING, RSA_X931_PADDING, nil)


        // EVP_PKEY_CTX_set_signature_md() When should this be set?



        //  SIGN

        var rc = EVP_DigestSignInit(md_ctx, &pkey_ctx, EVP_sha256(), nil,
myRSA.rsaKeypair)

        // EVP_DigestSignUpdate(md_ctx, message, message.count)

        // Complex macro needs to be replaced

        rc = EVP_DigestUpdate(md_ctx, message, message.count)



        // allocate memory for signature

        var sig_len: Int = Int(EVP_PKEY_size(rsaKeypair))

        let sig = UnsafeMutablePointer<UInt8>.allocate(capacity: sig_len)


        rc = EVP_DigestSignFinal(md_ctx, sig, &sig_len)





        // VERIFY

        rc = EVP_DigestVerifyInit(md_ctx_verify, nil, EVP_sha256(), nil,
rsaKeypair)


        //        rc = EVP_DigestVerifyUpdate(md_ctx_verify, message,
message.count)

        rc = EVP_DigestUpdate(md_ctx_verify, message, message.count)



        rc = EVP_DigestVerifyFinal(md_ctx_verify, sig, sig_len)

        print("signature verified = \(rc == 1 ? "OK" : "FAIL")")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171229/948484aa/attachment.html>

From matt at openssl.org  Fri Dec 29 16:07:05 2017
From: matt at openssl.org (Matt Caswell)
Date: Fri, 29 Dec 2017 16:07:05 +0000
Subject: [openssl-users] Padding for RSA signatures
In-Reply-To: <CALug0JYww2iwD8MxuODgVH1BwE6ZVw+N-9nMoqK5=swLP7piYA@mail.gmail.com>
References: <CALug0JYww2iwD8MxuODgVH1BwE6ZVw+N-9nMoqK5=swLP7piYA@mail.gmail.com>
Message-ID: <17ab7c75-e4a1-65ee-85c8-4b32d07fbceb@openssl.org>

Some comments inserted below.

Matt

On 29/12/17 15:20, Gelareh Taban wrote:
> Hi all,
> 
> Any help would be *much* appreciated. I am playing around with RSA
> signatures with different padding options and I have some questions.
> 
> I am trying to define different padding options and so am defining and
> using a?EVP_PKEY_CTX?. However I am not sure if this padding is getting
> used in the signature since ?my Verify outputs OK regardless of which
> option my Sign uses. Which leads to:
> 
> 1 - Do I need to use a?EVP_PKEY_CTX?with the same options when doing
> verify? If so, I assume I can't reuse the same PKey_Ctx and I have to
> define another one. Right now even when I don't use any?EVP_PKEY_CTX?in
> Verify, I still verify OK, which makes me question if the padding option
> has been set.

It hasn't. The call to EVP_DigestSignInit() expects an EVP_PKEY_CTX **.
This is because that function creates its *own* EVP_PKEY_CTX * and
stores it in the location you provide (if you give one). In your code
the EVP_PKEY_CTX you are creating is being overwritten by the one
created by EVP_DigestSignInit(). From the documentation:

  EVP_DigestSignInit() sets up signing context ctx to use digest type
  from ENGINE impl and private key pkey. ctx must be created with
  EVP_MD_CTX_new() before calling this function. If pctx is not NULL the
  EVP_PKEY_CTX of the signing operation will be written to *pctx: this
  can be used to set alternative signing options.

Try removing the creation of your own EVP_PKEY_CTX *, and moving the
EVP_PKEY_CTX_set_rsa_padding() call to after EVP_DigestSignInit().

> 
> 2 - Is there a way to figure out what padding/hashing/etc option was
> used for the Sign/verify operation? This way I can be sure what
> algorithm or standard is being used.?
> 
> 3 - Do I need to set the hash function I am using in both?EVP_PKEY_CTX?
> as well as?EVP_MD_CTX?? Or the latter is what defines this for the
> signing option?

You only need to specify the hash function in
EVP_DigestSignInit()/EVP_DigestVerifyInit().

To answer your question in the code, there is no need to call
EVP_PKEY_CTX_set_signature_md() directly in this scenario. It is called
for you by EVP_DigestSignInit()/EVP_DigestVerifyInit().

> 
> 4 - In general, is there a way of making the Signature/Encryptions in
> OpenSSL be deterministic for debugging/testing purposes? >
> 5 - I noticed that there are two ways of determining the signature size:
> (a) by calling?EVP_PKEY_size(rsaKeypair)?as I am doing below, as well as
> (b) calling?EVP_DigestSignFinal(md_ctx, nil, &sig_len)?. Is one better
> than the other? 

The former gives you a maximum bound on the size of the signature before
the signature is created. The latter gives you the *actual* size of the
signature that is generated (which could be smaller).


> 
> My sample code is below for reference. It's in Swift (but it should
> still be close enough to C to be readable). Also in Swift, some of the
> complex macros in OpenSSL have to be broken down to be compilable hence
> my usage of?EVP_DigestUpdate?instead of?EVP_DigestVerifyUpdate?.
> 
> Thanks in advance for any insight in the above.
> 
> cheers!
> Gelareh
> 
> 
> ? ? ? ??let md_ctx = EVP_MD_CTX_create()
> 
> ? ? ? ? let md_ctx_verify = EVP_MD_CTX_create()
> 
> ?? ? ? ?
> 
> ? ? ? ??// To define padding option used in signature
> 
> ? ? ? ? let pkey_ctx = EVP_PKEY_CTX_new(rsaKeypair, nil)
> 
> ?? ? ? ?
> 
> ? ? ? ? // EVP_PKEY_CTX_set_rsa_padding(pkey_ctx, RSA_PKCS1_PADDING) -
> complex macro needs to be replaced
> 
> ? ? ? ? EVP_PKEY_CTX_ctrl(pkey_ctx, EVP_PKEY_RSA, -1,
> EVP_PKEY_CTRL_RSA_PADDING, RSA_X931_PADDING, nil)
> 
> 
> ? ? ? ? // EVP_PKEY_CTX_set_signature_md() When should this be set?
> 
> ? ? ? ??
> 
> ? ? ? ??//? SIGN
> 
> ? ? ? ??var rc = EVP_DigestSignInit(md_ctx, &pkey_ctx, EVP_sha256(),
> nil, myRSA.rsaKeypair)
> 
> ? ? ? ??// EVP_DigestSignUpdate(md_ctx, message, message.count)
> 
> ? ? ? ? // Complex macro needs to be replaced
> 
> ? ? ? ? rc = EVP_DigestUpdate(md_ctx, message, message.count)
> 
> ? ? ? ??
> 
> ? ? ? ??// allocate memory for signature
> 
> ? ? ? ??var sig_len: Int =?Int(EVP_PKEY_size(rsaKeypair))
> 
> ? ? ? ? let sig = UnsafeMutablePointer<UInt8>.allocate(capacity: sig_len)
> 
> 
> ? ? ? ? rc = EVP_DigestSignFinal(md_ctx, sig, &sig_len)
> 
> ? ? ??
> 
> ?? ? ? ?
> 
> ? ? ? ? // VERIFY
> 
> ? ? ? ? rc = EVP_DigestVerifyInit(md_ctx_verify, nil, EVP_sha256(),?nil,
> rsaKeypair)
> 
> 
> ? ? ? ??//? ? ? ? rc = EVP_DigestVerifyUpdate(md_ctx_verify, message,
> message.count)
> 
> ? ? ? ? rc = EVP_DigestUpdate(md_ctx_verify, message, message.count)
> 
> ? ? ? ?
> 
> ? ? ? ? rc = EVP_DigestVerifyFinal(md_ctx_verify, sig, sig_len)
> 
> ? ? ? ? print("signature verified = \(rc == 1? "OK": "FAIL")")
> 
> ?? ? ? ?
> 
> 
> 
> 
> 
> 
> 

From levitte at openssl.org  Fri Dec 29 17:14:04 2017
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 29 Dec 2017 18:14:04 +0100 (CET)
Subject: [openssl-users] Can't build OpenSSL on Windows
In-Reply-To: <20171229145927.2201-1-martin@eclypsium.com>
References: <20171229.000641.1297349608194041259.levitte@openssl.org>
 <20171229145927.2201-1-martin@eclypsium.com>
Message-ID: <20171229.181404.780642950361658869.levitte@openssl.org>

In message <20171229145927.2201-1-martin at eclypsium.com> on Fri, 29 Dec 2017 11:59:27 -0300, Martin Galvan <omgalvan.86 at gmail.com> said:

omgalvan.86> Well, after a couple more tries it seems to be working now. I don't get the
omgalvan.86> same error as before, but rather a complaint about stddef.h not being found.
omgalvan.86> I'm guessing that's more of a Visual Studio problem, so I'll look into that.

Ok, so this is a timestamp thing.  I had a system once where this
happened, because some of the files configdata.pm depended on were
timestamped in the future.  It turned out that the time of that
systems was badly set (in the past), so it took that time difference
before 'mms' (this was a VMS machine, 'mms' is the 'make' command
there) stopped reconfiguring.

configdata.pm depends on Configure, Configurations/*.conf,
Configurations/*.pl, Configurations/*.tmpl, and all the
build.info files.  If any of those are newer, 'nmake' will
automatically reconfigure and ask you to run again.

Timing is everything ;-)

Cheers,
Richard

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

From Michael.Wojcik at microfocus.com  Fri Dec 29 17:18:16 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 29 Dec 2017 17:18:16 +0000
Subject: [openssl-users] How to form a proper hash after writing
 somethinginto SSL handshake.
In-Reply-To: <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>
References: <5a424644.8230620a.c89bf.4e27@mx.google.com>
 <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>
 <5a463fb0.5412620a.a6c3a.b009@mx.google.com>
 <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AF48AF@prvxmb04.microfocus.com>

And to be honest, specifying any font for a technical or business email message (rather than simply letting the MUA use the user's default) is suspect. It says that you believe your stylistic preferences are more important than the reader's. That's a poor footing to begin a request for assistance or cooperation.

Personally, due to Outlook's terrible handling of HTML email (particularly in formatting replies), I am considerably more likely to reply to a plain-text message posted to openssl-users than I am to an HTML one. That may well be a personal idiosyncrasy, but the general principle of not making your message any more complicated than it needs to be is worth keeping in mind.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 



From levitte at openssl.org  Fri Dec 29 17:34:14 2017
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 29 Dec 2017 18:34:14 +0100 (CET)
Subject: [openssl-users] How to form a proper hash after writing
 somethinginto SSL handshake.
In-Reply-To: <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>
References: <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>
 <5a463fb0.5412620a.a6c3a.b009@mx.google.com>
 <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>
Message-ID: <20171229.183414.1279570989098595096.levitte@openssl.org>

Marty, you might want to consider that the values of western society
are hardly universal.  Comic Sans isn't as badly seen everywhere, and
there's no reason why western society biases should trump any other.

Also, I'd like to remind everyone that we have a code of conduct,
https://www.openssl.org/community/conduct.html

Cordially,
Richard

In message <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb at gmail.com> on Fri, 29 Dec 2017 09:00:00 -0500, Marty G <martygalyean at gmail.com> said:

martygalyean> For the same reason one doesn't wear a halloween costume to a technical meeting, Comic Sans is
martygalyean> looked down upon when used outside comics and day-care centers. It is considered a snub to use
martygalyean> it in non-trivial settings.
martygalyean> 
martygalyean> Much as lifting up your middle finger has no inherent meaning per se, but once one realizes that it
martygalyean> definitely has meaning to others and one lifts one's middle finger to others anyway, it can only be
martygalyean> assumed that one has intended to send the message others have assigned to it. So, for whatever
martygalyean> vague societal reasons, comic sans has become equivalent to wearing a speedo to a formal
martygalyean> wedding, giggling hysterically during one's performance review, or skipping around the track in a
martygalyean> tu-tu and clownface during the 440 meter track event at the Olympics. Those are the breaks!
martygalyean> Sorry for your loss of a connotation free comic sans. I feel your pain. Herd dynamics can be brutal
martygalyean> and bleak.
martygalyean> 
martygalyean> http://knowyourmeme.com/memes/comic-sans
martygalyean> "...While adequate for certain industry sectors like childcare and entertainment, its usage in
martygalyean> business or professional settings has been criticized by many aesthetic-conscious Internet users,
martygalyean> who say Comic Sans conveys silliness and irreverence that is hardly suitable for serious
martygalyean> matters....:
martygalyean> 
martygalyean> On 12/29/2017 08:14 AM, Sai Teja Chowdary wrote:
martygalyean> 
martygalyean>  Why? What is the problem with Comic Sans. I like it!
martygalyean> 
martygalyean>  You can say more if you have something useful.
martygalyean> 
martygalyean>  Thanks
martygalyean> 
martygalyean>  Saiteja.
martygalyean> 
martygalyean>  From: Michael Sierchio
martygalyean>  Sent: Friday, December 29, 2017 10:38 AM
martygalyean>  To: openssl-users at openssl.org
martygalyean>  Subject: Re: [openssl-users] How to form a proper hash after writing somethinginto SSL
martygalyean>  handshake.
martygalyean> 
martygalyean>  Comic Sans. Need I say more?
martygalyean> 
martygalyean>  On Tue, Dec 26, 2017 at 4:53 AM, Sai Teja Chowdary <asteja.chowdary.ece13 at itbhu.ac.in>
martygalyean>  wrote:
martygalyean> 
martygalyean>  Hi,
martygalyean> 
martygalyean>  Happy Holidays everyone.
martygalyean> 
martygalyean>  I want to send client certificate, client key exchange and client verify in a single handshake
martygalyean>  message which appears as multiple handshake messages in a single record. But to sent
martygalyean>  the client verify I need to first make a hash of previous messages(client certificate and
martygalyean>  client key exchange) to create the signature.
martygalyean> 
martygalyean>  Can anyone help me to find the function in OpenSSL 1.1.1-dev xx XXX xxxx (or right
martygalyean>  procedure that needs to be done before creating a certificate verify message)that can do
martygalyean>  a proper transcript(digest or hash not clear). I tried using ssl3_finish_mac() on the
martygalyean>  message containing client certificate and client key exchange and then tried to generate
martygalyean>  the signature in certificate verify message.
martygalyean> 
martygalyean>  But it is giving me a digest error. I am new to the mailing list want a bit of help to proceed
martygalyean>  forward stuck here. Please reply in case if anything is not clear.
martygalyean> 
martygalyean>  Here is a code snippet, how I am forming the data containing all client certificate , client
martygalyean>  key exchange and certificate verify messages inside write_state_machine().
martygalyean> 
martygalyean>  if(WPACKET_init(&pkt, s->init_buf)){
martygalyean> 
martygalyean>  //Client certificate formation
martygalyean> 
martygalyean>  if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL && !confunc(s,&pkt) ||
martygalyean>  !ssl_close_construct_packet(s,&pkt,mt)){
martygalyean> 
martygalyean>  printf("PROBLEM\n");
martygalyean> 
martygalyean>  }
martygalyean> 
martygalyean>  transition(s); //transition to next state i.e client key exchange
martygalyean> 
martygalyean>  get_construct_message_f(s, &pkt, &confunc, &mt);
martygalyean> 
martygalyean>  //client key exchange formation
martygalyean> 
martygalyean>  if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL && !confunc(s,&pkt) ||
martygalyean>  !ssl_close_construct_packet(s,&pkt,mt)){
martygalyean> 
martygalyean>  printf("AGAIN A PROBLEMO\n");
martygalyean> 
martygalyean>  }
martygalyean> 
martygalyean>  //ssl3_finish_mac(s, &s->init_buf->data[s->init_off], s->init_num);
martygalyean> 
martygalyean>  st->write_state_work = post_work(s, st->write_state_work);
martygalyean> 
martygalyean>  transition(s); // transition to next state i.e certificate verify
martygalyean> 
martygalyean>  get_construct_message_f(s, &pkt, &confunc, &mt);
martygalyean> 
martygalyean>  //certificate verify message formation.
martygalyean> 
martygalyean>  if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL && !confunc(s,&pkt) ||
martygalyean>  !ssl_close_construct_packet(s,&pkt,mt)){
martygalyean> 
martygalyean>  printf("AGAIN A PROBLEMO\n");
martygalyean> 
martygalyean>  }
martygalyean> 
martygalyean>  WPACKET_finish(&pkt);
martygalyean> 
martygalyean>  Please take a look at it, appreciate every bit of help.
martygalyean> 
martygalyean>  Regards,
martygalyean> 
martygalyean>  Saiteja
martygalyean> 
martygalyean>  --
martygalyean>  openssl-users mailing list
martygalyean>  To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
martygalyean> 
martygalyean>  --
martygalyean> 
martygalyean>  "Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an
martygalyean>  intelligent person requires only two thousand five hundred."
martygalyean> 
martygalyean>  - The Mah?bh?rata
martygalyean> 

From openssl-users at dukhovni.org  Fri Dec 29 18:04:26 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 29 Dec 2017 13:04:26 -0500
Subject: [openssl-users] How to form a proper hash after writing
 somethinginto SSL handshake.
In-Reply-To: <20171229.183414.1279570989098595096.levitte@openssl.org>
References: <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>
 <5a463fb0.5412620a.a6c3a.b009@mx.google.com>
 <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>
 <20171229.183414.1279570989098595096.levitte@openssl.org>
Message-ID: <87AA8BE3-4C71-4322-A615-E2BF5AD12B4B@dukhovni.org>



> On Dec 29, 2017, at 12:34 PM, Richard Levitte <levitte at openssl.org> wrote:
> 
> Marty, you might want to consider that the values of western society
> are hardly universal.  Comic Sans isn't as badly seen everywhere, and
> there's no reason why western society biases should trump any other.

My issue with the post was that it was just too difficult to read,
largely as a result of the font.  So I just deleted it and moved on.
So this has little to do with Western vs. non-Western values.  Written
communication is most clear when the fonts don't get in the way of the
content.  Decorative fonts are for party announcements and the like,
usually in large print on physical posters.

-- 
	Viktor.


From openssl at jordan.maileater.net  Fri Dec 29 17:11:25 2017
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Fri, 29 Dec 2017 09:11:25 -0800
Subject: [openssl-users] How to form a proper hash after writing
 somethinginto SSL handshake.
In-Reply-To: <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>
References: <5a424644.8230620a.c89bf.4e27@mx.google.com>
 <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>
 <5a463fb0.5412620a.a6c3a.b009@mx.google.com>
 <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>
Message-ID: <01e722af-ef06-c1c9-cf1f-c2adf213db17@jordan.maileater.net>

On 12/29/2017 6:00 AM, Marty G wrote:
> For the same reason one doesn't wear a halloween costume to a
> technical meeting, Comic Sans is looked down upon when used outside
> comics and day-care centers.? It is considered a snub to use it in
> non-trivial settings.
>
> Much as lifting up your middle finger has no inherent meaning per se,
> but once one realizes that it definitely has meaning to others and one
> lifts one's middle finger to others anyway, it can only be assumed
> that one has intended to send the message others have assigned to it.?
> So, for whatever vague societal reasons, comic sans has become
> equivalent to wearing a speedo to a formal wedding, giggling
> hysterically during one's performance review, or skipping around the
> track in a tu-tu and clownface during the 440 meter track event at the
> Olympics.? Those are the breaks!? Sorry for your loss of a connotation
> free comic sans.? I feel your pain.? Herd dynamics can be brutal and
> bleak.
>
> http://knowyourmeme.com/memes/comic-sans
> "...While adequate for certain industry sectors like childcare and
> entertainment, its usage in business or professional settings has been
> criticized by many aesthetic-conscious Internet users, who say Comic
> Sans conveys silliness and irreverence that is hardly suitable for
> serious matters....:

Committing a fashion faux pas may be gauche, but pointing and laughing
is even more so.? If you think that somebody's choice of fashion is
inappropriate, keep it to yourself or an appropriate gossip forum.?
Congratulations, you've just convinced this newcomer that the
openssl-users group is populated by fashionistas rather than serious
technical people.

The original poster had a technical question.? I don't know enough to
answer it, or I would.? Could somebody who *does* know enough please
take a stab?

Saiteja, one suggestion:? when an error occurs, don't just report that
there was a problem.? Report what the problem was.? Don't these
functions set the results that SSL_get_error( ) returns?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171229/2e9c30ca/attachment.html>

From Michael.Wojcik at microfocus.com  Fri Dec 29 18:34:34 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 29 Dec 2017 18:34:34 +0000
Subject: [openssl-users] Can't build OpenSSL on Windows
In-Reply-To: <20171229.181404.780642950361658869.levitte@openssl.org>
References: <20171229.000641.1297349608194041259.levitte@openssl.org>
 <20171229145927.2201-1-martin@eclypsium.com>
 <20171229.181404.780642950361658869.levitte@openssl.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AF4C16@prvxmb04.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Richard Levitte
> Sent: Friday, December 29, 2017 12:14
> 
> If any of those are newer, 'nmake' will
> automatically reconfigure and ask you to run again.

It's also worth noting that nmake's dependency-graph generation is flaky (possibly due to flaws in Windows file timestamping, though I've never tracked down the exact cause). I have a number of nmake files that regularly rebuild things unnecessarily, and others that sporadically do.

So as Richard said, check the time on the machine and try running nmake again. Sometimes it's worth temporarily throttling the CPU to slow the build down a bit.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From Michael.Wojcik at microfocus.com  Fri Dec 29 18:34:35 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 29 Dec 2017 18:34:35 +0000
Subject: [openssl-users] How to form a proper hash after writing
 somethinginto SSL handshake.
In-Reply-To: <87AA8BE3-4C71-4322-A615-E2BF5AD12B4B@dukhovni.org>
References: <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>
 <5a463fb0.5412620a.a6c3a.b009@mx.google.com>
 <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>
 <20171229.183414.1279570989098595096.levitte@openssl.org>
 <87AA8BE3-4C71-4322-A615-E2BF5AD12B4B@dukhovni.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AF4C19@prvxmb04.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Friday, December 29, 2017 13:04
> 
> > On Dec 29, 2017, at 12:34 PM, Richard Levitte <levitte at openssl.org> wrote:
> >
> > Marty, you might want to consider that the values of western society
> > are hardly universal.  Comic Sans isn't as badly seen everywhere, and
> > there's no reason why western society biases should trump any other.
> 
> My issue with the post was that it was just too difficult to read,
> largely as a result of the font.  So I just deleted it and moved on.
> So this has little to do with Western vs. non-Western values.  Written
> communication is most clear when the fonts don't get in the way of the
> content.  Decorative fonts are for party announcements and the like,
> usually in large print on physical posters.

Indeed. This has little to do with "the values of western society", or the values of any other community. (Nor, with apologies to Richard, does it have much to do with the OpenSSL mailing-list code of conduct; the messages on this topic have ranged from curt to civil, but none have been abusive under any reasonable definition.)

It has to do with appealing to the intended audience, which of course is one of the most critical aspects of writing. I could cite thousands of years of rhetorical theory - from cultures European and otherwise - but this is such a commonplace that there's no need. Marty's message was a useful, generous, and polite response to Saiteja's query. And while his examples were culturally specific, his argument was not.

That said, I suspect the larger reason why Saiteja has not had a technical response to the original query is that few people on openssl-users have experience with using the WPACKET API and other low-level operations in the 1.1 codebase. It still might be worth reposting without the controversial styling.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From openssl-users at dukhovni.org  Fri Dec 29 18:47:22 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 29 Dec 2017 13:47:22 -0500
Subject: [openssl-users] How to form a proper hash after writing
 somethinginto SSL handshake.
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801A9AF4C19@prvxmb04.microfocus.com>
References: <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>
 <5a463fb0.5412620a.a6c3a.b009@mx.google.com>
 <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>
 <20171229.183414.1279570989098595096.levitte@openssl.org>
 <87AA8BE3-4C71-4322-A615-E2BF5AD12B4B@dukhovni.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AF4C19@prvxmb04.microfocus.com>
Message-ID: <0A8BAAF3-8C0D-4BB7-A395-30EA29E7B60A@dukhovni.org>



> On Dec 29, 2017, at 1:34 PM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
> 
> That said, I suspect the larger reason why Saiteja has not had a technical response to the original query is that few people on openssl-users have experience with using the WPACKET API and other low-level operations in the 1.1 codebase. It still might be worth reposting without the controversial styling.

More importantly, what problem is the OP really trying to solve?

The WPACKET interface is an internal interface that does not
appear in any public OpenSSL headers.  It is undocumented and
subject to change without notice.  The OP should not be using
this interface, except as part of a code contribution to improve
the implementation of TLS in the OpenSSL library.

-- 
	Viktor.


From asteja.chowdary.ece13 at iitbhu.ac.in  Sat Dec 30 02:44:27 2017
From: asteja.chowdary.ece13 at iitbhu.ac.in (Sai Teja Chowdary)
Date: Sat, 30 Dec 2017 08:14:27 +0530
Subject: [openssl-users] How to form a proper hash after writing
 somethinginto SSL handshake.
In-Reply-To: <0A8BAAF3-8C0D-4BB7-A395-30EA29E7B60A@dukhovni.org>
References: <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>
 <5a463fb0.5412620a.a6c3a.b009@mx.google.com>
 <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>
 <20171229.183414.1279570989098595096.levitte@openssl.org>
 <87AA8BE3-4C71-4322-A615-E2BF5AD12B4B@dukhovni.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AF4C19@prvxmb04.microfocus.com>
 <0A8BAAF3-8C0D-4BB7-A395-30EA29E7B60A@dukhovni.org>
Message-ID: <CAKyT-XEx3jCGh21QV8ahevHsWkbX9aktJH9w5Z+zjxLg6=vWFA@mail.gmail.com>

Hi everyone,

I apologize for Comic Sans. And honestly I didn't know using it implies
this many impressions. As I said my other subscription named "Ananthaneni
Saiteja Chowdary" is my outlook account that i use for my office
work(because I am using a QHD resolution my fonts are so small so i
selected the font that looks good for me to read.)  I actually posted two
questions one from this email and other from outlook account. This question
was actually posted through my outlook account in the beginning, and just
as a followup and to include some more information in my question I thought
of asking the question again. So I copied the contents of my previous mail
and added few more info at the end in my Mail app, unfortunately the font
got changed to comic sans. Its not that i knowingly changed the font to
impress or insult. I am a non native English speaker and I sometimes don't
understand the exact emotion or feeling in non-technical conversation.

I am using OpenSSL client to create a custom TLS client which can send or
manipulate the default TLS handshake messages so that i can test for any
bugs in our TLS server implementation. I spent about 4 months in reading
OpenSSL code and making changes and adding new arguments to modify the
default client. So in that process i came across the WPACKET API. For
framing SSL records I had to use it.

I will post the question again in a new thread. Please take a look at it
and help me out.

Regards

Saiteja.

On Sat, Dec 30, 2017 at 12:17 AM, Viktor Dukhovni <
openssl-users at dukhovni.org> wrote:

>
>
> > On Dec 29, 2017, at 1:34 PM, Michael Wojcik <
> Michael.Wojcik at microfocus.com> wrote:
> >
> > That said, I suspect the larger reason why Saiteja has not had a
> technical response to the original query is that few people on
> openssl-users have experience with using the WPACKET API and other
> low-level operations in the 1.1 codebase. It still might be worth reposting
> without the controversial styling.
>
> More importantly, what problem is the OP really trying to solve?
>
> The WPACKET interface is an internal interface that does not
> appear in any public OpenSSL headers.  It is undocumented and
> subject to change without notice.  The OP should not be using
> this interface, except as part of a code contribution to improve
> the implementation of TLS in the OpenSSL library.
>
> --
>         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/20171230/d8e1ad00/attachment.html>

From asteja.chowdary.ece13 at iitbhu.ac.in  Sat Dec 30 03:18:16 2017
From: asteja.chowdary.ece13 at iitbhu.ac.in (Sai Teja Chowdary)
Date: Sat, 30 Dec 2017 08:48:16 +0530
Subject: [openssl-users] How to form a proper hash after writing something
	into SSL handshake.(Revised)
Message-ID: <CAKyT-XGHagJwH=XhVJxCAp=TtNzrg7=XY8MiQ5i1Xn7sE+3dFQ@mail.gmail.com>

Hi everyone,

I want to send client certificate, client key exchange and client verify in
a single handshake message which appears as multiple handshake messages in
a single record. But to sent the client verify I need to first make a hash
of previous messages(client certificate and client key exchange) to create
the signature. I tried framing the record with above three messages and
then directly sending the record in the wire using SSL3_write_machine()
which is giving me Bad signature error. So i thought of doing a hash of
client certificate and client key exchange messages that go before client
verify.

Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX xxxx
(or right procedure that needs to be done before creating a certificate
verify message)that can do a proper transcript(digest or hash not clear). I
tried using ssl3_finish_mac() on the message containing client certificate
and client key exchange and then tried to generate the signature in
certificate verify message.

But it is giving me a digest check error. I am new to the mailing list want
a bit of help to proceed forward stuck here. Please reply in case if
anything is not clear.

Here is a code snippet, how I am forming the data containing all client
certificate , client key exchange and certificate verify messages inside
write_state_machine().

*if(WPACKET_init(&pkt, s->init_buf)){*
*//Client certificate formation*
*             if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL &&
!confunc(s,&pkt) ||         !ssl_close_construct_packet(s,&pkt,mt)){*
*                  printf("PROBLEM 1\n");*
*                }*
*             transition(s);  //transition to next state i.e client key
exchange*
*             get_construct_message_f(s, &pkt, &confunc, &mt);*
*//client key exchange formation*
*             if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL &&
!confunc(s,&pkt) ||         !ssl_close_construct_packet(s,&pkt,mt)){*
*                   printf("PROBLEM 2\n");*
*                }*
*//ssl3_finish_mac(s, &s->init_buf->data[s->init_off], s->init_num);*
*             st->write_state_work = post_work(s, st->write_state_work);*
*             transition(s);  // transition to next state i.e  certificate
verify*
*             get_construct_message_f(s, &pkt, &confunc, &mt);*
*//certificate verify message formation.*
*             if(!ssl_set_handshake_header(s,&pkt,mt) || confunc != NULL &&
!confunc(s,&pkt) ||
!ssl_close_construct_packet(s,&pkt,mt)){*
*                   printf("PROBLEM 3\n");*
*                }*
*             WPACKET_finish(&pkt);*
*}*

I also tried to do a ssl3_finish_mac() individually after forming Client
certificate and client key exchange (this part is not there in the code but
that way also gave me digest check error.)

Here is the stackoverflow link that i posted the question in. Take a look
at it for the trace snapshot for handshake message that I am trying to form.

Please take a look at it, appreciate every bit of help.

Jordan, thanks for the suggestion i will definitely try to state the error
now on. I am not sure whether SSL_get_error() logs these errors, i tried to
print SSL_get_error() it is returning NULL.

Regards
Saiteja.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171230/277cbe91/attachment.html>

From openssl-users at dukhovni.org  Sat Dec 30 05:17:12 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 30 Dec 2017 00:17:12 -0500
Subject: [openssl-users] How to form a proper hash after writing
 something into SSL handshake.(Revised)
In-Reply-To: <CAKyT-XGHagJwH=XhVJxCAp=TtNzrg7=XY8MiQ5i1Xn7sE+3dFQ@mail.gmail.com>
References: <CAKyT-XGHagJwH=XhVJxCAp=TtNzrg7=XY8MiQ5i1Xn7sE+3dFQ@mail.gmail.com>
Message-ID: <A2D6715E-F8A8-4B06-BB7E-67A232DA75D8@dukhovni.org>



> On Dec 29, 2017, at 10:18 PM, Sai Teja Chowdary <asteja.chowdary.ece13 at iitbhu.ac.in> wrote:
> 
> I want to send client certificate, client key exchange and client verify in a single handshake message which appears as multiple handshake messages in a single record. But to sent the client verify I need to first make a hash of previous messages(client certificate and client key exchange) to create the signature. I tried framing the record with above three messages and then directly sending the record in the wire using SSL3_write_machine() which is giving me Bad signature error. So i thought of doing a hash of client certificate and client key exchange messages that go before client verify.
> 
> Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX xxxx (or right procedure that needs to be done before creating a certificate verify message)that can do a proper transcript(digest or hash not clear). I tried using ssl3_finish_mac() on the message containing client certificate and client key exchange and then tried to generate the signature in certificate verify message.

There is no such feature, and none is likely to ever be offered.
The reason is that you're essentially trying to write your own
TLS implementation, and SSL library in OpenSSL is provides public
interfaces for SSL users, not for new SSL implementations.

You can of course build your OpenSSL implementation based on the
OpenSSL source code, but figuring out how the code works is then
up to you. :-(

-- 
	Viktor.


From Michael.Wojcik at microfocus.com  Sat Dec 30 17:17:15 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Sat, 30 Dec 2017 17:17:15 +0000
Subject: [openssl-users] How to form a proper hash after writing
 somethinginto SSL handshake.
In-Reply-To: <CAKyT-XEx3jCGh21QV8ahevHsWkbX9aktJH9w5Z+zjxLg6=vWFA@mail.gmail.com>
References: <CAHu1Y73yUvwe+92uRf5ky+-fxcaavPTjEeq9LwS8zDXh5RPiig@mail.gmail.com>
 <5a463fb0.5412620a.a6c3a.b009@mx.google.com>
 <7d7e5da5-7ddb-4278-987b-21ce9f7b3cfb@gmail.com>
 <20171229.183414.1279570989098595096.levitte@openssl.org>
 <87AA8BE3-4C71-4322-A615-E2BF5AD12B4B@dukhovni.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801A9AF4C19@prvxmb04.microfocus.com>
 <0A8BAAF3-8C0D-4BB7-A395-30EA29E7B60A@dukhovni.org>
 <CAKyT-XEx3jCGh21QV8ahevHsWkbX9aktJH9w5Z+zjxLg6=vWFA@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801A9AF4DCA@prvxmb04.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Sai Teja Chowdary
> Sent: Friday, December 29, 2017 21:44

> I am using OpenSSL client to create a custom TLS client which can send or manipulate the default TLS handshake
> messages so that i can test for any bugs in our TLS server implementation. I spent about 4 months in reading OpenSSL
> code and making changes and adding new arguments to modify the default client. So in that process i came across the
> WPACKET API. For framing SSL records I had to use it.?

I can't help with your specific issue. I don't know the 1.1.x codebase (my teams are still using 1.0.2). But I'd suggest that perhaps OpenSSL is not the ideal starting point for this.

When security researchers do this sort of thing - generate specific TLS messages to test a peer implementation - they often use a scripting language with suitable add-on modules, such as Python with the ssl, cryptography, and gmpy2 modules. While these scripts are often quick-and-dirty, they're probably easier to modify. So you might look at various open-source TLS test scripts, such as the one Hanno B?ck wrote for ROBOT (see robotattack.org).

There are also various open-source test frameworks for TLS, such as TLSPretense. I don't have any experience with them myself, but it's worth taking a look.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus