Re: Using EVP_PKEY with EVP_EncryptInit_ex

On 01/04/2020 17:34, Andrew Felsher wrote: > Hi, > > I'm trying to do what I assumed would be a very common and typical use > of OpenSSL. I'm just encrypting and decrypting some data (in code; not > from command line). EVP_EncryptInit_ex (and decrypt, update, and final > variants) are the

Re: TLS 1.3 migration: SSL_set_cipher_list vs SSL_set_ciphersuites and "aliases" of families of cipher like TLSv1.3

On 01/04/2020 10:34, Romain GEISSLER via openssl-users wrote: > Hi, > > We are using OpenSSL 1.1.1 for quite some time, and we have been able to > migrate over time to the different version of SSL/TLS, up to TLS 1.2 with > success. > > Now we wish to prepare the migration to TLS 1.3. The

Re: Program works with older libssl, but not with newer

On 31/03/2020 15:21, Salz, Rich via openssl-users wrote: > Isn't this the SSL EOF thing? No. In older OpenSSL's SSL_read() would return SSL_ERROR_SYSCALL on EOF with an errno of 0. This was "fixed" in 1.1.1e to return SSL_ERROR_SSL with an entry on the error stack. And unfixed in 1.1.1f to

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.1f. This release will be made available on Tuesday 31st March 2020 between 1200-1600 UTC. This is a bug fix only release. Yours The OpenSSL Project

Re: New decode_errors due to EOF changes in master and 1.1.1e

There is an ongoing discussion on this issue here: https://github.com/openssl/openssl/issues/11378 In the specific case of s_client/s_server this actually uncovered a bug in s_server, which is why you see the problem there. Matt On 24/03/2020 23:35, John Baldwin wrote: > I replied to the

Re: 3.0 FIPS related questions

On 24/03/2020 15:02, Salz, Rich wrote: > >>> The second question is somewhat related. Has there been a decision yet >> whether the FOM 3.0 will go through a 140-2 or a 140-3 validation? > >>We are going through 140-2. > > Has the list of validated platforms been made public

Re: 3.0 FIPS related questions

On 24/03/2020 14:06, Pete wrote: > Hello, > > I have two questions regarding support for FIPS in 3.0.  We're currently > working on early planning for our migration to OpenSSL 3.0 and we're > trying to size the effort for our team.  We're also beginning to put together > contingency plans in

Re: Handshake failure: TLSv1.3 early data?

On 23/03/2020 12:06, Angus Robertson - Magenta Systems Ltd wrote: >>> My public web servers shows several handshake failures daily >>> due to 'TLSv1.3 early data', sometimes after a previous >>> successful TLSv1.3 connection, but not always. >> >> Do you have specific error messages? > > I

Re: Handshake failure: TLSv1.3 early data?

On 23/03/2020 11:09, Angus Robertson - Magenta Systems Ltd wrote: > My public web servers shows several handshake failures daily due to > 'TLSv1.3 early data', sometimes after a previous successful TLSv1.3 > connection, but not always. Do you have specific error messages? > > I'm not

Re: AD with PKI authentication - issue on cert generation

Yes - it exists so removing it should be fine. Matt > > -Original Message- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Matt Caswell > Sent: 17 March 2020 14:10 > To: openssl-users@openssl.org > Subject: Re: AD with PKI au

Re: AD with PKI authentication - issue on cert generation

On 17/03/2020 12:33, Lionel Monchecourt wrote: > I already tried to replace > > scardLogin=1.3.6.1.4.1.311.20.2.2 > > with > > msSmartcardLogin=1.3.6.1.4.1.311.20.2.2 Try removing this line altogether. OpenSSL already has a built-in object of this name with this OID so it should not be

Re: Regarding engine implementation for RSA and AES

On 17/03/2020 07:42, Mahendra SP wrote: > Hi, > > We are looking at implementing an engine for RSA and AES. > > For AES, looking at the documentation, understand that engine will get > invoked only if the application or SSL library invokes EVP based calls > rather than native AES calls. Is

Re: Question about handshake error

On 11/03/2020 15:31, Viktor Dukhovni wrote: > On Wed, Mar 11, 2020 at 03:12:26PM +0000, Matt Caswell wrote: > >>> The signature algorithm security level is not expected to be enforced >>> on self-signed certificates (root CAs). How is it happening here? >> >&g

