Re: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW...

[Support]

Hi Christian,

A similar patch was already applied to the master branch - see
https://rt.openssl.org/Ticket/Display.html?id=3346 and commit
028bac0670c167f154438742eb4d0fbed73df209

You could cherry-pick the commit and apply it to the 1.0.2 branch.


Cheers,


Peter Mosmans

On 12-10-2015 12:03, christian fafard via RT wrote:
> I'm sorry for that mess with the previous message.There was no CRLF because 
> it was copy-pasted from emacs.
> What i tried to say basically is that the "negate regex match" (!/^0$$/) 
> constructused in the line 244 of 'test/Makefile' does not work with some 
> versions of perl.Like for exemple, perl v5.8.8 in the MinGW/msys distibution.
> That's the reason why 'make test' fail on that platform.
> My proposal is to invert the if/else actions to get rid of the negation in 
> the expression (/^0$$/).
> So the line:
> @ () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) 
> {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR 
> "\n$$i tests passed\n"'
> would became:
> @ () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) 
> {print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR 
> "\n$$i tests passed\n"'
> I attached a patch.
> ThanksChristian 
>
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

Re: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW...

[Support via RT]

Hi Christian,

A similar patch was already applied to the master branch - see
https://rt.openssl.org/Ticket/Display.html?id=3346 and commit
028bac0670c167f154438742eb4d0fbed73df209

You could cherry-pick the commit and apply it to the 1.0.2 branch.


Cheers,


Peter Mosmans

On 12-10-2015 12:03, christian fafard via RT wrote:
> I'm sorry for that mess with the previous message.There was no CRLF because 
> it was copy-pasted from emacs.
> What i tried to say basically is that the "negate regex match" (!/^0$$/) 
> constructused in the line 244 of 'test/Makefile' does not work with some 
> versions of perl.Like for exemple, perl v5.8.8 in the MinGW/msys distibution.
> That's the reason why 'make test' fail on that platform.
> My proposal is to invert the if/else actions to get rid of the negation in 
> the expression (/^0$$/).
> So the line:
> @ () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) 
> {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR 
> "\n$$i tests passed\n"'
> would became:
> @ () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) 
> {print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR 
> "\n$$i tests passed\n"'
> I attached a patch.
> ThanksChristian 
>
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


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

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

[Dmitry Belyavsky via RT]

Hello Matt,

On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT 
wrote:

> 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 the one currently in master?
>

Yes, it's on master. I think that I use the engine currently in master.
I'll try to reproduce it again.


-- 
SY, Dmitry Belyavsky

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

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

[Dmitry Belyavsky]

Hello Matt,

On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT 
wrote:

> 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 the one currently in master?
>

Yes, it's on master. I think that I use the engine currently in master.
I'll try to reproduce it again.


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Matt Caswell via RT]

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 the one currently in master?

Matt

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

Re: [openssl-dev] ovsdb-client connected error when i update the ovsdb-server ca_cert.pem file

[Liuyongqiang (A)]

Does anybody know why ovsdb-server only use the openssl api 
SSL_CTX_add_client_CA to add certificate, but have no delete api to delete 
certificate.

I found that if I update ca_crt.pem  many times(SSL_CTX_add_client_CA add 649 
certificates), the error of ovsdb-client connecting ovsdb-server will occur,  I 
found that there are 649 certificates in stack  list ctx->client_CA when the 
error occurred.

Are there any limits on stack list ctx->client_CA?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW...

[christian fafard via RT]

Hi Peter,
 
You are completely right! Windows carriage return is the real problem.
 
I should have done better testing before posting a ticket.
 
I'll use your patch until it get commited to the 1.0.2 branch.
 
Thank you
Christian
 
