RE: ungrade openssl 3.0.2 to 3.0.7

[Dr. Matthias St. Pierre via openssl-users]

Anupam,

please don’t attempt to install an openssl version which you built yourself to 
your Linux system, it might brake your applications. Your Linux distribution 
(Ubuntu) installs their own compiled versions  which you can upgrade using its 
package manager (apt)

Regards,

Matthias


From: openssl-users  On Behalf Of Anupam 
Dutta via openssl-users
Sent: Wednesday, November 2, 2022 9:12 AM
To: openssl-users@openssl.org
Subject: ungrade openssl 3.0.2 to 3.0.7

Hi Team,

I want to upgrade openssl from 3.0.2 to 3.0.7. I have downloaded 3.0.7 from 
https://www.openssl.org/source and installed successfully. But, still it is 
showing version 3.0.2.Please help. It's urgent.

My OS: 22.04.1 LTS (Jammy Jellyfish)

Regards,
Anupam


smime.p7s
Description: S/MIME cryptographic signature

RE: Test failure for 1.1.1p - 10-test_bn

[Dr. Matthias St. Pierre]

My guess is that the loop is caused by one of the commits 0ed27fb7a8  and 
8438d3a7b7.
Would you mind to (a) check whether that's correct and which one of the two 
commits
causes the problem, and (b) raise a GitHub issue for it?

Matthias


~/src/openssl/1.1.1$ git log --oneline --stat OpenSSL_1_1_1o..OpenSSL_1_1_1p -- 
crypto/bn
a3fc812c0c (security/OpenSSL_1_1_1-stable) Update copyright year
 crypto/bn/asm/x86_64-mont5.pl | 2 +-
 crypto/bn/rsaz_exp.c  | 2 +-
 crypto/bn/rsaz_exp.h  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

8438d3a7b7 Add an extra reduction step to RSAZ mod_exp implementations
 crypto/bn/rsaz_exp.c |  8 
 crypto/bn/rsaz_exp.h | 23 +++
 2 files changed, 31 insertions(+)

0ed27fb7a8 Always end BN_mod_exp_mont_consttime with normal Montgomery 
reduction.
 crypto/bn/asm/x86_64-mont5.pl | 196 
--
 crypto/bn/bn_exp.c|  44 +++
 2 files changed, 26 insertions(+), 214 deletions(-)



> -Original Message-
> From: openssl-users  On Behalf Of 
> rsbec...@nexbridge.com
> Sent: Wednesday, June 22, 2022 1:40 AM
> To: openssl-users@openssl.org
> Subject: Test failure for 1.1.1p - 10-test_bn
>
> Our test process for 10-test_bn went into a hard loop when building using
> IEEE float. This has not happened in prior tests or when using platform
> floating point (default). The situation does not occur in 3.0.4 - only
> 1.1.1p. At 1.1.1o there was no issue. I am concerned that there are
> assumptions made relating to BN processing with this change but do not know
> enough about the Montgomery structures to be able to isolate the cause of
> this.
>
> This happens on the big-endian NonStop x86 platform.
>

smime.p7s
Description: S/MIME cryptographic signature

RE: Legal : guide to sign cla. has legal mail a PGP key ?

[Dr. Matthias St. Pierre]

FWIW: it's the final / after 'licenses' which causes the problem.

The OpenSSL Software Foundation
Individual Contributor License Agreement ("Agreement") v1.0
https://www.openssl.org/licenses/

Apparently, there is a simple rewrite rule on the server, which fails to remove 
the trailing slash.

https://www.openssl.org/policies/cla.html/

If you remove the trailing slash, the link works.

The OpenSSL Software Foundation
Individual Contributor License Agreement ("Agreement") v1.0
https://www.openssl.org/licenses


IMHO, both the rewrite rule as well as the link in the ICLA/CCLA document 
should be fixed.

https://www.openssl.org/policies/openssl_icla.pdf


Matthias

> -Original Message-
> From: openssl-users  On Behalf Of pl
> Sent: Wednesday, April 27, 2022 10:14 PM
> To: openssl-users@openssl.org
> Subject: Legal : guide to sign cla. has legal mail a PGP key ?
> 
> Hi,
> 
> After a pull request to github for openssl demos sslecho i was requested
> to sign a cla since my change
> was considered non trivial.
> 
> Using https://www.openssl.org/policies/openssl_icla.pdf as a libreoffice
> input i did recreate a pdf. One remark here, the url wihtin document
> https://www.openssl.org/licenses/ leads to an existing page.
> 
> I wanted to send it ciphered since it contains personal information but
> didn't find a gpg key for legal at opensslfoundation.org, is there any ?
> If no what is the secure procedure to use to stay within digital
> boundaries ?
> 
> Regards,
> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

RE: RSA and DES encryption and decryption with C++ on Windows

[Dr. Matthias St. Pierre]

Pauli accidentally posted a link to our internal repository. You can jost 
replace githuib.openssl.org by github.com:


https://github.com/openssl/openssl/tree/master/demos/encrypt


Matthias


From: openssl-users  On Behalf Of John Alway
Sent: Monday, April 11, 2022 7:06 PM
Cc: openssl-users@openssl.org
Subject: Re: RSA and DES encryption and decryption with C++ on Windows

Pauli,

Thanks for the link, but apparently that code requires having an account to 
view it.

However, I've passed the information from this thread onto the guy I'm working 
with and he's going to reevaluate what he wants to do.

Regards,
...John

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png]

Virus-free. 
www.avg.com


On Sun, Apr 10, 2022 at 5:52 PM Dr Paul Dale 
mailto:pa...@openssl.org>> wrote:
Have a look in the demos/encrypt folder: 
https://github.openssl.org/openssl/openssl/tree/master/demos/encrypt

There has been an amount of effort put into updating these for 3.0 & later.  
There is more to do.


Pauli
On 10/4/22 23:50, Kenneth Goldman wrote:

Anyway, I'm trying to encrypt/decrypt using RSA and DES schemes.  I've tried 
some of the older code examples I could find, but some of the functions weren't 
recognized by my header files.
[kgold] You cannot encrypt long streams with RSA.  DES is deprecated.

Can anyone help me with this?  I want to encrypt fairly long strings.  A few 
hundred bytes or so.   Maybe longer.  If I can do a continuous stream of blocks 
that would be great, as well.


[kgold] Post a short example that did not work.







smime.p7s
Description: S/MIME cryptographic signature

RE: looking for properly configured Windows VMs

[Dr. Matthias St. Pierre]

> I see lots of logs.
> Maybe it's private to me.

The link is not private, but it expires after a short amount of time. The 
timeout is visible in the URL (after url-decoding it):


...?urlExpires=2022-04-02T15:36:04.2664486Z&urlSigningMethod=HMACV1&urlSignature=J9eXW05FxMynRtIZFhvnWKNDCJtYBmnlPPcMQe5jPj0=

smime.p7s
Description: S/MIME cryptographic signature

RE: SSL_ERROR_WANT_READ after the handshake

[Dr. Matthias St. Pierre]

FWIW: I noticed recently, that in TLSv1.3 it seems to be rather normal to 
encounter an SSL_WANT_READ immediately
after returning from a successful SSL_connect() call (even in the blocking 
case), because part of the handshake is disguised
as application data and apparently SSL_connect() returns before the entire 
handshake has completed, see [issue #17654].

[issue #17654]: https://github.com/openssl/openssl/issues/17654

From: openssl-users  On Behalf Of loic 
nicolas
Sent: Sunday, March 13, 2022 12:08 AM
To: openssl-users@openssl.org
Subject: SSL_ERROR_WANT_READ after the handshake

Hello,

I use my own bios and non-blocking sockets.

After the handshake, is it really necessary to check SSL_ERROR_WANT_READ and 
SSL_ERROR_WANT_WRITE? (whether on the server or client side)
I don't want to accept a renegotiation, is it really possible that OpenSSL 
sends me these events without them being linked to a renegotiation?

I did several tests on more or less long connections and I never receive them 
but I would like to be sure.

Thank you

smime.p7s
Description: S/MIME cryptographic signature

RE: Upgrade openssl 1.0.2 to 1.1.1 guideline

[Dr. Matthias St. Pierre]

The following wiki page might serve as a starting point:

https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes

HTH,
Matthias


> -Original Message-
> From: openssl-users  On Behalf Of Yan, Bob 
> via openssl-users
> Sent: Tuesday, March 8, 2022 5:48 PM
> To: openssl-users@openssl.org
> Subject: Upgrade openssl 1.0.2 to 1.1.1 guideline
> 
> Hi All,
> 
> Is there any guideline for upgrading openssl version from 1.0.2 to 1.1.1?
> 
> Thanks
> Bob
> 


smime.p7s
Description: S/MIME cryptographic signature

RE: How run the specific test case //答复: How to run a simple test case

[Dr. Matthias St. Pierre]

The problem lies with the Perl script, not the C program.

The perl script generates the file 17-renegotiate.cnf.default from the template 
file  17-renegotiate.cnf.in.
The environment variable “${ENV::TEST_CERTS_DIR}” should have been replaced by 
Perl.

Please open an issue on GitHub, it’s easier to discuss your problem there. You 
might want to tag @levitte, he should be able to help.

https://github.com/openssl/openssl/issues/new/choose


Matthias



smime.p7s
Description: S/MIME cryptographic signature

RE: How run the specific test case //答复: How to run a simple test case

[Dr. Matthias St. Pierre]

Ah ok, maybe I slightly misunderstood your question. From your transcript I 
infer that the testsuite ran the perl script `generate_ssl_tests.pl`, which 
generated some test files an then ran the binary `ssl_test` as follows:

./test/ssl_test ./test-runs/test_ssl_new/17-renegotiate.cnf.default

If the testfile `./test-runs/test_ssl_new/17-renegotiate.cnf.default` still 
exists, you should be able to debug the program in gdb with the aid of the 
`wrap.pl` helper script as follows:

./util/wrap.pl  gdb –args ./test/ssl_test 
./test-runs/test_ssl_new/17-renegotiate.cnf.default


Hope that helps,

Matthias



smime.p7s
Description: S/MIME cryptographic signature

RE: How to run a simple test case

[Dr. Matthias St. Pierre]

The README file in the test directory contains a detailed explanation.

https://github.com/openssl/openssl/blob/master/test/README.md

In a nutshell, you run `make test`, passing  `V=1` to turn on verbose output 
and `TESTS=...` to select one or more tests:

make V=1  TESTS=  test


HTH,
Matthias




From: openssl-users  On Behalf Of 
Chenxinping via openssl-users
Sent: Wednesday, February 9, 2022 4:49 AM
To: openssl-users@openssl.org
Subject: How to run a simple test case

The config file have some ENV variable and will result fail to load the config 
file, How to run a simple test case?
Example:
./test/ssl_test ./test-runs/test_ssl_new/17-renegotiate.cnf.default
ERROR:  @ test/ssl_test.c:553

smime.p7s
Description: S/MIME cryptographic signature

RE: Confusion Configuring

[Dr. Matthias St. Pierre]

Hal,

I just reread your initial post and noticed that my explanation is somewhat 
inconsistent
with your observations, since in your case the system openssl prints the 
expected path.

Nevertheless, using

util/wrap.pl apps/openssl  ...

is the correct way to test your self-built application. And with the given 
information,
you should be able to figure out what precisely happens in your original case 
using
ldd an/or strace.

Matthias


> -Original Message-
> From: openssl-users  On Behalf Of Dr. 
> Matthias St. Pierre
> Sent: Saturday, December 18, 2021 9:20 AM
> To: Hal Murray ; openssl-users@openssl.org
> Subject: RE: Confusion Configuring
>
> For OpenSSL 3.0, it's better to use  util/wrap.pl instead.
>
> (Note: util/wrap.pl is created from util/wrap.pl.in by the Configure command)
>
> > -Original Message-
> > From: openssl-users  On Behalf Of Dr. 
> > Matthias St. Pierre
> > Sent: Saturday, December 18, 2021 9:11 AM
> > To: Hal Murray ; openssl-users@openssl.org
> > Subject: RE: Confusion Configuring
> >
> > Hal,
> >
> > > But when I run
> > >   ./apps/openssl version -d
> > > it says:
> > >   OPENSSLDIR: "/usr/local/ssl"
> > > I was expecting /etc/pki/tls from the Configure line above.
> > >
> > > What am I missing?  How do I tell it where to find the default 
> > > certificates?
> >
> > It is very likely that your binary is actually loading the system's shared 
> > libraries instead of
> > the ones you just compiled. You can verify whether this using the `ldd` 
> > command, see below.
> >
> > There is a shared library wrapper called `shlib_wrap.sh` which can be used 
> > to run
> > the compiled application correctly without installing it:
> >
> > ## incorrect (without wrapper)
> > msp@msppc:~/src/openssl-1.1.1$ apps/openssl version -d
> > OPENSSLDIR: "/etc/ssl"
> >
> > ## correct (using the wrapper)
> > msp@msppc:~/src/openssl-1.1.1$ util/shlib_wrap.sh apps/openssl version -d
> > OPENSSLDIR: "/opt/openssl-1.1.1-dev/ssl"
> >
> > HTH,
> >
> > Matthias
> >
> >
> >
> >
> > ## ldd output without wrapper
> >
> > msp@msppc:~/src/openssl-1.1.1$ ldd apps/openssl
> > linux-vdso.so.1 (0x7fff05b81000)
> > libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x7f6e46ade000)
> > libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x7f6e4682)
> > libdl.so.2 => /lib64/libdl.so.2 (0x7f6e4681a000)
> > libpthread.so.0 => /lib64/libpthread.so.0 (0x7f6e467fa000)
> > libc.so.6 => /lib64/libc.so.6 (0x7f6e46641000)
> > /lib64/ld-linux-x86-64.so.2 (0x7f6e46c5d000)
> >
> > ## ldd output using the wrapper
> >
> > msp@msppc:~/src/openssl-1.1.1$ util/shlib_wrap.sh ldd apps/openssl
> > linux-vdso.so.1 (0x7ffd2032e000)
> > libssl.so.1.1 => util/../libssl.so.1.1 (0x7f4a34aeb000)
> > libcrypto.so.1.1 => util/../libcrypto.so.1.1 (0x7f4a347a2000)
> > libdl.so.2 => /lib64/libdl.so.2 (0x7f4a34785000)
> > libpthread.so.0 => /lib64/libpthread.so.0 (0x7f4a34765000)
> > libc.so.6 => /lib64/libc.so.6 (0x7f4a345ac000)
> > /lib64/ld-linux-x86-64.so.2 (0x7f4a34c78000)

smime.p7s
Description: S/MIME cryptographic signature

RE: Confusion Configuring

[Dr. Matthias St. Pierre]

For OpenSSL 3.0, it's better to use  util/wrap.pl instead.

(Note: util/wrap.pl is created from util/wrap.pl.in by the Configure command)

> -Original Message-
> From: openssl-users  On Behalf Of Dr. 
> Matthias St. Pierre
> Sent: Saturday, December 18, 2021 9:11 AM
> To: Hal Murray ; openssl-users@openssl.org
> Subject: RE: Confusion Configuring
>
> Hal,
>
> > But when I run
> >   ./apps/openssl version -d
> > it says:
> >   OPENSSLDIR: "/usr/local/ssl"
> > I was expecting /etc/pki/tls from the Configure line above.
> >
> > What am I missing?  How do I tell it where to find the default certificates?
>
> It is very likely that your binary is actually loading the system's shared 
> libraries instead of
> the ones you just compiled. You can verify whether this using the `ldd` 
> command, see below.
>
> There is a shared library wrapper called `shlib_wrap.sh` which can be used to 
> run
> the compiled application correctly without installing it:
>
> ## incorrect (without wrapper)
> msp@msppc:~/src/openssl-1.1.1$ apps/openssl version -d
> OPENSSLDIR: "/etc/ssl"
>
> ## correct (using the wrapper)
> msp@msppc:~/src/openssl-1.1.1$ util/shlib_wrap.sh apps/openssl version -d
> OPENSSLDIR: "/opt/openssl-1.1.1-dev/ssl"
>
> HTH,
>
> Matthias
>
>
>
>
> ## ldd output without wrapper
>
> msp@msppc:~/src/openssl-1.1.1$ ldd apps/openssl
> linux-vdso.so.1 (0x7fff05b81000)
> libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x7f6e46ade000)
> libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x7f6e4682)
> libdl.so.2 => /lib64/libdl.so.2 (0x7f6e4681a000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f6e467fa000)
> libc.so.6 => /lib64/libc.so.6 (0x7f6e46641000)
> /lib64/ld-linux-x86-64.so.2 (0x7f6e46c5d000)
>
> ## ldd output using the wrapper
>
> msp@msppc:~/src/openssl-1.1.1$ util/shlib_wrap.sh ldd apps/openssl
> linux-vdso.so.1 (0x7ffd2032e000)
> libssl.so.1.1 => util/../libssl.so.1.1 (0x7f4a34aeb000)
> libcrypto.so.1.1 => util/../libcrypto.so.1.1 (0x7f4a347a2000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7f4a34785000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f4a34765000)
> libc.so.6 => /lib64/libc.so.6 (0x7f4a345ac000)
> /lib64/ld-linux-x86-64.so.2 (0x7f4a34c78000)