Re: Forthcoming OpenSSL release

m/openssl/openssl/issues/10015 > > Reviewed-by: Bernd Edlinger > GH: https://github.com/openssl/openssl/pull/10044 > > See https://github.com/nodejs/node/pull/32002 for background. > > On Wed, Mar 11, 2020 at 8:53 AM Matt Caswell wrote: >> >>

Re: Question about handshake error

On 11/03/2020 17:08, Niki Dinsey wrote: > As for going back to the software vendor, I absolutely want to but don't > hold out too much hope they will change anything.  > I'm basically going to say this: > > The certificate chain contains two redundant root certificates, these > should be

Re: Question about handshake error

On 11/03/2020 16:56, Viktor Dukhovni wrote: > On Wed, Mar 11, 2020 at 03:12:26PM +0000, Matt Caswell wrote: > >>> The signature algorithm security level is not expected to be enforced >>> on self-signed certificates (root CAs). How is it happening here? >> >&g

Forthcoming OpenSSL release

The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1e. This release will be made available on Tuesday 17th March 2020 between 1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551 previously announced here:

Re: Question about handshake error

On 11/03/2020 15:08, Viktor Dukhovni wrote: > On Wed, Mar 11, 2020 at 12:15:32PM +0000, Matt Caswell wrote: > >> I would recommend that the server operator removes both copies of the >> root cert from its cert chain. Hopefully this should then mean that it >> do

Re: Question about handshake error

On 11/03/2020 08:56, Niki Dinsey wrote: > openssl s_client -connect thankqcrm.accessacloud.com:443 > > > * Debian 10 + 1.1.1d - Handshake Error   > * Debian 9 + 1.1.0l - Working > * Ubuntu 18.04 + 1.1.1  11 Sep 2018 -Working > * Ubuntu 19.10 + 1.1.1c  28

Re: Question about handshake error

On 10/03/2020 17:05, Niki Dinsey wrote: > Hi there, I have an issue I can't seem to work out the answer to. > > Server: thankqcrm.accessacloud.com > > root@willis:~# openssl version > OpenSSL 1.1.1d  10 Sep 2019 > root@willis:~# openssl s_client -connect

Re: How to cleanup CRL memory used after SSL(OpenSSL) handshake has completed?

The CTX needs to be there for the whole time that the SSL is. Matt On 06/03/2020 11:17, Hyer Low wrote: > Noted. Renegotiation has been disable. > > Is there anyway to clean the CTX while let SSL object itself serving the > tunnel ? Or I can only depend on the CTX ref after the SSL is delete? >

Re: How to cleanup CRL memory used after SSL(OpenSSL) handshake has completed?

One other thing does occur: if you allow renegotiation then you might need access to the cert-store after the initial handshake has completed. Matt On 06/03/2020 10:57, Hyer Low wrote: > All configs can have different cert being setup as well, hence each CTX cert > store might also different

Re: How to cleanup CRL memory used after SSL(OpenSSL) handshake has completed?

On 06/03/2020 03:13, Hyer Low wrote: > I'm using *X509_load_cert_crl_file*(openssl) to load the CRL file into the > CTX and create SSL for ssl_accept handshake. For each SSL connection that > has CRL file(600KB) loaded used up 10 times memory more than SSL connection > that doesn't load CRL. >

Re: Ues 'openssl s_server command' to disable TLS1.0

t; [mailto:openssl-users-boun...@openssl.org] 代表 Matt Caswell > 发送时间: 2020年3月3日 18:51 > 收件人: openssl-users@openssl.org > 主题: Re: Ues 'openssl s_server command' to disable TLS1.0 > > > > On 03/03/2020 07:48, guoxiaobi...@163.com wrote: >> Dear All, >> &

Re: OpenSSL reports wrong TLS version to FreeRADIUS

On 02/03/2020 11:28, iilinasi wrote: > Freeradius (3.0.16, 3.0.20) Could be this issue: https://github.com/FreeRADIUS/freeradius-server/issues/2385 "It may be due to the issue fixed in commit fd803c9. 3.0.17 sometimes complained that TLS 1.3 was unknown, and refused to do TLS 1.3 at all.

Re: OpenSSL reports wrong TLS version to FreeRADIUS

