Re: [openssl-dev] Is X509_free(NULL) ok?

➢So it's guaranteed for 1.1, mostly guaranteed for recent 1.0.2, but not guaranteed for older 1.0.2. yes. ➢ I also think it would be good to backport all to 1.0.2 Yes. I believe I did that, but I am not absolutely 100% positive. -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Is X509_free(NULL) ok?

On 12/22/2017 9:59 AM, Salz, Rich via openssl-dev wrote: I think we fixed all such cases in 1.1.0, all *_free() functions should handle NULL. I don't think we backported to changes to 1.0.2. Yes, and we fixed the documentation. I backported all/most of them to 1.0.2 to make cherry-picking

Re: [openssl-dev] Is X509_free(NULL) ok?

➢ I think we fixed all such cases in 1.1.0, all *_free() functions should handle NULL. I don't think we backported to changes to 1.0.2. Yes, and we fixed the documentation. I backported all/most of them to 1.0.2 to make cherry-picking easier. I don’t know if I changed the docs.

Re: [openssl-dev] Is X509_free(NULL) ok?

On Fri, Dec 22, 2017 at 09:30:19AM -0500, Ken Goldman wrote: > On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote: > > > if (ptr!= NULL) free(ptr); > > That shouldn’t be necessary for OpenSSL. If you find places where it is, > > please open an issue. > > OK. I'll mention a few, but

Re: [openssl-dev] Is X509_free(NULL) ok?

On Fri, Dec 22, 2017 at 01:06:20PM +, Salz, Rich via openssl-dev wrote: > Our intent is that all FREE functions can handle NULL. If you find things > missing or undocumented, please open an issue on GitHub. Thanks! I think we fixed all such cases in 1.1.0, all *_free() functions should

Re: [openssl-dev] Is X509_free(NULL) ok?

On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote: if (ptr!= NULL) free(ptr); That shouldn’t be necessary for OpenSSL. If you find places where it is, please open an issue. OK. I'll mention a few, but it's a global issue. The code may handle NULL. However,

Re: [openssl-dev] [openssl-users] Is X509_free(NULL) ok?

> if (ptr!= NULL) free(ptr); That shouldn’t be necessary for OpenSSL. If you find places where it is, please open an issue. ➢ BTW, "can handle" should explicitly say what happens. Perhaps use the C library text, which says: If ptr is NULL, no operation is

Re: [openssl-dev] Is X509_free(NULL) ok?

Our intent is that all FREE functions can handle NULL. If you find things missing or undocumented, please open an issue on GitHub. Thanks! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Is X509_free(NULL) ok?

Hi, I think it should be documented, but currently the two supported branches are ok with NULL: - following from IMPLEMENT_ASN1_FUNCTIONS(X509), for both openssl-1.0.2n and 1.1.0g: - 1.0.2n ends up in asn1_item_combine_free() - 1.1.0g ends up in asn1_item_embed_free() - in both cases an explicit

Re: [openssl-dev] Is X509_free(NULL) ok?

> On Dec 20, 2017, at 5:50 PM, Ray Satiro via openssl-dev > wrote: > > 'm trying to figure out whether it's supported to call X509_free(NULL) > in 1.0.2 and beyond. It's not documented what action occurs when the > pointer is null. Also generally speaking is it

[openssl-dev] Is X509_free(NULL) ok?

I'm trying to figure out whether it's supported to call X509_free(NULL) in 1.0.2 and beyond. It's not documented what action occurs when the pointer is null. Also generally speaking is it supported to call openssl free functions with null pointers? -- openssl-dev mailing list To unsubscribe:

[openssl-dev] Padding for RSA signatures

Hi, I am playing around with RSA signatures with different padding and have some questions. I have my sample code below for reference. It's in Swift (but it should still be close enough to C to be readable). Also in Swift, some of the complex macros in OpenSSL have to be broken down to be

Re: [openssl-dev] [openssl-users] Windows OpenSSL's FIPS Binaries

