Re: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation
On 2016-08-11 18:04:41 [+0200], Hubert Kario wrote: > On Thursday, 11 August 2016 13:50:53 CEST Sebastian Andrzej Siewior wrote: > > On 2016-08-11 11:34:24 [+0200], Hubert Kario wrote: > > > it all depends on the environment, in some renegotiation is completely > > > unnecessary (public HTTP servers without client certificate based > > > authentication), in others just client-initiated renegotiation is needed > > > (typical configuration for HTTP with client certificates), while in other > > > > Is this renegotiation (in this case) triggert by the client or by the > > server? I have here access to a few servers which require a client certs > > and they don't support renegotiation (triggert by the client) right > > after connect. > > in this case the renegotiation is triggered by server good. So still no reason to accept a renegotiation request from the client (except your "long standing connection" point (which could be ratelimited or shifted to the server)). Sebastian -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc
Hi, > I have no time to check with debugger now, Then no progress will be made. Problem needs to be identified first, and since similar problem was identified earlier, I'd have to insist on confirmation whether or not it's the same. > but I do not think it is caused by assembler, > because, > - gcc-5.4.0 with gas (GNU Binutils) 2.27 > - cc (Solaris developerstudio12.5) with /usr/ccs/bin/as > have the same result (see openssl.org #4642 also). > > perl version which I use is v5.24.0. Well, (assuming for a moment it's the same problem) there is *less* reason to believe that x86_64cpuid.pl is broken. Because it's used with a *number* of other toolchains, Linux, BSD, mingw, MSVC, without any problem. Nor can I reproduce the problem on my Solaris VM. It's not as fancy as yours, apparently, but it also kind of speak in favour of suggestion that it's not an OpenSSL problem... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4584] Self test failures under X32
On 11/08/16 13:29, Andy Polyakov via RT wrote: >> ( cd test; \ >> SRCTOP=../. \ >> BLDTOP=../. \ >> PERL="perl" \ >> EXE_EXT= \ >> OPENSSL_ENGINES=.././engines \ >> perl .././test/run_tests.pl test_afalg ) >> ../test/recipes/30-test_afalg.t .. >> 1..1 >> ALG_PERR: afalg_fin_cipher_aio: io_read failed : Bad address >> test_afalg_aes_128_cbc() failed encryption >> ../util/shlib_wrap.sh ./afalgtest => 1 >> not ok 1 - running afalgtest >> >> # Failed test 'running afalgtest' >> # at ../test/recipes/30-test_afalg.t line 23. >> # Looks like you failed 1 test of 1. >> Dubious, test returned 1 (wstat 256, 0x100) >> Failed 1/1 subtests > > For reference, problem is not specific to x32, real x86 32-bit build > fails in same manner as well. [As well as executed under qemu-user, but > we are probably not in position to expect *that* work.] What's common > between x32 and x86 is that system calls pass an "emulation" layer where > 32-bit arguments are adjusted for 64-bit kernel and return values back > for 32-bit application... > > Could be this: https://github.com/openssl/openssl/pull/1432 Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation
On Thursday, 11 August 2016 13:50:53 CEST Sebastian Andrzej Siewior wrote: > On 2016-08-11 11:34:24 [+0200], Hubert Kario wrote: > > it all depends on the environment, in some renegotiation is completely > > unnecessary (public HTTP servers without client certificate based > > authentication), in others just client-initiated renegotiation is needed > > (typical configuration for HTTP with client certificates), while in other > > Is this renegotiation (in this case) triggert by the client or by the > server? I have here access to a few servers which require a client certs > and they don't support renegotiation (triggert by the client) right > after connect. in this case the renegotiation is triggered by server -- Regards, Hubert Kario Senior 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: This is a digitally signed message part. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc
Hello, I have no time to check with debugger now, but I do not think it is caused by assembler, because, - gcc-5.4.0 with gas (GNU Binutils) 2.27 - cc (Solaris developerstudio12.5) with /usr/ccs/bin/as have the same result (see openssl.org #4642 also). perl version which I use is v5.24.0. Regards, --- Kiyoshi - Original Message - > From: Andy Polyakov via RT > To: yoi_no_myou...@yahoo.co.jp > Cc: openssl-dev@openssl.org > Date: 2016/8/11, Thu 21:17 > Subject: Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test > stops with solaris64-x86_64-gcc > > Hi, > >> make test stops on Solaris10 x64. >> >> >> % ./Configure solaris64-x86_64-gcc >> >> % make >> % make test >> : >> ../test/recipes/01-test_abort.t ok >> ../test/recipes/01-test_sanity.t ... ok >> ../test/recipes/01-test_symbol_presence.t .. ok >> ../test/recipes/02-test_ordinals.t . ok >> ../test/recipes/05-test_bf.t ... ok >> ../test/recipes/05-test_cast.t . ok >> ../test/recipes/05-test_des.t .. ok >> ../test/recipes/05-test_fuzz.t . ok >> ../test/recipes/05-test_hmac.t . > > There was private report about similar problem. I mean if you can > confirm that it's stuck in OPENSSL_cleanse, then it's same problem(*). > Trouble is that it doesn't seem to be OpenSSL problem, because generated > code appears to be mis-compiled. When single-stepping with 'stepi' you > are likely to observe "lea 0(%rdi),%rdi" instruction, and it should be > "lea 1(%rdi),%rdi". I mean it *is* "lea 1(%rdi),%rdi" in > source file, > crypto/x86_64cpuid.pl, and that's where our responsibility ends. In > sense that we are responsible for providing source, and you are > effectively responsible for providing working compiler environment. I > don't know which components were involved in first report, I mean things > like perl version, which assembler and its version, so I can't give any > advice about updates that might be required... > > (*) To confirm run test/hmactest under debugger, break, see if it's in > OPENSSL_cleanse, issue 'stepi' command few times to see if it's > going > "in circles". > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 > Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4584] Self test failures under X32
> ( cd test; \ > SRCTOP=../. \ > BLDTOP=../. \ > PERL="perl" \ > EXE_EXT= \ > OPENSSL_ENGINES=.././engines \ > perl .././test/run_tests.pl test_afalg ) > ../test/recipes/30-test_afalg.t .. > 1..1 > ALG_PERR: afalg_fin_cipher_aio: io_read failed : Bad address > test_afalg_aes_128_cbc() failed encryption > ../util/shlib_wrap.sh ./afalgtest => 1 > not ok 1 - running afalgtest > > # Failed test 'running afalgtest' > # at ../test/recipes/30-test_afalg.t line 23. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/1 subtests For reference, problem is not specific to x32, real x86 32-bit build fails in same manner as well. [As well as executed under qemu-user, but we are probably not in position to expect *that* work.] What's common between x32 and x86 is that system calls pass an "emulation" layer where 32-bit arguments are adjusted for 64-bit kernel and return values back for 32-bit application... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc
Hi, > make test stops on Solaris10 x64. > > > % ./Configure solaris64-x86_64-gcc > > % make > % make test >: > ../test/recipes/01-test_abort.t ok > ../test/recipes/01-test_sanity.t ... ok > ../test/recipes/01-test_symbol_presence.t .. ok > ../test/recipes/02-test_ordinals.t . ok > ../test/recipes/05-test_bf.t ... ok > ../test/recipes/05-test_cast.t . ok > ../test/recipes/05-test_des.t .. ok > ../test/recipes/05-test_fuzz.t . ok > ../test/recipes/05-test_hmac.t . There was private report about similar problem. I mean if you can confirm that it's stuck in OPENSSL_cleanse, then it's same problem(*). Trouble is that it doesn't seem to be OpenSSL problem, because generated code appears to be mis-compiled. When single-stepping with 'stepi' you are likely to observe "lea 0(%rdi),%rdi" instruction, and it should be "lea 1(%rdi),%rdi". I mean it *is* "lea 1(%rdi),%rdi" in source file, crypto/x86_64cpuid.pl, and that's where our responsibility ends. In sense that we are responsible for providing source, and you are effectively responsible for providing working compiler environment. I don't know which components were involved in first report, I mean things like perl version, which assembler and its version, so I can't give any advice about updates that might be required... (*) To confirm run test/hmactest under debugger, break, see if it's in OPENSSL_cleanse, issue 'stepi' command few times to see if it's going "in circles". -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL 1.1.0 pre 6: SPARCv9 capability bits problem
> The following change introduced build problems: > >> +if (vec[1]&0x8) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS4; > > ... here we use vec[1], so the compiler warns: > > crypto/sparcv9cap.c:179:20: warning: array subscript is above array > bounds [-Warray-bounds] > if (vec[1]&0x8) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS4; > ^ Fixed. > need the following patch to crypto/sparcv9cap.c here (warning "implicit > declaration of function '_sparcv9_fjaesx_probe'"): > > @@ -93,6 +93,7 @@ > void _sparcv9_fmadd_probe(void); > unsigned long _sparcv9_rdcfr(void); > void _sparcv9_vis3_probe(void); > +void _sparcv9_fjaesx_probe(void); > unsigned long _sparcv9_random(void); > size_t _sparcv9_vis1_instrument_bus(unsigned int *, size_t); > size_t _sparcv9_vis1_instrument_bus2(unsigned int *, size_t, size_t); Being fixed. Thanks for report. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation
On 2016-08-11 11:34:24 [+0200], Hubert Kario wrote: > it all depends on the environment, in some renegotiation is completely > unnecessary (public HTTP servers without client certificate based > authentication), in others just client-initiated renegotiation is needed > (typical configuration for HTTP with client certificates), while in other Is this renegotiation (in this case) triggert by the client or by the server? I have here access to a few servers which require a client certs and they don't support renegotiation (triggert by the client) right after connect. > still renegotiation is necessary for both sides (long sessions that want the > ability to renew encryption keys). You are talking here about long sessions. A simple rate limit would be okay. My wording was "remove client initiated renegotiation if possible" I think. Also keeping a rate limit per connection would be nice then. Sebastian -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation
On Tuesday, 9 August 2016 21:51:32 CEST Sebastian Andrzej Siewior wrote: > On 2016-08-09 19:26:44 [+], Viktor Dukhovni wrote: > > On Tue, Aug 09, 2016 at 09:18:58PM +0200, Sebastian Andrzej Siewior wrote: > > > I don't really know what I am supposed to do with this information. Do > > > you want me to add this as an example into the doc patch or do you > > > simply point out that others already took precautions? > > > > CPU exhaustion attacks on servers are a fundamental feature of TLS. > > I mentioned this. > > > I am not sure that OpenSSL needs to say anything about this. Server > > applications that want to protect against inadvertent DoS by buggy > > clients can implement the obvious counter-measure (rate limit > > handshakes with clients that generate too many new sessions per > > sample interval). If you feel that this is not obvious, and others > > agree, feel free to propose some text. > > I tried. There was some text in the patch. > > > Note, that deliberate DoS and especially DDoS will overcome even > > rate limits, by attacking from multiple clients, or just flooding > > the target network. So this can only protect against accidents, > > not malice by capable adversaries. > > I don't claim the opposite. I came across server software which supports > client side renegotiation and I don't think that this is required and > would like to patch it out. So far, so good? And then there is the > "same" thing if the attacker starts multiple connections the sake of a > handshake. So I though to point this out as well. And then I though it > would be nice to document this within the openssl documentation so I > could just point there and make them aware. it all depends on the environment, in some renegotiation is completely unnecessary (public HTTP servers without client certificate based authentication), in others just client-initiated renegotiation is needed (typical configuration for HTTP with client certificates), while in other still renegotiation is necessary for both sides (long sessions that want the ability to renew encryption keys). -- Regards, Hubert Kario Senior 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: This is a digitally signed message part. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