On 03/03/2020 12:51, iilinasi wrote: > Alfred, I'd like to say "thanks" once more. > > I tried with newer ciphers and version 1.2 - and now freeradius (3.0.16) > indeed sends me the second "challenge". So, it's a huge progress. > > However it still complains on the unknown TLS version. I

Re: Ues 'openssl s_server command' to disable TLS1.0

On 03/03/2020 07:48, guoxiaobi...@163.com wrote: > Dear All, > >   > > I hit the following error when used ‘openssl s_server -no_tls1’ command > to disable TLS1.0 on Redhat Linux server. Your question is slightly ambiguous. It implies you expect the command to disable TLSv1.0 for all

Re: OpenSSL reports wrong TLS version to FreeRADIUS

On 02/03/2020 11:28, iilinasi wrote: > I'd like to understand, how does OpenSSL get to the idea of "0304" > version, if there is no such a byte sequence in the packet... > My question is: how OpenSSL determines the TLS version? How to debug it? > Very strange. I have no idea. Looking at the

Re: aes_cbc_hmac_sha1 implementation

ocs/man1.1.1/man3/SSL_CONF_cmd.html Matt > > Regards > Phani > > On Fri, Feb 28, 2020 at 8:53 AM Matt Caswell <mailto:m...@openssl.org>> wrote: > > > > On 27/02/2020 18:30, Phani 2004 wrote: > > Thanks for the reply. > > > > In

Re: aes_cbc_hmac_sha1 implementation

On 27/02/2020 18:30, Phani 2004 wrote: > Thanks for the reply. > > In ssl_get_evp_cipher api when etm flag is enabled the > aesni_cbc_hmac_sha1_cipher is not used. In this cipher only it > implements mte. This part is not clear to me? Support I implement one > cipher func which needs to handle

Re: OpenSSL 3.0

> *Sent:* Thursday, February 27, 2020 1:31 PM > *To:* Matt Caswell ; openssl-users@openssl.org > > *Subject:* Re: OpenSSL 3.0 >   > >>    It would probably be a good idea for us to pull together a "Getting >     Started" guide on the Wiki with some basic informat

Re: OpenSSL 3.0

On 26/02/2020 21:06, Dr Paul Dale wrote: > You should be able to set the environment variable OPENSSL_CONF to > test/fips.cnf which will then load a FIPS only configuration. > > Teething problems are expected.  Not everything has been activated in > the FIPS module but enough has to do some

Re: OpenSSL 3.0

On 25/02/2020 19:07, Jason Schultz wrote: > Greetings. It has been several months since this blog post on OpenSSL 3.0: > > https://www.openssl.org/blog/blog/2019/11/07/3.0-update/ > > “We are now not expecting code completion to occur until the end of Q2 > 2020 with a final release in early

Re: Using EVP api in fips mode (openssl3.0)

al corruption of the module (or the conf file). If either of these is changed then it will be detected. It is not intended to prevent deliberate modification of both the module and the conf file at the same time. Matt > > Regards > Manish > > On Thu, 16 Jan 2020, 8:29 pm Matt

Re: aes_cbc_hmac_sha1 implementation

On 24/02/2020 13:04, Phani 2004 wrote: > Hi Team, > > "aes_cbc_hmac_sha1" implementation is currently supported on x86 > platforms only. > With which RFC is this compliant with? > This cipher is only used when the "encrypt then mac" option is disabled. > Is this understanding correct. I am

Re: Query regarding SSL_ERROR_SSL during SSL handshake

_SYSCALL. Matt > > Thanks > Mahendra > > On Wed, Feb 19, 2020 at 3:09 PM Matt Caswell <mailto:m...@openssl.org>> wrote: > > > > On 19/02/2020 05:16, Mahendra SP wrote: > > Hi All, > > > > We are using Openssl versi

Re: Query regarding SSL_ERROR_SSL during SSL handshake

On 19/02/2020 05:16, Mahendra SP wrote: > Hi All, > > We are using Openssl version 1.0.2h. When we call SSL_do_handshake, > sometimes we notice that handshake fails with error SSL_ERROR_SSL.  > As per the documentation for this error, it is non recoverable and fatal > error.  Documentation

QUIC in OpenSSL

The OMC has just published a blog post on our thoughts on QUIC in OpenSSL. You can read it here: https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/ Matt