> does anybody know if there are downloadable binaries of > openssl-fips and/or openssl-fips-ecp (2.0.16 or earlier) for > Windows ? http://wiki.overbyte.eu/wiki/index.php/ICS_Download We have OpenSSL 1.0.2m-fips for Win32, primarily for application testing since our DLLs would not pass FIPS

[openssl-dev] openssl X509 reading signature Hash algorithm using C unix

I'm trying to convert my root certificate to Pem files using C unix. In my current code I'm using the openssl function const EVP_MD *digest=EVP_sha1(); to make the digest as SHA1, but now I want to modify the code to support sha256 and sha512. >From the current openssl.h I found that

Re: [openssl-dev] Potential timing problems in OpenSSL RSA implementation

Hi, > I'd like to stress that this is highly speculative, it may very well be > that this is not exploitable in any practical way. But I thought it's > important enough that it should be public knowledge. (Also "This leaves > a small timing channel, [...] but it is not believed to be large >

Re: [openssl-dev] OpenSSL version 1.0.2n published

I went back to our Jenkins test logs and found that this breakage was prior to 1.0.2n. Sorry for the confusion. I still need to track down why this is happening. Advice is appreciated on pursing this. Thanks, Randall -- Brief whoami: NonStop developer since approximately

Re: [openssl-dev] OpenSSL version 1.0.2n published

On 07/12/17 15:16, Randall S. Becker wrote: > For HPE NonStop J-Series: Builds passed. Previous version was 1.0.2m. > > New breakage: > ../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem ../apps/server.pem > SSL_accept() failed -1, 1 > 1827815872:error:140800FF:SSL

Re: [openssl-dev] OpenSSL version 1.0.2n published

For HPE NonStop J-Series: Builds passed. Previous version was 1.0.2m. New breakage: ../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem ../apps/server.pem SSL_accept() failed -1, 1 1827815872:error:140800FF:SSL routines:ssl3_accept:unknown state: openssl/ssl/s3_srvr.c:869: -Original

Re: [openssl-dev] OpenSSL version 1.0.2n published

OpenSSL in gmane.comp.encryption.openssl.devel (Thu, 7 Dec 2017 13:55:43 +): > OpenSSL version 1.0.2n released I ran into a compiling issue with openssl-fips-2.0.16. See https://github.com/openssl/openssl/issues/4864 -- Jan -- openssl-dev mailing list To unsubscribe:

[openssl-dev] OpenSSL Security Advisory

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [07 Dec 2017] Read/write after SSL object in error state (CVE-2017-3737) == Severity: Moderate OpenSSL 1.0.2 (starting

[openssl-dev] OpenSSL version 1.0.2n published

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.0.2n released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2n of our open

Re: [openssl-dev] frequency and size of heartbeat requests

On Tue, 5 Dec 2017 19:21:50 + "Salz, Rich via openssl-dev" wrote: > There is never any reason to use this in TCP-based TLS; > that was an OpenSSL bug that enabled it there. I opened an issue for this bug, so it can be fixed:

Re: [openssl-dev] A question DH parameter generation and usage

You can re-use the keys, but then you get no forward secrecy, and sessions generated with one connection are vulnerable to another. Why are you using DH? Unless you have compelling reasons (interop with legacy), you really should use ECDHE. -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] frequency and size of heartbeat requests

thanks Hanno and Rich. On Tue, 12/5/17, Hanno Böck wrote: Subject: Re: [openssl-dev] frequency and size of heartbeat requests To: openssl-dev@openssl.org Cc: "Jitendra Lulla" Date: Tuesday, December 5, 2017,

Re: [openssl-dev] A question DH parameter generation and usage

For DHE_RSA, you first need a pair of RSA certificate/key for signing. And you if want to use specific DH parameters, you can use the SSL_CTX_set_tmp_dh API, there is documentation describing how to use this function. DH parameter could be generated by OpenSSL in many ways, one of the common

[openssl-dev] ECC ciphers in OpenSSL and Citricom Patent/License terms

Hi, I have a question on ECC ciphers implementaion in OpenSSL. I do see README.ECC file in FIPS certfied OpenSSL crypto library. That says The OpenSSL Software Foundation has executed a sublicense agreement entitled "Elliptic Curve Cryptography Patent License Agreement" with the National

[openssl-dev] A question DH parameter generation and usage

Hi, We are planning to use DHE_RSA TLS ciphers into our product. I have few questions on using DH parameter. We would like to use DH-2048. our product includes both TLS client and server applications. Thus any time there will be considerable number of active connectioons. I believe we can use

Re: [openssl-dev] frequency and size of heartbeat requests

On Tue, 5 Dec 2017 19:14:41 + (UTC) Jitendra Lulla via openssl-dev wrote: > Could the solution be a restricted count of HB requests along with a > timer? No, the solution is to disable TLS heartbeats. I actually wanted to bring this up when I recently noticed that

Re: [openssl-dev] frequency and size of heartbeat requests

The purpose of the HEARTBEAT message is for DTLS applications to determine the maximum packet size and tune the application records accordingly. There is never any reason to use this in TCP-based TLS; that was an OpenSSL bug that enabled it there. The usefulness of HEARTBEAT even in DTLS is

[openssl-dev] frequency and size of heartbeat requests

Hi, With an "intentionally corrupted" tls1_heartbeat() in Openssl 1.0.2l, heart beat requests with big payloads such as 16300 or slightly more can be repeatedly sent to the server. The server, religiously responds back with such big payloads after spending its cpu on encrypting/HMAC

Re: [openssl-dev] Known apps supporting tls max frag size extn

On Monday, 4 December 2017 13:43:32 CET Jitendra Lulla via openssl-dev wrote: > Thanks Joey. > > And I found the url for listing a server's tls extensions here: > > http://possible.lv/tools/hb/?domain=yahoo.com > > Do you know how we can enable/test the extensions using firefox or any other >

Re: [openssl-dev] Known apps supporting tls max frag size extn

Thanks Joey. And I found the url for listing a server's tls extensions here: http://possible.lv/tools/hb/?domain=yahoo.com Do you know how we can enable/test the extensions using firefox or any other browser? On Mon, 12/4/17, Joey Yandle

Re: [openssl-dev] Known apps supporting tls max frag size extn

> Also, I have lost the url of a website which used to analyze any given server > ( eg www.yahoo.com) for its supporting various tls extensions. You provide > the server url and it will display all the tls extns supported by that > server. If you know of any such url, could you please help me

[openssl-dev] Known apps supporting tls max frag size extn

Hi, Could anybody please help me in finding known standard apps ( eg browsers and servers) which support tls extension for maximum fragment size negotiation? Also, I have lost the url of a website which used to analyze any given server ( eg www.yahoo.com) for its supporting various tls

Re: [openssl-dev] Certificate Limitation Profile

On Tue, Nov 28, 2017 at 11:37:35PM +0300, Dmitry Belyavsky wrote: > Thank you. It seems reasonable to add nextUpdate field to > the header of CLP to avoid problems related to using stale CLP. > > I expect that fresh CLPs in most cases are delivered via update procedures > of applications, and

Re: [openssl-dev] Certificate Limitation Profile

Dear Victor, On Tue, Nov 28, 2017 at 11:14 PM, Viktor Dukhovni < openssl-us...@dukhovni.org> wrote: > On Tue, Nov 28, 2017 at 07:18:48PM +, Blumenthal, Uri - 0553 - MITLL > wrote: > > > I think it makes perfect sense to sign CLP, because it allows you to > > separate trust in the server

Re: [openssl-dev] Certificate Limitation Profile

On Tue, Nov 28, 2017 at 07:18:48PM +, Blumenthal, Uri - 0553 - MITLL wrote: > I think it makes perfect sense to sign CLP, because it allows you to > separate trust in the server you�re downloading the content from and the > content itself. The problem with "data at rest" signatures is that

Re: [openssl-dev] Certificate Limitation Profile

I'm wondering how you think that policy will be distributed and why it needs signed. … For instance it might come as part of some software distribution (like a browser), and either you trust all the files in that distribution or you don't. I agree that an unsigned variant of CLP makes sense.

Re: [openssl-dev] Certificate Limitation Profile

Dear Kurt, On Tue, Nov 28, 2017 at 3:25 PM, Kurt Roeckx wrote: > On Mon, Nov 27, 2017 at 07:56:00PM +0300, Dmitry Belyavsky wrote: > > Here is the link to the draft: > > https://datatracker.ietf.org/doc/draft-belyavskiy- > certificate-limitation-policy/ > > I'm wondering how you

Re: [openssl-dev] [openssl-users] DTLS in multi-thread and concurrent connection acceptance environment

> I don't know if anyone has ever created any metrics on how far it > can be scaled. I've certainly not seen it if they have. But there > are no knownlimitations on this approach (this is the intended > way to do things). Our Delphi OpenSSL implementation on Windows mostly uses a single thread

Re: [openssl-dev] Certificate Limitation Profile

On Mon, Nov 27, 2017 at 07:56:00PM +0300, Dmitry Belyavsky wrote: > Here is the link to the draft: > https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/ I'm wondering how you think that policy will be distributed and why it needs signed. I expect that there will

[openssl-dev] Certificate Limitation Profile

Hello, I'm working on an internet draft describing application-level analog of CRLs. I named the proposed file format Certificate Limitation Profile. I think that current model of trust when only CAs can revoke the certificates issued by them does not fit current situation, and we also need

Re: [openssl-dev] FIPS module for 1.1.x ?

FIPS remains a very important goal. Hopefully we’ll have more details to share in early December. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] FIPS module for 1.1.x ?

