Re: [External] : Re: BIO_read() crash

On Mon, Dec 05, 2022 at 11:31:18AM -0800, Thomas Dwyer III wrote: > Why does EVP_get_digestbyname("md4") return non-NULL if the legacy provider > isn't loaded? Similarly, why does it return non-NULL for "md5" after doing > EVP_set_default_properties(NULL, "fips=yes")? This seems unintuitive.

Re: TLS 1.3 Early data

On Sat, Nov 05, 2022 at 11:50:18AM +0100, Dirk Menstermann wrote: > Hello, > > I did few experiments with early data but was not successful in solving my > exotic use case: "Using early data dependent on the SNI" > > I control the server (linux, supports http2) based on OpenSSL 111q and use a >

Re: Query reg. using certificates bigger than 4k for EAP-TLS

I'm also a bit confused at how this became the limiting factor for the application in question. https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert-08 has some discussion of how large certificates can cause issues for EAP (as well as some guidance to EAP deployments as to how to

Re: Will TLSv1.3 always send session ticket?

On Thu, Sep 16, 2021 at 12:40:55PM -0400, Viktor Dukhovni wrote: > On Thu, Sep 16, 2021 at 09:30:18AM -0700, Benjamin Kaduk via openssl-users > wrote: > > On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote: > > > > > > I don't recall whether OpenSSL m

Re: Will TLSv1.3 always send session ticket?

On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote: > > I don't recall whether OpenSSL makes any effort to or supports deferring > the transmission of session tickets until just before the first > application data transmission from server to client (or else perhaps > just before

Re: Getting SSL_SESSION remaining lifetime

On Thu, Sep 16, 2021 at 04:57:03PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 16:28:47 CEST, Benjamin Kaduk wrote: > > On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: > > > On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: > > > > > > > > I am trying

Re: Getting SSL_SESSION remaining lifetime

On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: > > > > I am trying to get the remaining lifetime of the ticket so that server > > can decide to renew ticket or not > > TLS 1.3 tickets are single use. If the ticket

Re: OpenSSL 3.0.0 two tests fail on Solaris 10 SPARC64 ( Oracle/Fujitsu )

On Sat, Sep 11, 2021 at 10:29:07PM -0400, Dennis Clarke via openssl-users wrote: > > This is slightly better than the beta release : > > Test Summary Report > --- > 03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 >

Re: Congratulations! Missing 3.0.0 tag?

On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote: > But if i use > > #?0|kent:tls-openssl.git$ alias gl1 > alias gl1='git slpn -1' > #?0|kent:tls-openssl.git$ git alias|grep slpn > alias.slpn log --show-signature --patch --find-renames --stat > --no-abbrev-commit >

Re: Congratulations! Missing 3.0.0 tag?

On Thu, Sep 09, 2021 at 12:15:44AM +0200, Steffen Nurpmeso wrote: > > P.S.: maybe at least release commits and tags could be signed? > And/or HTTPS access to the repository ... but then i get the gut > feeling that the answer to this will be "use github" or something. tag openssl-3.0.0 Tagger:

Re: client authentication status

On Wed, Sep 01, 2021 at 03:36:36PM +, Zeke Evans wrote: > Hi, > > Is there any way to check the status of client authentication sent in a TLS > 1.3 handshake after SSL_connect returns? With TLS 1.2 SSL_connect seems to > always capture the status and return an error code if it failed but

Re: Can OpenSSL handle multiple authentication mechanisms on the same SSL context?

On Tue, Jun 22, 2021 at 04:18:25AM +, Revestual, Raffy [AUTOSOL/PSS/MNL] wrote: > Also asked this question in stackoverflow.com > >

Re: 3.0 beta1 feedback about (shared) library names

On Mon, Jun 21, 2021 at 10:23:06PM -0400, Michael Richardson wrote: > > I downloaded and compiled opensssl 3.0.0-beta1 from git today. > I installed into a private prefix. > > While my debian desktop system has: > > %ls -l /usr/lib/x86_64-linux-gnu/libssl* > -rw-r--r-- 1 root root 357056 Jul

Re: Symbols X509_set_notAfter and X509_set_notBefore are missing