smime.p7s
Description: S/MIME cryptographic signature

RE: Confusion Configuring

[Dr. Matthias St. Pierre]

Hal,

> But when I run
>   ./apps/openssl version -d
> it says:
>   OPENSSLDIR: "/usr/local/ssl"
> I was expecting /etc/pki/tls from the Configure line above.
>
> What am I missing?  How do I tell it where to find the default certificates?

It is very likely that your binary is actually loading the system's shared 
libraries instead of
the ones you just compiled. You can verify whether this using the `ldd` 
command, see below.

There is a shared library wrapper called `shlib_wrap.sh` which can be used to 
run
the compiled application correctly without installing it:

## incorrect (without wrapper)
msp@msppc:~/src/openssl-1.1.1$ apps/openssl version -d
OPENSSLDIR: "/etc/ssl"

## correct (using the wrapper)
msp@msppc:~/src/openssl-1.1.1$ util/shlib_wrap.sh apps/openssl version -d
OPENSSLDIR: "/opt/openssl-1.1.1-dev/ssl"

HTH,

Matthias




## ldd output without wrapper

msp@msppc:~/src/openssl-1.1.1$ ldd apps/openssl
linux-vdso.so.1 (0x7fff05b81000)
libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x7f6e46ade000)
libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x7f6e4682)
libdl.so.2 => /lib64/libdl.so.2 (0x7f6e4681a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f6e467fa000)
libc.so.6 => /lib64/libc.so.6 (0x7f6e46641000)
/lib64/ld-linux-x86-64.so.2 (0x7f6e46c5d000)

## ldd output using the wrapper

msp@msppc:~/src/openssl-1.1.1$ util/shlib_wrap.sh ldd apps/openssl
linux-vdso.so.1 (0x7ffd2032e000)
libssl.so.1.1 => util/../libssl.so.1.1 (0x7f4a34aeb000)
libcrypto.so.1.1 => util/../libcrypto.so.1.1 (0x7f4a347a2000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f4a34785000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f4a34765000)
libc.so.6 => /lib64/libc.so.6 (0x7f4a345ac000)
/lib64/ld-linux-x86-64.so.2 (0x7f4a34c78000)

smime.p7s
Description: S/MIME cryptographic signature

RE: Enumerating TLS protocol versions and ciphers supported by the peer

[Dr. Matthias St. Pierre]

> Look at 
> https://testssl.sh/

> That is an openssl wrapper which enumerates ciphers and protocols ( and a 
> whole lot more)

Nice tool, I didn’t know it yet. I was already recommended to me by Michael 
Wojcik in his  first reply, but thanks nevertheless for the link.
 
Matthias



smime.p7s
Description: S/MIME cryptographic signature

RE: Enumerating TLS protocol versions and ciphers supported by the peer

[Dr. Matthias St. Pierre]

> "Comparable elegant" is underspecified.

(I guess, "Comparably elegant" would have been grammatically more correct.)

> Perhaps try testssl.sh (https://testssl.sh/)? It has various options for 
> reducing the number and types of tests it runs. We've used it for
> profiling internal TLS-enabled servers.

My question was mainly for educational purpose (since the 'nmap' tool already 
satisfies my needs), but I wanted to know whether the openssl tool
can do same thing with a comparable effort. By this I mean a simple shell 
one-liner (or failing that just a few lines of shell script) utilizing `openssl 
s_client`.
Thanks for the weblink nevertheless.


Matthias



smime.p7s
Description: S/MIME cryptographic signature

Enumerating TLS protocol versions and ciphers supported by the peer

[Dr. Matthias St. Pierre]

Hi all,

today I learned that nmap has a nice feature to enumerate the protocol versions 
and cipher suites supported by the peer (see below).
Is there a comparable elegant way to obtain the same results using the `openssl 
s_client` tool?

Matthias


--

$ nmap -script ssl-enum-ciphers -p 443 www.openssl.org

Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-06 15:05 CET
Nmap scan report for www.openssl.org (96.16.136.61)
Host is up (0.0041s latency).
Other addresses for www.openssl.org (not scanned): 
2a02:26f0:1700:393::c1e 2a02:26f0:1700:380::c1e
rDNS record for 96.16.136.61: a96-16-136-61.deploy.static.akamaitechnologies.com

PORTSTATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|   TLSv1.1:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|   TLSv1.2:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 1.10 seconds

smime.p7s
Description: S/MIME cryptographic signature

RE: Starting the QUIC Design

[Dr. Matthias St. Pierre]

Second attempt 😉

> #17184 - QUIC API Design
> https://github.com/openssl/openssl/pull/17184
> 
> #17185 - QUIC Event Loop Design
> https://github.com/openssl/openssl/pull/17185

> > -Original Message-
> > From: openssl-users  On Behalf Of Matt 
> > Caswell
> > Sent: Friday, December 3, 2021 1:05 PM
> > To: openssl-proj...@openssl.org; openssl-users@openssl.org
> > Subject: Starting the QUIC Design
> >
> > Please see my blog post on starting the QUIC design here:
> >
> > https://www.openssl.org/blog/blog/2021/12/03/starting-the-quic-design/
> >
> > Matt
> >



smime.p7s
Description: S/MIME cryptographic signature

RE: Starting the QUIC Design

[Dr. Matthias St. Pierre]

Sorry, the links to the pull requests are broken. This will be fixed as soon as 
possible.

Here the correct links:

#17184 - QUIC API Design
https://github.com/openssl/openssl/pull/17184

#17185 - QUIC Event Loop Design
https://github.com/openssl/pull/17185


> -Original Message-
> From: openssl-users  On Behalf Of Matt 
> Caswell
> Sent: Friday, December 3, 2021 1:05 PM
> To: openssl-proj...@openssl.org; openssl-users@openssl.org
> Subject: Starting the QUIC Design
> 
> Please see my blog post on starting the QUIC design here:
> 
> https://www.openssl.org/blog/blog/2021/12/03/starting-the-quic-design/
> 
> Matt
> 



smime.p7s
Description: S/MIME cryptographic signature

RE: Queries for openssl

[Dr. Matthias St. Pierre]

Hi,

you can find this sort of information in the manual pages, either on you 
UNIX*SH operating system,
or online on our website:

HTH,
Matthias


https://www.openssl.org/docs/man1.1.1/man3/PEM_read_bio_X509.html:
RETURN VALUES
The read routines return either a pointer to the structure read or NULL if an 
error occurred.

https://www.openssl.org/docs/man1.1.1/man3/d2i_X509_bio.html
RETURN VALUES
d2i_TYPE(), d2i_TYPE_bio() and d2i_TYPE_fp() return a valid TYPE structure or 
NULL if an error occurs. If the "reuse" capability has been used with a valid 
structure being passed in via a, then the object is freed in the event of error 
and *a is set to NULL.
i2d_TYPE() returns the number of bytes successfully encoded or a negative value 
if an error occurs.
i2d_TYPE_bio() and i2d_TYPE_fp() return 1 for success and 0 if an error occurs.




From: openssl-users  On Behalf Of Kumar 
Mishra, Sanjeev
Sent: Wednesday, November 24, 2021 6:37 AM
To: openssl-users@openssl.org
Subject: Queries for openssl

Hi ,

I have two queries to be asked.


  1.  Is there any Api which is used to convert certificates from PEM format to 
DER format?
  2.  Does these two Api's return same value ?( These Api's give NULL when they 
are failing, I need to know if they return same value in success case)
  3.  d2i_X509_bio
  4.  PEM_read_bio_X509

Thanks,
Sanjeev


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

smime.p7s
Description: S/MIME cryptographic signature

RE: useless search box on openssl.org

[Dr. Matthias St. Pierre]

More strangeness: the side bar for the master and 1.1.1 manpage displays the 
text "[an error occurred while processing this directive]"

https://www.openssl.org/docs/manmaster/man3/X509_get_ext_d2i.html
https://www.openssl.org/docs/man1.1.1/man3/X509_get_ext_d2i.html


smime.p7s
Description: S/MIME cryptographic signature

RE: useless search box on openssl.org

[Dr. Matthias St. Pierre]

It's a little bit strange though that according to Google the page was cached 
on 2. Nov 2021, which is only two and a half weeks ago.
Have the manual pages for 1.1.0 been deleted only recently?

https://webcache.googleusercontent.com/search?q=cache:j2DJQRBLHm8J:https://www.openssl.org/docs/man1.1.0/man3/X509_get_ext_d2i.html+&cd=1&hl=de&ct=clnk&gl=de

Matthias

> -Original Message-
> From: openssl-users  On Behalf Of Dr Paul 
> Dale
> Sent: Thursday, November 18, 2021 11:32 PM
> To: openssl-users@openssl.org
> Subject: Re: useless search box on openssl.org
> 
> It would be nice if the search engines checked for URL validity and
> cleaned their caches from time to time.
> 
> Apart from keeping dross around from old unsupported versions, I don't
> think there is much the project can do about this unfortunately.
> 
> 
> Pauli
> 
> On 19/11/21 7:48 am, Michael Richardson wrote:
> > If you go to any page on openssl.org, and using the search box, you enter,
> > say:
> >  X509_get_ext_d2i
> >
> > then you go to:
> >   
> > https://www.google.com/search?sitesearch=www.openssl.org&q=X509_get_ext_d2i
> >
> > which gives me, aas the top link:
> >
> > X509V3_get_d2i - OpenSSLhttps://www.openssl.org › man3 › X509_get_ext_d2i
> > X509V3_get_ext_d2i() looks for an extension with OID nid in the extensions x
> > and, if found, decodes it. If idx is NULL then only one occurrence of an
> > extension ...
> >
> > which is a link to:
> >https://www.openssl.org/docs/man1.1.0/man3/X509_get_ext_d2i.html
> >
> > which is Page Not Found.  I guess because man1.1.1 is now current.
> > With no forwarder.
> >
> >
> >
> >


smime.p7s
Description: S/MIME cryptographic signature

RE: API to get BIGNUM member "top" in openssl 3.0

[Dr. Matthias St. Pierre]

> Can you give a MWE for what you are trying to achieve?

I guess that "minimal working example" is the correct choice from the 
gazillions of possible meanings of "MWE"?   😉

Regards,
Matthias


[1] https://www.acronymattic.com/MWE.html
[2] https://www.abbreviations.com/MWE



smime.p7s
Description: S/MIME cryptographic signature

RE: Testing

[Dr. Matthias St. Pierre]

I’ll take care of it and ask the administrator to remove it manually if 
possible.

From: Kingsley O 
Sent: Thursday, August 26, 2021 3:41 PM
To: Dr. Matthias St. Pierre 
Cc: openssl-users@openssl.org
Subject: Re: Testing

Didn't work..:-(

Did not receive email to complete the unsubscribe process

On Thu, Aug 26, 2021 at 7:50 AM Dr. Matthias St. Pierre 
mailto:matthias.st.pie...@ncp-e.com>> wrote:



To unsubscribe, visit https://mta.openssl.org/mailman/listinfo/openssl-users

Regards



[NCP engingeering GmbH]

Dr. Matthias St. Pierre

Tech Lead Cryptography
matthias.st.pie...@ncp-e.com<mailto:matthias.st.pie...@ncp-e.com>
Phone: +49 911 9968-0
www.ncp-e.com<http://www.ncp-e.com>


Follow us on:
 Facebook<https://www.facebook.com/NCPengineering> | 
Twitter<https://twitter.com/NCP_engineering> | 
Xing<https://www.xing.com/companies/ncpengineeringgmbh> | 
YouTube<https://www.youtube.com/user/NCPengineeringGmbH> | 
LinkedIn<http://www.linkedin.com/company/ncp-engineering-inc.?trk=cws-cpw-coname-0-0>

Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 • 
Nuremberg
North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite 501-25 • 
Clearwater, FL 33755

Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich
Registry Court: Lower District Court of Nuremberg
Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 
133557619

This e-mail message including any attachments is for the sole use of the 
intended recipient(s) and may contain privileged or confidential information. 
Any unauthorized review, use, disclosure or distribution is prohibited. If you 
are not the intended recipient, please immediately contact the sender by reply 
e-mail and delete the original message and destroy all copies thereof.



From: openssl-users 
mailto:openssl-users-boun...@openssl.org>> 
On Behalf Of Kingsley O
Sent: Wednesday, August 25, 2021 6:06 PM
To: Turritopsis Dohrnii Teo En Ming 
mailto:ceo.teo.en.m...@gmail.com>>
Cc: openssl-users@openssl.org<mailto:openssl-users@openssl.org>
Subject: Re: Testing

Please remove my email from this group.

Thank you

On Wed, Aug 25, 2021 at 4:10 PM Turritopsis Dohrnii Teo En Ming 
mailto:ceo.teo.en.m...@gmail.com>> wrote:
Testing


smime.p7s
Description: S/MIME cryptographic signature

RE: Testing

[Dr. Matthias St. Pierre]

To unsubscribe, visit https://mta.openssl.org/mailman/listinfo/openssl-users

Regards

From: openssl-users  On Behalf Of Kingsley O
Sent: Wednesday, August 25, 2021 6:06 PM
To: Turritopsis Dohrnii Teo En Ming 
Cc: openssl-users@openssl.org
Subject: Re: Testing

Please remove my email from this group.

Thank you

On Wed, Aug 25, 2021 at 4:10 PM Turritopsis Dohrnii Teo En Ming 
mailto:ceo.teo.en.m...@gmail.com>> wrote:
Testing


smime.p7s
Description: S/MIME cryptographic signature

RE: How to debug ssl library in OpenSSL 1.1.1a? Thanks in advance.

[Dr. Matthias St. Pierre]

If you add the `--debug` argument to your configure command and rebuild OpenSSL,
you will get a library with debug information and without optimization.

https://github.com/openssl/openssl/blob/master/INSTALL.md#build-type

HTH,
Matthias


From: openssl-users  On Behalf Of Ma Zhenhua
Sent: Saturday, August 14, 2021 6:09 AM
To: openssl-users@openssl.org
Subject: How to debug ssl library in OpenSSL 1.1.1a? Thanks in advance.

Hi Team,

I modified OpenSSL 1.1.1a ssl library but it seemed that there was some problem.
How can I debug it? Thanks in advance.

Sincerely,
Allen

smime.p7s
Description: S/MIME cryptographic signature

RE: Hi team, I modified openssl code and make test failed. What should I do with the failed cases. Thx in advance.

[Dr. Matthias St. Pierre]

The README file in the test directory contains some hints how to troubleshoot 
test failures.
Look which test is failing and rerun it in verbose mode:


   make tests V=1  TESTS=testname

https://github.com/openssl/openssl/blob/master/test/README.md#test-failures


Hope that helps,
Matthias


From: openssl-users  On Behalf Of Ma Zhenhua
Sent: Saturday, August 14, 2021 1:57 AM
To: openssl-users@openssl.org
Subject: Hi team, I modified openssl code and make test failed. What should I 
do with the failed cases. Thx in advance.

Hi team,

I modified openssl code and make test failed. What should I do with the failed 
cases. Thx in advance.

Best regards,
Allen

smime.p7s
Description: S/MIME cryptographic signature

RE: What's different between RSASSA and RSAPSS padding mode?

[Dr. Matthias St. Pierre]

Correction: It seems like the naming of the TPM_ALG_* constants is a little bit 
inconsistent: According to

https://trustedcomputinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry_r1p32_pub.pdf