With the recent changes in OMC, how has the OpenSSL 1.1.x FIPS plan changed? Can the OMC provide some insight? It was suggested that I wait for things to settle before asking and it has been a few weeks since the last of the announcements. Previously, there was a plan to expand the engine

[openssl-dev] Initialization and cleanup in 1.1.0f

I'm using OpenSSL 1.1.0f in a client application. My implementation is using up memory like crazy, so I must not be doing something right. I read that 1.1.0 no longer needs explicit library initialization, so I've take out the one-time calls (like SSL_library_init() and SSL_load_error_strings()).

Re: [openssl-dev] Problems building openssl on Solaris

Hello, On Fri, Nov 17, 2017 at 2:21 PM, Richard Levitte wrote: > Ah, sorry, I didn't read the output properly. > > Regarding the STV_PROTECTED warnings, I don't know at all... I did a > bit of a search and saw that this has been discussed before, a little > more than a

Re: [openssl-dev] Problems building openssl on Solaris

I tested 1.1.0g on my solaris10 sparc machine and it worked fine, but I use opencsw packages with a more modern gcc (4.9.2). Essentially my build environment and build looks like this: # Install packages from opencsw pkgadd -d http://get.opencsw.org/now&& \ /opt/csw/bin/pkgutil -U

Re: [openssl-dev] Problems building openssl on Solaris

