Re: [openssl-dev] version script patch from Debian

On 21/01/16 16:53, Tom Kacvinsky wrote: > I ran into this problem with the OpenSSL 1.0.1e I built from source on a > Debian based system (Ubuntu): > > libssl.so.1.0.0: no version information available (required by python) > > Found this page: > >

[openssl-dev] [openssl.org #4141] GOST ciphersuites

This one was fixed a while ago. Closing. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4213] Error defining ciphersuite 0x0300ff87

Patch applied - thanks. Closing ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

Alessandro's patch has now been applied (thanks). Closing this ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format

On Mon Dec 28 23:53:02 2015, matt wrote: > On Mon Dec 28 22:01:04 2015, rs...@akamai.com wrote: > > Yes we would be interested in this but someone would almost > > definitely > > have to be provided as a complete patch because it seems unlikely > > anyone on the team will get around to doing it by

Re: [openssl-dev] Backporting opaque struct getter/setter functions

On 11/01/16 18:29, Viktor Dukhovni wrote: > >> On Jan 11, 2016, at 5:23 AM, Tomas Mraz wrote: >> >> On Po, 2016-01-11 at 01:09 +, Peter Waltenberg wrote: >>> The point of using accessor FUNCTIONS is that the code doesn't break >>> if the structure size or offsets of

Re: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption

On 06/01/16 06:14, Zi Lin wrote: > Hi Matt, > > thanks for your time. I am glad to see the big efforts done to make > OpenSSL code better in the master branch (and v1.1.0+). I will find a > way to start working on the master branch. A quick glance into the > master branch state machine: the

Re: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption

On 05/01/16 22:44, Zi Lin wrote: > Hi OpenSSL devs, > > I want to propose a patch that makes OpenSSL compatible with > asynchronous session lookup during session resumption. Currently, the > session lookup expects the session callback to return immediately with > success or failure. Now consider

[openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format

On Mon Dec 28 22:01:04 2015, rs...@akamai.com wrote: > Yes we would be interested in this but someone would almost definitely > have to be provided as a complete patch because it seems unlikely > anyone on the team will get around to doing it by 1.1 release. > Actually I think this capability is

[openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake

On Wed Dec 23 16:48:20 2015, matt wrote: > On Wed Dec 23 15:42:54 2015, d...@inky.com wrote: > > Using the current master (head) code, this reproduces it: > > > > openssl s_client -connect mail.baggett.org:465 > > > > This is my own personal mail server, so feel free to poke and prod > > it. > > >

[openssl-dev] [openssl.org #4120] CertificateStatus message is optional

Thanks for the report David. This has now been fixed in master/1.0.2/1.0.1 Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake

On 23/12/15 17:21, Viktor Dukhovni wrote: > On Wed, Dec 23, 2015 at 04:48:20PM +0000, Matt Caswell via RT wrote: > >> The problem is that the server has been configured to allow client auth. The >> CertificateRequest message coming from the server seems very lo

[openssl-dev] [openssl.org #4197] [PATCH] Memory leak in state machine in error path

On Tue Dec 22 17:02:07 2015, tsh...@akamai.com wrote: > Hello OpenSSL org: > > I found the following issue via code inspection. In > tls_process_client_key_exchange(), when EC is disabled, and an error > occurs in ssl_generate_master_secret() or RAND_bytes(), the error path > does not free

[openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake

before). Matt >From 14202312b361b5b5c1ad719b96c02daeb1e2b0c0 Mon Sep 17 00:00:00 2001 From: Matt Caswell <m...@openssl.org> Date: Wed, 23 Dec 2015 16:36:59 + Subject: [PATCH] Increase the max size limit for a CertificateRequest message Previous versions of OpenSSL had the max size limit fo

[openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake

On Wed Dec 23 03:54:19 2015, d...@inky.com wrote: > Openssl Version 1.1.0 (master as of 22-DEC-15) > Mac OS X 10.11.2 > > Connection to my SMTP server, which has a 4096-bit RSA key, fails > with: > > Traceback (most recent call last): > File "tls/_openssl.py", line 359, in handshake > error:

[openssl-dev] [openssl.org #1222] Please introduce versioned symbols

This feature is now available in master (1.1.0). Closing this ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OSTIF

Hi all I've had some emails recently from Derek at OSTIF who has been talking to me about their plans to do an audit (separate to the current CII one) of OpenSSL next year. OSTIF is not associated or affiliated with OpenSSL, but if you're interested you can learn more here: https://ostif.org/

Re: [openssl-dev] EAP-FAST and OpenSSL 1.1.x with new client TLS state machine

ou get on. Thanks Matt From 07315256ab0a97e1172304a098c262a845833206 Mon Sep 17 00:00:00 2001 From: Matt Caswell <m...@openssl.org> Date: Fri, 4 Dec 2015 10:18:01 + Subject: [PATCH] Fix EAP FAST in the new state machine The new state machine code missed an allowed transition when resumi

[openssl-dev] [openssl.org #4167] Missing "include/openssl" in the latest tarballs

The files in "include/openssl" get populated at configure time and are not necessary to successfully build and install openssl. Closing this ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] test_ordinals causes make update to fail after make clean

On 04/12/15 15:41, Adam Eijdenberg wrote: > On Thu, Dec 3, 2015 at 9:47 PM Viktor Dukhovni > > wrote: > > On Fri, Dec 04, 2015 at 03:05:28AM +, Adam Eijdenberg wrote: > > > When I'm preparing a patch I've gotten myself

Re: [openssl-dev] EAP-FAST and OpenSSL 1.1.x with new client TLS state machine

On 04/12/15 13:08, Jouni Malinen wrote: > On Fri, Dec 04, 2015 at 10:27:48AM +0000, Matt Caswell wrote: >> EAP-FAST is very strange. Normally you know whether you are resuming a >> session or not based on the session id returned from the server. However >> that's not the cas

Re: [openssl-dev] OpenSSL version 1.0.1q released (corrected download)

On 03/12/15 19:10, Quanah Gibson-Mount wrote: > make[5]: *** No rule to make target `../../include/openssl/idea.h', > needed by `e_idea.o'. Stop. Hmmm. I don't get that. Can you post your build steps? Matt ___ openssl-dev mailing list To

[openssl-dev] OpenSSL version 1.0.0t released (corrected download)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 1.0.0t released

[openssl-dev] OpenSSL version 1.0.1q released (corrected download)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 1.0.1q released

[openssl-dev] OpenSSL version 0.9.8zh released (corrected download)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 0.9.8zh released

Re: [openssl-dev] OpenSSL version 1.0.1q released (corrected download)

On 03/12/15 19:28, Quanah Gibson-Mount wrote: > --On Thursday, December 03, 2015 7:18 PM +0000 Matt Caswell > <m...@openssl.org> wrote: > >> >> >> On 03/12/15 19:10, Quanah Gibson-Mount wrote: >>> make[5]: *** No rule to make target `../../includ

[openssl-dev] Forthcoming OpenSSL releases

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2e, 1.0.1q, 1.0.0t and 0.9.8zh. These releases will be made available on 3rd December between

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

On 24/11/15 15:16, Jonathan Larmour wrote: > On 23/11/15 20:34, Matt Caswell wrote: >> On 23/11/15 17:49, Nico Williams wrote: >> >>> Still, if -lpthread avoidance were still desired, you'd have to find an >>> alternative to pthread_key_create(), pthread_getsp

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

On 23/11/15 17:49, Nico Williams wrote: > [Resend, with slight edits.] > > [Viktor asked me for my advice on this issue and bounced me the post > that I'm following up to. -Nico] > > The summary of what I've to say is that making libcrypto and libssl need > -lpthread is something that does

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

On 23/11/15 21:56, Paul Dale wrote: > Somewhat tangentially related to this is the how thread locking in > OpenSSL is slowing things up. Alessandro has submitted an interesting patch to provide a much better threading API. See: https://github.com/openssl/openssl/pull/451 I'm not sure what the

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 17/11/15 00:01, Viktor Dukhovni wrote: > On Mon, Nov 16, 2015 at 11:23:52PM +0000, Matt Caswell wrote: > >> Disabling algorithms isn't the right answer IMO. I do like the idea of a >> "liblegacycrypto". That way people that only have need of current &g

[openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Meant to send this to openssl-dev not openssl-users so resending... On 16/11/15 15:51, Emilia Käsper wrote: > Thanks all for your feedback! > > I asked for mainstream use-cases for algorithms whose removal could > cause widespread pain. Some individual users, undoubtedly, will be hit > by this,

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 15/11/15 21:16, Viktor Dukhovni wrote: > Is the pain worth the gain? I'm inclined to think that dropping > TLS ciphersuite code points, and assembly support, is a rather > sensible first step. I agree with this. I am wary of dropping too much too quickly. Matt

Re: [openssl-dev] procedure for adding new engine registration

On 13/11/15 11:16, Vemulapalli Jyothi wrote: > Hi Matt, > > Very useful information. > > I too agree with you that we need not have a new engine distribution. > > I see some options like dynamic engines and static engine support. > > If we have built a library with dynamic engine interface,

Re: [openssl-dev] procedure for adding new engine registration

On 12/11/15 18:21, Vemulapalli Jyothi wrote: > Hi all, > > > > We would like to add a new engine registration to openssl. > > > > Can you please explain a procedure? > > > > When we gone through the code, we could find an engines directory in > openssl , but those files are not

Re: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello

I really like that idea. I'll take a look at doing that in the new DTLSv1_listen code. Matt >From d973a67f17917869ab2238c041c447996ff94976 Mon Sep 17 00:00:00 2001 From: Matt Caswell <m...@openssl.org> Date: Tue, 3 Nov 2015 14:45:07 + Subject: [PATCH 1/3] Fix DTLS handshake fragme

Re: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello

On 04/11/15 15:30, David Benjamin via RT wrote: > On Wed, Nov 4, 2015 at 7:04 AM Matt Caswell via RT <r...@openssl.org> wrote: > >> >> >> On 03/11/15 17:43, David Benjamin via RT wrote: >> >>> I'm not sure that fix quite works though. If BIO_flush

Re: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello

Hi David, On 03/11/15 01:58, David Benjamin via RT wrote: > Hey folks, > > We found a small DTLS bug while writing some tests. I think it affects > 1.0.1 and 1.0.2 too, so I thought I'd send you a note. (Note sure about > master. I'm unfamiliar with the new state machine mechanism.) Just from

Re: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello

On 03/11/15 18:28, Viktor Dukhovni wrote: > On Tue, Nov 03, 2015 at 04:16:37PM +0000, Matt Caswell via RT wrote: > >> One other related point is that fragmenting ClientHellos is probably a >> bad idea. The whole ClientHello/HelloVerifyRequest mechanism is meant to >>

Re: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello

ntation in master we drop fragmented ClientHellos. Patch attached for these two issues (patch against 1.0.2). Matt >From 35b6c161b032bd2e04e54e80120f72b5d586c031 Mon Sep 17 00:00:00 2001 From: Matt Caswell <m...@openssl.org> Date: Tue, 3 Nov 2015 14:45:07 + Subject: [PATCH 1/2] F

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 02/11/15 10:16, Albe Laurenz via RT wrote: > Hubert Kario wrote: >> On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote: >>> My concern though is broader than this specific case. I have given two >>> *examples* of exploits that we may open ourselves up to i

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 25/10/15 11:12, Albe Laurenz via RT wrote: > Matt Caswell wrote: >> On 23/10/15 15:33, Albe Laurenz wrote: >>> Matt Caswell wrote: >>>> Imagine an attacker who is able to eavesdrop on messages between a >>>> legitimate client who presents

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 23/10/15 15:33, Albe Laurenz wrote: > Matt Caswell wrote: >> On 16/10/15 16:05, Hubert Kario via RT wrote: >>> we may actually be able to patch this up partially in 1.0.x >>> >>> the original problem description mentions server being unable to process >

[openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

There seems a strong consensus to change this so: https://github.com/openssl/openssl/commit/3fde6c9276c9cd6e56e8e06e756350a4fbdd7031 Closing this ticket. Matt ___ openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 16/10/15 16:05, Hubert Kario via RT wrote: > we may actually be able to patch this up partially in 1.0.x > > the original problem description mentions server being unable to process > application data before Certificate/Client Key Exchange, not in any > place what so ever > > (Albe,

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

On 15/10/15 20:53, Alexander Cherepanov via RT wrote: > On 2015-10-15 15:41, Matt Caswell via RT wrote: >> The purpose of the sanity check is not then for security, but to guard >> against programmer error. For a correctly functioning program this test >> should never fai

[openssl-dev] [openssl.org #4093] Problem loading engine from config

On Wed Oct 14 19:29:42 2015, beld...@gmail.com wrote: > Hello! > > The attached patch fixes it. Patch applied. Thanks! Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 16/10/15 11:57, Kurt Roeckx via RT wrote: > On Fri, Oct 16, 2015 at 08:53:06AM +0000, Matt Caswell via RT wrote: >> >> So now I really don't know what the "right" way forward is. Should we be >> applying the patch or not? > > Has anybody contact Orac

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 13/10/15 12:31, Hubert Kario via RT wrote: > On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote: >> On 12/10/15 17:19, Matt Caswell via RT wrote: >>> On 12/10/15 16:39, Matt Caswell via RT wrote: >>>> The value of "in_read_app_data&

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 16/10/15 09:53, Matt Caswell via RT wrote: > > > On 13/10/15 12:31, Hubert Kario via RT wrote: >> On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote: >>> On 12/10/15 17:19, Matt Caswell via RT wrote: >>>> On 12/10/15 16:39, Matt C

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 16/10/15 10:56, Hubert Kario via RT wrote: > On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote: >> So now I really don't know what the "right" way forward is. Should we >> be applying the patch or not? > > I can't think of a way to exploit it if

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

On 16/10/15 17:32, Viktor Dukhovni wrote: > On Fri, Oct 16, 2015 at 04:09:57PM +, Kaduk, Ben via RT wrote: > >> I hope I am not dragging this thread on too long, but with all due >> respect, we are not asking the compiler/optimizer to detect overflow -- >> we are asking the compiler to

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

On 15/10/15 04:11, Pascal Cuoq via RT wrote: > As of 2015-10-14, the function PACKET_buf_init in ssl/packet_locl.h > reads: > > static inline int PACKET_buf_init(PACKET *pkt, unsigned char *buf, > size_t len) { /* Sanity check for negative values. */ if (buf + len < > buf) return 0; > >

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

On 15/10/15 14:35, Salz, Rich via RT wrote: > >> PACKET_buf_init. This code can assume that |len| is from a trusted source. >> >> The purpose of the sanity check is not then for security, but to guard >> against >> programmer error. For a correctly functioning program this test should never >>

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 12/10/15 17:19, Matt Caswell via RT wrote: > > > On 12/10/15 16:39, Matt Caswell via RT wrote: >> >> >> On 12/10/15 16:03, Alessandro Ghedini via RT wrote: >>> On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT wrote: >>>> On Fri

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 13/10/15 11:55, Hubert Kario via RT wrote: >>> The value of "in_read_app_data" not being true when it is supposed >>> to >>> appears to be running into a slightly different bug. It's also >>> present in 1.0.2 but you have to switch off version negotiation. So >>> running s_server like this in

[openssl-dev] Engine removal

There are a number of engines within OpenSSL which, I believe, are largely dead and unused. I would like to remove them from version 1.1.0. Before I do so, I'd like to hear from anyone that can tell me about any active use of these engines. Specifically the ones I am currently looking at are:

[openssl-dev] [openssl.org #4073] Segfault in engine processing

On Tue Oct 06 20:08:12 2015, beld...@gmail.com wrote: > Hello! > > I get a segfault when executing the command > > openssl dgst -engine gost -md_gost94 -mac hmac -macop > key:123456901234567890123456789012 > I assume this is on master? I can't reproduce this. Are you using your new GOST engine or

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 12/10/15 16:03, Alessandro Ghedini via RT wrote: > On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT wrote: >> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote: >>> On 09/10/15 19:02, Hubert Kario via RT wrote: >>>> And for good measure

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 12/10/15 16:39, Matt Caswell via RT wrote: > > > On 12/10/15 16:03, Alessandro Ghedini via RT wrote: >> On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT wrote: >>> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote: >>>> On 09/10

[openssl-dev] [openssl.org #4072] dgst command incompatibility between 1.0.2 and 1.1.0

On Tue Oct 06 19:53:30 2015, beld...@gmail.com wrote: > Hello! > > I've found a difference in behaviour between openssl cmdline 1.0.2 and > 1.1.0 versions. > The -macopt cmdline option is not recognized, openssl dgst expects -macop > instead. > Fixed. Thanks. Matt

[openssl-dev] [openssl.org #4089] NULL ciphersuites do not work in master

Closing ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 12/10/15 19:11, Kurt Roeckx via RT wrote: > On Mon, Oct 12, 2015 at 04:19:43PM +0000, Matt Caswell via RT wrote: >> >> Having done some more digging it seems the problem only occurs if you >> get the initial handshake, following by a second reneg handshake *and* >&g

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 12/10/15 20:40, Kurt Roeckx via RT wrote: > On Mon, Oct 12, 2015 at 06:54:46PM +0000, Matt Caswell via RT wrote: >> >> >> On 12/10/15 19:11, Kurt Roeckx via RT wrote: >>> On Mon, Oct 12, 2015 at 04:19:43PM +, Matt Caswell via RT wrote: >>>> &

[openssl-dev] [openssl.org #4059] Error processing set_serial parameter of the req command

Fixed, thanks for the report. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4085] Bug in genpkey in master

Fixed. Thanks Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4086] s_server bug in master

Fixed. Thanks Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4084] correction to the message i sent earlier...

Closing ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 09/10/15 19:02, Hubert Kario via RT wrote: > And for good measure, I also created a test script that > combines fragmentation with interleaving. Did you try my patch with it? And if so what happened? Thanks Matt ___ openssl-dev mailing list To

Re: [openssl-dev] Adding async support

On 08/10/15 11:26, Dmitry Belyavsky wrote: > Dear Matt, > > I have some questions. > > On Thu, Oct 8, 2015 at 12:32 AM, Matt Caswell <m...@openssl.org > <mailto:m...@openssl.org>> wrote: > > > > On 07/10/15 21:44, Dmitry Belyavsky wrote: >

Re: [openssl-dev] Adding async support

On 08/10/15 12:18, Dmitry Belyavsky wrote: > > I see. So am I correct supposing that pseudo code for > offload_cipher_to_hardware looks like this: > > static int async_wrapper(void * args) > { > ... > } > > static ASYNC_JOB *offload (void *args) > { > ASYNC_JOB *pjob = NULL; > int

Re: [openssl-dev] Elliptical Cipher Suites

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/10/15 12:27, Aaron Jones wrote: > On 07/10/15 13:54, Thirumal, Karthikeyan wrote: >> Vik Am using 0.9.8a version. Am trying to fix few weak ciphers >> in my SSL connection and also to make Elliptical cipher suites >> enable. I see that

[openssl-dev] [openssl.org #4076] PROBLEM： there exists a wrong return value of function int_rsa_verify()

On Thu Oct 08 08:55:45 2015, rucsoft...@163.com wrote: > Bug Description: > Function int_rsa_verify() defined in file crypto/rsa/rsa_sign.c would > return 1 if a signature is valid, and 0 otherwise. The variable 'ret' > keeps the return value, and it may be assigned to 1 if the condition > in line

[openssl-dev] [openssl.org #3982] [PATCH] Fix unhandled error condition in sslv2 client hello parsing

Patch was applied. Closing. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

On 08/10/15 18:56, Dmitry Belyavsky wrote: > The second problem is entirely engine dependant. It will be a different > solution for different hardware. These patches do not provide a solution > to that problem. > > > So I do not understand what you mean by "offload" :-( > > I

Re: [openssl-dev] Adding async support

On 07/10/15 21:44, Dmitry Belyavsky wrote: > Dear Matt, > > On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell <m...@openssl.org > <mailto:m...@openssl.org>> wrote: > > > > On 07/10/15 14:29, Viktor Dukhovni wrote: > > > > Should

[openssl-dev] Adding async support

Hi all A number of people have expressed interest in the async work that I have been doing in collaboration with Intel. This has now progressed to the point where it is going through team review. I thought some of you might like to get early sight of this so I have pushed it to my personal github

Re: [openssl-dev] Adding async support

On 07/10/15 14:29, Viktor Dukhovni wrote: > On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote: > >> I have also added async support to s_server and s_client through the new >> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an >&

Re: [openssl-dev] Adding async support

On 07/10/15 16:57, Devchandra L Meetei wrote: > > > On Wed, Oct 7, 2015 at 3:16 PM, Matt Caswell <m...@openssl.org > <mailto:m...@openssl.org>> > wrote:<https://github.com/openssl/openssl/pull/433> > > > > libssl has been made async

[openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length)

Fixed in master, 1.0.2 and 1.0.1. Closing ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function

On 01/10/15 15:18, Tiantian Liu via RT wrote: > Hi, > > Good morning! Thanks for your response. > > I configured my OpenSSL with '-d' option to enable the debugging information. > Where I don't know how to use it during my application running. Which version of OpenSSL did you download? My

Re: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build

On 30/09/15 10:22, Alessandro Ghedini via RT wrote: > On Wed, Sep 30, 2015 at 02:01:54am +, Rich Salz via RT wrote: >> We fixed this in a slightly different way. We made BIO_new_file and >> BIO_s_file >> return an alternate implementation that returns run-time failures. Almost all >> of the

Re: [openssl-dev] [openssl.org #4066] bug: openssl clean up crash

On 30/09/15 16:06, Haiyang Yin via RT wrote: > Hello, I am using memory-based bio to handle dtls sessions. Crash > happened after close notify received and SSL was cleaned up ? OpenSSL > version is 1.0.2d. If more detailed information required, pls. let me > known. Your gdb output is impossible

Re: [openssl-dev] [openssl.org #4066] bug: openssl clean up crash

On 30/09/15 16:06, Haiyang Yin via RT wrote: > Hello, I am using memory-based bio to handle dtls sessions. Crash > happened after close notify received and SSL was cleaned up ? OpenSSL > version is 1.0.2d. If more detailed information required, pls. let me > known. Your gdb output is impossible

Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function

I agree with everything Viktor said. In particular that you should continue to use SSLv23_method. Some additional comments below: On 28/09/15 16:31, Tiantian Liu via RT wrote: > sslerror = SSL_get_error(ssl, res); > if (sslerror == SSL_ERROR_WANT_READ)

Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function

On 29/09/15 14:56, Tiantian Liu via RT wrote: > Hi Matt & Vi > > I tried the SSLv23_method(), and precluded/excluded all SSLv2, SSLv3, TLSv1. > I only enabled the TLSv1.2 by SSL_CTX_set_option(). > You can see my previous code: > > /*setup up by SSLv23_method*/ > meth = SSLv23_method(); >

Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function

On 29/09/15 15:45, Tiantian Liu via RT wrote: > Hi Matt, > Thanks for prompt response! > While I confirm with you that my application crashed INSIDE the SSL_connect() > function. Your previous email indicated it was not crashing with SSLv23_method(): "While the above code didn't work. I

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 28/09/15 12:35, Albe Laurenz via RT wrote: > Matt Caswell wrote: >> I've been looking into this issue. The reason this fails is because at >> some point in the past there has been an explicit design decision to >> disallow it. > > Thank you for your work! &

[openssl-dev] [openssl.org #2481] Full-duplex SSL/TLS renegotiation failure (reproducible 100% of the time)

This as a duplicate of 3712. Closing this ticket in favour of that one. See the patch associated with that ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL

On 26/09/15 17:18, Devchandra L Meetei via RT wrote: > Sure, Sorry for the noise. > and Thanks Steve. > > is the API introduced recently openssl 1.0.1f does not seem to have it? > > if so, any plan to backport it? This was introduced in 1.0.2. There are no plans to backport it. Regards

[openssl-dev] [openssl.org #4064] Re: Client Hello longer than 2^14 bytes are rejected

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/09/15 14:19, Hubert Kario wrote: > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite > branches reject Client Hello messages bigger than 2^14+4 bytes. Right. The reason for that is that there is an explicit (deliberate) check

[openssl-dev] [openssl.org #4064] Re: Client Hello longer than 2^14 bytes are rejected

Gahhhdidn't mean to open this as a new ticket. Closing. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected

On 25/09/15 17:05, Alessandro Ghedini via RT wrote: > On Fri, Sep 25, 2015 at 03:02:27pm +, Hubert Kario via RT wrote: >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote: >>> As a matter of test I changed the ssl_get_message() in >>> ssl3_get_client_hello() to use

Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected

On 25/09/15 17:05, Alessandro Ghedini via RT wrote: > On Fri, Sep 25, 2015 at 03:02:27pm +, Hubert Kario via RT wrote: >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote: >>> As a matter of test I changed the ssl_get_message() in >>> ssl3_get_client_hello() to use

Re: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected

On 25/09/15 20:19, Kurt Roeckx wrote: > On Fri, Sep 25, 2015 at 04:23:27PM +, Hubert Kario via RT wrote: >> >> Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends >> up as an extension, possibly multiple ones), and that quantum computing >> resistant algorithms usually

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 25/09/15 11:25, Hubert Kario via RT wrote: > > A Finished message is always sent immediately after a change > cipher spec message to verify that the key exchange and > authentication processes were successful. This is perhaps the key statement. It could do with being more

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On 25/09/15 11:25, Hubert Kario via RT wrote: > On Friday 25 September 2015 10:47:42 Matt Caswell wrote: >> However, I have some concerns with the wording of the RFC. It seems to >> place no limits whatsoever on when it is valid to receive app data in >> the handshake. By t

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

ed is processed that we verify the handshake data MAC - and yet we could already have acted upon app data received. I assume the intent was to allow the interleaved app data only up until the point that the CCS is received. I have attached a patch for 1.0.2 that implements that logic. Matt From

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

ed is processed that we verify the handshake data MAC - and yet we could already have acted upon app data received. I assume the intent was to allow the interleaved app data only up until the point that the CCS is received. I have attached a patch for 1.0.2 that implements that logic. Matt >F

[openssl-dev] [openssl.org #4062] [PATCH] Fix build failure

Patch applied. Thanks. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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