They are macros now. You should still be able to build code that uses them. -Ben On Fri, Apr 09, 2021 at 08:03:28PM +, Robert Smith via openssl-users wrote: > Hello, > I am porting application from openSSL version 1.0.2u to 1.1.1k and linker > complaints that symbols X509_set_notAfter and 

Re: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string

On Tue, Mar 09, 2021 at 02:44:20AM +, Stephen Farrell wrote: > > Hiya, > > On 08/03/2021 02:37, Benjamin Kaduk wrote: > > Hi Stephen :) > > > > The API you'll want to use is EVP_PKEY_fromdata(); there's > > a stubbed out example of using it to make an EVP_PKEY with > > EC group parameters

Re: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string

Hi Stephen :) The API you'll want to use is EVP_PKEY_fromdata(); there's a stubbed out example of using it to make an EVP_PKEY with EC group parameters at https://github.com/openssl/openssl/issues/14258#issuecomment-783351031 but the translation to also specify OSSL_PKEY_PARAM_PRIV_KEY (and

Re: PEM file line size

On Thu, Feb 25, 2021 at 03:30:43PM -0800, Frank Liu wrote: > Looking at test cases > https://urldefense.com/v3/__https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/test/recipes/04-test_pem.t__;!!GjvTz_vk!A42D2c2brOwptas6T1iBt9i7pMWhwehkKAmeCuILgR-6iv5n0TQPQ6tkkVgG9A$ > > , openssl

Re: ASN.1 encoding error

That sounds like the certificate is encoded using ASN.1 BER rules, that openssl accepts, but the python library is insisting on DER encoding (per the spec). -Ben On Thu, Feb 25, 2021 at 05:19:32PM +, John Robson via openssl-users wrote: > Hi all, > > I'm encountering an error connecting to

Re: Parsing and generating CBOR certificates?