Ah, sorry, I didn't read the output properly. Regarding the STV_PROTECTED warnings, I don't know at all... I did a bit of a search and saw that this has been discussed before, a little more than a year ago. See https://mta.openssl.org/pipermail/openssl-dev/2016-August/008192.html As for the

Re: [openssl-dev] Problems building openssl on Solaris

Dear Richard, Adding no-threads just removes gcc complaint about -pthreads. On Fri, Nov 17, 2017 at 1:23 PM, Richard Levitte wrote: > I suggest adding 'no-threads' to the OpenSSL configuration options, at > least as a first step. That should at least take away gcc's

Re: [openssl-dev] Problems building openssl on Solaris

I suggest adding 'no-threads' to the OpenSSL configuration options, at least as a first step. That should at least take away gcc's complaint about '-pthread'... I cannot say if that'll fix the rest, I don't know Solaris enough. Cheers, Richard In message

[openssl-dev] Problems building openssl on Solaris

Hello, We experience problems building OpenSSL on Solaris. /usr/local/src/openssl-1.1.0g>uname -a SunOS pooh.tcinet.ru 5.10 Generic_147147-26 sun4u sparc SUNW,SPARC-Enterprise /usr/local/src/openssl-1.1.0g>gcc -v Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs

Re: [openssl-dev] a possible bug for certain usage of openSSL1.1.0 with TLSv1