> Subject: Re: [openssl-dev] [openssl.org #4083] possible fix to make test 
> failure with openssl-1.0.2d on MinGW...
> From: r...@openssl.org
> To: c...@hotmail.com
> CC: openssl-dev@openssl.org
> Date: Mon, 12 Oct 2015 06:03:23 +
> 
> 
> Hi Christian,
> 
> A similar patch was already applied to the master branch - see
> https://rt.openssl.org/Ticket/Display.html?id=3346 and commit
> 028bac0670c167f154438742eb4d0fbed73df209
> 
> You could cherry-pick the commit and apply it to the 1.0.2 branch.
> 
> 
> Cheers,
> 
> 
> Peter Mosmans
> 
> On 12-10-2015 12:03, christian fafard via RT wrote:
> > I'm sorry for that mess with the previous message.There was no CRLF because 
> > it was copy-pasted from emacs.
> > What i tried to say basically is that the "negate regex match" (!/^0$$/) 
> > constructused in the line 244 of 'test/Makefile' does not work with some 
> > versions of perl.Like for exemple, perl v5.8.8 in the MinGW/msys 
> > distibution.
> > That's the reason why 'make test' fail on that platform.
> > My proposal is to invert the if/else actions to get rid of the negation in 
> > the expression (/^0$$/).
> > So the line:
> > @ > () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) 
> > {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR 
> > "\n$$i tests passed\n"'
> > would became:
> > @ > () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) 
> > {print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR 
> > "\n$$i tests passed\n"'
> > I attached a patch.
> > ThanksChristian   
> >
> >
> > ___
> > openssl-dev mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 
> 
  
___
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

[Matt Caswell via RT]

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, I also created a test script that
 combines fragmentation with interleaving.
>>>
>>> Did you try my patch with it? And if so what happened?
>>
>> I'm using interleave-data-102.patch attached to this ticket.
>>
>> So, for state-machine-rewrite branch it doesn't apply, there's no 
>> ssl/s3_pkt.c file.
>>
>> For current 1.0.1 branch, the patch applies, test case results are as 
>> follows:
>>  * test-openssl-3712.py - pass
>>  * test-interleaved-application-data-in-renegotiation.py - pass
>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
>> renegotiation.py - pass
>>
>> For current 1.0.2 branch, the patch applies, tests case results are as 
>> follows:
>>  * test-openssl-3712.py - pass
>>  * test-interleaved-application-data-in-renegotiation.py - pass
>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
>> renegotiation.py - pass
>>
>> for current master the patch doesn't apply, just like with state-
>> machine-rewrite there's no ssl/s3_pkt.c file
>>
>> Note: the two latter test cases need the s_server run in -www mode, the 
>> first test case ignores server response so will work regardless, that 
>> may be why Alessandro testing doesn't show the issue as fixed
> 
> Ah, yep, with -www it works for me too. Note that on master the file to change
> should be ssl/record/ssl3_record.c. However, while the patch applies cleanly 
> to
> this file, all the tests fail (even with -www). It seems that the field
> in_read_app_data is never true, so the UNEXPECTED_MESSAGE alert is sent.

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 1.0.2 and rerunning Hubert's test will hit it:

openssl s_server -www -tls1_2

The 1.0.2 version negotiation is hiding the issue. In master version neg
has been completely rewritten and simplified - but in doing so no longer
hides the problem. :-(

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

[Matt Caswell via RT]

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/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?
>>>
>>> I'm using interleave-data-102.patch attached to this ticket.
>>>
>>> So, for state-machine-rewrite branch it doesn't apply, there's no 
>>> ssl/s3_pkt.c file.
>>>
>>> For current 1.0.1 branch, the patch applies, test case results are as 
>>> follows:
>>>  * test-openssl-3712.py - pass
>>>  * test-interleaved-application-data-in-renegotiation.py - pass
>>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
>>> renegotiation.py - pass
>>>
>>> For current 1.0.2 branch, the patch applies, tests case results are as 
>>> follows:
>>>  * test-openssl-3712.py - pass
>>>  * test-interleaved-application-data-in-renegotiation.py - pass
>>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
>>> renegotiation.py - pass
>>>
>>> for current master the patch doesn't apply, just like with state-
>>> machine-rewrite there's no ssl/s3_pkt.c file
>>>
>>> Note: the two latter test cases need the s_server run in -www mode, the 
>>> first test case ignores server response so will work regardless, that 
>>> may be why Alessandro testing doesn't show the issue as fixed
>>
>> Ah, yep, with -www it works for me too. Note that on master the file to 
>> change
>> should be ssl/record/ssl3_record.c. However, while the patch applies cleanly 
>> to
>> this file, all the tests fail (even with -www). It seems that the field
>> in_read_app_data is never true, so the UNEXPECTED_MESSAGE alert is sent.
> 
> 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 1.0.2 and rerunning Hubert's test will hit it:
> 
> openssl s_server -www -tls1_2
> 
> The 1.0.2 version negotiation is hiding the issue. In master version neg
> has been completely rewritten and simplified - but in doing so no longer
> hides the problem. :-(

Having done some more digging it seems the problem only occurs if you
get the initial handshake, following by a second reneg handshake *and*
interleaved app data all within the scope of a *single* SSL_read call.
AFAICT if SSL_read returns between the first handshake and the second,
you don't get the problem.

That's starting to sound like quite an unlikely scenario and we're only
hitting it now because of the slightly artificial nature of Hubert's
test. I'm wondering whether "will not fix" is the right response to this
second bug? Thoughts? Having said that it would be nice to have a
reliable test for the interleaved-app data issue.

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

[Salz, Rich via RT]

> AFAICT if SSL_read returns between the first handshake and the second, you
> don't get the problem.

I think it should not matter when or what SSL_read returns.  That should only 
be returning application-level data to the caller.  All state manipulations, 
etc., should be done underneath and completely hidden.  So yes, I vote for 
fixing.


___
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

[Salz, Rich]

> AFAICT if SSL_read returns between the first handshake and the second, you
> don't get the problem.

I think it should not matter when or what SSL_read returns.  That should only 
be returning application-level data to the caller.  All state manipulations, 
etc., should be done underneath and completely hidden.  So yes, I vote for 
fixing.
___
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

[Hubert Kario via RT]

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, I also created a test script that
> > combines fragmentation with interleaving.
> 
> Did you try my patch with it? And if so what happened?

I'm using interleave-data-102.patch attached to this ticket.

So, for state-machine-rewrite branch it doesn't apply, there's no 
ssl/s3_pkt.c file.

For current 1.0.1 branch, the patch applies, test case results are as 
follows:
 * test-openssl-3712.py - pass
 * test-interleaved-application-data-in-renegotiation.py - pass
 * test-interleaved-application-data-and-fragmented-handshakes-in-
renegotiation.py - pass

For current 1.0.2 branch, the patch applies, tests case results are as 
follows:
 * test-openssl-3712.py - pass
 * test-interleaved-application-data-in-renegotiation.py - pass
 * test-interleaved-application-data-and-fragmented-handshakes-in-
renegotiation.py - pass

for current master the patch doesn't apply, just like with state-
machine-rewrite there's no ssl/s3_pkt.c file

Note: the two latter test cases need the s_server run in -www mode, the 
first test case ignores server response so will work regardless, that 
may be why Alessandro testing doesn't show the issue as fixed
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Matt Caswell via RT]

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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Matt Caswell via RT]

Closing ticket.

Matt

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

[openssl-dev] [openssl.org #4090] [PATCH] Assorted fixes

[Alessandro Ghedini via RT]

Hello,

I've prepared a few patches to fix several minor-ish issues (I though it didn't
make much sense to submit them one by one). See GitHub pull request at:
https://github.com/openssl/openssl/pull/436

The patches are:

- Do not treat 0 return value from BIO_get_fd() as error (fixes RT#4068)
- Replace malloc+strlcpy with strdup
- Fix memory leaks and other mistakes on errors
- Set salt length after the malloc has succeeded
- Fix typos
- Fix references to various RFCs
- Check memory allocation
- Remove useless code (fixes RT#4081)

(some of the issues were found using Clang's static analyzer).

They should be all pretty self-explanatory.

Cheers

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
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

[Nikos Mavrogiannopoulos]

On Mon, 2015-09-28 at 11:35 +, Albe Laurenz via RT wrote:

> The RFC writes:
> 
>Note: If a rehandshake occurs while data is flowing on a
> connection,
>the communicating parties may continue to send data using the old
>CipherSpec.  However, once the ChangeCipherSpec has been sent, the
>new CipherSpec MUST be used.  The first side to send the
>ChangeCipherSpec does not know that the other side has finished
>computing the new keying material (e.g., if it has to perform a
>time-consuming public key operation).  Thus, a small window of
> time,
>during which the recipient must buffer the data, MAY exist.  In
>practice, with modern machines this interval is likely to be
> fairly
>short.
> 
> Could that be interpreted to mean that the recepient should buffer
> all incoming Application Data messages that are sent between
> ChangeCipherSpec and Finished?

That doesn't sound safe. Consider the case where re-authentication
occurs and a different identity is presented while the previous
commands are being cached. The server will see the commands of the
initial session as commands coming from the new session which is under
a new user. I think that unless you can separate re-authentication from
rehandshake to refresh the keys, the current behavior of openssl which
drops the session is quite safe.

regards,
Nikos

___
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

[Nikos Mavrogiannopoulos via RT]

On Mon, 2015-09-28 at 11:35 +, Albe Laurenz via RT wrote:

> The RFC writes:
> 
>Note: If a rehandshake occurs while data is flowing on a
> connection,
>the communicating parties may continue to send data using the old
>CipherSpec.  However, once the ChangeCipherSpec has been sent, the
>new CipherSpec MUST be used.  The first side to send the
>ChangeCipherSpec does not know that the other side has finished
>computing the new keying material (e.g., if it has to perform a
>time-consuming public key operation).  Thus, a small window of
> time,
>during which the recipient must buffer the data, MAY exist.  In
>practice, with modern machines this interval is likely to be
> fairly
>short.
> 
> Could that be interpreted to mean that the recepient should buffer
> all incoming Application Data messages that are sent between
> ChangeCipherSpec and Finished?

That doesn't sound safe. Consider the case where re-authentication
occurs and a different identity is presented while the previous
commands are being cached. The server will see the commands of the
initial session as commands coming from the new session which is under
a new user. I think that unless you can separate re-authentication from
rehandshake to refresh the keys, the current behavior of openssl which
drops the session is quite safe.

regards,
Nikos


___
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

[Alessandro Ghedini via RT]

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, I also created a test script that
> > > combines fragmentation with interleaving.
> > 
> > Did you try my patch with it? And if so what happened?
> 
> I'm using interleave-data-102.patch attached to this ticket.
> 
> So, for state-machine-rewrite branch it doesn't apply, there's no 
> ssl/s3_pkt.c file.
> 
> For current 1.0.1 branch, the patch applies, test case results are as 
> follows:
>  * test-openssl-3712.py - pass
>  * test-interleaved-application-data-in-renegotiation.py - pass
>  * test-interleaved-application-data-and-fragmented-handshakes-in-
> renegotiation.py - pass
> 
> For current 1.0.2 branch, the patch applies, tests case results are as 
> follows:
>  * test-openssl-3712.py - pass
>  * test-interleaved-application-data-in-renegotiation.py - pass
>  * test-interleaved-application-data-and-fragmented-handshakes-in-
> renegotiation.py - pass
> 
> for current master the patch doesn't apply, just like with state-
> machine-rewrite there's no ssl/s3_pkt.c file
> 
> Note: the two latter test cases need the s_server run in -www mode, the 
> first test case ignores server response so will work regardless, that 
> may be why Alessandro testing doesn't show the issue as fixed

Ah, yep, with -www it works for me too. Note that on master the file to change
should be ssl/record/ssl3_record.c. However, while the patch applies cleanly to
this file, all the tests fail (even with -www). It seems that the field
in_read_app_data is never true, so the UNEXPECTED_MESSAGE alert is sent.

Cheers


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

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

[Dmitry Belyavsky]

Hello!

Thank you, I can't reproduce it either. Please close the ticket.
Sorry for disturbing.

On Mon, Oct 12, 2015 at 12:39 PM, Dmitry Belyavsky via RT 
wrote:

> Hello Matt,
>
> On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT 
> wrote:
>
> > 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 the one currently in master?
> >
>
> Yes, it's on master. I think that I use the engine currently in master.
> I'll try to reproduce it again.
>
>
> --
> SY, Dmitry Belyavsky
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dmitry Belyavsky via RT]

Hello!

Thank you, I can't reproduce it either. Please close the ticket.
Sorry for disturbing.

On Mon, Oct 12, 2015 at 12:39 PM, Dmitry Belyavsky via RT 
wrote:

> Hello Matt,
>
> On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT 
> wrote:
>
> > 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 the one currently in master?
> >
>
> Yes, it's on master. I think that I use the engine currently in master.
> I'll try to reproduce it again.
>
>
> --
> SY, Dmitry Belyavsky
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky

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

Re: [openssl-dev] who wants to fix travis builds?

[Alessandro Ghedini]

On Tue, Oct 06, 2015 at 07:41:13pm +, Salz, Rich wrote:
> > I've opened the following PR to add support for GCC v5 and address sanitizer
> > (not sure if we want valgrind as well...):
> > https://github.com/openssl/openssl/pull/429
> 
> I've started the internal review.  Asan is awesome.

Ping?

Cheers


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Andrey Kulikov via RT]

On 12 October 2015 at 12:08, Matt Caswell via RT  wrote:

> Are you using your new GOST
> engine or the one currently in master?
>


Sorry to come in in the middle, but where to get that new GOST engine, that
is not on master now?
Is it on some other branch?

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

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

[Andrey Kulikov]

On 12 October 2015 at 12:08, Matt Caswell via RT  wrote:

> Are you using your new GOST
> engine or the one currently in master?
>


Sorry to come in in the middle, but where to get that new GOST engine, that
is not on master now?
Is it on some other branch?
___
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

[Kurt Roeckx via RT]

On Mon, Oct 12, 2015 at 04:19:43PM +, 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*
> interleaved app data all within the scope of a *single* SSL_read call.
> AFAICT if SSL_read returns between the first handshake and the second,
> you don't get the problem.
> 
> That's starting to sound like quite an unlikely scenario and we're only
> hitting it now because of the slightly artificial nature of Hubert's
> test. I'm wondering whether "will not fix" is the right response to this
> second bug? Thoughts? Having said that it would be nice to have a
> reliable test for the interleaved-app data issue.

Are you saying this is 1 TLS record with 2 handshakes in it?

>From what I understand, the authentication could change.  Doesn't
that mean we should make sure the client reads all data with
SSL_read() before we tell it authentication changes and that we
might have to delay processing some messages until that is done?


Kurt


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

[openssl-dev] [openssl.org #2923] X509_cmp() introduces unnecessary dependency on SHA1

[Emilia Käsper via RT]

Thanks for the report. This has now been addressed in 1.0.1+, see commit
bfc19297cddd5bc2192c02c7f8896d804b0456cb.

Cheers,
Emilia

___
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

[Matt Caswell via RT]

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:
>>
>> Having done some more digging it seems the problem only occurs if you
>> get the initial handshake, following by a second reneg handshake *and*
>> interleaved app data all within the scope of a *single* SSL_read call.
>> AFAICT if SSL_read returns between the first handshake and the second,
>> you don't get the problem.
>>
>> That's starting to sound like quite an unlikely scenario and we're only
>> hitting it now because of the slightly artificial nature of Hubert's
>> test. I'm wondering whether "will not fix" is the right response to this
>> second bug? Thoughts? Having said that it would be nice to have a
>> reliable test for the interleaved-app data issue.
> 
> Are you saying this is 1 TLS record with 2 handshakes in it?
> 
> From what I understand, the authentication could change.  Doesn't
> that mean we should make sure the client reads all data with
> SSL_read() before we tell it authentication changes and that we
> might have to delay processing some messages until that is done?
>

No. I'm saying it is within the scope of one SSL_read. libssl will read
1 record at a time from the network, process it, then read the next one,
and so on. It will continue until it returns back to the user code
because it ran out of data to read (NBIO), or it has filled the buffer
supplied by the user code. So there is not reason why it couldn't do
multiple handshakes within a single SSL_read if the buffer is big enough
(or not much app data is read between handshakes) and the data is coming
in from the network fast enough to prevent an IO block (e.g. such as
when we are running Hubert's test code on a single machine).

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

[Matt Caswell via RT]

On 12/10/15 20:40, Kurt Roeckx via RT wrote:
> On Mon, Oct 12, 2015 at 06:54:46PM +, 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:

 Having done some more digging it seems the problem only occurs if you
 get the initial handshake, following by a second reneg handshake *and*
 interleaved app data all within the scope of a *single* SSL_read call.
 AFAICT if SSL_read returns between the first handshake and the second,
 you don't get the problem.

 That's starting to sound like quite an unlikely scenario and we're only
 hitting it now because of the slightly artificial nature of Hubert's
 test. I'm wondering whether "will not fix" is the right response to this
 second bug? Thoughts? Having said that it would be nice to have a
 reliable test for the interleaved-app data issue.
>>>
>>> Are you saying this is 1 TLS record with 2 handshakes in it?
>>>
>>> From what I understand, the authentication could change.  Doesn't
>>> that mean we should make sure the client reads all data with
>>> SSL_read() before we tell it authentication changes and that we
>>> might have to delay processing some messages until that is done?
>>>
>>
>> No. I'm saying it is within the scope of one SSL_read. libssl will read
>> 1 record at a time from the network, process it, then read the next one,
>> and so on. It will continue until it returns back to the user code
>> because it ran out of data to read (NBIO), or it has filled the buffer
>> supplied by the user code. So there is not reason why it couldn't do
>> multiple handshakes within a single SSL_read if the buffer is big enough
>> (or not much app data is read between handshakes) and the data is coming
>> in from the network fast enough to prevent an IO block (e.g. such as
>> when we are running Hubert's test code on a single machine).
> 
> Maybe I should go and re-reads the RFCs again, or I'm missing
> something, but I don't see how we could have 2 unprocessed
> handshakes in the buffers.  I expect that we need to write
> something before the 2nd can arrive.  But maybe it's something
> related to NPN or something like that?

You can't. That's not what I'm saying. They only need to be in the
buffer by the time you try to read the data. Or if you're using blocking
IO, it will just keep trying to read app data until its got some to
return, processing any handshake messages it encounters as it goes (and
processing means it may swap to writing handshake messages out).

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

[Kurt Roeckx via RT]

On Mon, Oct 12, 2015 at 06:54:46PM +, 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:
> >>
> >> Having done some more digging it seems the problem only occurs if you
> >> get the initial handshake, following by a second reneg handshake *and*
> >> interleaved app data all within the scope of a *single* SSL_read call.
> >> AFAICT if SSL_read returns between the first handshake and the second,
> >> you don't get the problem.
> >>
> >> That's starting to sound like quite an unlikely scenario and we're only
> >> hitting it now because of the slightly artificial nature of Hubert's
> >> test. I'm wondering whether "will not fix" is the right response to this
> >> second bug? Thoughts? Having said that it would be nice to have a
> >> reliable test for the interleaved-app data issue.
> > 
> > Are you saying this is 1 TLS record with 2 handshakes in it?
> > 
> > From what I understand, the authentication could change.  Doesn't
> > that mean we should make sure the client reads all data with
> > SSL_read() before we tell it authentication changes and that we
> > might have to delay processing some messages until that is done?
> >
> 
> No. I'm saying it is within the scope of one SSL_read. libssl will read
> 1 record at a time from the network, process it, then read the next one,
> and so on. It will continue until it returns back to the user code
> because it ran out of data to read (NBIO), or it has filled the buffer
> supplied by the user code. So there is not reason why it couldn't do
> multiple handshakes within a single SSL_read if the buffer is big enough
> (or not much app data is read between handshakes) and the data is coming
> in from the network fast enough to prevent an IO block (e.g. such as
> when we are running Hubert's test code on a single machine).

Maybe I should go and re-reads the RFCs again, or I'm missing
something, but I don't see how we could have 2 unprocessed
handshakes in the buffers.  I expect that we need to write
something before the 2nd can arrive.  But maybe it's something
related to NPN or something like that?


Kurt


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

[openssl-dev] [openssl.org #4091] Openssl make depends gives errors when no-md5 is specified

[Ethan Barnes via RT]

Hi,

I'm trying to compile with as few options as I can since I only need AEAD and 
thought I would use SHA256 or SHA512 and AES.

However, when I try to disable certain cryptos and hashes I get errors:

./config no-ssl no-md5 no-rsa

make depends


gives:

...
eth.c cm_pmeth.c
make[2]: Leaving directory 
'/home/ruck/branches/fh-23489-encryption/src/lib/crypto/crypto/cmac'
make[1]: Leaving directory 
'/home/ruck/branches/fh-23489-encryption/src/lib/crypto/crypto'
making depend in ssl...
make[1]: Entering directory 
'/home/ruck/branches/fh-23489-encryption/src/lib/crypto/ssl'
In file included from s3_srvr.c:171:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
#  error MD5 is disabled.
   ^
In file included from s3_clnt.c:158:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
#  error MD5 is disabled.
   ^
In file included from s3_lib.c:155:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
#  error MD5 is disabled.
   ^
In file included from s3_enc.c:141:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
#  error MD5 is disabled.
   ^
In file included from s3_cbc.c:59:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
#  error MD5 is disabled.
   ^
In file included from t1_enc.c:145:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
#  error MD5 is disabled.
   ^
In file included from d1_srvr.c:123:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
#  error MD5 is disabled.
   ^
In file included from d1_clnt.c:125:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
#  error MD5 is disabled.
   ^
Makefile:98: recipe for target 'local_depend' failed
make[1]: *** [local_depend] Error 1


I get the same errors if I include other no-ssl options, such as no-ssl2, 
no-ssl3, no-sslext, etc.

It also appears I cannot specify "no-rsa", as I also get errors in 'make 
depend'.

Can I exclude those options, and if so, what other options do I need to exclude 
in order to build?

Thanks,
Ethan



PLEASE NOTE: The information contained in this electronic mail message is 
intended only for the use of the designated recipient(s) named above. If the 
reader of this message is not the intended recipient, you are hereby notified 
that you have received this message in error and that any review, 
dissemination, distribution, or copying of this message is strictly prohibited. 
If you have received this communication in error, please notify the sender by 
telephone or e-mail (as shown above) immediately and destroy any and all copies 
of this message in your possession (whether hard copies or electronically 
stored copies).


___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Matt Caswell via RT]

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

[Matt Caswell via RT]

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

[Matt Caswell via RT]

Fixed.

Thanks

Matt

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

Re: [openssl-dev] [openssl.org #4091] Openssl make depends gives errors when no-md5 is specified

[Salz, Rich via RT]

Yes, the various no-options don't work well.  Not a high priority for 1.0.2 
unless patches are provided.



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