And again, where do you believe such a conversion is specified? The IETF internet-draft I reference is a way to do so, but it is (to repeat) very much a work in progress. -Ben On Thu, Jan 21, 2021 at 12:35:24AM +, Blumenthal, Uri - 0553 - MITLL wrote: > I meant not "CBOR protocol" (which,

Re: Fwd: channel binding

On Mon, Jan 11, 2021 at 10:31:01PM +, Jeremy Harris wrote: > On 11/01/2021 22:07, Benjamin Kaduk wrote: > > > Looking at the implementation, SSL_export_keying_material() only > > > functions for TLS 1.3 . This is not documented. Is this a bug? > > Are you looking at

Re: Fwd: channel binding

On Mon, Jan 11, 2021 at 09:26:30PM +, Jeremy Harris wrote: > On 11/01/2021 08:20, Benjamin Kaduk wrote: > > Current recommendations are not to use the finished message as the channel > > binding but instead to define key exporter label for the given usage > > (see > >

Re: Fwd: channel binding

On Sun, Jan 10, 2021 at 02:44:38PM +, Jeremy Harris wrote: > Hi, > > What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ? > > I do not find them documented at > >

Re: Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)

Hi Craig, On Wed, Dec 09, 2020 at 08:35:46PM +0900, Craig Henry wrote: > Hi, > > This is my first post to this list so please be kind! > > Environment - Linux Centos > SSL - 1.0.2k19-el7 > > Connection - CURL (via PHP) with public / private key auth + http basic auth > > We're having an issue

Re: Question about TLS 1.3 and openssl -cipher aNULL option

On Thu, Sep 03, 2020 at 11:45:28PM +, Yury Mazin via openssl-users wrote: > Hello, > > We have a server was originaly using OpenSSL 1.0.2h. > Server is configured to use SSL ciphers as following > ALL:!aNULL:!ADH:!EDH:!eNULL:!EXPORT > When openssl client tries to connect to this server with

Re: Real MTU problems with BIO pair

On Fri, Aug 21, 2020 at 05:05:51PM +0200, Detlef Vollmann wrote: > On 2020-08-20 21:44, Detlef Vollmann wrote: > > > > Is there any way to set the maximum fragment size for > > DTLS handshake with a BIO pair? > One solution is to set the MTU and the int_bio size to > exactly the same value. >

Re: NULL ciphers

On Thu, Aug 13, 2020 at 08:19:10PM +0200, Detlef Vollmann wrote: > Hello, > > with the following commands: > > openssl s_server -accept 18010 -cert srv.crt -key test.key \ > -CAfile testca.crt -debug -cipher 'NULL-SHA256' -dtls1_2 > > openssl s_client -connect localhost:18010 -cert clnt.crt \ >

Re: 'in_addr_t' in openssl 1.1.1g ??

Ah, so it really is the "gcc" configure target (I had to look up that such a thing even existed!). Unfortunately, 'gcc' implies 32-bit, and your x86_64-fslsdk-linux suggests that you're targetting a 64-bit system. Such a mismatch of configurations could easily cause this sort of compile error

Re: OpenSSL compliance with Linux distributions

On Wed, Aug 05, 2020 at 10:28:26PM +0200, Patrick Mooc wrote: > Thank you very much Kyle for your quick and clear answer. > > The reason why I want to upgrade OpenSSL version, is that I encounter a > problem with 1 frame exchange between client and server. > > This frame is the first packet sent

Re: 'in_addr_t' in openssl 1.1.1g ??

On Thu, Aug 06, 2020 at 01:51:35AM +0530, prudvi raj wrote: > Hi there, > > I got this error during compilation , in file b_addr.c : > In function 'BIO_lookup_ex': > /b_addr.c:748:9: error: unknown type name 'in_addr_t' > > I see that "in_addr_t" is defined in "netinet/in.h" & "arpa/inet.h" in >

Re: Compiling OpenSSL shared libraries with custom name on Unix platforms

On Tue, Jul 14, 2020 at 09:08:10PM +0200, shivaramakrishna chakravarthula wrote: > This is exactly similar to what I am looking for. I am using 1.0.2J version > and there are some changes in the next version onwards that causes problems > in SSL connections to older versions when DH key = 256

Re: Compiling OpenSSL shared libraries with custom name on Unix platforms

On Tue, Jul 14, 2020 at 04:58:38PM +0200, shivaramakrishna chakravarthula wrote: > Hi, > > I have compatibility issues for my application with new versions of OpenSSL > and I want to use the older version of OpenSSL with my application. So, I > want to link my application with an OpenSSL library

Re: Question about SSL_key_update

On Thu, Jul 09, 2020 at 06:07:41PM +, Andreas Müller wrote: > Hi, > > I "inherited" our project to support/use TLSv1.3 from a late colleague. We > have a server written in C++ (Windows, Linux) > and clients (Windows, Linux, also written in C++ and also a Java client). > With Java, we use the

Re: Are there any flag that control client finished hash verification

On Mon, Jun 08, 2020 at 06:53:32PM +, Neil Proctor via openssl-users wrote: > Hello, > > Specific to OpenSSL v1.0.2p and TLS1.2 are there any flags or options like, > SSL_CERT_FLAG_TLS_STRICT, that set whether or not the client handshake > finished hash is verified by the server? Or is

Re: 3.0.0-alpha2: openssl ciphers MEDIUM empty?

On Wed, Jun 03, 2020 at 07:05:32PM +0200, Claus Assmann wrote: > Just curious: Why is the output of > openssl ciphers MEDIUM > "empty" for 3.0.0.a2? There are no ciphers available by default that are at the MEDIUM level (which, to be honest, does not make a huge amount of sense at this point

Re: SSL_CTX_set_ssl_version changes security level

On Tue, May 12, 2020 at 05:22:29AM +0900, NAKANO Takuho wrote: > 2020年5月12日(火) 0:31 Benjamin Kaduk : > > > OS-vendor customization > > Thank you. That's very helpful. I get how to configure (but don't know > why...). > > On CentOS 8: > First result of SSL_CTX_get_security_level depends on > A:

Re: SSL_CTX_set_ssl_version changes security level

On Mon, May 11, 2020 at 05:01:27PM +0900, NAKANO Takuho wrote: > Hello, > > I've found SSL_CTX_set_ssl_version changes security level: > > = > int main(void){ > int i; > struct ssl_ctx_st *ctx = SSL_CTX_new(SSLv23_method()); > > printf("seclevel: %d\n",

Re: openssl 3 alpha 1 test failures on AIX

On Wed, May 06, 2020 at 05:22:17PM -0700, 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? > > Also note I had to set LD_LIBRARY_PATH to the SSL build directory to get the > tests to run at

Re: How to disable renegation before compiling openssl

On Tue, Apr 21, 2020 at 09:57:02PM +0200, Mark Windshield wrote: > Hello, > > I was wondering what I'd have to change in the openssl code/config before > compiling to have renegation disabled by default, so it won't send the > Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) when using