On 02/11/17 13:01, Ma chunhui wrote: > Hi, Openssl team > After we upgrade openSSL from 1.0.2 to 1.1.0f, we met an error which > might be a bug. Does this fix it: https://github.com/openssl/openssl/pull/4685 (master) https://github.com/openssl/openssl/pull/4686 (1.1.0) Matt -- openssl-dev

Re: [openssl-dev] Mailman privacy alert

Sent from my iPhone > On Nov 4, 29 Heisei, at 20:20, openssl-dev-boun...@openssl.org wrote: > > An attempt was made to subscribe your address to the mailing list > openssl-dev@openssl.org. You are already subscribed to this mailing list. > > Note that the list membership is not public, so it

[openssl-dev] OpenSSL Security Advisory

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [02 Nov 2017] bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736) == Severity: Moderate There is a carry propagating bug in

[openssl-dev] OpenSSL version 1.1.0g published

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.1.0g released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0g of our open

[openssl-dev] OpenSSL version 1.0.2m published

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.0.2m released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2m of our open

[openssl-dev] a possible bug for certain usage of openSSL1.1.0 with TLSv1

Hi, Openssl team After we upgrade openSSL from 1.0.2 to 1.1.0f, we met an error which might be a bug. 1. our usage We're using java application, and using JNI call to call OpenSSL API.(In fact, we're using an opensource project named wildfly-openssl) After context and ssl is created, for one

Re: [openssl-dev] Forthcoming OpenSSL releases

On 30/10/17 13:50, Matt Caswell wrote: > Forthcoming OpenSSL releases > > > The OpenSSL project team would like to announce the forthcoming release > of OpenSSL versions 1.1.0g and 1.0.2m. > > These releases will be made available on 2nd November 2017 between >

[openssl-dev] Forthcoming OpenSSL releases

Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.0g and 1.0.2m. These releases will be made available on 2nd November 2017 between approximately 1300-1700 UTC. This is a bug-fix release. It

Re: [openssl-dev] [openssl-users] OpenSSL engine and TPM usage.

Hi Jayalakshmi, Is your implementation OSS or intellectual property? If it is OSS can you please provide the URL? Regards, Freemon On Wed, Oct 25, 2017 at 1:06 PM, Jayalakshmi bhat < bhat.jayalaks...@gmail.com> wrote: > Hi All, > > Our device uses TPM to protect certificate private keys. We

Re: [openssl-dev] [openssl-users] OpenSSL engine and TPM usage.

On Thu, 2017-10-26 at 13:57 +0200, Richard Levitte wrote: > In message

Re: [openssl-dev] [openssl-users] OpenSSL engine and TPM usage.

In message

Re: [openssl-dev] Systemwide configurability of OpenSSL

On Wed, Oct 25, 2017 at 05:19:23PM +0200, Tomas Mraz wrote: > > The problem is that by default the applications do not read the file and > do not apply the defaults. Even the openssl s_client/s_server does not > seem to work, but I might be doing something wrong. > > What I would like to see is

[openssl-dev] OpenSSL engine and TPM usage.

