Re: [openssl-dev] [openssl.org #4091] Openssl make depends gives errors when no-md5 is specified
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
[openssl-dev] [openssl.org #4091] Openssl make depends gives errors when no-md5 is specified
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
Fixed, thanks for the report. 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 #4085] Bug in genpkey in master
Fixed. 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 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
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
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 +, 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
[openssl-dev] [openssl.org #2923] X509_cmp() introduces unnecessary dependency on SHA1
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
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
Re: [openssl-dev] [openssl.org #4073] Segfault in engine processing
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
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
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
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?
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 #3712] TLS Renegotiation with Java is broken
> 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
> 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
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
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
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
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
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 #3712] TLS Renegotiation with Java is broken
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 #4090] [PATCH] Assorted fixes
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
[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
[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 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...
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] ovsdb-client connected error when i update the ovsdb-server ca_cert.pem file
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 #4073] Segfault in engine processing
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
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
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