* TPM_ALG_RSASSA refers to RSASSA-PKCS1-v1_5

and

* TPM_ALG_RSAPSS refers to RSASSA-PSS.



smime.p7s
Description: S/MIME cryptographic signature

RE: What's different between RSASSA and RSAPSS padding mode?

[Dr. Matthias St. Pierre]

It’s the same. The correct full name is RSASSA-PSS, where ‘SSA’ stands for 
Secure Signature Algorithm (IIRC) and ‘PSS’ for Probabilistic Signature Scheme

Regards

https://en.wikipedia.org/wiki/PKCS_1#Schemes
https://datatracker.ietf.org/doc/html/rfc4056



From: openssl-users  On Behalf Of Eddie Chang
Sent: Wednesday, May 12, 2021 2:46 AM
To: openssl-users@openssl.org
Subject: What's different between RSASSA and RSAPSS padding mode?

Hi:
  I'm new comer to openssl. Recently, I study SPDM document 
https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_0.99a.pdf 
and feel confused about ReqBaseAsymAlg structure in page 49.
In this spec, I saw it can support RSASSA_4096 and RSAPSS_4096. But I check 
opensl source code,  rsa_padding_mode option only support pss padding. Don't 
have any idea about RSASSA.
Anyonce can please help to comemnt what different between RSASSA and RSAPSS is?

For testting, I can specify PSS padding with SHA256 digest for sign and 
verfiifcation as below command.
openssl dgst -sha512 -binary  -out sha512_out.bin  test.bin
openssl pkeyutl -sign -in sha512_out.bin -inkey gv100_rsa_3072_pvt_dbg.pem -out 
sig1.bin -pkeyopt digest:sha512 -pkeyopt rsa_padding_mode:pss -pkeyopt 
rsa_pss_saltlen:-1
openssl pkeyutl -verify -in sha512_out.bin -sigfile sig1.bin  -pkeyopt 
digest:sha512  -pkeyopt rsa_padding_mode:pss -pkeyopt rsa_pss_saltlen:-1 -pubin 
-inkey gv100_rsa_3072_pub_dbg.pem

But don't know how to test RSASSA.

Thanks
Byte 0 Bit 5. TPM_ALG_RSASSA_4096
Byte 0 Bit 6. TPM_ALG_RSAPSS_4096

--- 本郵件來自HiNet WebMail ---


smime.p7s
Description: S/MIME cryptographic signature

RE: configuration options 'fips' and 'makedepend' disabled by default on master

[Dr. Matthias St. Pierre]

The 'fips' option is now disabled by default.

For the 'makedepend' option, several people raised concerns whether the 
disadvantages of disabling it
wouldn't outweigh the performance gain at build time, see discussion in pull 
request #15050.
So I decided to drop pull request, the 'makedepend' option remains enabled by 
default.

Matthias


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



> -Original Message-
> From: openssl-users  On Behalf Of Dr. 
> Matthias St. Pierre
> Sent: Tuesday, April 27, 2021 9:50 PM
> To: openssl-users@openssl.org
> Subject: configuration options 'fips' and 'makedepend' disbled by default on 
> master
>
> Just a short heads-up to all users testing and developing for OpenSSL 3.0:
>
> The defaults for the configuration options 'fips' and 'makepend' are going to 
> change on the master branch soon
> (i.e., before the release of 3.0.0 alpha16): they will be disabled by default.
>
> If your developer workflow or your continuous integration relies on one of 
> those options, now it's a good time
> to enable them explicitly by adding 'enable-fips' resp. 'enable-makedepend' 
> to your configure arguments.
>
> Regards,
> Matthias
>
>
> disable fips: 
> https://github.com/openssl/openssl/pull/13684/commits/b76c7c2513384013f4edd5ed39f7175adbc8aaca
> disable makedepend: 
> https://github.com/openssl/openssl/pull/15050/commits/40a85b61d0b8344941b751d6e34d752a7d8e0827

smime.p7s
Description: S/MIME cryptographic signature

configuration options 'fips' and 'makedepend' disbled by default on master

[Dr. Matthias St. Pierre]

Just a short heads-up to all users testing and developing for OpenSSL 3.0:

The defaults for the configuration options 'fips' and 'makepend' are going to 
change on the master branch soon
(i.e., before the release of 3.0.0 alpha16): they will be disabled by default.

If your developer workflow or your continuous integration relies on one of 
those options, now it's a good time
to enable them explicitly by adding 'enable-fips' resp. 'enable-makedepend' to 
your configure arguments.

Regards,
Matthias


disable fips: 
https://github.com/openssl/openssl/pull/13684/commits/b76c7c2513384013f4edd5ed39f7175adbc8aaca
disable makedepend: 
https://github.com/openssl/openssl/pull/15050/commits/40a85b61d0b8344941b751d6e34d752a7d8e0827

smime.p7s
Description: S/MIME cryptographic signature

RE: Maiising Daily Snapshots for 20210416

[Dr. Matthias St. Pierre]

It seems a bit outdated nowadays to publish daily snapshots imho.

   https://www.openssl.org/source/snapshot/

Instead of maintaining those snapshots, couldn't we just advertise the GitHub 
download links?
Any branch or commit can be downloaded easily as ZIP or compressed TAR file, 
whatever you prefer.

Matthias

--

$ curl -JOL 
https://github.com/openssl/openssl/archive/refs/heads/master.tar.gz
$ curl -JOL 
https://github.com/openssl/openssl/archive/refs/heads/OpenSSL_1_1_1-stable.tar.gz

$ curl -JOL https://github.com/openssl/openssl/archive/refs/heads/master.zip
$ curl -JOL 
https://github.com/openssl/openssl/archive/refs/heads/OpenSSL_1_1_1-stable.zip


$ ls -l openssl-*.tar.gz openssl-*.zip
-rw-r--r-- 1 msp msp 14548457 Apr 16 16:34 openssl-master.tar.gz
-rw-r--r-- 1 msp msp  9996650 Apr 16 16:35 
openssl-OpenSSL_1_1_1-stable.tar.gz

$ ls -l openssl-*.tar.gz openssl-*.zip
-rw-r--r-- 1 msp msp 17122833 Apr 16 16:41 openssl-master.zip
-rw-r--r-- 1 msp msp 11844030 Apr 16 16:41 openssl-OpenSSL_1_1_1-stable.zip

> -Original Message-
> From: openssl-users  On Behalf Of Matt 
> Caswell
> Sent: Friday, April 16, 2021 4:12 PM
> To: openssl-users@openssl.org
> Subject: Re: Maiising Daily Snapshots for 20210416
> 
> There was a power outage at the datacentre last night. Everything should
> hopefully be back to normal now, so hopefully the snapshots will arrive
> as normal tonight.
> 
> Matt
> 
> 
> On 16/04/2021 14:25, The Doctor wrote:
> > Anyone knows what happened?
> >



smime.p7s
Description: S/MIME cryptographic signature

RE: openssl-users Digest, Vol 77, Issue 6

[Dr. Matthias St. Pierre]

> It isn't possible to do what you are wanting.  RAND_METHOD replaces the RNG 
> everywhere.  It cannot be done on a per thread process.

Well, technically it *is* possible. However, I'm still in doubt whether it is 
really necessary and should be done.

The following example assumes you are compiling for linux (or another unix-ish 
os) and using pthreads:
Assume that you recorded the thread id of your thread T1 (which you obtained 
from pthread_create())
in the static variable 'tid1'. Then you could take the code from [1] and modify 
it as follows:

```
static int my_rand_bytes(unsigned char *out, int count)
{
int ret;

if (pthread_equal(pthread_self(), tid1) {
   // ... call your special RNG here
} else {

   RAND_DRBG *drbg = RAND_DRBG_get0_public();

   if (drbg == NULL)
   return 0;

   ret = RAND_DRBG_bytes(drbg, out, count);
}

return ret;
}
```

This is just a rough sketch, note that there are more RAND_METHODs to be 
considered [2].


Matthias



[1] 
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L958-L970
[2] 
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L1146-L1153




From: openssl-users  On Behalf Of Dr Paul 
Dale
Sent: Monday, April 5, 2021 3:18 AM
To: openssl-users@openssl.org
Subject: Re: openssl-users Digest, Vol 77, Issue 6

Vishwanath,

It isn't possible to do what you are wanting.  RAND_METHOD replaces the RNG 
everywhere.  It cannot be done on a per thread process.


Pauli
On 4/4/21 9:55 pm, Vishwanath Mahajanshetty wrote:
Hi Paul,

Thanks for your response. I understand the concern for good random numbers; but 
in this scenario when second thread calls SSL_CTX_new it is waiting forever in 
RAND_priv_bytes(). Looks like entropy functions defined by first (bind) thread 
are very specific for its own use case and can't be used by other treads.
So I am thinking of using default OpenSSL RAND_METHOD for second thread and 
keep first thread (bind) to use its own random number generators.

Please let me know how can I make one thread use default RAND_METHOD and keep 
other thread to use its own method. I have gone through RAND_bytes() and 
drbg_bytes() but not getting enough idea. It would be really helpful if you 
point out APIs which help me to achieve this requirement.

Thank You,
Vishwanath M





smime.p7s
Description: S/MIME cryptographic signature

Re: Regarding RAND_set_rand_method (was: openssl-users Digest, Vol 77, Issue 6)

[Dr. Matthias St. Pierre]

Vishwanath,

have you already tried to simply use the default RAND_METHOD and not to replace 
it by your own? Except for the initial seeding(*), the thread local DRBGs 
should operate for a long time without blocking and without interfering with 
each other. Even if the thread local DRBGs reseed, they obtain their seed from 
the master DRBG, which does not reseed from the operating system every time. 
Even more, the RAND_{priv_}bytes() calls of different threads are completely 
independent from each other, except for the (unlikely) case that both threads 
block on the master DRBG which blocks on the os entropy source.

Please also post call stacks of the two threads if the problem persists. In 
particular, it would be useful to see which method is used to obtain the 
entropy (getrandom(), a read() from /dev/[u]random, ...), and why the system is 
so low on entropy.

Regards,
Matthias

(*) you might want to force an initial seeding during application startup by an 
explicit RAND_bytes() call.












From: openssl-users 
mailto:openssl-users-boun...@openssl.org>> 
On Behalf Of Vishwanath Mahajanshetty
Sent: Sunday, April 4, 2021 1:56 PM
To: openssl-users@openssl.org
Subject: RE: openssl-users Digest, Vol 77, Issue 6

Hi Paul,

Thanks for your response. I understand the concern for good random numbers; but 
in this scenario when second thread calls SSL_CTX_new it is waiting forever in 
RAND_priv_bytes(). Looks like entropy functions defined by first (bind) thread 
are very specific for its own use case and can't be used by other treads.
So I am thinking of using default OpenSSL RAND_METHOD for second thread and 
keep first thread (bind) to use its own random number generators.

Please let me know how can I make one thread use default RAND_METHOD and keep 
other thread to use its own method. I have gone through RAND_bytes() and 
drbg_bytes() but not getting enough idea. It would be really helpful if you 
point out APIs which help me to achieve this requirement.

Thank You,
Vishwanath M


smime.p7s
Description: S/MIME cryptographic signature

RE: Regarding RAND_set_rand_method

[Dr. Matthias St. Pierre]

Re Q1: I want to know is there any way to avoid this problem? I want thread T2 
to call default RAND methods and avoid calling methods set by thread T1. This 
is not only for RAND methods, but for any other methods.

First of all, I agree with Pauli: your first question should be, why do you 
need different random generators for different threads in the same application? 
Is this necessary, or are you overengineering?

Let me clarify some details about the RNG implemention in OpenSSL 1.1.1.: The 
RAND_METHOD interface itself is not thread aware. It is only the new default 
RAND_METHOD implementation (added in 1.1.1.) of OpenSSL (RAND_OpenSSL()), which 
supports thread local random generators. The implementation is based on 
deterministic random bit generators (DRBG) as described in NIST.SP.800-90Ar1. 
Wenn a thread calls RAND_bytes() (resp. RAND_priv_bytes()), the call is 
forwarded to the thread-specific DRBG instance. All per-thread instances reseed 
from a single global DRBG instance, which in turn reseeds from  from random 
sources provided by the operating system.

In your case, by replacing the RAND_METHOD, you are changing the complete RAND 
implementation for all threads. Moreover, you are completely responsible 
yourself for reseeding your RNG properly.

You could however implement a smarter RAND_METHOD which calls your specific RNG 
for T1 and delegates to the thread local DRBG (RAND_DRBG_get0_public() resp. 
RAND_DRBG_get0_private()) for all other threads. To get an idea how it can be 
done, take a look at the default implementation of RAND_bytes(),  drbg_bytes() 
in drbg_lib.c:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L958-L970


Re Q2: Also, is it possible to run OpenSSL as separate instance per thread 
(where each thread can do its own OpenSSL initialization) so that they can 
avoid above mentioned problem?

No. If you really need something like that, you might want to consider 
splitting your two threads into two processes.

HTH,
Matthias



From: openssl-users  On Behalf Of Dr Paul 
Dale
Sent: Friday, April 2, 2021 8:51 AM
To: openssl-users@openssl.org
Subject: Re: Regarding RAND_set_rand_method

There isn't an easy a way to do what you want in 1.1.1.  RAND_set_rand_method 
replaces the RNG for all of OpenSSL.  In theory your RAND_METHOD could detect 
which thread it is running in and do different things for each.  I'm not sure 
this is a good idea however.

Why aren't the random number from your first thread good enough for the second? 
 Good random numbers are just that - random.  It should be impossible to 
distinguish the two streams.

In OpenSSL 3.0 there are ways to achieve what you're wanting.


Pauli
On 2/4/21 4:24 pm, Vishwanath Mahajanshetty wrote:
Hi,

I have some doubts/questions on how to use methods (for ex: 
RAND_set_rand_method) in multi threaded application which use OpenSSL. In my 
application (running on OpenSSL 1.1.1d) there are two threads which use 
OpenSSL, both threads perform very different operations. The issue I am facing 
is as below:

Thread T1 calls RAND_set_rand_method() and sets RAND_METHOD structure. This is 
very specific to T1s use case. When thread T2 wants to create SSL_CTX it calls 
SSL_CTX_new() which then calls RAND_priv_bytes(). I am observing that the 
function RAND_priv_bytes() is calling the function set by T1 by RAND_METHOD in 
RAND_set_rand_method().

Essentially RAND_METHOD function set by thread T1 are getting called by thread 
T2.

Q1: I want to know is there any way to avoid this problem? I want thread T2 to 
call default RAND methods and avoid calling methods set by thread T1. This is 
not only for RAND methods, but for any other methods.

Q2: Also, is it possible to run OpenSSL as separate instance per thread (where 
each thread can do its own OpenSSL initialization) so that they can avoid above 
mentioned problem?

Thank you,
Vishwanath M




smime.p7s
Description: S/MIME cryptographic signature

RE: OpenSSL version 3.0.0-alpha10 published

[Dr. Matthias St. Pierre]

John,

I guess you received this mail because you are subscribed to the openssl-users 
mailing list.
(You might also be subscribed to the openssl-announce mailing list, but that's 
less likely.)

To unregister from the list, please visit

https://mta.openssl.org/mailman/listinfo/openssl-users  resp.
https://mta.openssl.org/mailman/listinfo/openssl-announce


and follow the instructions for unsubscribing.

Regards,
Matthias