Hi All, Our device uses TPM to protect certificate private keys. We have written engine interface to integrate TPM functionality into OpenSSL. Thus TPM gets loaded as an engine instance. Also we have mapped RSA operations to TPM APIS as like encryption/decryption etc. Now we are into few

Re: [openssl-dev] Systemwide configurability of OpenSSL

On 25/10/17 16:19, Tomas Mraz wrote: >> |However libssl currently does not have a way to apply some policy such >> |as using just protocol TLS1.2 or better system-wide with a possibility >> |for sysadmin to configure this via some configuration file. Of course >> |it would still be up to

Re: [openssl-dev] Systemwide configurability of OpenSSL

On 09/28/2017 12:21 AM, Steffen Nurpmeso wrote: > Hello. > > Tomas Mraz wrote: > |I would like to restart the discussion about possibilities of system- > |wide configurability of OpenSSL and particularly libssl. > | > |Historically OpenSSL allowed only for configuration of

[openssl-dev] Wanted details on ./config or Configure options

Hi All, I am looking for details on options used to disable or remove unwanted ciphers, components while openssl building. This is for OpenSSL 1.0.2h. I am seeing many things on internet. But most of them have minimum explanation, please can you tell me is there any link that I can refer.

Re: [openssl-dev] New crypto algorithms in openSSL engine

OpenSSL - Dev mailing list wrote >>@Victor; Are you saying so that the patches that enabled the GOST > ciphersuite be added are not included in openSSL? If so, would that > mean > it's not possible for me to fork off openSSL and follow the GOST > template? > > Not quite. He’s

Re: [openssl-dev] New crypto algorithms in openSSL engine

On Mon, Oct 23, 2017 at 4:54 PM, Salz, Rich via openssl-dev < openssl-dev@openssl.org> wrote: > ➢ Really, about a ten years ago, when we first developed GOST engine, we > have made patches, that allow to add ciphersuites dynamically. > Unfortunately, that time core team haven't accepted

Re: [openssl-dev] New crypto algorithms in openSSL engine

>@Victor; Are you saying so that the patches that enabled the GOST ciphersuite be added are not included in openSSL? If so, would that mean it's not possible for me to fork off openSSL and follow the GOST template? Not quite. He’s saying that adding new crypto to TLS requires

Re: [openssl-dev] New crypto algorithms in openSSL engine

➢ Really, about a ten years ago, when we first developed GOST engine, we have made patches, that allow to add ciphersuites dynamically. Unfortunately, that time core team haven't accepted these patches. Do you still have them available? We might make a different choice now … --

Re: [openssl-dev] New crypto algorithms in openSSL engine

Thanks for the replies guys. I'm happy enough to work on a separate fork. This is a research endevour so it's not critical that I get something integrated into the master openSSL branch. I don't see there being a significant enough user base anyway for anything to get added into core libssl.

Re: [openssl-dev] New crypto algorithms in openSSL engine

On 23/10/17 12:51, APOB83 wrote: > Hi, > > I've noticed the following statement in another thread here... > > *May I suggest you have a look at the GOST engine? It does implement > the algorithm entirely in the engine. The only things added in the > OpenSSL code are the OIDs (not strictly

Re: [openssl-dev] New crypto algorithms in openSSL engine

Hi, I've noticed the following statement in another thread here... *May I suggest you have a look at the GOST engine? It does implement the algorithm entirely in the engine. The only things added in the OpenSSL code are the OIDs (not strictly necessary) and the TLS ciphersuites (I don't

Re: [openssl-dev] confirm eaf6a05b1db3ce90b620c3c0e5498d999d97b3eb

Sent from my iPhone > On Oct 20, 29 Heisei, at 9:07 PM, openssl-dev-requ...@openssl.org wrote: > > Mailing list subscription confirmation notice for mailing list > openssl-dev > > We have received a request from 103.242.14.62 for subscription of your > email address, "kimsova...@gmail.com",

Re: [openssl-dev] #GP happens in do_sse3_after_all