Re: Issues with ASYNC_pause_job() wake up

ou need to do in libcurl terms. Matt > > Val > > -----Original Message- From: Matt Caswell > Sent: Tuesday, February 11, 2020 3:36 PM To: Valerio Di Gregorio > (vadigreg) ; openssl-users@openssl.org Subject: > Re: Issues with ASYNC_pause_job() wake up > > >

Re: Issues with ASYNC_pause_job() wake up

helping! > > Val > > > -Original Message- From: openssl-users > On Behalf Of Matt Caswell Sent: > Tuesday, February 11, 2020 2:52 PM To: openssl-users@openssl.org > Subject: Re: Issues with ASYNC_pause_job() wake up > > > > On 11/02

Re: Issues with ASYNC_pause_job() wake up

On 11/02/2020 13:05, Valerio Di Gregorio (vadigreg) via openssl-users wrote: > 1. ASYNC_pause_job() can wake up before write(). It will then block on > the read(), which is too bad in my single-threaded code. > 2. I fixed case 1 by making read() non-blocking, I then run >

Re: RSA-PSS - Backwards compatability - EVP_PKEY_get0_RSA

On 07/02/2020 18:14, Pedro Lopes wrote: > Hello, > > I'm assigning the RSA key as EVP_PKEY_RSA_PSS: > RSA* key; > EVP_PKEY_assign(*outKey, EVP_PKEY_RSA_PSS, key); > > As is known EVP_PKEY_get0_RSA was recently updated to also accepts > EVP_PKEY_RSA_PSS and return the rsa value. > > I'd like

Re: OpenVPN Failing

On 01/02/2020 21:10, Leslie Rhorer wrote: > Sat Feb  1 14:54:29 2020 us=650860 192.168.1.1:1194 VERIFY ERROR: > depth=0, error=unsupported certificate purpose: C=US, ST=TX, L=San > Antonio, O=Silicon Ventures, CN=RAID-Array, emailAddress=lesrho...@att.net > Sat Feb  1 14:54:29 2020 us=650899

Re: SSL_connect fails on systemd socket

IO are you using for reading the data in the server? Is it possible to get a wireshark trace of the failing handshake? Matt > > Regards, > Hari. > > -Original Message- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Matt Caswell >

Re: SSL_connect fails on systemd socket

On 28/01/2020 14:03, Tiwari, Hari Sahaya wrote: > 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong > version number:s3_pkt.c:365: You don't say, but from the reference to s3_pkt.c above I assume you are using OpenSSL 1.0.2 This error means that the server has received a

Re: What option is not recognized by OpenSSL 1.1.1d?

On 26/01/2020 21:03, Jeffrey Walton wrote: > I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d. > > Configure is dying: > > * Unsupported options: no-comp > --prefix=/home/jwalton/tmp/build-test > --libdir=/home/jwalton/tmp/build-test/lib > > According to

Re: Using EVP api in fips mode (openssl3.0)

On 14/01/2020 04:51, Manish Patidar wrote: > Hi > > Can any guide me how to use fips api in openssl? > > I try to use like below but it always returns null.  > > ctx = EVP_CIPHER_CTX_new() ; > ciph = EVP_CIPHER_fetch(NULL, "aes-128-cbc", "fips=yes") ; > > I am doubting fips provider is not

Re: Query regarding adding support aes-cbc-hmac-sha1 on non x86 platform through engine

hanks in advance. > > Regards > Phani > > On Mon, Jan 13, 2020 at 5:53 PM Matt Caswell <mailto:m...@openssl.org>> wrote: > > > > On 13/01/2020 06:20, Phani 2004 wrote: > > Hi Team, > > > > I am trying to add support on an har

Re: Query regarding adding support aes-cbc-hmac-sha1 on non x86 platform through engine

On 13/01/2020 06:20, Phani 2004 wrote: > Hi Team, > > I am trying to add support on an hardware engine for aes-cbc-hmac-sha1. > I have observed that currently aes-cbc-hmac-sha1 is supported only for > x86 architecture.  > "EVP_aes_128_cbc_hmac_sha1" api returns NULL for non-x86 platforms. The

Re: Enforcing group / key_share order in TLS1.3

