Re: PRNG not available when multiple providers are configured?

On 03/11/2020 18:03, Tomas Mraz wrote: > On Tue, 2020-11-03 at 15:13 +0000, Matt Caswell wrote: >> >> The reasons are a little complicated (see below) but the TL;DR >> summary >> is that there is an error in your config file. The ".include" line >

Re: PRNG not available when multiple providers are configured?

On 03/11/2020 15:13, Matt Caswell wrote: > I've seen this error a few times now so I'm thinking that we should > perhaps allow absolute paths. I'm not sure what the reason for > disallowing them was. I raised this issue about this: https://github.com/openssl/openssl/issues/13302 &g

Re: PRNG not available when multiple providers are configured?

On 03/11/2020 00:55, Thomas Dwyer III wrote: > I'm having trouble getting RAND_status() to return 1 when my openssl.cnf > has both the default provider and the fips provider configured at the > same time: > >         openssl_conf = openssl_init > >         [openssl_init] >         providers =

Re: Decrypt error when using openssl 1.1.1b during SSL handshake

n hardware and return the correct data. > > Please suggest if you have any comments for the above info. > > Thanks > Mahendra > > On Fri, Oct 30, 2020 at 7:50 PM Matt Caswell <mailto:m...@openssl.org>> wrote: > > > > On 30/10/2020 11:22, Mahe

Re: Decrypt error when using openssl 1.1.1b during SSL handshake

is coming from as described above. Matt > If you need any further info, please let us know.  > image.png > Thanks > Mahendra > > Please suggest. > > > > On Fri, Oct 30, 2020 at 3:32 PM Matt Caswell <mailto:m...@openssl.org>> wrote:

Re: Decrypt error when using openssl 1.1.1b during SSL handshake

On 30/10/2020 09:18, Mahendra SP wrote: > Hi All. > > We have upgraded openssl version to 1.1.1b > > With this, we are seeing decryption error during SSL handshake for the > below explained scenario. Our device acts as an SSL server. > > We have external hardware to offload RSA private key

Re: How is the TLS Record Layer Version Selected?