Hi, I met an issue in the crypto/chacha/chacha-x86_64.S, could you be kind to have a look on it? Thanks very much. Currently it will stuck in the function *do_sse3_after_all*, and a #GP will occurs due to the following instructions ““movdqa %xmm0,0(%rsp)” need 16 bytes alignment, however,

[openssl-dev] #GP happens in do_sse3_after_all

Hi dear openssl maintainer, I met an issue in the crypto/chacha/chacha-x86_64.S, could you be kind to have a look on it? Thanks very much. Currently it will stuck in the function do_sse3_after_all, and a #GP will occurs due to the following instructions ""movdqa %xmm0,0(%rsp)" need 16 bytes

Re: [openssl-dev] how to static compile ssl engine into openssl

> On 26 Sep 2017, at 18:13, 程文平 > wrote: > > There is some more info. > > https://github.com/01org/QAT_Engine/issues/9 > Interesting. This issue was created by me last year, seems some people

Re: [openssl-dev] how to static compile ssl engine into openssl

> On 26 Sep 2017, at 18:13, 程文平 > wrote: > > There is some more info. > > https://github.com/01org/QAT_Engine/issues/9 > Interesting. This issue was created by me last year, seems some people

[openssl-dev] Fwd: [TLS] Update on TLS 1.3 Middlebox Issues

An update on the TLS1.3 middlebox issue posted to the TLS WG list which may be of interest to the openssl-dev group. Matt Forwarded Message Subject:[TLS] Update on TLS 1.3 Middlebox Issues Date: Fri, 6 Oct 2017 13:16:37 -0700 From: Eric Rescorla To:

Re: [openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

On Wed, Oct 04, 2017 at 10:39:03AM +0100, Matt Caswell wrote: > > At the very least, it should be added to the big notes: > > https://www.openssl.org/news/openssl-1.1.0-notes.html > > (this was in fact the first place I looked when my data was broken, > > there was nothing about the enc tool

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote: > Thanks for the hint. The problem is fixed. > > Server was setting: > > if (SSL_CTX_set1_groups_list(ctx, "X25519:P-256") == 0) { > // > } > > The call succeeds. > > But the old TLS 1.2 code was setting: > > int nid =

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

Thanks for the hint. The problem is fixed. Server was setting: if (SSL_CTX_set1_groups_list(ctx, "X25519:P-256") == 0) { // } The call succeeds. But the old TLS 1.2 code was setting: int nid = NID_X9_62_prime256v1; EC_KEY* ecdh = EC_KEY_new_by_curve_name(nid);

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

I am attaching a pcap where I set the supported list to contain X25519. The client extension contains X25519. However, the server still responds with keyshare extension secp256r1 in a hello retry request. This is the case for all the 5 TLS 1.3 ciphers. Is there another setting for the server to

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote: > if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) { >//error > } > If you have the above line you're telling the client to advertise support for P-521:P-384:P-256 in that order and the server to only use them. >

Re: [openssl-dev] Can I haz TLS 1.3 ?

On 3 October 2017 at 20:45, Hanno Böck wrote: > On Tue, 3 Oct 2017 17:36:03 + > "Salz, Rich via openssl-dev" wrote: > > So I heard chatter about this, but not much details. Which I find > unfortunate and a bit disturbing. (I'm aware of a single case

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

On 10/04/2017 04:30 AM, Matt Caswell wrote: > > Looks like we should have an exception for this case (with a suitable > comment explaining why). Will you create a PR? > Yes, I was planning to.  I was just taking some time to ponder whether it's worth burning an option bit on, to allow an opt-out

Re: [openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

On Wed, Oct 04, 2017, Matt Caswell wrote: > > As Tomas said - that ship has sailed. In my mind that change was a > mistake. It could have been done in a non-breaking way by introducing a > new header format at that time. > As regards a new header format. In the case of some of the structures

Re: [openssl-dev] Can I haz TLS 1.3 ?

It's not specific to devops. Here, a quick history lesson: https://english.stackexchange.com/questions/20356/origin-of-i-can-haz Cheers Richard Ted Marynicz skrev: (4 oktober 2017 10:53:35 CEST) >Haz? > >Is that some kind of devops-speak I am not (yet) aware of? > >Ted

Re: [openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

On 03/10/17 18:51, Robin H. Johnson wrote: > On Tue, Oct 03, 2017 at 09:45:43AM +0200, Tomas Mraz wrote: >> On Tue, 2017-10-03 at 08:23 +0100, Matt Caswell wrote: >>> 1.2. This also opens the path to stronger key derivation (PBKDF2) 2. During decryption, if no header block is present,

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

On 03/10/17 16:15, Benjamin Kaduk via openssl-dev wrote: > Hi all, > > Doing some testing with a snapshot of master (s_client with -tls1_2 and > optionally a cipherspec that prefers ECDHE ciphers), we're running into > a sizeable number of servers that are sending extension 0xa (formerly >

Re: [openssl-dev] Can I haz TLS 1.3 ?

Can the people involved in these Tests please speak up what's going on here? Particularly can you please name vendor names? Tbe TLSWG mailing list is probably a more effective place to have that discussion; I was just informing the OpenSSL community of the state of play ;) --

Re: [openssl-dev] Can I haz TLS 1.3 ?

Hi, On Tue, 3 Oct 2017 17:36:03 + "Salz, Rich via openssl-dev" wrote: > Tests run by various companies, including Google, Mozilla, and > Facebook, indicate that the “failure rate” of TLS 1.3 is disturbingly > high. It appears that network hardware such as routers,

Re: [openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

On Tue, Oct 03, 2017 at 09:45:43AM +0200, Tomas Mraz wrote: > On Tue, 2017-10-03 at 08:23 +0100, Matt Caswell wrote: > > > > > 1.2. This also opens the path to stronger key derivation (PBKDF2) > > > 2. During decryption, if no header block is present, and no message > > >    digest was specified,

[openssl-dev] Can I haz TLS 1.3 ?

Some people have asked why TLS 1.3 isn’t available yet. This might help; it’s a draft of a posting for my company’s blog. Can I Haz TLS 1.3 ? Everybody wants to be able to use TLS 1.3. Among the reasons are: It’s faster – being able to reconnect to a server you’ve previously

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

It's just that extension in our experience. Enforcing that servers don't send extensions they aren't supposed to generally works fine and is good for the ecosystem. But that particular extension needs a quirk. I suspect there was some confusion because ec_point_format_list can be server-sent in

[openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

Hi all, Doing some testing with a snapshot of master (s_client with -tls1_2 and optionally a cipherspec that prefers ECDHE ciphers), we're running into a sizeable number of servers that are sending extension 0xa (formerly "elliptic_curves", now "supported_groups") in the ServerHello.  This is not

Re: [openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

On Tue, 2017-10-03 at 08:23 +0100, Matt Caswell wrote: > > > 1.2. This also opens the path to stronger key derivation (PBKDF2) > > 2. During decryption, if no header block is present, and no message > >    digest was specified, the default digest SHOULD be MD5. > > Should it? What about

Re: [openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

On 02/10/17 20:20, Robin H. Johnson wrote: > Commit f8547f62c212837dbf44fb7e2755e5774a59a57b (documented in > 9e8b6f042749ded556380227c9f2db7ffad9a3aa), changed the default digest > for the 'enc' utility from MD5 to SHA256. > > While I do strongly encourage getting away from MD5, this has the >

[openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

Commit f8547f62c212837dbf44fb7e2755e5774a59a57b (documented in 9e8b6f042749ded556380227c9f2db7ffad9a3aa), changed the default digest for the 'enc' utility from MD5 to SHA256. While I do strongly encourage getting away from MD5, this has the unfortunate side effect of silently breaking existing

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