On 10/01/2020 22:41, Sebastian Andrzej Siewior wrote: > gnutls-cli sends by default (in the supported groups extension) > `secp256r1' first and later `x25519'. The key_share extension contains a > key for both types. The server has both types configured both groups and > `x25519' comes first. >

Re: Doubts between libfips.a and fips.so in openssl3.0

On 02/01/2020 04:11, Manish Patidar wrote: > Hi > > What is the difference in libfips.a and fips.so.?  > Selftest.c and fipsprov.c is extra in fips.so library compilation.  Does > it mean that it just add provider entry function and self test, which is > required for fips certification.?

Forthcoming OpenSSL release

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.0.2u This release will be made available on Friday 20th December 2019 between 1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551

Re: OpenSSL source modification

On 13/12/2019 16:46, Shamatrin Dmitriy wrote: > Hello! > > I have few questions related to openssl distribution. > > Let's say that I need this: > > https://pastebin.com/D4Eh0i6P > > For my application to keep working. > > Could someone please help me with these questions? > > 1. Is that

Re: Backporting KTLS to 1.1.1

On 13/12/2019 23:52, John Baldwin wrote: > I've recently been working on adding support for kernel TLS offload > to FreeBSD and have some patches merged into master already along > with a couple of open reviews (and at least one other patchset in > progress). > > With the recent-ish

Re: OpenSSL 1.0.2x support for Extended Master Secret (EMS)

On 07/12/2019 11:41, Myron Joffe wrote: > Hi all > > Does either OpenSSL 1.0.2j or 1.0.2r support Extend Master Secret (EMS)? > No. Extended Master Secret support was first added in OpenSSL 1.1.0. Matt

Re: Json Web Keys again

On 04/12/2019 11:22, Angus Robertson - Magenta Systems Ltd wrote: >>> It seems the EVP_PKEY_RSA_PSS addition was only committed 28th >>> October 2019, so need to wait for 1.1.1e, hopefully real soon... >> >> Ah, that explains it! > > Now tested with 1.1.1e-dev and I can generate a JWK from an

Re: Json Web Keys again

On 03/12/2019 19:07, Angus Robertson - Magenta Systems Ltd wrote: >>> Agreed, code looks clear enough, but was this was for 1.1.1 or >>> master? >> >> This code looks the same in 1.1.1 and master. > > It seems the EVP_PKEY_RSA_PSS addition was only committed 28th October > 2019, so need to

Re: Json Web Keys again

On 03/12/2019 18:02, Angus Robertson - Magenta Systems Ltd wrote: >>> Sorry. My mistake. I actually meant what does EVP_PKEY_id() >> return. > > Also returns 912, the same as base_id. RSA keys both return 6. > >> So if you get EVP_PKEY_RSA_PSS returned from that I don't >> currently

Re: Json Web Keys again

On 03/12/2019 17:23, Angus Robertson - Magenta Systems Ltd wrote: >> What does EVP_PKEY_base_id() return for your pkey? How did you >> create it? > > base_id is 912, EVP_PKEY_RSA_PSS=NID_rsassaPss. Sorry. My mistake. I actually meant what does EVP_PKEY_id() return. That just does this:

Re: Json Web Keys again

On 03/12/2019 16:59, Angus Robertson - Magenta Systems Ltd wrote: >>> I create an RSA JWK using EVP_PKEY_get1_RSA and RSA_get0_key, >>> but this does not work for RSA-PSS. >> >> In what way does this not work? > > error:0607907F:digital envelope routines: EVP_PKEY_get0_RSA:expecting > an rsa

Re: Json Web Keys again

On 03/12/2019 16:29, Angus Robertson - Magenta Systems Ltd wrote: > Google has started using RSA-PSS private keys for Json Web Keys. > > I create an RSA JWK using EVP_PKEY_get1_RSA and RSA_get0_key, but this > does not work for RSA-PSS. In what way does this not work? Perhaps you are

Re: OpenSSL 1.0.2 EOL

; > On Tue, Nov 26, 2019 at 6:31 PM Matt Caswell <mailto:m...@openssl.org>> wrote: > > > > On 26/11/2019 11:38, shiva kumar wrote: > > Hi, > > As we know that OpenSSL 1.0.2 support will end in 31st  December 2019. > > and the latest versio

Re: OpenSSL 1.0.2 EOL