> -Original Message-
> From: openssl-users  On Behalf Of John 
> Wasilewski
> Sent: Thursday, January 7, 2021 3:23 PM
> To: open...@openssl.org
> Cc: OpenSSL Announce ML ; OpenSSL User Support 
> ML ; openssl-
> proj...@openssl.org
> Subject: Re: OpenSSL version 3.0.0-alpha10 published
> 
> Please remove my email from your distribution
> 
> > On Jan 7, 2021, at 9:08 AM, OpenSSL  wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> >
> >   OpenSSL version 3.0 alpha 10 released
> >   =
> >
> >   OpenSSL - The Open Source toolkit for SSL/TLS
> >   https://www.openssl.org/
> >
> >   OpenSSL 3.0 is currently in alpha.
> >
> >   OpenSSL 3.0 alpha 10 has now been made available.
> >
> >   Note: This OpenSSL pre-release has been provided for testing ONLY.
> >   It should NOT be used for security critical purposes.
> >
> >   Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well
> >   as known issues are available on the OpenSSL Wiki, here:
> >
> >https://wiki.openssl.org/index.php/OpenSSL_3.0
> >
> >   The alpha release is available for download via HTTPS 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-3.0.0-alpha10.tar.gz
> >  Size: 14084047
> >  SHA1 checksum:  dfeb99f9bdb270d11f723039d07fda1478a31219
> >  SHA256 checksum:  
> > b1699acf2148db31f12edf5ebfdf12a92bfd3f0e60538d169710408a3cd3b138
> >
> >   The checksums were calculated using the following commands:
> >
> >openssl sha1 openssl-3.0.0-alpha10.tar.gz
> >openssl sha256 openssl-3.0.0-alpha10.tar.gz
> >
> >   Please download and check this alpha release as soon as possible.
> >   To report a bug, open an issue on GitHub:
> >
> >https://github.com/openssl/openssl/issues
> >
> >   Please check the release notes and mailing lists to avoid duplicate
> >   reports of known issues. (Of course, the source is also available
> >   on GitHub.)
> >
> >   Yours,
> >
> >   The OpenSSL Project Team.
> >
> > -BEGIN PGP SIGNATURE-
> >
> > iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl/3ESsACgkQ2cTSbQ5g
> > RJErmQgAj74iDsxOIigH87UxtnKLUqZc7ewbyZxM41XK52G/OPAzqSzGlMxhsYit
> > gvN7k+4qHWGuzyP5UGoTnxued/eG3tggUJh/WeuTmZ8DdrdV4C8Mhfb9ZkocDZZj
> > /wCnVGfb4xS5SPVnHU0qqtn0bWrltddjvdAzmuKvzQmyhftH6d/+VyUA9b9oUTkr
> > ygAvJYI6sJ/WBBSbRzONhwO16GKiLi5AzpPTuW9z7ZJS3YdZCCFFCYKPO255To9y
> > 1GgxhGns9VksvN6NR3AFeTKMQyet3Uo2tRmigtRYZvaJDCE4am40zSuhdFmujwMA
> > HFVox7b+u1PJrUdxzOGJe+A+1I0R9A==
> > =yDQs
> > -END PGP SIGNATURE-



smime.p7s
Description: S/MIME cryptographic signature

RE: SHA256 openssl-1.1.1i Checksum Error

[Dr. Matthias St. Pierre]

You’re welcome. As Michael Woijcik pointed out in his reply to the list, the 
problem had nothing
to do with zsh specifics. It was caused by the fact that those weren’t normal 
double quotes, but
unicode left and right double quotes, which weren’t understood by the shell.

Regards,
Matthias


From: Chris Outwin 
Sent: Monday, December 28, 2020 9:43 PM
To: Dr. Matthias St. Pierre 
Subject: Re: SHA256 openssl-1.1.1i Checksum Error

Thank you for your prompt reply. Removing the quotes from VERSION=“1.1.1i” 
allowed the script to run.


On Dec 28, 2020, at 12:49 PM, Dr. Matthias St. Pierre 
mailto:matthias.st.pie...@ncp-e.com>> wrote:

I have no experience with zsh, but it seems that quoting is handled differently 
by zsh?
At least it looks like the double quotes ended up in the GET line and you 
simply received
an HTTP 404 Not Found (which is the reason why your digest isn’t correct.)

HTH,
Matthias


> GET /source/openssl-“1.1.1i”.tar.gz HTTP/1.1
> Host: www.openssl.org<http://www.openssl.org/>
> User-Agent: curl/7.64.1
> Accept: */*
>
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0< 
HTTP/1.1 404 Not Found



Dr. Matthias St. Pierre

Senior Software Engineer
matthias.st.pie...@ncp-e.com<mailto:matthias.st.pie...@ncp-e.com>
Phone: +49 911 9968-0
www.ncp-e.com<http://www.ncp-e.com/>


Follow us on: Facebook<https://www.facebook.com/NCPengineering> | 
Twitter<https://twitter.com/NCP_engineering> | 
Xing<https://www.xing.com/companies/ncpengineeringgmbh> | 
YouTube<https://www.youtube.com/user/NCPengineeringGmbH> | 
LinkedIn<http://www.linkedin.com/company/ncp-engineering-inc.?trk=cws-cpw-coname-0-0>

Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 • 
Nuremberg
North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite 501-25 • 
Clearwater, FL 33755

Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich
Registry Court: Lower District Court of Nuremberg
Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 
133557619
This e-mail message including any attachments is for the sole use of the 
intended recipient(s) and may contain privileged or confidential information. 
Any unauthorized review, use, disclosure or distribution is prohibited. If you 
are not the intended recipient, please immediately contact the sender by reply 
e-mail and delete the original message and destroy all copies thereof.




smime.p7s
Description: S/MIME cryptographic signature

RE: SHA256 openssl-1.1.1i Checksum Error

[Dr. Matthias St. Pierre]

I have no experience with zsh, but it seems that quoting is handled differently 
by zsh?
At least it looks like the double quotes ended up in the GET line and you 
simply received
an HTTP 404 Not Found (which is the reason why your digest isn’t correct.)

HTH,
Matthias


> GET /source/openssl-“1.1.1i”.tar.gz HTTP/1.1
> Host: www.openssl.org
> User-Agent: curl/7.64.1
> Accept: */*
>
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0< 
HTTP/1.1 404 Not Found


smime.p7s
Description: S/MIME cryptographic signature

RE: Use OpenSSL to decrypt TLS session from PCAP files

[Dr. Matthias St. Pierre]

Do you need to integrate the decryption into your own software, or are you just 
looking for a possibility to monitor and view the traffic?
If it’s the latter, try and take a look at the SSL decryption support that 
Wireshark provides.

https://wiki.wireshark.org/TLS
https://www.comparitech.com/net-admin/decrypt-ssl-with-wireshark/


hth,
Matthias

Disclaimer: I haven’t used it for TLS myself, only for IPsec, and I can’t tell 
how up-to-date it is, in particular whether it is TLS 1.3 ready.

From: openssl-users  On Behalf Of Oren 
Shpigel
Sent: Tuesday, December 8, 2020 3:15 PM
To: openssl-users@openssl.org
Subject: Use OpenSSL to decrypt TLS session from PCAP files

Hi,
I generated a PCAP file with TLS session, and I have the matching private key 
used by my HTTPS server.
The TLS session is not using DH for key exchange, so it should be possible to 
decrypt.
I know OpenSSL can be used to connect to a socket to "actively" handle the TLS 
session, but is there a way to "passively" decode and decrypt a session?
How can I "feed" the packets (both directions) into the OpenSSL library?
Thanks!


smime.p7s
Description: S/MIME cryptographic signature

RE: OpenSSL version 1.1.1h published

[Dr. Matthias St. Pierre]

> I think it would be better to just add a comment that the older branch
> changes are tracked elsewhere.

The note is already present, it's in the second paragraph of
https://www.openssl.org/news/changelog.html
but it is confusing nevertheless and it would be more useful if the
entire information would be visible on the website (in HTML).

