Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?

On Thu, Jul 13, 2017 at 12:34 PM, Dr. Stephen Henson wrote: > First if you want to link to the OpenSSL DLLs then you don't need fipslink.pl > at all: just link to them as you would any other application. I'm working on Node.js, it links statically, so this isn't an option for

[openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?

I'm having trouble linking on Windows with fipslink.pl, lots of FIPS_ symbols are unresolved. AFAICT, they are defined by the canister, and fipslink.pl is supposed to know this, and add them to the link libraries by itself, but it doesn't seem to do this. Looking at the linux fipsld, it does

Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?

On Thu, Jul 13, 2017 at 1:41 PM, Dr. Stephen Henson <st...@openssl.org> wrote: > On Thu, Jul 13, 2017, Sam Roberts wrote: >> On Thu, Jul 13, 2017 at 12:34 PM, Dr. Stephen Henson <st...@openssl.org> >> wrote: >> > If you do want to link against the static librar

Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?

On Thu, Jul 13, 2017 at 7:46 PM, Dr. Stephen Henson <st...@openssl.org> wrote: > On Thu, Jul 13, 2017, Sam Roberts wrote: > >> On Thu, Jul 13, 2017 at 1:41 PM, Dr. Stephen Henson <st...@openssl.org> >> wrote: >> >> >> >> Where is nt.

Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?

On Thu, Jul 13, 2017 at 11:07 AM, Sam Roberts <vieuxt...@gmail.com> wrote: > I'm having trouble linking on Windows with fipslink.pl, lots of FIPS_ > symbols are unresolved. OK, I attempted to do as ms/nt.mak does, rewriting it as a batch file: https://github.com/sam-github/node/b

Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?

On Thu, Jul 20, 2017 at 4:08 PM, Dr. Stephen Henson <st...@openssl.org> wrote: > On Thu, Jul 20, 2017, Sam Roberts wrote: > >> >> Most of the application is compiled with /MT, but openssl-fips-2.0.16 >> is using /MD, could this be an issue? Can I/should I convince

Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?

On Wed, Jul 19, 2017 at 6:27 PM, Dr. Stephen Henson wrote: > Try linking with fipscanister.lib too: that's where those symbols are located. OK, I'd tried that before with no luck, but I tried harder. I found that if my lib line has the fips_premain.obj, then the

Re: [openssl-users] PKCS7 and RSA_verify

On Thu, Sep 28, 2017 at 2:28 AM, ch wrote: > Hi! > > I thought the difference between PEM and DER is NOT ONLY a different > encoding of the string? > base64 vs. binary > > So to understand that clear please let me ask: > If I convert a PEM-signature from base64 to binary then

Re: [openssl-users] problem with -aes256 and -outform der in cmmand

Probably I misunderstand the context, since PKCS#8 can be used to encrypt EC private key info, some more info at https://tools.ietf.org/html/rfc5915. Which doesn't help the OP if the openssl CLI doesn't support it. On Mon, Aug 21, 2017 at 8:52 AM, Salz, Rich via openssl-users

Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?

On Thu, Jan 17, 2019 at 5:40 PM Jordan Brown wrote: > On 1/14/2019 4:09 AM, Matt Caswell wrote: > > This works more "by accident". There is no ciphersuite alias called > "TLSv1.3", so using it as above results in no ciphersuites matched. Since the > TLSv1.3 ciphersuites are on by default anyway

Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?

On Mon, Jan 14, 2019 at 5:18 AM Yann Ylavic wrote: > I suppose one can always, e.g.: > > $ openssl ciphers -v |grep TLSv1.3 |awk '{print $1}' # or whatever filtering > > to not depend on this "accident", right? No, `ciphers` gives you the TLS cipher suites that are enabled, it doesn't give all.

Re: [openssl-users] A script for hybrid encryption with openssl

On Tue, Dec 18, 2018 at 3:18 AM Nick wrote: > I should add that I don't really care about the format, or even the use of > openssl - just the ability to tackle large files with the benefits of public > key encryption, in a self-contained way without needing fiddly work deploying > the keys

Re: [openssl-users] version OPENSSL_1_1_1 not defined in file libcrypto.so.1.1 with link time reference

On Wed, Dec 5, 2018 at 5:22 AM Vincent Le Bourlot wrote: > After a fresh build of branch OpenSSL_1_1_1-stable on our ppc64 machine, > openssl seems broken for an unknown reason… > Executing `openssl version` results in: I'm no expert, but try `ldd openssl`, is it dynamically linking against the

[openssl-users] what is the relationship between (Client)SignatureAlgorithms and cipher_list()?

Do they overlap in purpose, so the cipher list can be used to limit the signature algorithms? Or are the signature algorithms used for different purposes than the cipher suites in the cipher list? If they have to be configured seperately, is the mechanism to use

[openssl-users] Is there any standard way of getting the error name from an SSL error?

For example, I want the string "SSL_R_TOO_MANY_WARN_ALERTS" for an error with that value, not just the "too many alerts" description. I'm suspecting not, I don't see any use of #reason in ERR_REASON() or the macros it uses. -- openssl-users mailing list To unsubscribe:

Re: [openssl-users] was the change in when disabled ciphers are skipped intentional?

On Fri, Nov 23, 2018 at 11:41 AM Viktor Dukhovni wrote: > > On Nov 23, 2018, at 2:25 PM, Sam Roberts wrote: > > > > In 1.1.0j, if SSL_CTX_set_cipher_list() is called with "not-a-cipher" > > or "rc4", then SSL_R_NO_CIPHER_MATCH will occur. > &g

[openssl-users] was the change in when disabled ciphers are skipped intentional?

In 1.1.0j, if SSL_CTX_set_cipher_list() is called with "not-a-cipher" or "rc4", then SSL_R_NO_CIPHER_MATCH will occur. In 1.1.1a, set_cipher_list() suceeds, seems to return the complete cipher list (should it do this?) but later ssl_cipher_list_to_bytes() will find that ssl_cipher_disabled() is

[openssl-users] is there an API to list all the TLS 1.3 cipher suite names?

node.js has an API that lists all the cipher suite names that can be validly passed to set_cipher_list(), but I don't see how to get them for TLS1.3 to list the valid inputs to set_cipher_suites(). The openssl ciphers CLI doesn't seem able to do this either.

Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?

On Tue, Jan 8, 2019 at 7:10 PM Viktor Dukhovni wrote: > On Tue, Jan 08, 2019 at 02:23:27PM -0800, Sam Roberts wrote: > > node.js has an API that lists all the cipher suite names that can be > > validly passed to set_cipher_list(), but I don't see how to get them > > for TLS

Re: [openssl-users] SSL_CTX_set_cert_verify_callback and certificate access

On Wed, Jan 9, 2019 at 6:54 PM Corey Minyard wrote: > My first inclination for a secure connection was to use ssh. However, > ssh is not as well suited for this as I would have liked, and all the > ssh libraries are tied to a file descriptor in ways that are not easily > fixable, and thus can't

Re: CVE-2019-1559 advisory - what is "non-stiched" ciphersuite means?

It would have been helpful if the sec announcement had contained a specific list of cipher suites affected, even without the additional list of specific architectures vulnerable. Its hard to communicate clearly ATM to people which suites are or are not affected, so they can know if they are

Re: Stitched vs non-Stitched Ciphersuites

On Tue, Feb 26, 2019 at 8:42 AM Matt Caswell wrote: > > What about AEAD ciphers? Are they considered "stitched"? > > No, they are not "stitched" but they are not impacted by this issue. We should > probably make that clearer in the advisory. That would be helpful! Even though this is fixed,

Re: Stitched vs non-Stitched Ciphersuites

On Wed, Feb 27, 2019 at 8:42 AM Matt Caswell wrote: > On 27/02/2019 16:33, Sam Roberts wrote: > > That would be helpful! > > It has been updated: Thank you, that is helpful.

Re: Online docs have broken links

I ran linklint on the output of `make install_html_docs`, and there are a fair amount of refs to non-existent pages as well. Maybe its worth adding a `test-docs` target? Would PRs to fix the below be welcomed? # # ERROR 18 missing html

Re: Why were edwards curves given distinct key types, aren't they EC keys?

That helps a lot, I can see why they are different enough from EC key types to be distinct. It still leaves me wondering whe two edwards curves have key types distinct from each other? Why aren't they both EVP_PKEY_ED? (or something of the like) Cheers, Sam

Re: Why were edwards curves given distinct key types, aren't they EC keys?

y as other project members. > > BR, > > Nicola > > On Sat, Mar 16, 2019, 17:00 Sam Roberts wrote: >> >> That helps a lot, I can see why they are different enough from EC key >> types to be distinct. >> >> It still leaves me wondering whe two edwa

Why were edwards curves given distinct key types, aren't they EC keys?

It seems like they are EC keys, with specific curve designs, and that also have some algorithms designed specifically for them, like EdDSA -- though it looks like that alg is being generalized to other curve types (https://tools.ietf.org/html/rfc8032#ref-EDDSA2). What about them makes it

Re: [openssl-users] how is it possible to confirm that a TLS ticket was used?

On Wed, Feb 6, 2019 at 1:01 PM Viktor Dukhovni wrote: > On Tue, Feb 05, 2019 at 02:43:03PM -0800, Sam Roberts wrote: > Your ticket rotation approach looks a bit fragile. I agree, though perhaps I should not have described what was happening as rotation. The test that was failing with

Re: when should client stop calling SSL_read to get TLS1.3 session tickets after the close_notify?

Resending, I just got banned for "bounces", though why gmail would be bouncing I don't know. On Thu, Feb 14, 2019 at 2:51 PM Sam Roberts wrote: In particular, I'm getting a close_notify alert, followed by two NewSessionTickets from the server. The does SSL_read()/SSL

Re: [openssl-project] OpenSSL 3.0 and FIPS Update

I don't see a FIPS repo in https://github.com/openssl, or a FIPS branch in https://github.com/openssl/openssl/branches/all Has coding started? If so, is it visible anywhere? If not, where should we watch for when it does? The FIPS design doc looks like lots of thought has gone into it, which is

Re: [openssl-users] when should client stop calling SSL_read to get TLS1.3 session tickets after the close_notify?

On Fri, Feb 15, 2019 at 3:35 PM Matt Caswell wrote: > On 15/02/2019 20:32, Viktor Dukhovni wrote: > >> On Feb 15, 2019, at 12:11 PM, Sam Roberts wrote: > > OpenSSL could delay the actual shutdown until we're about to return > > from the SSL_accept() t

[openssl-users] when should client stop calling SSL_read to get TLS1.3 session tickets after the close_notify?

In particular, I'm getting a close_notify alert, followed by two NewSessionTickets from the server. The does SSL_read()/SSL_get_error(), it is returning SSL_ERROR_ZERO_RETURN, so I stop calling SSL_read(). However, that means that the NewSessionTickets aren't seen, so I don't get the callbacks

Re: [openssl-users] how is it possible to confirm that a TLS ticket was used?

I tracked down my problem, its due to a change in the relative order of handshake completion (as detected by the info callback, anyhow), and the callback to SSL_CTX_set_tlsext_ticket_key_cb(). With TLS1.2, I can rotate ticket keys on the server when the handshake completes, and they will only

[openssl-users] is the openssl wiki down for maintenance, or is something broken?

https://wiki.openssl.org/index.php/TLS1.3 is returning ``` Sorry! This site is experiencing technical difficulties. Try waiting a few minutes and reloading. (Cannot access the database) ``` -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] how is it possible to confirm that a TLS ticket was used?

And is it possible that this is different for TLS1.2 and 1.3? Using TLS1.3, SSL_session_reused() is always returning false, I'm not sure if that's because I'm doing something else wrong, and the ticket is not being accepted and a full handshake is occurring, or if the API literally only signals

Re: [openssl-users] how is it possible to confirm that a TLS ticket was used?

On Mon, Feb 4, 2019 at 9:46 PM Viktor Dukhovni wrote: > On Mon, Feb 04, 2019 at 03:54:48PM -0800, Sam Roberts wrote: > However, because in TLS 1.3, session > tickets are sent *after* the completion of the handshake, it is > possible that the session handle you're saving is the o

Re: OpenSSL server sending certificate chain(inc. root cert) during handshake

The root cert is not used for validation, so it doesn't have to be sent. However, sending it does no harm, and it is useful for humans who are attempting to diagnose problems, it allows them to see what what root cert they are expected to have locally for sucessful cert chain validation.

Re: Calling EVP_DigestFinal_ex multiple times

On Mon, Jun 17, 2019 at 2:07 AM Matt Caswell wrote: > On 15/06/2019 15:08, Tobias Nießen wrote: > > I am wondering whether it is permitted to call EVP_DigestFinal_ex multiple > > times on the same context in order to retrieve the same digest twice. I > > expected OpenSSL to fail with an error

any subtleties about OCSP in TLS1.3 with ecdh curves?

Node.js has a bug report and repro of ocsp status not being sent from a node server to the openssl CLI when TLS1.3 is being used, but only when server is setting an ecdh curve, with SSL_CTX_set1_curves_list() repro is https://github.com/sam-github/node-ocsp-bug-repro TLS trace of success is

Re: Can a linux service work as both TLS client and server?

I'm curious, its pretty unusual to not know which side of a TCP connection is the client or server, not just TLS, HTTP, SMTP, etc. Its almost always the side that makes the accept() call that's the server, but that doesn't have to be. Why is it that you do not in this context? Without it,

Re: OpenSSL 3.0

On Tue, Feb 25, 2020 at 8:00 PM Matt Caswell wrote: > alpha1, 2020-03-31: Basic functionality plus basic FIPS module I'd like to give this a spin, to get an idea what's going to be involved in porting from FIPS2.0 to 3.0, any pointers on where to start? Sam

Re: OpenSSL 3.0

On Wed, Feb 26, 2020 at 8:36 AM Salz, Rich wrote: > > >I'd like to give this a spin, to get an idea what's going to be > involved in porting from FIPS2.0 to 3.0, any pointers on where to > start? > > Per the blog post, "most applications should just need to be recompiled." :) > > Get

Re: OpenSSL 3.0

On Wed, Feb 26, 2020 at 11:44 AM Salz, Rich wrote: > > The 3.0 release is a work in progress and is not done yet. > > FIPS 3.0 === OpenSSL 3.0, using a FIPS-validated crypto provider which will > be part of OpenSSL 3.0. > > The architecture documents are at https://www.openssl.org/docs Rich,

Re: Forthcoming OpenSSL release

Will it include ONLY the CVE fix, or will it include other fixes, such as to the getrandom() call on some archs? commit 4dcb150ea30f9bbfa7946e6b39c30a86aca5ed02 Author: Kurt Roeckx Date: Sat Sep 28 14:59:32 2019 +0200 Add defines for __NR_getrandom for all

website changelog didn't get updated for 1.1.1 f and g

https://www.openssl.org/news/changelog.html#openssl-111 ^--- missing the last two patch releases. Cheers, Sam

Re: OpenSSL version 3.0.0-alpha1 published

On Fri, Apr 24, 2020 at 1:05 AM Matt Caswell wrote: > This one is interesting: > > ERR_OSSL_EVP_FETCH_FAILED > > > This means that the algorithm you are trying to use isn't available in > the loaded providers. Since you should be getting the default provider > loaded automatically it could be

Re: OpenSSL Security Advisory

The announcement claims that this affects SSL_check_chain(). Is that an exhaustive list? If an application does NOT call that function, does this mean the vulnerability is not exploitable? I ask because the the fixed function tls1_check_sig_alg is called by tls1_check_chain, and that is called

Re: OpenSSL Security Advisory

That makes sense, thank you all.

Re: OpenSSL version 3.0.0-alpha1 published

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 > -Iproviders/implementations/include -Icrypto/inc

Re: OpenSSL version 3.0.0-alpha1 published

a minimal config file example to load both the default and > the legacy provider in the default library context. > > > Cheers, > > Nicola > > On Fri, 24 Apr 2020 at 17:56, Sam Roberts wrote: >> >> On Fri, Apr 24, 2020 at 1:05 AM Matt Caswell wrote: >&g

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

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 OSSL_PROVIDER_load(NULL, "legacy")? My first try after a static

Re: OpenSSL version 3.0.0-alpha1 published

Fwiw, took a quick run at building and testing Node.js against the 3.x beta. It was API compatible enough to build. The DH_, ECDH_, HMAC_, etc. deprecations make sense, will look at those. My assumption is that EVP versions of these exist in openssl 1.1.1, and that if we switch our openssl 1.1.1

Re: OpenSSL version 3.0.0-alpha1 published

On Thu, Apr 30, 2020 at 9:27 PM Richard Levitte wrote: > Yes, running from the DESTDIR "installation" gets you into trouble. > DESTDIR is intended to be a staging directory, i.e. a place to put Fair enough, I don't have to use DESTDIR, I configure with openssldir and prefix set to a sandbox now.

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

On Fri, May 1, 2020 at 10:22 AM Salz, Rich via openssl-users wrote: > Hm, so DSO support is a requirement for legacy crypto now? That probably > needs to be made explicit, and see if the project gets pushback. It would mean legacy alg support would not exist for Node.js binary distributions,