On 26/11/2019 11:38, shiva kumar wrote: > Hi, > As we know that OpenSSL 1.0.2 support will end in 31st  December 2019. > and the latest version is 1.0.2t, is there will be any release by EOL? > can we expect a release before EOL? This is as yet undecided. We issue releases on an as-needed

Re: ssl3_get_record:decryption failed on some machines

On 25/11/2019 08:45, fer...@hyperion.io wrote: > Sorry to bring this up again but I really don't know how to fix. I already > re-wrote my code to use SSL_read/SSL_write instead of a SSL filter BIO but I > still get the same error. > > I can reproduce when the sender is nginx, socat

Re: Is ED25519 on DTLS supported?

On 18/11/2019 16:42, Matt Caswell wrote: > > > On 17/11/2019 01:43, Rafael Ferrer wrote: >> It's DTLS-OK according to IANA. >> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 >> >> >> I tested ED25519 cer

Re: Is ED25519 on DTLS supported?

On 17/11/2019 01:43, Rafael Ferrer wrote: > It's DTLS-OK according to IANA. > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 > > > I tested ED25519 certificates on TLS 1.2 and it worked fine. > > openssl s_server -port 4321 -cert server-cert.pem -key

Re: How do I turn off EC point formats from showing up in TLS 1.3 client hello?

On 15/11/2019 22:03, Phil Neumiller wrote: > > TLS 1.3 doesn't use EC point formats right? I don't know why they are in my > TLS 1.3 client hello. No, its not used in TLSv1.3 but is used in TLSv1.2 or below. A ClientHello is sent before version negotiation takes place so you don't know what

Re: Why can't I force a specific cipher with the openssl app with TLS 1.3?

On 14/11/2019 22:30, Phil Neumiller wrote: > Hi Matt, > > That works fine for 256 as you mentioned. I trying to speak to a piece of > hardware that has one supported cipher, i.e. TLS_AES_256_GCM_SHA384. I > tried the naive approach of > > PSK=63ef2024b1 > openssl s_server -accept 4433

Re: Why can't I force a specific cipher with the openssl app with TLS 1.3?

On 14/11/2019 17:46, Phil Neumiller wrote: > Here is my server script is: > > PSK=63ef2024b1 > openssl s_server -accept 4433 -tls1_3 -nocert -psk $PSK -ciphersuites > TLS_AES_256_GCM_SHA384 > > Here is the client: > > PSK=63ef2024b1 > openssl s_client -tls1_3 -psk $PSK -connect :4433

Re: sk_X509_OBJECT_num()

On 13/11/2019 17:20, Jason Schultz wrote: > Hello- > > I am updating my Linux application from using OpenSSL 1.0.2 to 1.1.1 in > preparation for OpenSSL 3.0 (and of course the EOL of 1.0.2). I'm > confused about the function in the subject line as well as other, > related sk_X509_* functions. 

Re: upgrading the openSSL version from 1.0.2j to 1.1.1c - api changes

On 13/11/2019 09:22, Umamaheswari Nagarajan wrote: > The following apis seems to be unavailable or modified in 1.1.1c, > > ENGINE_cleanup This still exists, but was converted from a function to a macro that does nothing. You no longer need to call it. OpenSSL 1.1.0+ cleans itself up

Re: Removing Extensions from Client Hello Header

On 11/11/2019 20:51, Phil Neumiller wrote: > Extension: ec_point_formats (len=4) > Type: ec_point_formats (11) > Length: 4 > EC point formats Length: 3 > Elliptic curves point formats (3) > EC point format: uncompressed (0) > EC point

Re: Removing Extensions from Client Hello Header

On 11/11/2019 21:09, Phil Neumiller wrote: > The hardware wants to see a client hello like the following: By this do you imply that if you give it additional extensions it fails? That is a highly non-compliant implementation!! Matt

Re: Removing Extensions from Client Hello Header

On 11/11/2019 22:12, Michael Wojcik wrote: > -Original Message- >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of >> Phil Neumiller >> Sent: Monday, November 11, 2019 15:57 >> >> Code: SSL_CTX_set_options(ctx, !SSL_OP_ALL); > > That's just a verbose way of

Re: Removing Extensions from Client Hello Header