Re: OpenSSL Security Advisory

On Tue, Apr 21, 2020 at 12:46:43PM -0700, Sam Roberts wrote: > 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? That is correct (speaking only in

Re: opensssl 1.1.1g test failure(s)

On Tue, Apr 21, 2020 at 07:22:38PM +0200, Claus Assmann wrote: > Note sure whether this is already known (a search didn't bring up > anything meaningful): > > ../test/recipes/80-test_ssl_old.t .. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/6 subtests > Test Summary

Re: empty directory in the 1.1.1 series release tags

On Tue, Apr 21, 2020 at 10:19:28AM -0700, Quanah Gibson-Mount wrote: > --On Tuesday, April 21, 2020 11:16 AM -0700 Benjamin Kaduk > wrote: > > > The 'krb5' entry in git is a submodule, used for the external tests. > > It's removed while preparing release tarballs, but I'm not sure what > > you

Re: empty directory in the 1.1.1 series release tags

On Tue, Apr 21, 2020 at 10:08:39AM -0700, Quanah Gibson-Mount wrote: > The OpenSSL release tags contain an empty directory "krb5" that does not > exist in the release tarball. This is annoying because when I go to merge > release tags, I constantly get the following: > > CONFLICT

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

On Thu, Apr 16, 2020 at 09:41:23PM +0200, Harald Koch wrote: > Am 16.04.2020 um 17:54 schrieb Tomas Mraz : > > > > error queue of openSSL stays empty. The same code works with > >> openSSL with gzip support („./config enable-zlib ...“, for support of > >> compressed SMIME contents in other

Re: resumption problem

On Mon, Mar 23, 2020 at 11:46:43PM +, Jeremy Harris wrote: > OpenSSL 1.1.1 on Centos 8 > Ticket-based resumption > > > I'm getting a repeatable error from a client call to SSL_connect() > of "14228044:SSL routines:construct_ca_names:internal error". > > Packet capture shows an Alert being

Re: SSL_set_client_CA_list(ssl, NULL) problem?

Sorry for the very late response... On Sun, Nov 24, 2019 at 12:05:34PM +0100, Claus Assmann wrote: > Seems it is impossible to override the list with NULL for SSL, as > the code will then use the list from CTX (if my limited understanding > of the code is correct): > > STACK_OF(X509_NAME)

Re: SNI disable by default on 1.0 and 1.1.0?

On Mon, Dec 02, 2019 at 09:05:33PM +0100, aeris wrote: > Hello here, > > I try to compile 1.0.2t and 1.1.0l, but I notice SNI seems disabled by > default, when it's enabled by default on 1.1.1d… Please specify whether you are concerned about the s_client behavior specifically or the libssl

Re: Removing Extensions from Client Hello Header

On Tue, Nov 12, 2019 at 03:08:19PM -0700, Phil Neumiller wrote: > I find the comment below about TLS 1.3 troubling. [...] > */* > * TODO(TLS1.3): These APIs cannot set TLSv1.3 sig algs so we just test > it > * for TLSv1.2 for now until we add a new API. > */* >

Re: Removing Extensions from Client Hello Header

On Tue, Nov 12, 2019 at 01:13:49PM -0700, Phil Neumiller wrote: > Thanks for all the useful device. I was able to get the server to accept > this client hello message. If you're willing/able to share, it can be useful for us to know what products are buggy in that they don't implement extensions

Re: Removing Extensions from Client Hello Header

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 > see no way in the SSL API to remove the default extensions in the TLS 1.3 >

Re: Should SSL_get_servername() depend on SNI callback (no-)ACK?

There's some (additional?) discussion on this topic in https://github.com/openssl/openssl/pull/10018 . A couple comments inline, though... On Tue, Oct 22, 2019 at 02:30:37PM +0200, Yann Ylavic wrote: > Hi, > > in master (and 1.1.1), SSL_get_servername() returns either >

Re: debian openssh issue with openssl 1.1.1d

On Tue, Oct 08, 2019 at 05:23:56AM -0400, Michael Richardson wrote: > Salvatore Bonaccorso wrote: > > > - > > Debian Security Advisory DSA-4539-2 > secur...@debian.org > >

Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end

On Wed, May 08, 2019 at 04:40:07PM -0400, Michael Richardson wrote: > > Viktor Dukhovni wrote: > >> Diversionary issue: > >> > https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html > >> and: > >> >

Re: Listing TLS 1.3 Ciphers

On Wed, Apr 10, 2019 at 12:13:27PM -0400, Dennis Clarke wrote: > On 4/10/19 7:37 AM, Richard Moore wrote: > >Hi All, > > > >I haven't found a way to list the supported openssl ciphers from the > >command line (i.e. get the list of potential values for -ciphersuites). I > >understand that currently

Re: [openssl-users] SNI callback

On Wed, Nov 28, 2018 at 08:48:10PM +, Jeremy Harris wrote: > OpenSSL 1.1.1 FIPS 11 Sep 2018 > RHEL 8.0 beta > > Using SSL_CTX_set_tlsext_servername_callback() > when the called routine returns SSL_TLSEXT_ERR_NOACK > I was expecting the handshake to fail. It carries > on; am I doing

Re: [openssl-users] Two sessions in a single full handshake

s_client has -sess_out and -sess_in options that can be used to save session information to a file and read it in for a subsequent connection. Neither is used by default. -Ben On Sun, Sep 30, 2018 at 11:06:14AM +0800, John Jiang wrote: > Does s_client resume any session in the local session

Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working

On Thu, Sep 13, 2018 at 08:13:41PM +0200, Jakob Bohm wrote: > On 13/09/2018 09:57, Klaus Keppler wrote: > >Hi, > > > >thank you for all your responses. > > > >I've just tested with Firefox Nightly 64.0a1, and both s_server and our > >own app (using OpenSSL 1.1.1-release) are working fine. > > >

Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working

On Wed, Sep 12, 2018 at 03:50:17PM +0200, Klaus Keppler wrote: > Hi, > > when I create a TLS-1.3-only "web" server with s_server (from OpenSSL > 1.1.1-release), Firefox/Chrome can't access it. > According to all docs I've read so far, the TLS 1.3 implementations both > from Firefox (62.x) and

Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2

On Tue, Sep 11, 2018 at 03:04:06PM -0600, The Doctor wrote: > On Tue, Sep 11, 2018 at 02:57:09PM -0500, Benjamin Kaduk via openssl-users > wrote: > > On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > > > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote:

Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2

On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > > Looks likes I found a first bug > > > > ../test/recipes/70-test_comp.t . > > Proxy started on port [::1]:10789 > > Server command:

Re: [openssl-users] OpenSSL version 1.1.1 pre release 9 published

On Mon, Aug 27, 2018 at 04:38:24PM -0400, Robert Moskowitz wrote: > > > On 08/27/2018 04:07 PM, Hubert Kario wrote: > >On Monday, 27 August 2018 20:57:53 CEST Robert Moskowitz wrote: > >>On 08/27/2018 02:33 PM, Hubert Kario wrote: > >>>On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz

Re: [openssl-users] Access clienthello in openssl1.1.0

On Wed, Jun 13, 2018 at 11:32:11AM -0500, Zeyuan Yu wrote: > Hi All, > > Is there still a way to access client hello in 1.1.0? > > Before 1.1.0 I can just access the internal `s->init_msg`. And starting > 1.1.1, APIs are provided for the client hello. But there doesn't seem to be > similar

Re: [openssl-users] Call for testing TLS 1.3

(For those who are not Jouni, there is some spec work needed for TLS 1.3/EAP integration as well, occurring in the IETF EMU working group. I assume Jouni is on the mailing list and knows this already) -Ben On Mon, May 28, 2018 at 03:28:13PM +0300, Jouni Malinen wrote: > On Sun, Apr 29, 2018 at

Re: [openssl-users] compilation error with openssl-1.1.0 and DH_get0_key

On 02/21/2018 10:16 AM, Robert Watson wrote: > I'm trying to update a crypto library for crtmpserver to work with > openssl 1.1.0.  The software is no longer actively maintained and my > c++ skills are somewhat rudimentary but I keep getting a compilation > error for something that seems trivial.

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

On 02/19/2018 02:06 PM, Norm Green wrote: > Not sure if this is expected on this platform? > > Test Summary Report > --- > ../test/recipes/04-test_asn1_encode.t    (Wstat: 256 Tests: 1 > Failed: 1) >   Failed test:  1 >   Non-zero exit status: 1 >

Re: [openssl-users] Confirmation of what I believe to be true from docs and observation

On 01/10/2018 02:37 PM, Karl Denninger wrote: > On 1/10/2018 14:07, Benjamin Kaduk wrote: >> On 01/10/2018 08:41 AM, Karl Denninger wrote: >>> We start with a context that I load a dhparam file to (so I can take a >>> DH connection) along with an edh curve, then set an acceptable cipher >>> list

Re: [openssl-users] Confirmation of what I believe to be true from docs and observation

On 01/10/2018 08:41 AM, Karl Denninger wrote: > > We start with a context that I load a dhparam file to (so I can take a > DH connection) along with an edh curve, then set an acceptable cipher > list for it to use. > Why not just use AUTO_DH (the only option for 1.1.0, IIRC)? > Assume I next

Re: [openssl-users] cert chain file ordering question

On 01/08/2018 06:33 PM, Norm Green wrote: > This question is regarding OpenSSL 1.1. > > Let's say I have this trust hierarchy: > > RootCA > CA1 > CA2 > CA3 > userCert > > > So userCert is signed by CA3, CA3 is signed by CA2, and so on up to > RootCA, which is a self-signed root cert. > > If I

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

On 11/01/2017 09:52 AM, Dave Coombs wrote: >>> It would be nice, though, if the API provided a way to get the signer's >>> certificate. There is OCSP_resp_get0_signature(), but that only returns >>> the bit string. Comparable functions in other modules (eg: >>> X509_get0_signature(),

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

On 10/31/2017 01:05 PM, Dave Coombs wrote: >>> If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and >>> NULL for X509_STORE *st since it won't be used, then I think I should get >>> the desired result, yes, at the cost of ocsp_find_signer(single-entry >>> certs) and the

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

On 10/31/2017 10:36 AM, Matt Caswell wrote: > > On 31/10/17 13:06, Dave Coombs wrote: > >> Either way, I hereby report you've got a few macros in a public >> header that can't possibly work as things stand. :-) > Yes - a bug. I'm tempted just to remove them. > That seems like the best course of

Re: [openssl-users] Passing custom CFLAGS,LDFLAGS to configure ?

On 10/27/2017 07:35 AM, David Barishev wrote: > Hello, > I am building a custom script for building openssl for android, and i > want to use unified headers which are enabled by default with ndk r15+. > For this i need to pass custom CFLAGS and LDFLAGS, which i was able to > successfully compile

Re: [openssl-users] Issue with freeing X509

I thought this had become documented recently (i.e., in master only, not even in 1.1.0), but can't find any evidence of such documentation. SSL_CTX_use_PrivateKey() takes a reference on its pkey argument in the same way as SSL_CTX_use_certificate(); it is safe for the local code to free its local

Re: [openssl-users] Issue with freeing X509

On 10/17/2017 11:27 AM, Adi Mallikarjuna Reddy V wrote: >> I am only worried about the following line.  >> >> SSL_CTX_use_certificate(ctx, cert) >> >> After this line is it safe to free cert object while ctx is still >> used later on? >> SSL_CTX_use_certificate(ctx, cert), on successful return,

Re: [openssl-users] Issue with freeing X509

You only asked about freeing the X509, which is safe in this situation. It is not safe to free the SSL_CTX if you want to use it again later -- remove this SSL_CTX_free(ctx) call and put one in your program's cleanup instead. -Ben On 10/17/2017 11:08 AM, Adi Mallikarjuna Reddy V wrote: > Forgot

Re: [openssl-users] Issue with freeing X509

On 10/17/2017 08:39 AM, Adi Mallikarjuna Reddy V wrote: > Hi, > > If I have an X509 object and is created using PEM_read_bio_X509_AUX(), > then Can I free X509 right after the completion > of PEM_read_bio_X509_AUX()? > >                                BIO *cert_bio = BIO_new(BIO_s_mem()); >        

Re: [openssl-users] How to increase the priority of some cipher ?

I am curious about this statement that "(EC)DHE cost much more resources than RSA".  In particular, ECDHE is supposed to be less computation-intensive than RSA for a given security level, so it would be interesting to hear what your setup is where the reverse is supposed to be observed. -Ben On

Re: [openssl-users] s_server and explicit dhparam

On 09/21/2017 10:57 PM, Le Van Gong, Hubert wrote: > Hi Ben, > > Ah, good catch. Maybe the doc should be updated to mention that fact. > Does anyone know if this is on the roadmap? The documentation could not really get updated more easily than the code, and I committed the needed fix yesterday,

Re: [openssl-users] s_server and explicit dhparam

On 09/21/2017 03:30 AM, Le Van Gong, Hubert wrote: > Hi there, > > I'm trying to run opensslin server modeand leverage non-default DH > params with the following command: > sudo openssl s_server -cert server_cert.pem -dhparam dhparam_2.pem > -tls1_3 -accept 443 > > Where the dhparam_2.pem file

Re: [openssl-users] Openssl failed to decrypt certificate without \r\n

On 09/18/2017 12:59 AM, Viktor Dukhovni wrote: >> On Sep 17, 2017, at 10:23 PM, Zhang, Lily (USD) wrote: >> >> Would you help me to take a look this certificate issue? >> In order to send out the file, I added ".txt" in the file name. Please >> remove it before test it. >>

Re: [openssl-users] SSL_CTX_set_cipher_list returns failure for DHE-DSS-AES256-GCM-SHA384

On 09/06/2017 12:02 AM, mahesh gs wrote: > Hi All, > > I am using openssl version 01.01.00f for providing TLS and DTLS > security for TCP and SCTP connection for our application. I have query > regarding the "Ciphers" that are accepted by the > SSL_CTX_set_cpiher_list API. The list of ciphers that

Re: [openssl-users] SSL_CTX_set_msg_callback does not invoke for received change_cipher_spec

On 08/14/2017 11:30 PM, Vakul Garg wrote: > > Hi > > > > I am using openssl s_server and s_client with ‘-msg’ option to track > tls1.2 records being exchanged. > > I notice that while transmitted change_cipher_spec record gets printed. > > But the reception of change_cipher_spec record is not

Re: [openssl-users] session resumption tls1.2/tls1.3

On 07/25/2017 06:05 PM, Neetish Pathak wrote: > > > Please provide any comments if you have or how I should go about > debugging it. Correct me if I am doing it wrong > I don't really have any good suggestions for debugging it. It might be interesting to run in a debugger and collect full

Re: [openssl-users] Apache/OpenSSL1.1 sending Fatal, Description: Handshake Failure' packet to WebDAV client

On 07/27/2017 02:49 PM, Todd Blum wrote: > SSLv2 Record Layer: Client Hello SSLv2-compatible ClientHello is pretty old and probably unneeded > [Version: SSL 2.0 (0x0002)] > Length: 46 > Handshake Message Type: Client Hello (1) > Version: SSL 3.0 (0x0300) >

Re: [openssl-users] EDDSA certificates

On 07/27/2017 09:18 AM, Robert Moskowitz wrote: > Rich, > > Meant to ask you about this at IETF. > > Given draft-ietf-curdle-pkix-05.txt sec 10, is there openssl code to > produce these??? > There is code to validate them, per commit 4328dd41582bcdca8e4f51f0a3abadfafa2163ee. I didn't look hard

Re: [openssl-users] private key difference: openssl genrsa vs opnessl req newkey

On 07/26/2017 10:13 AM, Michele Mase' wrote: > During the generation of x509 certificates, both commands give the > same results: > > Command "a": openssl req -nodes -newkey rsa:2048 -keyout example.key > -out example.csr -subj "/C=GB/ST=London/L=London/O=Global > Security/OU=IT

Re: [openssl-users] session resumption tls1.2/tls1.3

[Matt's reply is likely to be high latency] On 07/24/2017 08:53 PM, Neetish Pathak wrote: > > > On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell > wrote: > > > > On 18/07/17 22:27, Neetish Pathak wrote: > > Hi , > > thanks Matt, this is

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

On 06/25/2017 03:06 PM, we...@infotech.de wrote: > Dear OpenSSSL users, > > we recently came across a certificate with OID: id-RSASSA-PSS aka > rsassaPss in x509 subjects public key AlgorithmIdentifier. > > According to rfc4056 it is legitimate to use rsaEncryption or > id-RSASSA-PSS as OID for

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

On 06/19/2017 04:12 PM, Neetish Pathak wrote: > > > On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak > wrote: > > Hi Matt, > Thanks > Could you help with following queries > > 1) On the blogpost for TLS1.3, you mentions the following

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

On 06/16/2017 05:36 PM, Matt Caswell wrote: >> The security properties of such "external" PSKs are substantially >> different than the "ephemeral" PSKs used in resumption flows. > Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE > based secret (assuming a suitable kex_mode

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

On 06/16/2017 01:58 PM, Neetish Pathak wrote: > Hello > Thanks > I tried reading some content from the server side and I observed the > new_session_cb getting invoked in that case on the client side. I > understand that may be due to delayed NewSession info transfer from > server side to client

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

On 06/09/2017 07:54 PM, Neetish Pathak wrote: > > On Thu, Jun 8, 2017 at 3:45 PM, Matt Caswell > wrote: > > > > On 08/06/17 23:12, Neetish Pathak wrote: > > Thanks. > > I had one query regarding the TLS 1.3 implementation on server >

Re: [openssl-users] Using weak ciphers in OpenSSL v 1.1.0e client

On 06/07/2017 11:13 AM, gerritvn wrote: > We are using OpenSSL in a terminal emulation product. > We recently upgraded from OpenSSL v 1.0.2g to OpenSSL v 1.1.0e. > Some servers we connect to do not support any of the strong ciphers which > are compiled by default in OpenSSL v 1.1.0e and returns an

Re: [openssl-users] Dumb question about DES

On 05/11/2017 03:17 PM, Scott Neugroschl wrote: > > So if I’m using 1.0.2, and want to deprecate 3DES, I need to do that > as part of my build? > > Yes. -Ben -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Dumb question about DES

ES CBC ciphers still part of DEFAULT? > > > > *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On > Behalf Of *Benjamin Kaduk via openssl-users > *Sent:* Thursday, May 11, 2017 9:18 AM > *To:* openssl-users@openssl.org > *Subject:* Re: [openssl-users] Dumb ques

Re: [openssl-users] Dumb question about DES

Those ciphers are triple-DES, not single-DES. (The "CBC3" gives it away ... well, not exactly.) The single-DES ciphers were removed in release 1.1.0 (they are included in the "40 and 56 bit cipher support removed from libssl" item in the release notes), though the raw crypto primitives remain in

Re: [openssl-users] NMAKE error

On 05/01/2017 10:02 AM, James Condren wrote: > > Getting the following error when attempting to make: > > NMAKE : fatal error U1073: don't know how to make > '"crypto\include\internal\bn_conf.h.in"' > > Stop. > > > > Here’s the lines from the makefile that are creating the error: > >

Re: [openssl-users] Multithreading: Global locks causing bottleneck in parallel SSL_write calls

On 04/12/2017 05:54 AM, dipakgaigole wrote: > Hi, > > I have a windows multi-threaded SSL server application which handles > each client request in a new thread. The Server handles different > types of requests. One of the request type is like “send file” where > server thread has to read a file

Re: [openssl-users] [openssl-dev] verify depth behavior change from 1.0.2 to 1.1.0?

On 04/04/2017 10:39 AM, Viktor Dukhovni wrote: >> On Apr 4, 2017, at 10:41 AM, Short, Todd via openssl-users >> wrote: >> >> Ben Kaduk: >> >> Do we know the values that are being passed to SSL_CTX_set_verify_depth() >> match the -verify_depth argument, or do they

Re: [openssl-users] Query regarding upgrading TLS compatibility

On 04/03/2017 04:42 AM, Hegde, Harsha wrote: > > Hi, > > I have an query regarding TLS compatibility used in my application. > Currently we are using TLS1.2 to connect to a third party sever. Is > there any way to always use the highest TLS available version without > modifying or recompiling the

Re: [openssl-users] openssl-compat patch for OpenSSL 1.0.2 and below?

On 04/02/2017 07:42 PM, Jeffrey Walton wrote: > I was looking at Kurt Roeckx 's patches for OpenSSH at > https://github.com/openssh/openssh-portable/pull/48/files. See > libcrypto-compat.h and libcrypto-compat.c. > > Are the source files distributed by OpenSSL? If so, where is the download? > > If

  1   2   >