Currently, I am updating the two documents on master occasionally.
This is not ideal, that's why I proposed in #11346 that we  always update
the information on master and backport the relevant changes to the stable
branches (for 3.0 and beyond only, because 1.1.1 is not in markdown yet.

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


Matthias

RE: OpenSSL version 1.1.1h published

[Dr. Matthias St. Pierre]

> On 22/09/2020 15:03, Michael Wojcik wrote:
> > changelog.html hasn't been updated since 1.1.1e.
> >
> > https://www.openssl.org/news/changelog.html#openssl-111 shows:
> 
> That's the master Changelog. Confusing I know.
> 
> The link to the 1.1.1 Changelog  is at the top of the page.

It is indeed confusing, and it shouldn't be. See
https://github.com/openssl/openssl/pull/12967


Regards,
Matthias

Re: Empty directories

[Dr. Matthias St. Pierre]

Hmmm... that might be a remnant which was forgotten during the reorganization 
of the
header files, see commit [1] of pull request [2].

It tested it on master, it seems like the empty directories are created by the 
Configure script.
Would you mind opening a GitHub issue for it?

Regards, Matthias



[1] 
https://github.com/openssl/openssl/commit/25f2138b0ab54a65ba713c093ca3734d88f7cb51
[2] https://github.com/openssl/openssl/pull/9333


On 08.09.20 10:34, Gisle Vanem wrote:

I've noted that when build OpenSSL using MSVC,
some empty directories are created:
  ./crypto/include
  ./crypto/providers

I configured with:
  perl.exe -I. -I./util/perl Configure VC-WIN32-ONECORE no-makedepend
  enable-zlib enable-trace enable-md2 no-ec_nistp_64_gcc_128
  enable-asan enable-aria enable-rc5 enable-heartbeats --prefix=/foo/bar
  --openssldir=/foo/bar

I see that the generated Makefile has lots of
'-I "crypto\include"'. AFAICS needlessly. But I
see no 'mkdir crypto\include' anywhere.

And I don't see 'mkdir-p.pl' is used to create these.
So how are these empty directories created/used?

RE: The need for 'gdi32.lib'

[Dr. Matthias St. Pierre]

> Grepping through all of my OpenSSL sources, I see only the
> above mention and one in 'Configurations\10-main.conf'.
> 
> So how/when is 'gdi32.dll' needed? Maybe it was true in the old-days?

My guess is that you are right and that it was needed only for the function 
readscreen(), used by RAND_screen() (see [1]).
A quick search shows that this function was removed in pull request #1079 
(merged as commit 888db7f224fe) before
the release of 1.1.0, see [2].

Would you mind creating a pull request for changing the NOTES?

Matthias

[1] 
https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/rand/rand_win.c#L679-L745
[2] https://github.com/openssl/openssl/pull/1079

RE: [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider

[Dr. Matthias St. Pierre]

Thomas,

> I consider this a bug, of course, but at least now I know what's causing it 
> and how to work around it.

thanks for sharing your analysis. Would you mind creating a GitHub issue for 
the hang?

https://github.com/openssl/openssl/issues

Matthias


From: openssl-users  On Behalf Of Thomas 
Dwyer III
Sent: Friday, July 17, 2020 6:57 PM
To: openssl-users 
Subject: [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider

It turns out the problem was caused by a misinterpretation of the phrase "add 
the following lines near the beginning" in section 7.1 of the documentation at 
https://wiki.openssl.org/index.php/OpenSSL_3.0 for enabling FIPS support. I 
added these lines to the very top of the file:


openssl_conf = openssl_init



.include /usr/local/ssl/fipsmodule.cnf



[openssl_init]

providers = provider_sect



[provider_sect]

fips = fips_sect

This caused the existing default section to now become part of the 
[provider_sect] section. Apparently any name=value line in that particular 
section where no [value] section exists causes OpenSSL to hang at exit when the 
FIPS provider is used. I consider this a bug, of course, but at least now I 
know what's causing it and how to work around it.

Regarding how to confirm which provider is actually providing a given 
algorithm, I found that EVP_MD_provider() returns NULL for any EVP_MD obtained 
via EVP_get_digestbyname() (even after it's used successfully by 
EVP_DigestInit_ex()) but it returns a valid OSSL_PROVIDER for any EVP_MD 
obtained via EVP_MD_fetch(). Is this intentional?


Tom.III

RE: freefunc - name clash with Python.h

[Dr. Matthias St. Pierre]

> Does my test program do anything interesting on your system?

No. Except for compiling with warnings ;-)

> Python has:
> typedef void (*freefunc)(void *);
> 
> That looks weird to me, but I'm not a language guy.

That's simply a C type definition for a pointer type named `freefunc`, which 
can hold the address of any function
`foo` which has the signature `void foo(void *)`.  This pointer type is used in 
various locations by python:

https://github.com/python/cpython/search?p=2&q=freefunc

So Python's global typedef has the same name as a function argument in our 
headers. The only potential
problem I see here that within one of our functions which has `freefunc` as an 
argument name, the
global `freefunc` type name would not be available.

You can safely ignore this warning. (Either omit `-Wshadow` entirely, or 
disable it locally using a #pragma.)

> No problems on 1.1.1g from Fedora.

I was able to trace back the warning to commit 
739a1eb1961cdc3b1597a040766f3cb359d095f6 from 2016,
which is included in OpenSSL Versions 1.1.0 and higher. So you should get the 
warning in 1.1.1g too, unless
Fedora patched the source code.

https://github.com/openssl/openssl/commit/739a1eb1961cdc3b1597a040766f3cb359d095f6


I don't see any reason to change our code, IMHO the clash is Python's fault: it 
declares a global typedef
with a short name that has no python-specific prefix.


HTH,

Matthias

RE: Asymetric crypto and OpenSSL 3.0 deprecated functions

[Dr. Matthias St. Pierre]

> The proper protocol would be to just sign the binary by your private
> RSA key and encrypt it with a symmetric key, that you directly pre-
> distribute to your recipients via the same channel that you now use to
> distribute your public RSA key.

I agree with Tomáš, just would like to emphasize that the order of operation 
matters:
It should be encrypt-then-sign, not vice versa. This ensures that the recipient 
can
check the integrity of the binary before attempting to decrypt it.

Matthias

RE: Have new release published in /source/old directory too?

[Dr. Matthias St. Pierre]

> For each new release, it seems that the tarball is published in the
> "/source" directory (website) while the previous one is moved to
> "/source/old/".
> 
> Would it be possible that all releases land in "/source/old",
> including the new one when published? After all anything is more or
> less old, as soon as it's born ;)


Normally, you should be able to access older releases without changing the URL,
(even after they were moved) because there is an URL rewrite rule which handles 
this.

For an example, 1.1.1a is available at the same location as 1.1.1g:

~/tmp$ curl -JOL https://www.openssl.org/source/openssl-1.1.1g.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
 Dload  
Upload   Total   SpentLeft  Speed
100 9571k  100 9571k0 0  1992k  0  0:00:04  0:00:04 
--:--:-- 1992k

~/tmp$ curl -JOL https://www.openssl.org/source/openssl-1.1.1a.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
 Dload  
Upload   Total   SpentLeft  Speed
100 8154k  100 8154k0 0  4962k  0  0:00:01  0:00:01 
--:--:-- 4960k

Concidentally, a few days ago the rewrite rule was broken, but that has been 
fixed.
(see https://github.com/openssl/openssl/issues/11521#issuecomment-612483438 and 
ff.)

HTH,

Matthias

RE: RAND SEED in vxworks6.9

[Dr. Matthias St. Pierre]

FYI: I restarted the discussion in #7946

https://github.com/openssl/openssl/issues/7946#issuecomment-603545804


Matthias

RE: RAND SEED in vxworks6.9

[Dr. Matthias St. Pierre]

> Indeed, one workaround for your application would be to seed and reseed
> the random generator manually using RAND_bytes(), ...

Correction, I meant to say ".. using RAND_add()..."


> -Original Message-
> From: openssl-users  On Behalf Of Dr. 
> Matthias St. Pierre
> Sent: Tuesday, March 24, 2020 11:49 PM
> To: Suvendhu Hansa ; openssl-users@openssl.org
> Subject: RE: RAND SEED in vxworks6.9
> 
> Hi,
> 
> > I am beginner in openssl and I am porting openSSL-1.1.1d in vxWorks-6.9. So
> > as suggested I have defined "OPENSSL_RAND_SEED_NONE" flag, as for vxWorks
> > 'none' is only supported but after doing so I am observing
> > "rand_pool_entropy_available()" returns 0 which further leads to failure.
> > I came across that while NONE is set then manual seed and re-seed is must
> > for the applications depend on random generator.
> 
> Indeed, OPENSSL_RAND_SEED_NONE is the default on platforms where OpenSSL
> does not know how to obtain cryptographically strong randomness from a trusted
> entropy source. This does not mean that no such source exists, but nobody has
> implemented the get_entropy callback for that platform yet.
> 
> > I am very confused and as not having any openSSL experience I am not able to
> > understand what needs to be done to resolve this issue.
> >
> > In my project many applications are using openssl APIs, So do I need to call
> > RAND_add() in all applications where some random generation is being done?
> > or is there anything else I can do to provide the seeds?
> 
> Indeed, one workaround for your application would be to seed and reseed
> the random generator manually using RAND_bytes(), as it is explained in the
> `RESEEDING` section of the RAND_DRBG(7)  manual page (see [1]).
> However, be warned that it notoriously hard to estimate the quality of a
> random source (a.k.a "entropy") correctly, and that a normal application
> developer with little knowledge of cryptography would end up with a fake
> sense of security because he overestimated the quality of his random seed.
> 
> A better solution would be to use a trusted random source provided by the
> operating system or some system library and use it to implement the
> get_entropy callbacks for the VxWorks platform. This could even become
> part of the official OpenSSL distribution. (Since it's a new feature, it won't
> be backported to 1.1.1, but you could patch your local  OpenSSL instance
> when the implementation is available).
> 
> There was some discussion about a suitable random source for VxWorks
> on GitHub in issue #7946 (see [1]), but unfortunately no pull request
> emerged of it and the discussion has stalled some time ago.
> 
> You could visit the issue's thread and try to contact Tobias Klotz
> (by mentioning @klotzt-draeger in the thread)  to find out what the
> current state is. If he comes up with a pull request, I could assist with
> reviewing it, but I can't implement it since I don't have access to the
> VxWorks platform.
> 
> Hope that helps,
> 
> Regards,
> Matthias
> 
> 
> [1] https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html
> [2] https://github.com/openssl/openssl/issues/7946
> 

RE: RAND SEED in vxworks6.9

[Dr. Matthias St. Pierre]

Hi,

> I am beginner in openssl and I am porting openSSL-1.1.1d in vxWorks-6.9. So
> as suggested I have defined "OPENSSL_RAND_SEED_NONE" flag, as for vxWorks
> 'none' is only supported but after doing so I am observing
> "rand_pool_entropy_available()" returns 0 which further leads to failure.
> I came across that while NONE is set then manual seed and re-seed is must
> for the applications depend on random generator.

Indeed, OPENSSL_RAND_SEED_NONE is the default on platforms where OpenSSL
does not know how to obtain cryptographically strong randomness from a trusted
entropy source. This does not mean that no such source exists, but nobody has
implemented the get_entropy callback for that platform yet.

> I am very confused and as not having any openSSL experience I am not able to
> understand what needs to be done to resolve this issue.
> 
> In my project many applications are using openssl APIs, So do I need to call
> RAND_add() in all applications where some random generation is being done?
> or is there anything else I can do to provide the seeds?

Indeed, one workaround for your application would be to seed and reseed
the random generator manually using RAND_bytes(), as it is explained in the
`RESEEDING` section of the RAND_DRBG(7)  manual page (see [1]).
However, be warned that it notoriously hard to estimate the quality of a
random source (a.k.a "entropy") correctly, and that a normal application
developer with little knowledge of cryptography would end up with a fake
sense of security because he overestimated the quality of his random seed.

A better solution would be to use a trusted random source provided by the
operating system or some system library and use it to implement the
get_entropy callbacks for the VxWorks platform. This could even become
part of the official OpenSSL distribution. (Since it's a new feature, it won't
be backported to 1.1.1, but you could patch your local  OpenSSL instance
when the implementation is available).

There was some discussion about a suitable random source for VxWorks
on GitHub in issue #7946 (see [1]), but unfortunately no pull request
emerged of it and the discussion has stalled some time ago.

You could visit the issue's thread and try to contact Tobias Klotz
(by mentioning @klotzt-draeger in the thread)  to find out what the
current state is. If he comes up with a pull request, I could assist with
reviewing it, but I can't implement it since I don't have access to the
VxWorks platform.

Hope that helps,

Regards,
Matthias


[1] https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html
[2] https://github.com/openssl/openssl/issues/7946

RE: How to split a pfx file into cert and key?

[Dr. Matthias St. Pierre]

It’s the passwort which protects the p12 file. If you were given a ‘PIN’ for 
your pfx file, try that.
OpenSSL calls it ‘import passwort’, because it is importing from p12 format and 
exporting to
pem format.

Two remarks about those three commands:

If you omit the  `-nodes` argument in the first command, OpenSSL will ask you 
for another
passwort to encrypt the private key, which I’d recommend if it’s an important 
key.
The third command is only necessary, if you omitted `-nodes` in the first step, 
because
otherwise the key already is unencrypted and has no passphrase.
1.  Run the following command to export the private key: openssl pkcs12 -in 
certname.pfx -nocerts -out key.pem -nodes
2.  Run the following command to export the certificate: openssl pkcs12 -in 
certname.pfx -nokeys -out cert.pem
3.  Run the following command to remove the passphrase from the private 
key: openssl rsa -in key.pem -out server.key
HTH,
Matthias




From: openssl-users  On Behalf Of Michael 
Leone
Sent: Thursday, February 13, 2020 9:34 PM
To: openssl-users@openssl.org
Subject: How to split a pfx file into cert and key?

I received a pfx file from one our techs. A pfx file is a cert and key, all in 
one binary file. He needs me to split it out into the cert and the key, so I 
can create a new request from that key, and then sign a new cert for him.

(no, I don't know why he can't just create a new request. And I would revoke 
the old cert, except that I am unsure of the details he used in naming it, so I 
don't know what to revoke .. So I am stuck trying to see if I can help the guy, 
by creating a new request from the private key, presuming I can extract the 
private key ...)

Anyways, I found this set of commands

Extracting Certificate and Private Key Files from a .pfx 
File
https://wiki.cac.washington.edu/display/infra/Extracting+Certificate+and+Private+Key+Files+from+a+.pfx+File


  1.  Note: the *.pfx file is in PKCS#12 format and includes both the 
certificate and the private key.
2.  Run the following command to export the private key: openssl pkcs12 -in 
certname.pfx -nocerts -out key.pem -nodes
3.  Run the following command to export the certificate: openssl pkcs12 -in 
certname.pfx -nokeys -out cert.pem
4.  Run the following command to remove the passphrase from the private 
key: openssl rsa -in key.pem -out server.key

But I'm asked for an "Import password" ..

$ sudo openssl pkcs12 -in requests/DCTRNPS001_cert.pfx -nocerts -out 
DCTRNPS001_key.pem -nodes
Enter Import Password:

And I have no idea what an "import" password is. It's not the password for the 
private key, so I don't know what it is.

Pointers, anyone?

--

Mike. Leone, >

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: 

This space reserved for future witticisms ...

RE: Re:openssl-users Digest, Vol 62, Issue 6

[Dr. Matthias St. Pierre]

Hi,

in the body of the message you just sent us, you find a detailed description 
how to unsubscribe:

To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
openssl-users-requ...@openssl.org

Regards,
Matthias


From: openssl-users  On Behalf Of RUBEN 
BARAINCA
Sent: Monday, January 27, 2020 7:44 PM
To: openssl-users@openssl.org
Subject: Re:openssl-users Digest, Vol 62, Issue 6
Importance: High

Hi!!
I want to unsubscribe.




 Original message 
From: 
openssl-users-requ...@openssl.org
Date: Mon, Jan 27, 2020, 7:20 PM
To: openssl-users@openssl.org
Subject: openssl-users Digest, Vol 62, Issue 6
Send openssl-users mailing list submissions to
openssl-users@openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
openssl-users-requ...@openssl.org

You can reach the person managing the list at
openssl-users-ow...@openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Thanks for Encoding Clarification (Douglas Morris)
   2. What option is not recognized by OpenSSL 1.1.1d? (Jeffrey Walton)
   3. Re: What option is not recognized by OpenSSL 1.1.1d?
  (Matt Caswell)
   4. Determine that there is no forward progress with non blocking
  SSL socket (Eran Borovik)
   5. Decryption slower in 1.1.1 branch? (Dan Heinz)


--

Message: 1
Date: Sun, 26 Jan 2020 04:58:42 + (UTC)
From: Douglas Morris mailto:dougbmor...@yahoo.com>>
To: "openssl-users@openssl.org" 
mailto:openssl-users@openssl.org>>
Subject: Thanks for Encoding Clarification
Message-ID: 
<791238297.11590163.1580014722...@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"

Viktor,
Thanks for meticulously answering my questions. I know the file name encoding 
is not necessarily the file content encoding. If a Python program were on a 
Windows computer, it might show a file name encoding of UTC-16, which would 
make UTC-16 a good guess for what openssl  -text would output as 
bytes to be converted (the way what I'm doing works with Python's subprocess 
module). That was my conjectural thinking and a heuristic I though might be 
useful. I could get the name of the operating system from Python and map that 
to a 'native' encoding I suppose, but that's too much work for dubious gain. 
I'm not testing on Windows. It is enough to know that there is no easy and 
obvious way to accommodate -text bytes on various OSes, supposing they would be 
different. Maybe there is no difference. I expect think there should be on 
older WIndows and Apple OSes. Yes, I could be wrong. I'll just go with what I 
knowledge I have, accept the uncertainty, and concentrate on the OS that I'
m using, which is Linux. I could always extract public key parameters and 
expiration dates from the OS-consistent PEM form, not that I want to try.

So DER is binary and PEM is ASCII text (which means utf-8 and not utf-16). 
Going by RFC 1421 via herongyang.com, the MS line breaks are a nice touch. I 
got the info I need to program something and troubleshoot any encoding problems 
from -text output bytes that might arise. I can see that 'openssl req -in  
-outform DER' outputs bytes that are not to be changed. I suppose the same is 
true of -outform PEM. That's good to know because I was 'fixing' the received 
certificate (in PEM I believe) by normalizing line breaks to '\n' and then 
trusting Python's universal newlines mode to write out the big string in a 
variable to a file with the native OS-line-break encoding. I think I'll just 
write out the raw bytes as received. Funny, but I ran openssl x509 -text on the 
one test/staging certificate I saved to file only hours ago, and with the 
aforesaid 'normalization', and it displayed correctly. I know that doesn't 
prove that such treatment for a real certificate will work correctly for t
he Web server when the time comes, but my program is coming along and I know a 
little more about what's going on.

Thanks.

Douglas Morris
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Sun, 26 Jan 2020 16:03:50 -0500
From: Jeffrey Walton mailto:noloa...@gmail.com>>
To: OpenSSL Users mailto:openssl-users@openssl.org>>
Subject: What

Re: Usage of Secure C (memcpy_s, strcpy_s etc) functions on OpenSSL

[Matthias St. Pierre]

Hello Raja,

according to our policy, the OpenSSL C source code needs to conform to ISO C90, 
which makes it
impossible to adopt C11 features.


Chapter 20:  Portability

To maximise portability the version of C defined in ISO/IEC 9899:1990
should be used. This is more commonly referred to as C90. ISO/IEC 9899:1999
(also known as C99) is not supported on some platforms that OpenSSL is
used on and therefore should be avoided.

(see https://www.openssl.org/policies/codingstyle.html)


Matthias


On 26.11.19 12:07, Raja ashok wrote:


Hi All,

We are using OpenSSL in our projects and we found some of the C standard 
functions (like memcpy, strcpy) used in OpenSSL may induce security 
vulnerablities like buffer overflow. Currently we have not found any instances 
which causes such issues.

But we feel better to change these calls to C11 standard's secure functions 
like memcpy_s, strcpy_s etc. By defining a secure calls method (list of func 
pointers) and allowing application to register the method. I understand that 
this affects performance because of return value check added for _s calls, 
but this will make sure it removes buffer overflow kind of issues completely 
from code. And also currently using secure c calls is a general industry 
practice.

Please share your opinion on it, and if any discussion happened in OpenSSL 
coummunity to do this change in future.

Thanks in advance.

Raja Ashok

Re: Problems porting Openssl 1.1.1d to zos.

[Matthias St. Pierre]

Please see also GitHub issue #4154, in particular

https://github.com/openssl/openssl/issues/4154#issuecomment-552838141

Re: Problems porting Openssl 1.1.1d to zos.

[Matthias St. Pierre]

On 11.11.19 16:42, Wendell Nichols via openssl-users wrote:

Is there anyone on this group with experience with ebcdic platforms, 
specifically zOS?  I have built 1.1.1d on zOS and connections to my server work 
for firefox 60 but not newer versions.  I don't know exactly where the cut off 
is or what they changed but current versions get an HMAC error.  I strongly 
suspect that it is keying the hmac with some combination of inputs that include 
an improperly translated text string, but I don't know for sure.  Its quite 
hard to track down when you don't have a debugger.

The error message:


An error occurred during a connection to cafe.na.tibco.com:1802. SSL received a 
record with an incorrect Message Authentication Code. Error code: 
SSL_ERROR_BAD_MAC_READ


If anyone can suggest an approach to figuring this out I'd be grateful.


Wendell Nichols



Incidentally, I just merged a pull request that fixed a misspelled EBCDIC 
string to master and 1.1.1.

https://github.com/openssl/openssl/pull/10396#issuecomment-552506972

But I have no idea whether it is related to your problem. Nevertheless, you 
might want to retry with the current tip of the OpenSSL_1_1_1-stable branch.


Regards,
Matthias

AW: Base64 or Base64url

[Dr. Matthias St. Pierre]

P.S: My answer to your original question applies to 1.0.1 as well:
https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/doc/crypto/EVP_EncodeInit.pod


Von: openssl-users  Im Auftrag von Dr. 
Matthias St. Pierre
Gesendet: Freitag, 18. Oktober 2019 09:10
An: Benjamin ENTE ; openssl-users@openssl.org
Betreff: AW: Base64 or Base64url

Just noticed your OpenSSL version: it is _very_ old and not supported anymore.
its successor, OpenSSL 1.0.2, will be EOL by the end of this year.
The current stable LTS version is OpenSSL 1.1.1.

Matthias

Von: openssl-users 
mailto:openssl-users-boun...@openssl.org>> 
Im Auftrag von Benjamin ENTE
Gesendet: Freitag, 18. Oktober 2019 08:51
An: openssl-users@openssl.org<mailto:openssl-users@openssl.org>
Betreff: Base64 or Base64url

Hi everyone

I'm looking for an information I can't find.

I'm using OpenSSL 1.0.1e 11 Feb 2013 and I want to know if it's encoding in 
base64 or in base64url.

Thank you in advance for your help

Best regards

Benjamin


[http://www.cromology.com/mail/cromology-it.gif]


Benjamin ENTE
Ingénieur système et BDD
Services Infrastructure
71, Bd du Général Leclerc - 92583 Clichy cedex
Tel. +33(0)175338276 | Mobile. +33(0)678003942
benjamin.e...@cromology.com<mailto:%22benjamin.e...@cromology.com%22>
www.cromology.com<http://www.cromology.com/>

Merci de penser à l'environnement avant d'imprimer ce message.

AW: Base64 or Base64url

[Dr. Matthias St. Pierre]

Just noticed your OpenSSL version: it is _very_ old and not supported anymore.
its successor, OpenSSL 1.0.2, will be EOL by the end of this year.
The current stable LTS version is OpenSSL 1.1.1.

Matthias

Von: openssl-users  Im Auftrag von Benjamin 
ENTE
Gesendet: Freitag, 18. Oktober 2019 08:51
An: openssl-users@openssl.org
Betreff: Base64 or Base64url

Hi everyone

I'm looking for an information I can't find.

I'm using OpenSSL 1.0.1e 11 Feb 2013 and I want to know if it's encoding in 
base64 or in base64url.

Thank you in advance for your help

Best regards

Benjamin


[http://www.cromology.com/mail/cromology-it.gif]


Benjamin ENTE
Ingénieur système et BDD
Services Infrastructure
71, Bd du Général Leclerc - 92583 Clichy cedex
Tel. +33(0)175338276 | Mobile. +33(0)678003942
benjamin.e...@cromology.com
www.cromology.com

Merci de penser à l'environnement avant d'imprimer ce message.

AW: Base64 or Base64url

[Dr. Matthias St. Pierre]

OpenSSL is using regular base64 encoding, see for example
https://www.openssl.org/docs/man1.1.1/man3/EVP_EncodeInit.html

But if you need base64url encoding, no problem: a simple string replace will 
help.
https://brockallen.com/2014/10/17/base64url-encoding/

Regards,
Matthias


Von: openssl-users  Im Auftrag von Benjamin 
ENTE
Gesendet: Freitag, 18. Oktober 2019 08:51
An: openssl-users@openssl.org
Betreff: Base64 or Base64url

Hi everyone

I'm looking for an information I can't find.

I'm using OpenSSL 1.0.1e 11 Feb 2013 and I want to know if it's encoding in 
base64 or in base64url.

Thank you in advance for your help

Best regards

Benjamin



Benjamin ENTE
Ingénieur système et BDD
Services Infrastructure
71, Bd du Général Leclerc - 92583 Clichy cedex
Tel. +33(0)175338276 | Mobile. +33(0)678003942
mailto:%22benjamin.e...@cromology.com%22 
http://www.cromology.com/
Merci de penser à l'environnement avant d'imprimer ce message.

AW: AW: building OpenSSL 1.1.1 with -DPURIFY

[Dr. Matthias St. Pierre]

> > The easiest way to obtain the fix is to update to the current head of the 
> > 1.1.1. stable branch.
> > https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-stable
> 
> I think you meant to link to the 1.1.1 branch not 1.0.1!
> 
> https://github.com/openssl/openssl/commits/OpenSSL_1_1_1-stable
> 
> Matt

You are right, thanks for the correction. I must have selected the wrong entry 
in the GitHub branch
selection box without noticing it. Fortunately, Tim didn't follow my advice 
blindly ;-)

Matthias

AW: building OpenSSL 1.1.1 with -DPURIFY

[Dr. Matthias St. Pierre]

Hi Tim,

> However, when I run the tests there appears to be failures.
> 
> Extract of the make test output  below:
> 
> 
> ../test/recipes/20-test_enc.t ..
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/172 subtests

Your test failure looks like issue 
https://github.com/openssl/openssl/issues/9866

which was fixed by Tomas in commit
https://github.com/openssl/openssl/commit/86ed78676c660b553696cc10c682962522dfeb6c

The easiest way to obtain the fix is to update to the current head of the 
1.1.1. stable branch.
https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-stable

Regards,
Matthias

AW: OpenSSL compilation errors in Windows

[Dr. Matthias St. Pierre]

> We are using OpenSSL APIs in our product code. We are not making any changes 
> in OpenSSL.
> Our product code is a C++ code and it makes use of openSSL APIs for some 
> functionality.

Local headers (like "ssl_locl.h" and "packet_locl.h") are *NOT* part of the 
official OpenSSL API.
Please don't expect any support w.r.t. compilation or compatibility problems if 
you do include
them in your application, even more if it's compiled using a C++ compiler.

It would be more helpful if you would tell us *why* you are including 
ssl_locl.h and what you
are trying to achieve. Then we might be able to tell you how you could achieve 
your goal using
the officially supported API.

Please note that many of the OpenSSL structures were made opaque in version 
1.1.0. This means
that there are only forward declarations of the structures in the public 
headers and the compiler
does not get to  see the structure members. Instead of directly accessing the 
members, it is now
necessary to use accessor functions (a.k.a. getters and setters). If this is 
the reason why you are
including private OpenSSL headers then you should adopt you application to use 
the new
accessors instead, instead of forcing the impossible to circumvent the new 
policy.

For more information, see 

https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes

Matthias

AW: OpenSSL compilation errors in Windows

[Dr. Matthias St. Pierre]

> OpenSSL code is compiling without any issues. When it is used from our 
> product code and while compiling using C++ compiler, the issue is seen.

As I wrote previously, the error you posted was caused  by the fact that you 
are compiling Ansi C (a.k.a ISO/IEC 9899:1990, a.k.a C90) source code
using a C++ compiler. While C permits a cast from ‘void *’ to ‘anytype *’, C++ 
doesn’t allow it without an explicit cast.

Only the *public* OpenSSL headers are guaranteed to be includable by a C++ 
compiler (they contain the necessary ` extern “C” ` blocks, etc.),
not the internal headers. Including *internal* headers is neither supported nor 
possible with a C++ compiler. And as Matt Caswell already told you,
there are no compatibility guarantees for those headers.

Matthias

AW: OpenSSL compilation errors in Windows

[Dr. Matthias St. Pierre]

> Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '=' : 
> cannot convert from 'void *' to 'unsigned char 'Conversion from 'void' to 
> pointer to non-'void' requires an explicit cast

Is it possible that your error message was copied incorrectly? Line 429 is an 
assignment from 'void *' to 'unsigned char*', not to 'unsigned char'.

Such an assignment is allowed in C (and the type is implicitly converted), but 
not in C++. Is it possible, that you are including this header in a module 
compiled with a C++ compiler? Note that this is an internal header file and not 
meant to be included by third party software.

HTH,
Matthias




Von: openssl-users  Im Auftrag von 
Nagalakshmi V J
Gesendet: Montag, 30. September 2019 08:44
An: openssl-users@openssl.org
Cc: Umamaheswari Nagarajan 
Betreff: OpenSSL compilation errors in Windows

Hi,
I am using openssl 1.1.c from our product code. While compiling the code, I am 
getting the errors which can be suppressed as warnings using -fpermissive flag 
in Linux (gcc/g++). In windows, I am getting the same compilation errors in 
visual studio (2005). Would like to know the alternative of -fpermissive flag 
that can be used in visual studio to suppress the errors.
I tried adding the flags such as '/fpermissive' , '/Ze' in module 
properties->C/C++->command Line->Additional options. But it did not resolve the 
problem.
Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '=' : 
cannot convert from 'void *' to 'unsigned char 'Conversion from 'void' to 
pointer to non-'void' requires an explicit cast

Since it is giving error in Openssl code, we cannot make any code changes 
there. Has anyone faced this kind of issue?
Please let me know how to resolve this issue.



Thanks and regards,
Nagalakshmi

=
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this electronic communication.
=

OpenSSL 1.1.1d: test 20-test_enc.t fails if zlib is enabled

[Dr. Matthias St. Pierre]

Hello,

since we got a few bug reports by now about this issue on GitHub,
I thought it might be a good idea to spread the information a little bit:

It is a known issue that the 20-test_enc.t test fails in OpenSSL
version 1.1.1d if zlib support is enabled (see [1]).

Meanwhile, the bug has been fixed on master and the OpenSSL_1_1_1-stable
branch (see [2]).

The test error can be ignored, if you don't use the `openssl zlib` command,
resp. the BIO_f_zlib() filter BIO. However, if you need a fix for it before the
next official release, you have two options:

- Apply the patch 86ed78676c66 manually to your copy of 1.1.1d (see [3]).
- Update to the tip of the OpenSSL_1_1_1-stable branch (see [4]).

Regards,

Matthias


[1] https://github.com/openssl/openssl/issues/9866
[2] https://github.com/openssl/openssl/pull/9877
[3] 
https://github.com/openssl/openssl/commit/86ed78676c660b553696cc10c682962522dfeb6c
[4] https://github.com/openssl/openssl/commits/OpenSSL_1_1_1-stable

AW: Test failed with openssl-1.1.1d ../test/recipes/20-test_enc.t

[Dr. Matthias St. Pierre]

> > I think this is a problem with the 20-test_enc.t Test and not with OPENSSL.
> >
> > Can you please help me to fix the Test ?
> >
> 
> Did you enable zlib by any chance? If so it could be this:
> 
> https://github.com/openssl/openssl/issues/9866
> 
> No resolution as yet.
> 
> Matt


If you need a quick workaround, you have two options:

- Don't use the 'zlib' option when configuring OpenSSL

- Revert the offending commit 8be96f2369. It is dispensible, because it only 
fixes
  a 'cosmetical' problem, namely that in certain situations you have to press
  CTRL-D in the console more often than expected in order to indicate EOF to the
  openssl application.

   
https://github.com/openssl/openssl/commit/8be96f236969caabf303bec389a2f812b4869c1c

HTH,
Matthias

AW: FIPS_selftest() Usage

[Dr. Matthias St. Pierre]

> For an application linked to FIPS capable OpenSSL, 

> 1) After calls to FIPS_mode_set() and FIPS_mode() both succeed, is it good 
> practice to call FIPS_selftest()? Or is this redundant call?
>
> 2) Did come across documentation which only hinted that FIPS_mode_set() calls 
> FIPS_selftest() internally. Is this correct?

> Regards.

Indeed, FIPS_mode_set() calls FIPS_selftest() internally(*), and if the 
selftest fails, FIPS mode will not be enabled. So there is no
need to run the selftest immediately after FIPS_mode_set() again. If your 
program is a long-running service, it might be a good idea
to  re-run the selftest on a regular base, but I have no particular 
recommendations about how often would be reasonable.

(*) It is stated explicitly in the manual pages, which are printed in Appendix 
D.2 of the OpenSSL FIPS 2.0 User Guide:

>Appendix D.2  FIPS_mode_set(), FIPS_selftest() 
> FIPS_mode_set() enables the FIPS mode of operation for applications
> that have complied with all the provisions of the OpenSSL FIPS 140-2 Security
> Policy. Successful execution of this function call with non-zero ONOFF is the
> only way to enable FIPS mode. After verifying the integrity of the executable
> object code using the stored digest FIPS_mode_set() performs the power-up 
> self-test.

https://www.openssl.org/docs/fips/UserGuide-2.0.pdf

This document is the official documentation and most comprehensive guide for 
the OpenSSL FIPS 2.0
object module. Anything you need to know you should be able to find in there.

Regards,
Matthias

Re: RAND_seed buffer freeing

[Matthias St. Pierre]

On 11.07.19 12:00, tobias.w...@t-systems.com wrote:


I`ve one question regarding RAND_seed, the first parameter refers to a buffer, 
who is freeing that buffer afterwards? Can I free it after the call to 
RAND_seed or is this done by openssl?



You own the buffer, OpenSSL only reads its contents. So you can free it 
immediately after the call.
Note that before freeing it, you should erase the buffer contents for security 
reasons.

Actually, since OpenSSL 1.1.1. most applications don't need to worry about 
manual seeding anymore,
because the OpenSSL CSPRNG does it automatically. For more details, see

https://www.openssl.org/docs/man1.1.1/man7/RAND.html 


and

https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html 


HTH,

Matthias

AW: AW: Performance Issue With OpenSSL 1.1.1c

[Dr. Matthias St. Pierre]

Yay,

there are some controversial discussions taking place on

https://github.com/openssl/openssl/issues/9078

It would be great if you could join us and provide more details about the
circumstances of your issue. In particular, information like kernel/os version
and whether the significant startup delay is encountered only at early boot time
or also when you start the daemon manually when the system is up and running.

Matthias

Re: AW: Performance Issue With OpenSSL 1.1.1c

[Matthias St. Pierre]

Hi,

I opened an issue on GitHub to discuss this problem in more detail.

https://github.com/openssl/openssl/issues/9078

It would be nice if you could join the discussion there.


Matthias


@Jay:  in particular I'm interested to learn, which linux version and 
distribution
you were using. On newer systems, `getentropy()` should be the method of
choice, because it does not share the deficiencies of the `/dev/urandom` device.




On 30.05.19 02:11, Dr. Matthias St. Pierre wrote:

To workaround the /dev/random blocking issue, you can just add:

-DDEVRANDOM="\"/dev/urandom\""

as a parameter to ./Configure

This will remove the special handling of /dev/urandom and /dev/random
in 1.1.1c.


Tomáš, Jay,

I'm afraid this suggestion won't help, because `DEVRANDOM_WAIT` is defined
unconditionally in e_os.h:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/e_os.h#L30-L34

This means that the select() call will happen on linux independently of what
`DEVRANDOM` is defined to be:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/crypto/rand/rand_unix.c#L509-L535

I think that pull request #8251 needs to be reconsidered. Give me one day or 
two,
I'll create a GitHub issue for that and post the link here when it's ready.

Matthias

AW: Performance Issue With OpenSSL 1.1.1c

[Dr. Matthias St. Pierre]

Correction, Tomáš was correct: there is an ` # ifndef DEVRANDOM` surrounding
the problematic code:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/e_os.h#L25-L34

Neverthelesss, I still think this code needs to be changed, because the seeding
should just work correctly out-of-the-box without having to add special
defines on the commandline.

Matthias

AW: Performance Issue With OpenSSL 1.1.1c

[Dr. Matthias St. Pierre]

> To workaround the /dev/random blocking issue, you can just add:
> 
> -DDEVRANDOM="\"/dev/urandom\""
> 
> as a parameter to ./Configure
> 
> This will remove the special handling of /dev/urandom and /dev/random
> in 1.1.1c.


Tomáš, Jay,

I'm afraid this suggestion won't help, because `DEVRANDOM_WAIT` is defined
unconditionally in e_os.h:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/e_os.h#L30-L34

This means that the select() call will happen on linux independently of what
`DEVRANDOM` is defined to be:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/crypto/rand/rand_unix.c#L509-L535

I think that pull request #8251 needs to be reconsidered. Give me one day or 
two, 
I'll create a GitHub issue for that and post the link here when it's ready.

Matthias

Re: Forthcoming OpenSSL Releases

[Matthias St. Pierre]

On 29.05.19 15:05, The Doctor wrote:

For the next branch of OpenSSL is it 1.1.2 or 1.2.0 ?



The next major release will be 3.0.0. See
https://www.openssl.org/blog/blog/2018/11/28/version 

for an explanation.

Matthias

AW: Performance Issue With OpenSSL 1.1.1c

[Dr. Matthias St. Pierre]

> I think I have tracked down the change in 1.1.1c that is causing this.
> It is the addition of the DEVRANDOM_WAIT functionality for linux in
> e_os.h and crypto/rand/rand_unix.c.  lighttpd (libcrypto) is waiting in
> a select() call on /dev/random.  After this eventually wakes up, it then
> reads from /dev/urandom.  OpenSSL 1.1.1b did not do this, but instead
> just read from /dev/urandom.  Is there more information about this
> change (i.e., a rationale)?  I did not see anything in the CHANGES file
> about it.

The original discussions for this change can be found on GitHub:

- issue #8215, fixed by pull request #8251 
- issue #8416, fixed by pull request #8428

(see links below).

And you are right, the change should have been mentioned in
the CHANGES file. Apologies for that.


HTH,
Matthias


https://github.com/openssl/openssl/issues/8215
https://github.com/openssl/openssl/pull/8251

https://github.com/openssl/openssl/issues/8416
https://github.com/openssl/openssl/pull/8428

AW: Slightly funny tar ball for openssl 1.1.1c ?

[Dr. Matthias St. Pierre]

> -Ursprüngliche Nachricht-
> I don't thing I have seen this before :
> 
> beta $ gzip -dc ../src/openssl-1.1.1c.tar.gz | tar -xf -
> tar: pax_global_header: typeflag 'g' not recognized, converting to
> regular file
> beta $
> 
> Must be a gnu tar thing?

Hi Dennis,

it's not a bug, it's a feature.  ;-)

No seriously: it's the `git archive` command which is used to export the tree
into a tarfile. It adds an extended header containing the commit hash of the
commit which was exported. Older tar programs don't know how to deal
with that header and are a bit confused about it.

We had a similar discussion after 1.1.1b was released, it started here
https://mta.openssl.org/pipermail/openssl-users/2019-February/009936.html

see in particular reply
https://mta.openssl.org/pipermail/openssl-users/2019-February/009949.html

and the links to the LKML which it contains
https://lkml.org/lkml/2005/6/18/5
https://marc.info/?l=linux-kernel&m=111909182607985&w=2

HTH,
Matthias

AW: why does RAND_add() take "randomness" as a "double"?

[Dr. Matthias St. Pierre]

I think nobody of us needs to be convinced anymore that making it a 'double' 
was a bad idea.
But the RAND api is very ancient and changing the argument type would be a 
breaking change. 
That's why we didn't dare to touch it when we overhauled the RNG implementation 
for 1.1.1,
because we tried very hard not to add unnecessary breaking changes to the ones 
made in 1.1.0.

Matthias

AW: Building openssh7.9p1 and above against openssl1.1.1b

[Dr. Matthias St. Pierre]

If the compilation errors are in openssh, then it might be better to ask the 
openssh people.
Also, posting the precise error messages by the compiler would be of great help.
As for your citation below: It seems to state that building against version 
1.1.0 and 1.1.1 is supported,
while building against version 1.0.2 will be supported until it is end-of-life, 
which is by the end of this year.

HTH,
Matthias


Von: openssl-users  Im Auftrag von Samiya 
Khanum via openssl-users
Gesendet: Mittwoch, 15. Mai 2019 04:55
An: openssl-users@openssl.org
Betreff: Building openssh7.9p1 and above against openssl1.1.1b

Hi,

After upgrading openssl to 1.1.1b, I am getting compilation errors in the 
openssh code.

Does Openssh 7.9p1 and above versions support building against the openssl 
1.1.1b version?
In Openssh release notes, below note is mentioned:

All: support building against the openssl-1.1 API (releases 1.1.0g

   and later). The openssl-1.0 API will remain supported at least

   until OpenSSL terminates security patch support for that API version.

Does this mean it is supported?
Thanks & Regards,
Samiya khanum

Re: Reg solaris support for openssl 1.1.1b

[Matthias St. Pierre]

My guess is that your binary is loading the system's shared libraries.
To find out whether this is the case, try

    ldd bin/openssl

If my assumption is correct, you might have to set the LD_LIBRARY_PATH 
explicitely.

HTH,
Matthias


On 15.03.19 09:43, ramakrushna mishra wrote:

Hi,

I am trying to upgrade openssl on solaris machine from 1.1.0e to 1.1.1b.
The "uname -a " output from solaris is :

SunOS  5.10 Generic_147147-26 sun4v sparc sun4v


The Configure and installation of openssl was successful.
But when i run "bin/openssl version" it fails with following error.

 "openssl version

ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: 
referenced symbol not found".


could you please anyone let me know what could be the problem ?


Thanks and regards,

Ram Krushna

Re: Developers, a small request

[Matthias St. Pierre]

On 13.03.19 21:09, Richard Levitte wrote:


So yeah, we do need to remember that PRs go through the CIs before
merging.



Agreed, and thanks Rich for the polite reminder :-)

Matthias

AW: AES-cipher offload to engine in openssl-fips

[Dr. Matthias St. Pierre]

> Uhm, I'm confused. I thought we were talking about 3.0?

Well, the original post started at FIPS 2.0:

  > I am using openssl-fips-2.0.16 and openssl-1.0.2e.
  https://mta.openssl.org/pipermail/openssl-users/2019-February/009919.html

But it seems like the discussion in the thread has drifted a little towards the 
FIPS 3.0 future,
which explains our mutual confusion. For that reason it is even more important 
that we don't
use legacy terms like "FIPS capable" in the context of FIPS 3.0 and stick to 
"FIPS Providers"
(or whatever correct new terms are; I'm currently not 100% up-to-date) instead.

Matthias

AW: AES-cipher offload to engine in openssl-fips

[Dr. Matthias St. Pierre]

> -Ursprüngliche Nachricht-
> > >I always understood "FIPS-capable OpenSSL" to refer specifically to an
> > OpenSSL compiled with the options to incorporate the FIPS canister
> > module, not just any OpenSSL build that might be used in FIPS compliant
> > applications (as that would be any OpenSSL at all).
> >
> > Yes, that is historically correct.  I don't believe the project uses
> > the term "FIPS-capable OpenSSL" any more.  Instead, the design and
> > such talk about a FIPS module which OpenSSL can use.
> 
> Correct.

I disagree: The term "FIPS Capable OpenSSL" is a technical term from the 
OpenSSL FIPS 2.0
User Guide (https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) and has a very 
clear and
precise meaning:

It refers to an OpenSSL 1.0.2 (or 1.0.1) library configured and built with 
`./configure fips ...`
in order to integrate the FIPS Object Module. Until FIPS 3.0 has been released 
and FIPS 2.0
is history, we should stick to that definition and not confuse FIPS users by 
reinterpreting it
or pretend that it is not used anymore or has a different meaning nowadays.

Matthias

--

You find the details in Sections 4.2.3 resp. 4.3.3 of  
https://www.openssl.org/docs/fips/UserGuide-2.0.pdf.

4.2.3 Building a FIPS Capable OpenSSL  (Unix/Linux)
4.3.3 Building a FIPS Capable OpenSSL  (Windows)

Here a brief excerpt:

Once the validated FIPS Object Module has been generated it is usually combined 
with an
OpenSSL distribution in order to provide the standard OpenSSL API. Any 1.0.1 or 
1.0.2 release
can be used for this purpose. The commands
./config fips <...other options...>
make <...options...>
make install
will build and install the new OpenSSL without overwriting the validated FIPS 
Object Module
files. The FIPSDIR environment variable or the --with­fipsdir command line 
option can
be used to explicitly reference the location of the FIPS Object Module 
(fipscanister.o).

The combination of the validated FIPS Object Module plus an OpenSSL 
distribution built in this
way is referred to as a FIPS capable OpenSSL, as it can be used either as a 
drop-in replacement for
a non-FIPS OpenSSL or for use in generating FIPS mode applications.

Re: AW: OpenSSL version 1.1.1b published

[Matthias St. Pierre]

On 27.02.19 13:51, Jan Ehrhardt wrote:

Matthias St. Pierre in gmane.comp.encryption.openssl.user (Wed, 27 Feb
2019 13:00:55 +0100):

On 27.02.19 10:09, Jan Ehrhardt wrote:

I ran into this using 7-Zip 18.05 (x64) on Windows, which is a fairly
recent version.

Thanks for the Updates about 7-Zip. But IMHO it is not really an issue, just a 
little 'manufacturing byproduct'.

It does not bother me at all. I just ignored it. But Thomas was right in
observing that it was different from the previous releases: OpenSSL
1.1.1a did not create that file when it was extracted by the same 7-zip
version.


This change was introduced by https://github.com/openssl/openssl/pull/7692:

Previously, the tarballs were created using the `tar` command, while nowadays 
it's done
using `git archive`,  see util/mktar.sh:

    git archive --worktree-attributes --format=tar --prefix="$NAME/" -v HEAD \
    | gzip -9 > "$TARFILE.gz"


And it's git that adds this comment.

Matthias

Re: AW: OpenSSL version 1.1.1b published

[Matthias St. Pierre]

On 27.02.19 10:09, Jan Ehrhardt wrote:

Thomas J. Hruska in gmane.comp.encryption.openssl.user (Tue, 26 Feb 2019
23:07:53 -0700):

On 2/26/2019 10:05 PM, Dr. Matthias St. Pierre wrote:

Hi Thomas,


Unlike previous releases, this tar-gzipped file contains a 52 byte file
called 'pax_global_header'.  The contents of the file contain a single
line of text:

52 comment=50eaac9f3337667259de725451f201e784599687

my extracted tarball does not contain this file. This seems to be a bug of the 
tar command which was fixed in 1.14.

https://lkml.org/lkml/2005/6/18/5
https://marc.info/?l=linux-kernel&m=111909182607985&w=2

HTH,
Matthias

Okay.  Certain versions of 7-Zip seem to be affected.  Just a FYI in
case anyone else brings it up on the list.

I ran into this using 7-Zip 18.05 (x64) on Windows, which is a fairly
recent version.


Thanks for the Updates about 7-Zip. But IMHO it is not really an issue, just a 
little 'manufacturing byproduct'.
As Linus wrote on the LKML mailing list: this file can safely be 
ignored/removed. Alternatively, you
can view it as a feature, because this file actually contains useful 
information: It's the id of the commit
from whose tree the tar file was created:

https://github.com/openssl/openssl/commit/50eaac9f3337667259de725451f201e784599687

If it really disturbs you, you might want to get in touch with the 7-Zip 
Developers on their SourceForge Forum.

https://sourceforge.net/p/sevenzip/discussion/search/?q=pax_global_header


Regards,
Matthias

AW: OpenSSL version 1.1.1b published

[Dr. Matthias St. Pierre]

Hi Thomas,

> Unlike previous releases, this tar-gzipped file contains a 52 byte file
> called 'pax_global_header'.  The contents of the file contain a single
> line of text:
> 
> 52 comment=50eaac9f3337667259de725451f201e784599687

my extracted tarball does not contain this file. This seems to be a bug of the 
tar command which was fixed in 1.14.

https://lkml.org/lkml/2005/6/18/5
https://marc.info/?l=linux-kernel&m=111909182607985&w=2

HTH,
Matthias

Re: [openssl-users] Possible bug in crypto/engine

[Dr. Matthias St. Pierre]

Sorry, the command contains a little error: please replace `gdb …` by `gdb 
–args …`:

util/shlib_wrap.sh  gdb  --args apps/openssl cms -sign -signer cert.pem 
-inkey 101 -keyform engine -engine pkcs11

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

Re: [openssl-users] Possible bug in crypto/engine

[Dr. Matthias St. Pierre]

Antonio,

did you debug the preinstalled openssl app or have you tried to debug your own 
version, built with a debug configuration?

You get the best results in the debugger if you use the `debug-linux-x86_64` 
config target and
after building (you only need to run `make`, not `make install`) run it in the 
debugger directly from the source
directory as follows:

util/shlib_wrap.sh  gdb  apps/openssl cms -sign -signer cert.pem -inkey 101 
-keyform engine -engine pkcs11

If you can reproduce the crash with your debug version, please post a backtrace 
of the call stack when it’s stopped
at the segmentation fault.

HTH,
Matthias

Von: openssl-users  Im Auftrag von Antonio 
Iacono
Gesendet: Sonntag, 6. Januar 2019 19:55
An: openssl-users@openssl.org
Betreff: [openssl-users] Possible bug in crypto/engine

Hi,

I sign a text file with:
openssl cms -sign -signer cert.pem -inkey 01 -keyform engine -engine pkcs11
in openssl.cnf
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /path/pkcs11.so
MODULE_PATH = /path/opensc-pkcs11.so
everything works well but if I write a wrong key, es. -inkey 101, this is gdb 
result:

PKCS11_get_private_key returned NULL
cannot load signing key file from engine
140737353990592:error:26096080:engine routines:ENGINE_load_private_key:failed 
loading private key:crypto/engine/eng_pkey.c:78:
unable to load signing key file
Program received signal SIGSEGV, Segmentation fault.
__GI___pthread_rwlock_wrlock (rwlock=0x0) at pthread_rwlock_wrlock.c:27
27pthread_rwlock_wrlock.c: No such file or directory

I realized that the error is probably here:
crypto/engine/eng_lib.c line 93
if (e->destroy)
e->destroy(e);
CRYPTO_free_ex_data(CRYPTO_EX_INDEX_ENGINE, e, &e->ex_data);
if I comment these lines openssl does not crash

I do not know engine well and I do not know what these two lines do, if anyone 
has any suggestions I can do some tests

Thanks,
Antonio Iacono
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Dr. Matthias St. Pierre]

>  |Both manpages got an update during the DRBG rewrite (by me) and I don't
>  |see any contradiction. You bring it to the point yourself:
> 
> I had a superficial look yesterday, but i think i have to reread
> them in total, anyway.

Yes, please start with RAND(7) and RAND_DRBG(7).

> That is really bad.  Of course you had to do it like this, and you
> surely have looked around to see what servers and other software
> which use OpenSSL do with the PRNG after forking (i.e., whether
> they reiterate the [RAND_file_name(),] RAND_load_file(),
> [:[RAND_add(),] RAND_status()], [RAND_write_file()] dance as
> documented, or not).

I really don't understand your frustration: the new PRNG was designed
to relieve the application from the burden of seeding. It is easier to use,
not more complicated: No need to call RAND_add(), RAND_seed(),
RAND_load_file() and all this stuff. Just make sure the os entropy sources
are available and then simply use RAND_bytes(). But don't expect it to
succeed always.

> I think i will move away from RAND_ then, nonetheless, and at
> least for the things i have control of.

I don't think this is a good idea. In the case when there is no suitable entropy
source, the OpenSSL RNG will fail to generate random bytes, indeed.
But how do you expect your application to seed the RNG properly in this
case? What is your application's entropy source? If you have one, which
OpenSSL does not handle yet, you could theoretically register your
own get_entropy callback for the master DRBG at application startup time.

But if you don't have a better entropy source than OpenSSL, you are bound to
fail, too. And isn't it better for your application to fail gracefully in this 
case
than to provide snake oil security?

HTH,
Matthias


P.S: As for automatic reseeding: There are potential issues when upgrading
applications which do a fork and chroot from 1.1.0 to 1.1.1. Because in
version 1.1.1, the application will reseed after fork, and the reseeding can 
fail
if the application developer (or administrator) did not pay attention to provide
a random device in the chroot jail. This was no problem with 1.1.0 and below,
because the RNG never reseeded automatically.

OpenSSL does everything to avoid such a chroot reseeding failure (#6432 and 
#7437).
Also, on modern linux systems OpenSSL will prefer the getrandom system call
which does not have this limitation of the random devices. 


https://github.com/openssl/openssl/pull/6432
https://github.com/openssl/openssl/pull/7437



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

Re: [openssl-users] RNG behavior by default

[Dr. Matthias St. Pierre]

I agree with Kurt, except for one point:

> The RAND_bytes and RAND_status manpages can clearly be improved.

Both manpages got an update during the DRBG rewrite (by me) and I don't
see any contradiction. You bring it to the point yourself:

> So _IF_ it is seeded it is seeded...

It is true that the DRBG will automatically seed, but it is equally true
that it can still end up in an unseeded (error) state, if no suitable entropy
source is available. And since this can also happen during reseeding (which
in particular is enforced after a fork), it is always necessary to check the 
return
value of the RAND_bytes() function. Because in the error state, the buffer is 
not
filled at all.

Matthias


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

Re: [openssl-users] RNG behavior by default

[Dr. Matthias St. Pierre]

> So my concerns are:
> 1. Whether I really can count on getting a high-entropy PRNG across these 
> various platforms, without any explicit initialization.

Yes, for the mentioned platforms, the default configuration is 
`--with-rand-seed=os`, which means the DRBG automatically seeds
and reseeds using os entropy sources.

2. If something goes wrong with PRNG initialization, that it will fail hard 
rather than fall back to something less secure. And if so how I detect such a 
failure.

If the (re-)seeding fails, the DRBG enters an error state. When you try to 
generate random bytes it will detect the error state and try
automatically to heal the error state by reinstantiating. But if reseeding 
fails, it will return and error code and not generate any pseudo random bytes.

Citing from the manual pages:

OpenSSL comes with a default implementation of the RAND API which is 
based on the
deterministic random bit generator (DRBG) model as described in [NIST 
SP 800-90A Rev. 1].
The default random generator will initialize automatically on first use 
and will be fully functional
without having to be initialized ('seeded') explicitly. It seeds and 
reseeds itself automatically using
trusted random sources provided by the operating system.

As a normal application developer, you do not have to worry about any 
details, just use RAND_bytes(3)
to obtain random data. Having said that, there is one important rule to 
obey: Always check the error
return value of RAND_bytes(3) and do not take randomness for granted.

https://www.openssl.org/docs/man1.1.1/man7/RAND.html

(See also https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html)

Matthias

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

Re: [openssl-users] Build target architecture

[Dr. Matthias St. Pierre]

> After some searching and check, I've realized that openssl is not configured 
> for different target architectures?
> I develop an application for Android using NDK(Native Development Kit).
> There is Configurations/15-android.conf inside openssl git repo, but could 
> not be sure. 

> Could someone advise for the right usage. There is also opensslconf.h, and I 
> was thinking adding macros and use it.
> I use Ubuntu16 and Mac-HighSierra as development OS. Thanks

If it's your first time you try compiling OpenSSL, I'd recommend you start with 
reading the INSTALL instructions and the
platform specific NOTES.ANDROID instructions first. There you will hopefully 
find the answers to your questions.
You find those two text files in the root of your OpenSSL source directory. You 
can also view them directly on GitHub at

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/INSTALL

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.ANDROID

The `opensslconf.h` file is not intended to be edited. It is created by the 
.\Configure script from the `opensslconf.h.in` template.
Also the `Configurations/*.conf` files which are part of the tarball are 
normally not intended to be edited, unless you
intend to get you changes merged upstream. But you are free to add your own 
configuration file if it really turns out to be necessary.
The config files also support inheritance, so you can derive from an existing 
configuration and apply incremental changes.

HTH,

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

Re: [openssl-users] openssl 1.1.1 manuals

[Dr. Matthias St. Pierre]

> The docs site is screwed up.

Actually, it is screwed up for the older versions, not for 1.1.1:
In OpenSSL 1.1.0 and before, the pod files (the manual page sources)
would be located in /doc/crypto and /doc/ssl, 
and only during the installation would be placed in the proper manX
subdirectory (X=1,3,5,7). Starting with OpenSSL 1.1.1, the pod files are
now reorganized in subdirectories doc/man1, doc/man3, doc/man5,
doc/man7, reflecting the manual section where they will finally be installed.

So the path is correct for 1.1.1 and screwed up for 1.1.0 and below.

https://www.openssl.org/docs/man1.1.1/man3/CMS_sign.html

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

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

Re: [openssl-users] openssl 1.1.1 manuals

[Dr. Matthias St. Pierre]

> Particularly if you don't know exactly what one is looking for...
> { There is something amiss with BIO_addr_rawaddress... it's shift right.
>   I don't see a problem in the HTML source though.. }
> 
> Sure, google will find some things, but usually it's the wrong version, and
> one has to guess what the URL for the most recent one is.
> 
> At which point, like Dennis Clarke suggests, might as well grep the POD files
> in the source code.  This is not terribly effective to find information
> about how to manipulate particular object types.
> 
> (I have started writing an index by object type for my own use, but I doubt
> I'll get very far)

The manpages are primarily what the name says: manual pages. I.e, their
primary use is the unix/linux 'man' command.

The conversion to html is an add-on to make it available via web server.
And I agree with you that static web pages are not of much help, it could
be better, more searchable.

As for grepping the POD files: There is a much simpler solution if you are using
bash on linux: Install your manual pages locally, add them to your MANPATH, and
marvel at the power of bash's tab completion.

Disclaimer: Unless you know what you are doing, you should not replace your
distribution's copy of OpenSSL by your own, but instead install it to a separate
location. For example, I have all my openssl library versions installed locally 
in 

  /opt/openssl-dev
  /opt/openssl-1.1.1-dev
  /opt/openssl-1.1.0-dev
  /opt/openssl-1.0.2-dev

(By configuring with --prefix=/opt/openssl-dev (etc.) and then running
'make -j 16 ; sudo make install'.)

Additionally, I have a simple script and a set of aliases 'ossl', 'ossl111'
to set the MANPATH accordingly:

  cat ~/.osslpath
  export PATH=${OSSLPATH}/bin:$ORI_PATH
  export LD_LIBRARY_PATH=${OSSLPATH}/lib:$ORI_LD_LIBRARY_PATH
  export MANPATH=${OSSLPATH}/${OSSL_MANPATH}:$ORI_MANPATH

  msp@msppc:~$ alias ossl
  alias ossl='export OSSLPATH=/opt/openssl-dev   ; OSSL_MANPATH=share/man 
source ~/.osslpath ; echo $OSSLPATH: $(openssl version)'

  msp@msppc:~$ alias ossl111
  alias ossl111='export OSSLPATH=/opt/openssl-1.1.1-dev ; 
OSSL_MANPATH=share/man source ~/.osslpath ; echo $OSSLPATH: $(openssl version)'

($ORI_PATH is initally set to $PATH in my .bashrc, and the same holds for the 
other $ORI_XXX)

Changing to the manual pages for the correct openssl version is now a matter of
a single command,

  msp@msppc:~$ ossl
  /opt/openssl-dev: OpenSSL 3.0.0-dev xx XXX 

And voila, if your tab completion is setup correctly, help is only two s 
away:
  
  msp@msppc:~$ man BIO_new  
  BIO_new BIO_new_file
  BIO_new_CMS BIO_new_fp
  BIO_new_accept  BIO_new_mem_buf
  BIO_new_bio_pairBIO_new_socket
  BIO_new_buffer_ssl_connect  BIO_new_ssl
  BIO_new_connect BIO_new_ssl_connect
  BIO_new_fd


Matthias

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

Re: [openssl-users] openssl 1.1.1 manuals

[Dr. Matthias St. Pierre]

> Generally I find everything I need in the source tarball and after the
> install is done everything anyone could want is installed on the system.
> As for 'sidenav' that sounds like someone actually has to go tweak stuff
> manually on some website. Sadly. Anyways, the source tarballs have
> everything that is for certain. A lot of symlinks to be sure.
> 
> Dennis

All supported manual page versions are publicly available from this site here.
https://www.openssl.org/docs/manpages.html

The missing link in the manual side bar is an oversight, which will be
fixed shortly, see https://github.com/openssl/web/pull/100

HTH,

Matthias



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

Re: [openssl-users] The 9 Lives of Bleichenbacher's CAT - Is there a CVE for OpenSSL?

[Dr. Matthias St. Pierre]

> The paper does not list the CVE for the openssl vulnerability.
> 
> Is there a CVE for this?  What are the affected versions and in which
> version they were fixed?

A similar question has been asked at the end of the GitHub issue
https://github.com/openssl/openssl/issues/7739. As far as I know,
the question is still unanswered...

HTH
Matthias



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

Re: [openssl-users] Error: does not have a number assigned

[Matthias St. Pierre]

Yes, that would be a good idea. Although it does not prevent merge conflicts, 
at least the ordinals
don't have to be renumbered every time. (That's the way we solved the problem 
in our company.)

On 27.11.18 15:58, Viktor Dukhovni wrote:

On Nov 27, 2018, at 7:38 AM, Dr. Matthias St. Pierre 
 wrote:

Short version: Just do 'make update' and the numbers will be added 
automagically.

Long version:  There  is a script, 'util/mkdef.pl', which gets invoked by 'make 
update'. It scans the header files
for new APIs an updates the .num files  (libcrypto.num/libeay.num and 
libssl.num) accordingly. For windows,
it also  updates the module definition files (*.def).

It might be prudent for the OP to assign a high value that OpenSSL
will not likely ever reach. Start at 32767 and count down for site-local
ordinals?



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

Re: [openssl-users] Error: does not have a number assigned

[Dr. Matthias St. Pierre]

Short version: Just do 'make update' and the numbers will be added 
automagically.

Long version:  There  is a script, 'util/mkdef.pl', which gets invoked by 'make 
update'. It scans the header files
for new APIs an updates the .num files  (libcrypto.num/libeay.num and 
libssl.num) accordingly. For windows,
it also  updates the module definition files (*.def).
 
So 'make update' will add your new API function. But be warned: As Jakob 
already mentioned, if you update
OpenSSL it can happen that you get merge conflicts (if you use git) or your 
numbers will get overwritten
(if you extract tarballs). You will have to renumber you symbols (or remove 
them and run 'make update' again).

HTH,
Matthias


> -Ursprüngliche Nachricht-
> Von: openssl-users  Im Auftrag von Jakob 
> Bohm via openssl-users
> Gesendet: Dienstag, 27. November 2018 12:09
> An: openssl-users@openssl.org
> Betreff: Re: [openssl-users] Error: does not have a number assigned
> 
> On 27/11/2018 11:50, EYAL INBAR wrote:
> > Hello
> >
> > I try to add API,CMP_build_KUR_req, to crypto lib and get
> >
> > Error: CMP_build_KUR_req does not have a number assigned
> >
> > Any suggestion?
> This means you are compiling for a platform (probably Windows
> or OS/2) where names exported from DLLs are assigned unique
> numbers for fast lookup during application load.
> 
> There is a source file in OpenSSL giving the assigned numbers.
> You will need to add numbers for you additional exports, and
> deal with the risk that a future OpenSSL release uses that
> number for something else.
> 
> 
> 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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to compile 1.1.1 under Windows

[Dr. Matthias St. Pierre]

Oh, I should have read your mail until the end:

Are you upgrading from 1.0.0h or 1.1.0h? Your post mentions both versions.

> -Ursprüngliche Nachricht-
> Von: openssl-users  Im Auftrag von Dr. 
> Matthias St. Pierre
> Gesendet: Dienstag, 23. Oktober 2018 09:17
> An: openssl-users@openssl.org
> Betreff: Re: [openssl-users] How to compile 1.1.1 under Windows
> 
> Hi,
> 
> a lot of structures where made opaque going from 1.0.2 to 1.1.0.
> This means, you will have to make changes to your program source code
> to compile it against 1.1.0 or 1.1.1.
> 
> For details, see https://www.openssl.org/docs/faq.html#PROG2
> 
> HTH,
> Matthias
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: openssl-users  Im Auftrag von Chris 
> > Clark
> > Gesendet: Dienstag, 23. Oktober 2018 08:51
> > An: openssl-users@openssl.org
> > Betreff: [openssl-users] How to compile 1.1.1 under Windows
> >
> > I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> > 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> > 1.1.1 for VC-WIN64A I get the following compile error:
> >
> >cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> > -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> > -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> > -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> > -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> > -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> > -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> > Files\\Common Files\\SSL\""
> > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> > "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> > NMAKE : fatal error U1077: 'cl' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > Stop.
> >
> > My Command lines from the VS 2008 x64 Command Prompt are:
> > perl Configure VC-WIN64A --prefix=c:/openssl
> > nmake
> >
> > I also tried compiling the latest stable snapshot
> > (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> > version 1.1.0h compiles without error. Can anyone tell me what the
> > problem is?
> >
> > Here is the configuration dump:
> >
> > Command line (with current working directory = .):
> > c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> > Perl information:
> > c:\perl\bin\perl.exe
> > 5.24.3 for MSWin32-x64-multi-thread
> > Enabled features:
> > aria
> > asm
> > async
> > autoalginit
> > autoerrinit
> > autoload-config
> > bf
> > blake2
> > camellia
> > capieng
> > cast
> > chacha
> > cmac
> > cms
> > comp
> > ct
> > deprecated
> > des
> > dgram
> > dh
> > dsa
> > dso
> > dtls
> > dynamic-engine
> > ec
> > ec2m
> > ecdh
> > ecdsa
> > engine
> > err
> > filenames
> > gost
> > hw(-.+)?
> > idea
> > makedepend
> > md4
> > mdc2
> > multiblock
> > nextprotoneg
> > ocb
> > ocsp
> > pic
> > poly1305
> > posix-io
> > psk
> > rc2
> > rc4
> > rdrand
> > rfc3779
> > rmd160
> > scrypt
> > seed
> > shared
> > siphash
> > sm2
> > sm3
> > sm4
> > sock
> > srp
> > srtp
> > sse2
> > ssl
> > static-engine
> > stdio
> > tests
> > threads
> > tls
> > ts
> >

Re: [openssl-users] How to compile 1.1.1 under Windows

[Dr. Matthias St. Pierre]

Hi,

a lot of structures where made opaque going from 1.0.2 to 1.1.0.
This means, you will have to make changes to your program source code
to compile it against 1.1.0 or 1.1.1.

For details, see https://www.openssl.org/docs/faq.html#PROG2

HTH,
Matthias


> -Ursprüngliche Nachricht-
> Von: openssl-users  Im Auftrag von Chris 
> Clark
> Gesendet: Dienstag, 23. Oktober 2018 08:51
> An: openssl-users@openssl.org
> Betreff: [openssl-users] How to compile 1.1.1 under Windows
> 
> I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> 1.1.1 for VC-WIN64A I get the following compile error:
> 
>cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> Files\\Common Files\\SSL\""
> -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> NMAKE : fatal error U1077: 'cl' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> Stop.
> 
> My Command lines from the VS 2008 x64 Command Prompt are:
> perl Configure VC-WIN64A --prefix=c:/openssl
> nmake
> 
> I also tried compiling the latest stable snapshot
> (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> version 1.1.0h compiles without error. Can anyone tell me what the
> problem is?
> 
> Here is the configuration dump:
> 
> Command line (with current working directory = .):
> c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> Perl information:
> c:\perl\bin\perl.exe
> 5.24.3 for MSWin32-x64-multi-thread
> Enabled features:
> aria
> asm
> async
> autoalginit
> autoerrinit
> autoload-config
> bf
> blake2
> camellia
> capieng
> cast
> chacha
> cmac
> cms
> comp
> ct
> deprecated
> des
> dgram
> dh
> dsa
> dso
> dtls
> dynamic-engine
> ec
> ec2m
> ecdh
> ecdsa
> engine
> err
> filenames
> gost
> hw(-.+)?
> idea
> makedepend
> md4
> mdc2
> multiblock
> nextprotoneg
> ocb
> ocsp
> pic
> poly1305
> posix-io
> psk
> rc2
> rc4
> rdrand
> rfc3779
> rmd160
> scrypt
> seed
> shared
> siphash
> sm2
> sm3
> sm4
> sock
> srp
> srtp
> sse2
> ssl
> static-engine
> stdio
> tests
> threads
> tls
> ts
> ui-console
> whirlpool
> tls1
> tls1-method
> tls1_1
> tls1_1-method
> tls1_2
> tls1_2-method
> tls1_3
> dtls1
> dtls1-method
> dtls1_2
> dtls1_2-method
> Disabled features:
> afalgeng[not-linux]
> asan[default]   OPENSSL_NO_ASAN
> crypto-mdebug   [default]   OPENSSL_NO_CRYPTO_MDEBUG
> crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> devcryptoeng[default]   OPENSSL_NO_DEVCRYPTOENG
> ec_nistp_64_gcc_128 [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
> egd [default]   OPENSSL_NO_EGD
> external-tests  [default]   OPENSSL_NO_EXTERNAL_TESTS
> fuzz-libfuzzer  [default]   OPENSSL_NO_FUZZ_LIBFUZZER
> fuzz-afl[default]   OPENSSL_NO_FUZZ_AFL
> heartbeats  [default]   OPENSSL_NO_HEARTBEATS
> md2 [default]   OPENSSL_NO_MD2 (skip crypto\md2)
> msan[default]   OPENSSL_NO_MSAN
> rc5 [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
> sctp[default]   OPENSSL_NO_SCTP
> ssl-trace   [default]   OPENSSL_NO_SSL_TRACE
> ubsan   [default]   OPENSSL_NO_UBSAN
> unit-test   [default]   OPENSSL_NO_UNIT_TEST
> weak-ssl-ciphers[default]   OPENSSL_NO_WEAK_SSL_CIPHERS
> zlib[default]
> zlib-dynamic[default]
> ssl3[default]   OPENSSL_NO_SSL3
> ssl3-method [default]   OPENSSL_NO_SSL3_METHOD
> Config target attributes:
> AR => "lib",
> ARFLAGS => "/nologo",
> AS => "nasm",
> ASFLAGS => "-g",
> CC => "cl",
> CFLAGS => "/W3 /wd4090 /nologo 

Re: [openssl-users] Seeding before RSA key generation

[Dr. Matthias St. Pierre]

> -Ursprüngliche Nachricht-
> Von: openssl-users  Im Auftrag von Paul 
> Dale
> Gesendet: Freitag, 5. Oktober 2018 01:33
> An: openssl-users@openssl.org
> Betreff: Re: [openssl-users] Seeding before RSA key generation
> 
> Not mentioned thus far is that if you are using 1.0.2 with FIPS support, the 
> random number generator does not self-seed.

This is true, but it will be fixed in the next letter release 1.0.2q, see commit

https://github.com/openssl/openssl/commit/f58001c35f39c50cb4aabcbc234d871ac740c179

which has been added recently to the OpenSSL_1_0_2-stable branch.

Matthias

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

Re: [openssl-users] Certificate format question?

[Dr. Matthias St. Pierre]

> -Ursprüngliche Nachricht-
> In the meantime:
> 
>$ perl -ne 'print if (/^-BEGIN/../^-END/);' foo.pem |
>openssl asn1parse
> 
> > On Sep 25, 2018, at 1:15 PM, Hubert Kario  wrote:
> >
> > then it looks like the parser used in asn1parse -inform pem is non-
> > compliant...
> >
> > https://github.com/openssl/openssl/issues/7317

Starting with version 1.1.0, the asn1parse has the -strictpem option to deal
with exactly this case.

I just submitted a pull request on GitHub which attempts to make RFC compliance
the default behavior and introduces a new '-inform b64' option for raw base64
parsing.

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

I would be interested in your (the users) opinion about whether this should
become the new default in the future, or whether raw base64 parsing should
remain the default.

Matthias

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

Re: [openssl-users] Manpages still say "pre-release"

[Dr. Matthias St. Pierre]

Thanks for the reminder, see   https://github.com/openssl/web/pull/83.

Matthias

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

Re: [openssl-users] openssl 1.0.2 and TLS 1.3

[Dr. Matthias St. Pierre]

> Von: openssl-users  Im Auftrag von The 
> Doctor
> Gesendet: Dienstag, 11. September 2018 08:49
> An: openssl-users@openssl.org; openssl-...@openssl.org
> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3
> 
> Will that combination occur?

Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released 
today.
OpenSSL 1.0.2 is an LTS release which will only receive security updates and no 
new
features.

HTH,
Matthias

See also
https://wiki.openssl.org/index.php/TLS1.3
https://www.openssl.org/policies/releasestrat.html



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