On 11/11/2019 19:43, Benjamin Kaduk via openssl-users wrote: > On Mon, Nov 11, 2019 at 12:32:22PM -0700, Phil Neumiller wrote: >> I am speaking TLS 1.3 with openssl to a hardware device that I can't change. >> I need the client hello header to only support certain extensions, yet I Any

OpenSSL Blog Post

Please take a look at my blog post that gives an update on OpenSSL 3.0 development, FIPS and 1.0.2 EOL: https://www.openssl.org/blog/blog/2019/11/07/3.0-update/ Matt

Re: Stitched aes-128 and hmac-sha1 (encrypt-then-mac)

gt; Is it planned to add aes-128-hmac-sha1 encrypt-then-mac? There are no current plans. You might investigate the impact of using AEAD ciphers instead. Matt > > On Fri, Nov 1, 2019 at 1:32 PM Matt Caswell <mailto:m...@openssl.org>> wrote: > > > >

Re: Stitched aes-128 and hmac-sha1 (encrypt-then-mac)

On 01/11/2019 07:56, pablo platt wrote: > Hi, > > Stitching aes-cbc with sha1 can result with x2 performance [1]. > Is there support for stitched aes-128-hmac-sha1 encrypt-then-mac? This > issue [2] says that only mac-then-encrypt is supported in OpenSSL. The issue is correct. Only

Re: Digest algorithms for Ruby

On 31/10/2019 11:59, Samuel Williams wrote: > I am maintaining the OpenSSL bindings for Ruby, and I'm considering > exposing SHA3 and BLAKE digests. > > In addition, for the first time, I wrote some tests to test ALL > algorithms we expose, and found that "DSS", "DSS1" and "SHA" no longer >

Re: OpenSSL compilation errors in Windows

d.html Matt > > Not sure if I can use the above link. > > > /Thanks & Regards,/ > /Nagalakshmi V J/ > ---- > *From:* Matt Caswell > *Sent:* 29 October 2019 10:47 > *To:* Nagalakshmi V J ;

Re: OpenSSL compilation errors in Windows

