On 02/02/18 11:18, Atul Gupta wrote:
> I want to add GCM support to afalg engine and have the patch tested with
> apache and s_server/s_client. Can I submit the patch for review? Any
> suggestion?
A patch would be most welcome. All patches should be submitted through
github. Please make sure you
On 19/01/18 16:32, Michael Richardson wrote:
> Matt Caswell wrote:
> > Please raise a separate PR for this work. It *must* be portable though
> > and work across all our platforms (e.g. including VisualC etc). My
> > suggestion is that your BI
On 17/01/18 16:34, Michael Richardson wrote:
>
> > It seems like a fairly simple solution could solve this. Currently we
> > have BIO_dgram_get_peer() which returns the peer's address for the last
> > message read from a BIO. You could imagine a new call being introduced
> > to g
On 17/01/18 16:34, Michael Richardson wrote:
>
> Matt Caswell wrote:
> >> Matt Caswell wrote: >> a) when the existing FD is
> >> connect(2) any future traffic to the bound >> port will get rejected
> >> with no port. So the a
On 16/01/18 19:44, Michael Richardson wrote:
>
> Matt Caswell wrote:
> >> a) when the existing FD is connect(2) any future traffic to the bound
> >> port will get rejected with no port. So the application really has to
> >> open a new socket first.
On 16/01/18 15:32, Michael Richardson wrote:
>
> a) when the existing FD is connect(2) any future traffic to the bound port
>will get rejected with no port. So the application really has to open a
>new socket first.
>The application can do this two ways: it can open a new socket on
Today I have had great pleasure in attending the Real World Crypto 2018
conference in Zürich in order to receive the Levchin prize on behalf of
the OpenSSL team. More details are available in my blog post here:
https://www.openssl.org/blog/blog/2018/01/10/levchin/
Matt
--
openssl-dev mailing lis
FYI I have recently pushed to master support for TLSv1.3 draft 22.
Matt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On 08/12/17 05:33, The Doctor wrote:
> On Thu, Dec 07, 2017 at 03:35:05PM +0100, Jan Ehrhardt wrote:
>> 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 htt
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 routines:ssl3_accept:unkn
Forthcoming OpenSSL release
===
The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 1.0.2n. There will be no OpenSSL 1.1.0 release at
this time.
This release will be made available on 7th December 2017 between
approximately 1300-1700
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 ma
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
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 w
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 indi
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 n
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: t...@ietf.o
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
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
> "elli
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
>
On 02/10/17 15:00, Blumenthal, Uri - 0553 - MITLL wrote:
> Moving to openssl-dev, because I think OpenSSL-1.0.2 needs a fix.
>
>
>
> To be more specific, the following get methods are missing in 1.0.2:
>
>
>
> - EVP_PKEY_meth_get_sign(EVP_PKEY_METHOD *, …)
>
> - EVP_PKEY_meth_get_decryp
how the client behaves (which you
cannot control) and how the network behaves. If this was working for you
before then it sounds like you've been lucky so far.
Matt
>
> Thanks.
>
>
>>From: Matt Caswell mailto:m...@openssl.org>>
>>To: openssl-dev@openssl.org &
On 27/09/17 15:32, Byrne, Andrew wrote:
> I’m working on testing some lattice based algorithms in openSSL for the
> establishment of a TLS channel. I’ve investigated the potential for
> developing an engine to support this as it would mean I don’t need to
> touch the core openSSL code. However, I
On 27/09/17 15:44, Ma chunhui wrote:
> Hi,
>
> I met one problem when using OpenSSL1.1.0f with protocol TLSv1.
> In brief, when using TLSv1, after server side received encrypted data,
> and after function tls1_enc finished, the decrypted data is not put in
> result buffer, after another tls1_e
sion negotiation and is always
set to TLSv1.2.
Matt
--
Matt Caswell
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
HELLO;
> > return WRITE_TRAN_CONTINUE;
> >
> >
> > The reason there is not currently a case for TLS_ST_BEFORE is that whether
> > or not we're going to be using TLS 1.3 is supposed to be determined on the
> > server as part of version negotiation, so when we're sending a ClientHello,
> > our version is in an indeterminate status -- the general-purpose TLS method
> > must be used at that part of the handshake.
> >
> > The client hello gets sent out, but I only saw a TLS 1.2 version being
> > sent.
> > Is this a bug?
> >
> >
> > The legacy_version field in a TLS 1.3 ClientHello will be 0x0303, matching
> > the historical value for TLS 1.2. The actual list of versions are conveyed
> > in a "supported_versions" extension, which is what you need to be looking
> > at.
> >
> > -Ben
> >
--
Matt Caswell
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
http://highlandsun.com/hyc/
>Chief Architect, OpenLDAP http://www.openldap.org/project/
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
--
Matt Caswell
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Issue 4283 (https://github.com/openssl/openssl/issues/4283) has caused
me to take a close look at QUIC. This seems to have been getting a *lot*
of attention just recently. See the IDs below for details:
https://tools.ietf.org/html/draft-ietf-quic-transport-05
https://tools.ietf.org/html/draft-ietf
On 04/09/17 08:59, Matt Caswell wrote:
>
>
> On 03/09/17 22:18, Blumenthal, Uri - 0553 - MITLL wrote:
>> MacOS 10.12.6, Xcode-8.3.3. Current Github master:
>>
>> Test Summary Report
>> ---
>> ../test/recipes/70-test_clienthello.t
On 03/09/17 22:18, Blumenthal, Uri - 0553 - MITLL wrote:
> MacOS 10.12.6, Xcode-8.3.3. Current Github master:
>
> Test Summary Report
> ---
> ../test/recipes/70-test_clienthello.t(Wstat: 256 Tests: 1
> Failed: 1)
> Failed test: 1
> Non-zero exit status: 1
> Files
On 01/09/17 18:05, Hubert Kario wrote:
> When openssl sends a second Client Hello message, it modifies it quite
> extensively, not only client_random is changed but also advertised cipher
> suites.
>
> see https://github.com/openssl/openssl/issues/4292
>
> That makes it non-compliant with the
On 01/09/17 23:42, Blumenthal, Uri - 0553 - MITLL wrote:
>
>
> Begin forwarded
>
>> *Subject:* *openssl 1-1-0-stable fails*
>>
>> OpenSSL_1_1_0-stable current Github
>>
>> Test Summary Report
>> ---
>> ../test/recipes/80-test_cms.t(Wstat: 256 Tests: 4 Failed: 1)
>>
On 31/08/17 14:52, Hubert Kario wrote:
> On Thursday, 31 August 2017 11:13:13 CEST Richard Levitte wrote:
>> In message
>> on
>> Thu, 31 Aug 2017 11:25:16 +0530, Jayalakshmi bhat
>> said:
>>
>> bhat.jayalakshmi> Hi All,
>> bhat.jayalakshmi>
>> bhat.jayalakshmi> I am trying to build openssl. As
On 29/08/17 15:02, Salz, Rich via openssl-dev wrote:
>
> dev asap. If there are problems with it we can always revert it before
> it makes it into a release.
>
> Someone on the OMC called that “flip-flopping” and seemed to be against this
> kind of thing.
>
> If we are going to have
On 29/08/17 10:45, Dr. Matthias St. Pierre wrote
> Currently, the OpenSSL core members seem to be reluctant to make the
> API public, at least at this early stage. I understand Rich Salz's
> viewpoint that this requires a thorough discussion, because a public
> interface can't be easily changed an
On 17/08/17 13:22, Salz, Rich via openssl-dev wrote:
> I understand the concern. The issue I am wrestling with is strict
> compatibility with the existing code. Does anyone really *want* the
> RNG’s to not reseed on fork? It’s hard to imagine, but maybe
> somewhere someone is. And then it’s n
r setup. Will update if I face any
> more issues.
Yes - your kernel headers must be at least at 4.1.0 or better for afalg
to work.
Matt
>
> Thanks
> Jitendra
>
>
>
>
> ----
> On Wed, 8/16/17, Jitendra Lulla wrote:
>
> Subject: Re: afalg with OpenSSL
Comments inserted.
On 14/08/17 08:20, Jitendra Lulla wrote:
> Hi,
>
> I am trying to use afalg on Linux 4.9.37 with OpenSSL 1.1.0f.
>
> I am facing 2 issues:
>
> ONE: when I issue the speed command, I see the following:
>
> [root@localhost apps]# ./openssl speed -evp aes-128-cbc -engine afalg
On 02/08/17 03:19, Matthew Stickney wrote:
> Ok, progress (sort of)! It turns out I was indeed using the wrong
> version of perl -- I was using the perl that was installed as part of
> the msys2 base-devel group, not the mingw-w64--perl package,
> which is a whole separate thing.
Errr no. You w
On 05/07/17 13:16, slon v sobstvennom palto wrote:
> Hi,
> openssl command line utility "s_server" command "-legacy_renegotiation"
> option was present in version 1.0.1u but removed in version 1.0.2a. In
> the source code of 1.0.2a the option is still present in the on screen
> help but not parse
On 01/07/17 01:35, Hubert Le Van Gong wrote:
> Greetings,
>
> We're doing some testings around TLS1.3 and in particular we're looking
> at session resumption.
>
> We've captured some of the NewSessionTicket msgs sent by the server
> (Nginx over openssl 1.1.1-dev) and have a hard time reconcilin
as an option.
I don't think we will necessary be able to do the latter on all
platforms that we support.
As for which of the two is the default: where it is available - the
latter. Where it isn't the former.
Matt
>
> Regards,
>
> Matthias St. Pierre
>
>
> Vote 1:
On 27/06/17 19:50, Benjamin Kaduk wrote:
> On 06/27/2017 02:28 AM, Matt Caswell wrote:
>>
>> On 26/06/17 21:18, Kurt Roeckx wrote:
>>
>>> I think it should by default be provided by the OS, and I don't
>>> think any OS is documenting how much randomn
On 26/06/17 21:18, Kurt Roeckx wrote:
>> “Recommendation for Random Number Generation Using Deterministic Random
>> Bit Generators”
>> http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf
>>
>> That design may look complicated, but if you think you can
>> leave out some of the bl
On 26/06/17 19:57, Salz, Rich via openssl-dev wrote:
> I was asked off-list why we're doing this. A reasonable question. :)
>
> There are many complains about the OpenSSL RNG. For started:
> https://github.com/openssl/openssl/issues/2168
> https://github.com/openssl/openssl/issues/
On 16/06/17 10:43, Matt Caswell wrote:
>
>
> On 16/06/17 10:25, Matt Caswell wrote:> Possibly a bad clang-3.9
> update?? Any ideas?
> After this command in the logs:
>
> $ sudo -E apt-get -yq --no-install-suggests --no-install-recommends
> --force-yes install cl
On 16/06/17 10:25, Matt Caswell wrote:> Possibly a bad clang-3.9
update?? Any ideas?
After this command in the logs:
$ sudo -E apt-get -yq --no-install-suggests --no-install-recommends
--force-yes install clang-3.9
Failing builds look like this:
After this operation, 262 MB of additional d
I'm seeing some weird Travis failures:
LD_LIBRARY_PATH=.: clang-3.9 -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG
-DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC
-DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -DOPENSSLDIR="/usr/local/ssl"
-DENGINESDIR="/usr/local/lib/engines-1.1" -Wall -O3 -pthread
Again with this one, please submit as a github patch.
Matt
On 04/06/17 01:35, Juan Manuel Guerrero wrote:
> I do not know if someone really cares about this, but I have compiled
> openssl-1.0.2-stable-SNAP-20170602 using the DJGPP port of gcc-7.1.0.
> The code has been configured using --strict-w
Please submit these patches as a github pull request.
Matt
On 04/06/17 01:15, Juan Manuel Guerrero wrote:
> I do not know if patches for DJGPP/FreeDOS are still welcome at all for the
> OpenSSL 1.0.2 branch but if yes, then I would like to propose some fixes
> and
> improvements. No one of the
On 02/06/17 15:20, Emeric Brun wrote:
>
> I've just read the code and I see it is not possible.
>
> I'm disappointed because i think that a lot of applications which are using
> openssl in asynchronous mode
> also uses SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER and have
> ephemeral/reused/circular
On 02/06/17 11:00, Emeric Brun wrote:
> Hi,
>
> I'm working on an ASYNC engine designed to offload crypto on multiple thread
> for monoproc applications.
>
> No issue on asymetric crypto part but i'm facing a problem concerning ciphers:
>
> When an SSL_read operation perform a do_cipher decry
Forthcoming OpenSSL releases
The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.0.2l and 1.1.0f.
These releases will be made available on 25th May 2017 between
approximately 1200-1600 UTC.
Note: These are bug-fix only relea
On 18/05/17 06:32, Jayalakshmi bhat wrote:
> Please can any one let me know the release date or time line for OpenSSL
> 1.1.1?
We have not set a date as yet. At the very least we will not be able to
release until the IETF takes TLSv1.3 out of draft status - which is not
in our control.
Matt
--
On 09/05/17 18:12, Nick Reilly wrote:
>
>
> On 2017-05-09 10:08 AM, Matt Caswell wrote:
>>
>> I'm not sure why this makes a difference. The return value of dlclose()
>> tells you whether there has been an error or not. Not whether the
>> library has actual
On 09/05/17 15:03, Salz, Rich via openssl-dev wrote:
>> doesn't test for whether this is set. I think the shlibloadtest should only
>> test
>> the dlclose() return value on if OPENSSL_USE_NODELETE is set.
>
> Please see https://github.com/openssl/openssl/pull/3399
>
>> 2) crypto/init.c at lin
On 09/05/17 14:43, Nick Reilly wrote:
> Hi,
> I just ported OpenSSL 1.1.0e to QNX and ran in to an issue on
> shlibloadtest and it trying to unload the shared libraries in
> conjunction with the code in crypto/init.c
>
> 1) crypto/init.c at line 106 deliberately leaks a reference to prevent
> th
On 09/05/17 01:22, Zubin Mevawalla wrote:
> I was curious if these were real null pointer dereference issues?
>
> CodeAi, an automated repair tool being developed at Qbit logic,
> suggested a couple of if-guards as fixes.
>
> The first was in crypto/async/async_wait.c on line 157. `prev` is
> a
Hi all
OpenSSL 1.1.1, when it is released, will support TLSv1.3 and it will be
binary and source compatible with OpenSSL 1.1.0. If your application
already supports 1.1.0 then, in theory, all you need to do to support
TLSv1.3 is to drop in the new OpenSSL version. However there are various
issues
Just to let you all know that we managed to close 58 old tickets as a
result of this event. Fantastic!
Thanks
Matt
On 27/04/17 08:43, Matt Caswell wrote:
>
>
> Hi all
>
> Our next "Code Health Tuesday" event will be on Tuesday 2nd May.
>
> This time we wou
FYI, I have just made the necessary updates to bring the OpenSSL master
branch up to TLSv1.3 draft-20 compatibility. I don't know of any other
draft-20 implementations yet so treat with caution and please test!
As with all new drafts, draft-20 is not compatible with draft-19. If you
were using the
Just a reminder about our code health Tuesday event this week. Please
see the details below.
Matt
Forwarded Message
Subject: Code Health Tuesday - old issues
Date: Thu, 27 Apr 2017 08:43:18 +0100
From: Matt Caswell
To: openssl-dev@openssl.org
Hi all
Our next "Code H
Hi all
Our next "Code Health Tuesday" event will be on Tuesday 2nd May.
This time we would like to focus on closing off Github issues (with a
particular focus on old ones - including all those we brought over from RT).
Thanks!
Matt
FAQ:
Q: How do I participate?
A: Review the old issues in G
On 20/04/17 21:24, David Woodhouse wrote:
> On Wed, 2017-04-19 at 12:14 +, Salz, Rich via openssl-dev wrote:
>>> Out of curiosity, what's the ETA for TLS 1.3?
>>> [1] mentions April 5 as the release date (which was two weeks ago).
>>>
>>> [1]: https://blogs.akamai.com/2017/01/tls-13-ftw.htm
On 14/04/17 21:11, Lysoněk Milan wrote:
>
> On 06/04/17 00:25 Matt Caswell wrote:
>> Can you reproduce it using the fuzz corpora added in commit 44f206aa9df,
>> or by running the large message test introduced in 84d5549e69?
>>
>> Matt
>>
>
> Commit 44f
On 13/04/17 01:02, Paul Dale wrote:
> Code Health Tuesday is over once again.
>
>
>
> In total 27 PRs were raised for the event with three of these as yet
> unmerged. In total about thirty tests were updated which represents
> roughly half of the outstanding test cases.
>
> All in all, a so
On 12/04/17 00:20, Michael Reilly wrote:
> Unfortunately the check breaks code which doesn't know nor need to know the
> keysize. The engine takes care of allocating buffers required.
So how does EVP_SignFinal() work with your engine? The "sig" parameter
is supposed to be allocated by the calle
On 05/04/17 19:24, Lysoněk Milan wrote:
> Hello,
> I'd like to make test for CVE-2016-6309
> https://www.openssl.org/news/secadv/20160926.txt in tlsfuzzer. I tried
> combining and sending different lengths (from small lengths to large) of
> application data and padding, but I could not trigger th
On 04/04/17 15:34, Thiago Arrais wrote:
> Hmmm... The Getting Started page talks about writing test cases.
>
> It seems like a good start. Is there any area that needs special attention?
Actually I have a suggestion for a fairly small self-contained piece of
work suitable for a starting project
gards
> Darshan
>
> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt
> Caswell
> Sent: Monday, April 03, 2017 2:53 PM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] Renegotiation ticket 3712
>
>
>
&g
On 02/04/17 04:50, Mody, Darshan (Darshan) wrote:
> Hi Matt,
>
> Is re-negotiation fixed with openssl 1.1.0
> ?
> https://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guesthttps://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guest
>
> From the ticket it seems its ma
On 31/03/17 18:54, Raja ashok wrote:
> Hi All,
>
>
>
> In ssl3_write_bytes, if (len < tot) we are returning failure with
> SSL_R_BAD_LENGTH error. In this place I hope we should set “tot” back to
> “s->s3->wnum”. Otherwise when application calls back SSL_write with
> correct buffer, it causes serio
On 23/03/17 17:57, Matt Caswell wrote:
> Our next "Code Health Tuesday" event will be on Tuesday 28th March.
>
> We've seen some great contributions during our last two events with many
> significant improvements merged as a result. We'd like to continue
Just a reminder about this event taking place tomorrow!
Matt
On 23/03/17 17:57, Matt Caswell wrote:
>
> Hi all
>
> Our next "Code Health Tuesday" event will be on Tuesday 28th March.
>
> We've seen some great contributions during our last two events with many
; client certificate and chain.
> darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY
> passed to openssl from app is cleaned up by the app.
> darshanmody> 3. Connect client with certificates that server does not trust.
> darshanmody> 4. The conne
Hi all
Our next "Code Health Tuesday" event will be on Tuesday 28th March.
We've seen some great contributions during our last two events with many
significant improvements merged as a result. We'd like to continue that
trend with our next theme - documentation.
Just find some missing documenta
it (assuming the problem is in
OpenSSl itself). We would need some simple reproducer code that
demonstrates the problem occurring.
Matt
>
> Thanks Darshan
>
> -Original Message- From: openssl-dev
> [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell
> Se
On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
> Matt,
>
> Even after accounting for the EC_KEY we still observe some leak. The
> leak started after we started using supporting EC with callback
> SSL_set_tmp_ecdh_callback().
>
> The core dump shows the string data of the far-end certificate
> else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
>
> Thanks
> Darshan
>
> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.
https://github.com/openssl/openssl/pull/3009
On 21/03/17 15:24, Raja ashok wrote:
> Hi All,
>
>
>
> Looks like there is a typo mistake in dtls1_read_bytes, because of this
> alert is not send for bad CCS.
>
>
>
> In dtls1_read_bytes, incase of bad change cipher spec we are setting
> alert
On 21/03/17 09:46, Matt Caswell wrote:
>
> There is a potential leak in this case:
>
> if (s->s3->tmp.ecdh != NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>ERR_R_INTERNAL_ERROR);
> goto er
On 15/03/17 05:44, Mody, Darshan (Darshan) wrote:
> Hi,
>
> We have observed memory leak when we register for ECDH
> callback(SSL_set_tmp_ecdh_callback). While performing negative testing
> with load we find that the applications starts leaking memory.
>
> Further checking the Openssl impleme
On 16/03/17 16:29, Salz, Rich via openssl-dev wrote:
> Our most recent code health Tuesday was a success. Nearly a dozen people
> worked to achieved the following:
>
> - Our external contributors wrote completely new unit test for previously
> untested API's (stack, LHASH, and RSA_padding_add
All,
I have just pushed to master the updates necessary for TLSv1.3 draft-19
support. This covers most of the required changes with the exception of
CertificateRequests which are waiting on PR 2918 to be merged.
Unfortunately there aren't other draft-19 implementations out there yet
(that I know
On 23/02/17 12:54, The Doctor wrote:
> Please fix!
>
This fix is already on the way:
https://github.com/openssl/openssl/pull/2713
Matt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I am pleased to be able to announce the publication of our new Project
Bylaws. I have written a short blog post about what we are hoping to
achieve and some of the thinking that went into these here:
https://www.openssl.org/blog/blog/2017/02/13/bylaws/
The bylaws themselves are available here:
h
On 13/02/17 16:55, Salz, Rich wrote:
>> extension by default that wasn't there before - and that we've already
>> decided to add new extensions in 1.1.1 due to the forthcoming
>> TLSv1.3 support.
>
> You mean adding new extensions in the wire protocol? Or are did we modify
> any API/ABI behavi
I'd like to canvas opinion on this PR:
https://github.com/openssl/openssl/pull/2614
At the moment s_client does not add the SNI extension by default. You
have to explicitly ask for it using the "-servername" option. This can
lead to some problems where servers reject connection attempts from
s_cli
On 05/02/17 06:54, yuchi tian wrote:
> Dear OpenSSL developers,
>
> We are software engineering researchers at University of Virginia. As
> part of a research project, we have built a tool for automatically
> finding and fixing error handling bugs and are testing it on
> various cryptographic li
and a ref-counter assertion failure from:
> https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L977-L978
> The only other thing could be that the code (which I inherited) is calling a
> SSL_shutdown() beforehand which does something I have missed...?
>
> Best wishes,
> M
On 30/01/17 10:13, Mischa Salle wrote:
> Hi all,
>
> I noticed a doublefree when calling SSL_set_bio(ssl, bio, bio) followed
> by either SSL_set_bio(ssl, NULL, NULL) or SSL_set_io_SSL_free(ssl).
> Valgrind shows the double free, and I see the assert in
> https://github.com/openssl/openssl/blob/m
On 27/01/17 16:54, Benjamin Kaduk via openssl-dev wrote:
> [moving from github to -dev]
>
> On 01/27/2017 07:36 AM, mattcaswell wrote:
>>
>> 1.0.2 is the software version.
>> The numbers on the end of lbssl.so.1.0.0 refer to the ABI version -
>> which is different. Software version 1.0.2 is a dr
In case anyone on these lists missed this on the openssl-announce list:
Forwarded Message
Subject: [openssl-announce] Forthcoming OpenSSL releases
Date: Mon, 23 Jan 2017 21:08:50 + (GMT)
From: OpenSSL
Reply-To: openssl-us...@openssl.org
To: openssl-annou...@openssl.org
For
On 11/01/17 08:58, Michel wrote:
> Can we assume it is temporary due to “the process of transitioning from
> NPN to ALPN” mentioned in ssl_locl.h ?
Its a bug:
https://github.com/openssl/openssl/pull/2212
Matt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listin
On 09/01/17 17:46, Leonard den Ottolander wrote:
> Hello,
>
> https://github.com/openssl/openssl/commit/10621efd3296a92f489f6ab26a88e88d9790930e#diff-4b59eddb1c722b1dc3d17b5f64149e12
>
> is a white space nightmare. The replacement of "#define"s by "# define"s
> etc. is just silly and makes it u
On 03/01/17 12:44, Salz, Rich wrote:
>>> I'm still waiting on a reply ... I assume holidays are contributing to the
>>> delay.
>>> However, openssl_tpm_engine is a DCO project, so that concern is
>>> irrelevant here.
>>
>> Sorry, I'll push to get the bylaws made public, is that what you need?
>
On 17/12/16 01:59, Peter Djalaliev (CS) wrote:
> Hello,
>
>
>
> Will commit
>
>
>
> Don't allow too many consecutive warning alerts
>
>
>
> author Matt Caswell
>
> Wed, 21 Sep 2016 08:07:31 -0500 (1
//github.com/openssl/openssl/pull/2075
> <https://github.com/openssl/openssl/pull/2075>
>
> On Mon, Dec 12, 2016 at 3:17 PM, Matt Caswell <mailto:m...@openssl.org>> wrote:
>
> Could you open that as an issue in GitHub? Or even bette
Could you open that as an issue in GitHub? Or even better a PR to fix it ;-)
Thanks
Matt
On 12/12/16 12:16, Dmitry Belyavsky wrote:
> Hello!
>
> I found a typo in the BUF_reverse manual
> (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html)
>
> The manual says:
>
> BUF_reverse
On 28/11/16 09:51, Matt Caswell wrote:
>
>
> On 27/11/16 13:27, The Doctor wrote:
>> Can you get his fixed?
>>
>> ../util/shlib_wrap.sh ./heartbeat_test
>> test_dtls1_not_bleeding failed: expected return value -1, received 0
>
1 - 100 of 981 matches
Mail list logo