On 29/10/2020 03:52, Thomas Antonio via openssl-users wrote: > Hello, how does openSSL determine the Record Layer Version used to > initiate a ClientHello message to the server? I believe the > determination is made at this level. > > When testing using multiple implementations (Python

Re: CAPI engine seems to break server validation

On 23/10/2020 14:10, Brett Stahlman wrote: > It seems that the CAPI engine is breaking the server verification somehow. > Note that the only reason I'm using the ca-bundle.crt is that I couldn't > figure out how to get CAPI to load the Windows "ROOT" certificate > store, which contains the

Re: OpenSSL version 1.1.1h published

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. Matt > > - >

Re: EVP_DigestSignUpdate missing from libcrypto

On 16/09/2020 15:23, Sage Gerard wrote: > I'm okay with using EVP_DigestSign, but both that and online materials > presume EVP_DigestSignUpdate's availability, and the source code does > not seem to have a directive to exclude the signature or implementation > at first glance. What can explain

Re: Removing difference between CLI and FFI use for computing a message digest

On 15/09/2020 22:48, Sage Gerard wrote: > I have a Racket program that uses libcrypto through FFI bindings to > compute digests. It's wrong because it returns different answers than > `openssl dgst`,regardless of hash algorithm. > > The code is here: >

Forthcoming OpenSSL Release

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1h. This release will be made available on Tuesday 22nd September 2020 between 1300-1700 UTC. OpenSSL 1.1.h is a bug-fix release. There are no CVEs

Re: OpenSSL Security Advisory

On 10/09/2020 16:14, Jakob Bohm via openssl-users wrote: > On 2020-09-10 09:03, Tomas Mraz wrote: >> On Wed, 2020-09-09 at 22:26 +0200, Jakob Bohm via openssl-users wrote: >>> Wouldn't a more reasonable response for 1.0.2 users have been to >>> force on >>> SSL_OP_SINGLE_DH_USE rather than

Re: Compiling OpenSSL without compabitlity with for OpenSSL 1.0

On 09/09/2020 20:43, Bjoern Bidar wrote: > /usr/bin/ld: ./libcrypto.so: undefined reference to `OpenSSLDie' > What version of OpenSSL are you trying to compile? I can't seem to replicate this. Matt

OpenSSL is looking for a full time Administrator and Manager

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The OpenSSL Management Committee are looking to hire a full time Administrator and Manager. Details of the role can be found here: https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole/ To apply please send your cover letter and

Re: OpenSSL 3.0.0 security concerns using dynamic providers

On 01/09/2020 16:46, CODERE Carl-Eric wrote: > Greetings, > Thanks for the quick reply, actually from the perspective > of mobile > security, once the platform sandbox has been compromised, it is much > easier for an attacker to replace a shared library with another one

Re: OpenSSL 3.0.0 security concerns using dynamic providers

On 01/09/2020 03:01, CODERE Carl-Eric wrote: > 1. Replacing the provider by a tampered provider by replacing the > shared/dynamic library. This can partially be protected by the caller > verifying the hash of the provider before calling it, will OpenSSL 3.0.0 > do this, or will need to be done

Re: enabling null cipher

This should do it: openssl s_server -cert /path/to/cert -key /path/to/key -cipher eNULL@SECLEVEL=0 -no_tls1_3 >From the client side: openssl s_client -cipher eNULL@SECLEVEL=0 Matt On 27/08/2020 05:32, vishwas k.n. wrote: > Hello All, > > Could someone please let me know what is the right

Re: Checking if a key can sign / verify in 3.0

On 19/08/2020 02:01, Norm Green wrote: > In 3.0 I see this new function in evp.h : > > int EVP_PKEY_can_sign(const EVP_PKEY *pkey); > > Is there an equivalent way to check if a key can verify? I'm not seeing > an obvious way to do that.  Previously I used > EVP_PKEY_meth_get_verifyctx() but

Re: SSL_ERROR_WANT_TIME: Pause SSL_connect to fetch intermediate certificates

On 19/08/2020 20:35, Alex Rousskov wrote: > Does this clarify what I meant? Do you agree that OpenSSL async API is > not suitable for callbacks that _require_ ASYNC_pause_job() to return > control to the application? Yes, it clarifies what you meant. And, yes, its true that strictly speaking

Re: SSL_ERROR_WANT_TIME: Pause SSL_connect to fetch intermediate certificates

On 18/08/2020 22:31, Alex Rousskov wrote: > As you know, OpenSSL provides the certificate verification callback that > can discover that the origin certificate chain is incomplete. An > application using threads or blocking I/O can probably "pause" its > verification callback execution, fetch

Re: Testing TLS 1.0 with OpenSSL master

On 17/08/2020 18:55, John Baldwin wrote: > 1) Is 'auth_level' supposed to work for this? The CHANGES.md change >references SSL_CTX_set_security_level and openssl(1) claims that >'-auth_level' changes this? Is the CHANGES.md entry wrong and only >SECLEVEL=0 for the ciphers work by

Re: OpenSSL compliance with Linux distributions

On 18/08/2020 05:10, Jakob Bohm via openssl-users wrote: > The key thing to do is to make those client applications not request the > ssl23-method from OpenSSL 0.9.x . > ssl23 explicitly requests this backward-compatibility feature while > OpenSSL 3.x.x apparently deleted the > ability to

Re: Adding support for OS/2 back to Open SSL 1.1.1.

On 17/08/2020 23:55, Roderick Klein wrote: > New to this list. I am looking at compiling OpenSSL 1.1.1. on OS/2 with > GCC. Would OpenSSL be willing to accept patches to re-enable OS/2 in the > OpenSSL ? Such patches are unlikely to be accepted into 1.1.1 since that is a stable release. 3.0

Re: OpenSSL FIPS for 1.1.x

so you'd have to seek guidance from those third parties. Matt > > Thanks, > -vijay > > On Mon, Aug 10, 2020 at 8:08 AM Matt Caswell <mailto:m...@openssl.org>> wrote: > > > > On 10/08/2020 16:01, Vijay Chander wrote: > > Hi, > > >

Re: OpenSSL FIPS for 1.1.x

On 10/08/2020 16:01, Vijay Chander wrote: > Hi, > > This link here below only seems to talk about 1.0.x > https://wiki.openssl.org/index.php/FIPS_Library_and_Android > > Is there a wiki for openssl fips for openssl-1.1.0x ? There is no FIPS module for the 1.1.x series. We are currently

Re: alternative to deprecated ENGINE_* API for external engines for openssl-3.0.0

On 31/07/2020 16:57, Emeric Brun wrote: > > Thanks! A lot to read! > > I have few questions: > > Do those changes have an impact on the external engine side API, specially > for Async engines? The most used engine with my application is the Intel > Quick Assist, in async mode. > > Does

Re: FIPS and default properties

On 31/07/2020 00:12, Thomas Dwyer III wrote: > Is the result of EVP_default_properties_is_fips_enabled() supposed to > take into account the default properties specified in the config file? I > don't see it doing that. Also, regarding #11594, if default properties > are currently still broken,

Re: alternative to deprecated ENGINE_* API for external engines for openssl-3.0.0

On 30/07/2020 16:06, Emeric Brun wrote: > Trying to compile my soft using openssl-3.0.0alpha5, I notice a lot of > warnings about deprecated ENGINE_* functions (since commit > 8dab4de53887639abc1152288fac76506beb87b3). > > Is-there any documentation on a new API/functions to handle

Re: How to help with getting KTLS patches merged

ad >>>> support that I'm aware of: >>>> >>>> - 11589 adds TLS1.3 for Linux, has one approval from Matt Caswell >>>> - 10626 adds TLS1.3 for FreeBSD, from which 11589 is derived, but will >>>> need to be rebased on top of 11589 once it is m

Re: Fwd: openssl support for PQUIC

On 23/07/2020 08:21, Samath Lokuge wrote: > Hello, > I am trying to install PQUIC set up for some testing. > https://pquic.org/  > > it says I need  "openssl-dev" but I could not find that package. > So I installed "openssl-1.1.1g" instead but it does not work. > I have 2 questions . > 1

Re: "rsa->meth->rsa_sign" method in Openssl 1.1.1g

On 21/07/2020 20:19, prudvi raj wrote: > > While upgrading to openssl 1.1.1 from 1.0.2k . > I came across this code snippet : >     if (rsa->flags & RSA_FLAG_SIGN_VER) >         return rsa->meth->rsa_sign (type, m, lLen, sigret, siglen, rsa); > > From Docs : > Enhance RSA_METHOD structure.

Re: TLSv1.3, AES and Apache2 on opensuse leap 15.2

On 21/07/2020 09:42, cryptearth wrote: > Hello Rüdiger, > > I got the same reply on the opensuse forums. > Yes, it does "fix" my "issue", but as the reply on the forums noted: > AES128 is mandatory for a 1.3 compliant implementation, AES128 is mandatory-to-implement for an RFC compliant

Re: OpenSSL 3.0 hangs at exit with FIPS provider

On 15/07/2020 18:20, Thomas Dwyer III wrote: > Platform: Linux x86_64 > > I understand this is still alpha but how complete is the FIPS provider > right now? Fairly complete. Please could you raise this as a github issue so that it can be properly investigated and tracked? > When I run

Re: Order of protocols in MinProtocol

On 08/07/2020 17:48, Klaus Umbach via openssl-users wrote: > On 08.07.20 12:21, Viktor Dukhovni wrote: >> On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: >> >>> On 08/07/2020 16:28, Viktor Dukhovni wrote: >>>>> How could I set the a System

Re: Order of protocols in MinProtocol

On 08/07/2020 17:21, Viktor Dukhovni wrote: > On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: > >> On 08/07/2020 16:28, Viktor Dukhovni wrote: >>>> How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? >>> >>

Re: Order of protocols in MinProtocol

On 08/07/2020 16:28, Viktor Dukhovni wrote: >> How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? > > AFAIK, that's not presently possible. You can specify application > profiles, for applications that specify an application name when > initializing OpenSSL. Or use

Re: FTP server

The infrastructure was upgraded on Thursday and so things were down for a while. Should all be back to normal now. If there are still problems then let us know. Matt On 04/07/2020 20:48, The Doctor wrote: > Have there been stablility issues lately? >

Re: manual edit: i2d_PKCS7_bio

On 30/06/2020 20:25, Michael Mueller wrote: > https://www.openssl.org/docs/man1.1.1/man3/i2d_PKCS7_bio.html > > current: > > i2d_TYPE_fp() is similar to i2d_TYPE() except it writes the encoding of > the structure a to BIO bp and it returns 1 for success and 0 for failure. > > Suggested

Re: Error building OpenSSL-1.1.1g

On 26/06/2020 14:30, Matt Caswell wrote: >> C:\Perl64\bin\perl.exe Try *removing* this perl from your %PATH%. It may well be that your MSYS2 environment already has perl available but this version is taking priority. Matt >> $ perl Configure mingw --pr

Re: Error building OpenSSL-1.1.1g

one from your path. Maybe we should add an FAQ section of common faults and how to fix them. Matt > Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw > Using os-specific seed configuration > -----

Re: OpenSSL 1.1.1g test failures

On 26/06/2020 10:45, David Harris wrote: > Is this just the way it is? I would have thought that 50% self-test failure > would be > ringing alarm bells everywhere if it were common, so I can only conclude that > there's > something odd about my environment, or that I'm doing something

Re: Error building OpenSSL-1.1.1g

ppreciate any useful information or pointers to such. > > Thanks. > > > -Original Message- > From: openssl-users On Behalf Of Matt > Caswell > Sent: Thursday, June 25, 2020 2:03 PM > To: openssl-users@openssl.org > Subject: Re: Error building OpenSSL-1.1.

Re: Error building OpenSSL-1.1.1g

: fatal error U1077: 'link' : return code '0x1' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"' > : return code '0x2' > Stop. > > -Original Message-

Re: Error building OpenSSL-1.1.1g

On 25/06/2020 18:32, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of >> mhkelley2...@gmail.com >> Sent: Thursday, June 25, 2020 11:54 > >> Error: 'ml64' is not recognized as an internal or external command, >> operable program or batch

Re: Monolith compile verify.c

On 24/06/2020 20:20, Michael Mueller wrote: > > Questions > > 1. Is the fix valid? Seems ok, but it looks like the compiler warning is a bit over zealous. We have the same pattern in many parts of the code I think without problems. > > 2.  If fix is valid, what are the chances of getting

Re: Record Layer Buffers & Zeroization

rested, I am happy to prepare a PR and move the > discussion there. I guess this is "CLA: trivial" patch anyways. Please feel free to raise a PR - although this is unlikely to be CLA trivial (we have a very high bar for something to be considered trivial). Matt > > Ma

Re: Record Layer Buffers & Zeroization

On 22/06/2020 18:28, Martin Elshuber wrote: > I might be blind, but I just cannot find the location where this > plaintext data is > zeroized, neither by OPENSSL_cleanse() nor memset(). > > Am I blind, or is this just not done? Shouldn't there be a way to do > this just like > it is already

Re: endless loop in probable_prime

m 20:33 schreef Ronny Meeus : >> >> Op do 18 jun. 2020 om 20:01 schreef Matt Caswell : >>> >>> >>> >>> On 18/06/2020 17:27, Ronny Meeus wrote: >>>> Op do 18 jun. 2020 om 18:13 schreef Salz, Rich : >>>>> >>>>>

Re: CMAC timings

On 18/06/2020 20:18, Kurt Roeckx wrote: > On Thu, Jun 18, 2020 at 07:24:39PM +0200, Kurt Roeckx wrote: >> >> Now that a large fraction of the cost has been found, I can look >> again to see where the biggest cost in 3.0 comes from now and if we >> can do something about it. > > So a code path

Re: endless loop in probable_prime

On 18/06/2020 17:27, Ronny Meeus wrote: > Op do 18 jun. 2020 om 18:13 schreef Salz, Rich : >> >>>BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is >> BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES >> should also be 4. If BN_BYTES is being

Re: endless loop in probable_prime

On 18/06/2020 16:06, Ronny Meeus wrote: > probable_prime BN_num_bits=1473 bits=1536 > BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4): >

Re: endless loop in probable_prime

On 18/06/2020 08:46, Ronny Meeus wrote: > Hello > > we are in the process of upgrading our openssl to version 1.1.1g. > On one of our architectures (Cavium MIPS, running kernel 4.9) we have > an issue in the ssh-keygen tool. It keeps on consuming 100% CPU of 1 > core. > On other architectures

Re: Typos in man pages

On 17/06/2020 12:39, Hal Murray wrote: > > There are 3 cases of "structure of NULL" where the "of" should be "or". > The "NULL" is actually "B" in the pod file. > > doc/man3/EVP_PKEY_CTX_new.pod > doc/man3/X509_NAME_add_entry_by_txt.pod > doc/man3/X509V3_get_d2i.pod > > -- > > There

Re: Cleaning up usage of CMAC_xxx

On 12/06/2020 00:27, Hal Murray wrote: > > levi...@openssl.org said: >> In 1.1.1 and earlier, there is a different idea, using EVP_PKEY routines to >> "sign" with a MAC. We have a EVP_PKEY to EVP_MAC bridge in 3.0.0 to bridge >> the gap. > > Thanks, but... > > The EVP_PKEY seems to assume

Re: installing openssl on win10 64bit

On 09/06/2020 10:26, Michael Lev מיכאל לאב wrote: > Hi, > For developing and testing I need http server on my win10 64 bit pc, > so I use http server from  > https://www.npmjs.com/package/http-server >

Re: [openssl][uwp] SSL_CTX_load_verify_locations not working for UWP port

On 05/06/2020 02:04, Feng LI wrote: > SSL_CTX_load_verify_locations > >  is > required for UWP port to load ca file since OpenSSL will not use the CA > of the OS. > > But in UWP build, stdio is disabled >

Re: 3.0.0-alpha2: openssl ciphers MEDIUM empty?

On 04/06/2020 00:39, Benjamin Kaduk via openssl-users wrote: > only reports the TLS 1.3 ciphersuites and some SEED ciphers for an > input of MEDIUM, and IIRC the SEED ciphers have been foisted off to the > legacy provider and are not available by default. Yes - this is exactly the reason.

Re: checking for enable-weak-ssl-ciphers at runtime?

On 23/05/2020 21:08, Daniel Lenski wrote: > When OpenConnect is explicitly requested to connect to an ancient > server, what I am currently trying to do is > SSL_CTX_set_cipher_list(ctx, "DEFAULT:+3DES:+RC4"). However, this > fails silently on subsequent connection if 3DES/RC4 support isn't >

Re: How to debug a TLSv1.3 protocol problem?

On 22/05/2020 13:09, Claus Assmann wrote: > On Tue, May 19, 2020, Claus Assmann wrote: > > Here's another (confusing) note: the (failing) S8 trace log: > >> Sent Record >> Header: >> Version = TLS 1.2 (0x303) >> Content Type = Handshake (22) > ... >> extensions, length = 12 >>

Re: How to debug a TLSv1.3 protocol problem?

On 20/05/2020 21:46, Viktor Dukhovni wrote: > Glad to hear that at least handshakes are less prone to unexpected > issues of that sort. I'd be interested to hear your thoughts (perhaps a > separate thread) on what to do about SSL_read() and SSL_write(). Perhaps open a github issue for this?

Re: How to debug a TLSv1.3 protocol problem?

On 20/05/2020 21:36, Viktor Dukhovni wrote: > My take is that this is a sufficiently nasty problem to warrant some > changes in SSL_read(), SSL_write, SSL_accept(), ... to internally > memoize the error status before returning, in a manner that does not > depend on the prior state of the error

Re: How to debug a TLSv1.3 protocol problem?

On 20/05/2020 17:52, Claus Assmann wrote: > On Wed, May 20, 2020, Matt Caswell wrote: > > [Thanks for still helping me with this!] > >> Can you test the underlying socket to see if it has been closed down in >> an orderly way (i.e. recv() should return 0 on the sock

Re: How to debug a TLSv1.3 protocol problem?

On 20/05/2020 14:24, Claus Assmann wrote: > On Wed, May 20, 2020, Matt Caswell wrote: > >> I wonder if there could be some middlebox in between these two peers >> that is interfering with the connection in some way and arbitrarily >> closing it down? > > No,

Re: How to debug a TLSv1.3 protocol problem?

On 20/05/2020 13:44, Claus Assmann wrote: > On Wed, May 20, 2020, Matt Caswell wrote: > >> SSL_accept:TLSv1.3 early data > >> What happens in the application code? What was the function being called >> (SSL_accept?) and what return value do you get? What doe

Re: How to debug a TLSv1.3 protocol problem?

On 19/05/2020 15:56, Claus Assmann wrote: > That's basically already in the code: > while ((l = ERR_get_error_line_data((const char **) , , > (const char **) , )) != 0) > log it ... > but that does not generate any output. Even if I add > the line you suggested there's no

Re: How to debug a TLSv1.3 protocol problem?

On 19/05/2020 11:49, Claus Assmann wrote: > On Mon, May 18, 2020, Viktor Dukhovni wrote: > >> I'll strongly second Matt's request for a PCAP file. > > If tcpdump is "good enough" then that should be attached. > If wireshark and some TLS decoding is needed, then I need > some time to figure

Re: How to debug a TLSv1.3 protocol problem?

Are you able to capture a wireshark trace of the handshake? Matt On 18/05/2020 17:59, Claus Assmann wrote: > I'm stuck and looking for some hints/help. I have two MTAs (let's > call them M1 and S8), both built with OpenSSL 1.1.1g. The problem > is M1 cannot establish a TLSv1.3 connection with

Re: EVP_PKEY_new_raw_private_key() vs EVP_PKEY_new_mac_key() ?

On 14/05/2020 22:21, Thomas Dwyer III wrote: > Are EVP_PKEY_new_raw_private_key() and EVP_PKEY_new_mac_key() > functionally equivalent? They have very different implementations > internally but appear to produce identical results when used with > EVP_DigestSignInit() and key type EVP_PKEY_HMAC.

Re: Current openssl 3 alpha dev 2 and upcoming openssh 8.3

On 13/05/2020 08:00, The Doctor wrote: > Odd. Found this today. In make test , the test stops at simple > transfer. > > In openssh-8.2p1 I worked find to a point. > > Any changes in the 3 aplha daily snaphots that could cause this? > Nothing that springs to mind. There have been

Re: Intermittent ssl errors without OPENSSL_ia32cap

On 13/05/2020 02:14, abel alejandro wrote: > At the end I was able to get rid of the warnings and download without > data corruption by using OPENSSL_ia32cap="~0x202". Could > this be a bug somewhere in openssl or my hardware is just bad? It could be a bug. I suggest you raise a

Re: Minimum gcc version required for openssl 3.x?

On 13/05/2020 00:21, Thomas Dwyer III wrote: > Although this works in gcc-4.9.2, it appears that the -z flag wasn't > documented until gcc-5.5. All Google hits I get for "-z defs" take me to > pages that show "-Wl,-z,defs" so it's curious that this particular > option isn't being passed with

Re: openssl 3 and deprecation

On 12/05/2020 15:35, Billy Brumley wrote: > Howdy Folks, > > I checked https://www.openssl.org/policies/releasestrat.html but did > not manage to find an answer. > > At what stages is marking a function deprecated still allowed? Only > before beta? Or at all stages? Or is it case-by-case with

Re: Which 1.1.1 config options set OPENSSL_NO_TESTS ?

On 12/05/2020 14:50, Jakob Bohm via openssl-users wrote: > When running Configure in OpenSSL 1.1.1g with various options, it sometimes > silently sets OPENSSL_NO_TESTS as reported by "perl configdata.pm -d" . Looking at the code here:

Re: openssl 3 alpha 1 test failures on AIX

On 07/05/2020 01:22, Norm Green wrote: > All tests on AIX fail like this.  Is this a known issue?  What debugging > information is needed?  Should I open an issue on github? Yes - please open an issue on github. > > Also note I had to set LD_LIBRARY_PATH to the SSL build directory to get >

Re: mutual-TLS / mTLS Example with certificate problem

On 06/05/2020 19:44, Andreas Tengicki wrote: >     SSL_CTX_set_ecdh_auto(srvCtx->ctx, 1); Viktor and Michael have already provided some excellent advice on this so I won't cover the same ground. Just one note on this line though - this is actually unnecessary in modern versions of OpenSSL

Re: liblegacy.a does not work unless compiled with -static

On 02/05/2020 16:39, Sam Roberts wrote: > On Sat, May 2, 2020 at 12:31 AM Richard Levitte wrote: >> No. When DSO support is turned off, the legacy provider code becomes >> part of libcrypto, in an inaccessible state (in other words, you still >> have to "load" it). > > Using

Re: liblegacy.a does not work unless compiled with -static

liblegacy.a is an internal artifact! You're not supposed to link your applications against it! You are supposed to link against libcrypto normally. If legacy.so isn't in the default install location then make sure the OPENSSL_MODULES environment variable is pointing at its directory. Matt On

Re: OpenSSL version 3.0.0-alpha1 build failed

On 30/04/2020 22:44, Matt Caswell wrote: > This appears to be a bug in perl. You have a very old version of perl > (the oldest we support is 5.10.0). It's probably worth trying to upgrade it. I've seen a very similar (but not quite the same) crash in an older version of perl on a dif

Re: OpenSSL version 3.0.0-alpha1 build failed

This appears to be a bug in perl. You have a very old version of perl (the oldest we support is 5.10.0). It's probably worth trying to upgrade it. Matt On 30/04/2020 22:12, Ken Goldman wrote: > My build failed with the below. > > x86_64 Linux kernel 2.6.32 > RHEL 6.7 > Perl 5.10.1 > >

Re: EVP Signing and Verifying

On 27/04/2020 20:51, Thomas Dwyer III wrote: > The first signing example at > https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying explicitly > calls both EVP_DigestInit_ex() and EVP_DigestSignInit(). Is the former > really necessary? It appears that the implementation of >

Re: Openssl s_client error ?

On 27/04/2020 09:07, FooCrypt wrote: > Hi > > Im just testing openssl s_client against a server IP and it appears to be > failing with the following. : > > openssl s_client -showcerts -servername ${Site} -connect ${Site}:443 -debug > > OpenSSL 1.0.2u 20 Dec 2019 :

Re: 3.0.0-alpha1 compile error: minor problem

On 24/04/2020 17:38, Claus Assmann wrote: > It seems something went wrong when include/openssl/opensslv.h > was generated? > > cc -Icrypto -I. -Iinclude -Iproviders/common/include > -Iproviders/implementations/include -Icrypto/include -DAES_ASM -DBSAES_ASM > -DCMLL_ASM -DECP_NISTZ256_ASM

Re: OpenSSL version 3.0.0-alpha1 published

On 24/04/2020 16:12, Steffen Nurpmeso wrote: make: *** [Makefile:2801: build_sw] Error 2 > > I have to go now, maybe this all goes away if i get myself the > Test::Builder::TodoDiag perl module? I doubt it. This isn't code in the tests. Try adding this line with the other includes at at the

Re: OpenSSL version 3.0.0-alpha1 published

On 24/04/2020 13:15, Yann Ylavic wrote: > On Fri, Apr 24, 2020 at 1:26 PM Yann Ylavic wrote: >> >> - Custom input BIO_METHOD (using httpd filters' stack) asserted its >> _ctrl() was never called, so far.. >> The new BIO_eof() calls in codebase, notably from ssl3_read_n(), >> breaks this

Re: OpenSSL version 3.0.0-alpha1 published

On 24/04/2020 12:26, Yann Ylavic wrote: > Hi team, > > I gave 3.0.0-alpha1 a try with Apache httpd. > tl;dr it works with minimal changes, congrats! That's great to hear. Thanks for the feedback Yann! Matt

Re: OpenSSL version 3.0.0-alpha1 published

On 24/04/2020 00:05, Sam Roberts wrote: > Fwiw, took a quick run at building and testing Node.js against the 3.x beta. > > It was API compatible enough to build. Good to hear! > The DH_, ECDH_, HMAC_, etc. > deprecations make sense, will look at those. > > My assumption is that EVP versions

Re: OpenSSL version 3.0.0-alpha1 published

On 23/04/2020 18:01, Sam Roberts wrote: > Resending to -users. > > On Thu, Apr 23, 2020 at 9:58 AM Sam Roberts wrote: >> >> Seems to be something wrong with the way config is generating the >> version strings: >> gcc -Icrypto -I. -Iinclude -Iproviders/common/include >>

Re: questions on using ed25519

On 22/04/2020 18:12, Viktor Dukhovni wrote: > sadly the > EVP_PKEY_METHOD for ed25519 has a NULL sign() member, instead, somewhat > ironically, it has a digestsign() method. This is presumably to > distinguish between the pure and prehash variants. Therefore, presently > pkeyutl(1) indeed

Re: Generating and checking SM2 signatures

On 23/04/2020 03:36, Billy Brumley wrote: >> I'm tasked to implement certain cryptographic functions (chiefly >> signature creation/validation) using the SM2 algorithm for a >> communication testing application. My problem is that the standard which >> I need to follow (which is, unfortunately,

Re: opensssl 1.1.1g test failure(s)

On 21/04/2020 23:45, Michael Tuexen wrote: >> Looks like the failing call is here: >> >>if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, >> (const void *), sizeof(on)) != 0) { > Can you provide a pointer to the code? Yes, its here:

Re: opensssl 1.1.1g test failure(s)

On 21/04/2020 18:34, Claus Assmann wrote: > Thanks for the reply, below is the output, It seems it only fails > because the host doesn't support IPv6? Yes - it does seem to be an IPv6 problem. I don't recall any recent changes in this area. Were you successfully able to run the tests with

Re: OpenSSL Security Advisory

SSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This > issue did not affect OpenSSL versions prior to 1.1.1d. > > Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g > > This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April > 2020. It

Re: TLS 1.3 PSK succeeds even if the pre-shared key is wrong

You might want to experiment with pointing the client you are using at s_server, and also with s_client pointing at your server, and try out those options to see if you can isolate the problem. Matt > > > ‐‐‐ Original Message ‐‐‐ > On Monday, April 20, 2020 5:35 PM, Matt

Re: TLS 1.3 PSK succeeds even if then pre-shared key is wrong

On 20/04/2020 12:59, brandon.murphy1996 via openssl-users wrote: > From what I noticed, the handshake completes successfully, regardless > of the value of "psk_key" (as long as PSK length is even). However, > if the identity value is mismatched between psk_find_session_cb and > use_session_cb,

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

On 16/04/2020 14:42, Harald Koch wrote: > Hello list, > > I have a TLS server which is started on demand in a multithreaded (pthread) > application. The TLS server is one thread which is being started and stopped. > At first start, the TLS server initialized with SSL_CTX_new with >

Re: Add user-defined argument in TLS 1.3 External PSK callback

On 16/04/2020 00:12, brandon.murphy1996 via openssl-users wrote: > Currently, the psk_use_session_cb_func() contains a hardcoded PSK and > identity value. However, I want to send an extra argument (preferably > a custom struct) to this callback that will contain the pre-shared > key and

Forthcoming OpenSSL Release

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1g. This release will be made available on Tuesday 21st April 2020 between 1300-1700 UTC. OpenSSL 1.1.g is a security-fix release. The highest severity

Re: openssl-1.1.1-stable-SNAP-20200408

On 09/04/2020 07:45, The Doctor wrote: > On Wed, Apr 08, 2020 at 09:26:31AM +0100, Matt Caswell wrote: >> The fix is already going through review here: >> >> https://github.com/openssl/openssl/pull/11489 >> >> It will probably be tomorrow before it gets mer

Re: Additional FOM 3.0 question

On 08/04/2020 17:11, Pete wrote: > By any chance has there been any discussion yet regarding what will and > will not be in the new 3.0 FOM?  If I recall correctly, the content list > for the now defunct 1.1.1 based FOM was very long and complete.  Our > team is in the planning stages for

<    1   2   3   4   5   6   7   8   9   10   >