On 29/10/2019 10:34, Nagalakshmi V J wrote: > > tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf), > > pGenerator->master_secret,sizeof(pGenerator->master_secret), > > km,tmp,num); It seems your code is replicating parts of libssl - which seems like a strange (and

Re: Are DHE_DSS cipher suites not supported?

On 25/10/2019 09:39, Viktor Dukhovni wrote: > On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote: > >> I'm using OpenSSL 1.1.1d. >> Just want to confirm if DHE_DSS cipher suites are not supported by this >> version. > > They are supported, but: > > * DSS ciphersuites are disabled

Re: PSK with TLSv1.3

On 23/10/2019 12:32, Johannes Bauer wrote: > One step further... I've peeked at s_server.c and copied some of that > code. I.e., concretely I now am at: > > const unsigned char tls13_aes128gcmsha256_id[] = { 0x13, 0x01 }; > const SSL_CIPHER *cipher = SSL_CIPHER_find(ssl,

Re: PSK with TLSv1.3

On 23/10/2019 10:24, Johannes Bauer wrote: > Hi list, > > I'm in the process of refactoring/updating code that has been using > TLS-PSK with TLSv1.2 for a number of years successfully. I want to > upgrade it so that it uses TLSv1.3 exclusively. > > I find it *exceptionally* hard to wrap my

Re: OpenSSL compilation errors in Windows

hanks & Regards, > Nagalakshmi V J > -------- > *From:* Matt Caswell > *Sent:* 18 October 2019 14:48:33 > *To:* Nagalakshmi V J ; > openssl-users@openssl.org > *Subject:* Re: OpenSSL compilation errors in Windo

Re: OpenSSL compilation errors in Windows

On 18/10/2019 11:49, Nagalakshmi V J wrote: > Now the issue is SSL_session structure is also having accessor APIs > which I am not aware of. So I need to get the APIs for accessing the > master_key_length,etc.. given in the above code. Those are not listed > in the openssl link referred. On

Re: Regarding netinet/sctp.h inclusion in bss_dgram.c

On 15/10/2019 10:32, Matt Caswell wrote: > > > On 15/10/2019 07:51, Naveen Shivanna wrote: >> Hi,  >> >> After adding 'enable-sctp' compile option, OpenSSL (DTLS) can work with >> SCTP as transport. >> >> OpenSSL bss_dgram.c file includes the

Re:

On 15/10/2019 07:51, Naveen Shivanna wrote: > Hi,  > > After adding 'enable-sctp' compile option, OpenSSL (DTLS) can work with > SCTP as transport. > > OpenSSL bss_dgram.c file includes the kernel /netinet/sctp.h. > > We have our own custom SCTP implementation (also implements  custom BIO >

Re: full-chain ocsp stapling

On 11/10/2019 10:10, Jeremy Harris wrote: > On 11/10/2019 09:57, Matt Caswell wrote: >> OpenSSL does not currently support that. You can only place a status response >> after the first certificate. >> >> Matt > > > That's why I asked: > >>> Ar

Re: full-chain ocsp stapling

On 10/10/2019 22:53, Jeremy Harris wrote: > On 01/10/2019 12:21, Jeremy Harris wrote: >> I'm using the indexfile variant. It seems that the -CA argument >> needs to be the signer of the cert, not the CA for the chain; and >> you cannot give -CA multiple times. So you don't get good OCSP

Re: FIPS 3.0 private_* hash functions

On 10/10/2019 16:40, Neptune wrote: > Hi all, > I am in the process of making required changes to migrate our code to the > 1.1.x branch. We are currently using the FIPS Object Module 2.0 and eagerly > await word on the new 3.0 FIPS Object Module, but in the meantime there is > one issue of

Re: AW: building OpenSSL 1.1.1 with -DPURIFY

On 09/10/2019 22:57, Dr. Matthias St. Pierre wrote: > 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

Re: OPENSSL_config vs OPENSSL_init_crypto

On 08/10/2019 00:20, Samuel Williams wrote: > Hello, > > I am trying to understand what is the correct initialization process for > Ruby's > SSL module. It's not my area so any input would be most welcome. > > https://github.com/ruby/openssl/pull/267 Reading that PR it seems your objective

Re: Windows 10 run-time issue

On 03/10/2019 00:50, Andy Kennedy wrote: > So, I connect to the app with the VS debugger and find: > > file: pki_crypto.c: > > function:  pki_signature_from_ecdsa_blob() > > line: (1769) SAFE_FREE(raw_sig_data); These symbols all appear to be libssh symbols so I don't think

Re: OpenSSL compilation errors in Windows

On 03/10/2019 11:10, Nagalakshmi V J wrote: > Hi Matthias, > >   > > Please find my response for your queries below. > >   > > 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

Re: EVP_PKEY_CTX* Best Practices

On 02/10/2019 03:10, Christian Mazakas wrote: > I'm relatively new to the world of OpenSSL. > > I'm trying to write a QUIC stream class and for that, I need to use the > EVP_PKEY_CTX and I'm not sure what's the optimal way of scoping instances of > this context. > > For example, should I have

Re: Fwd: ASN1_generate_nconf - incorrect integer encoding?

On 01/10/2019 16:30, Rafał Arciszewski wrote: > Hi all, > I am trying to use OpenSSL libraries (libssl-dev 1.0.2 or 1.1.1)  to encode > integers into DER format.I am using ASN1_generate_nconf but it seems that this > function incorrectly encodes integers. It should encode in two's complement >

Re: [openssl-users] issue with EVP_EncryptUpdate in XTS mode?

On 25/01/2019 20:16, Andrew Tucker wrote: > I was doing some comparisons of XTS and GCM mode using the EVP APIs and found > a > discrepancy that seems to be an issue with XTS. > > In GCM mode if the buffer is encrypted in one call to EVP_EncryptUpdate or > with > several calls with smaller

Re: full-chain ocsp stapling

On 30/09/2019 14:49, Jeremy Harris wrote: > Looking at implementing the above, under TLSv1.3 and (at least > initially) server-side. I'm currently using > > SSL_CTX_set_tlsext_status_cb() > SSL_set_tlsext_status_ocsp_resp( a DER blob ) > > and the problem is: will this accept a >

Re: OpenSSL compilation errors in Windows

On 30/09/2019 11:56, Nagalakshmi V J wrote: > In our code, We included “ssl_locl.h” which in turn includes packet_locl.h. > Any > way to avoid this kind of error? Don't include "ssl_locl.h"!!! This is an internal header file and relying on it is likely to cause problems for you. There are no

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