[openssl-dev] [openssl.org #4558] Performance issue with DTLS packet reassembly
The DTLS packet reassembly code has a performance problem that could result in a DoS attack being possible. The DTLS packet reassembly uses the data structure defined in ssl/pqueue.c for the purpose (it is the only user of this data structure that I can find). This source file implements a priority queue using a singly linked list. This means O(n^2) worst case complexity, where n is the number of fragments. A better, and in fact optimal, solution would be to use a heap for the purpose giving O(n log n) worst case complexity. Doing this would prevent a potential DoS attack. The attack would consist of fragmenting the DTLS stream into as many small packets as possible and sending them in sequential order. Each fragment will require a complete traversal of the list to be added. Continue sending these as long as the DoS is wanted. For reference, changing the list search method or ordering won't prevent such an attack, it just means a different packet ordering is required. Tim Hudson suggested I submit this even though I haven't been able to find time to craft a patch. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4558 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4556] Unknown: mysterious perl(1) error during [master:8d054a5] installation process
On Thu Jun 02 15:50:31 2016, stef...@sdaoden.eu wrote: > Hello. > > I have never seen something like this: > > Parser.c: loadable library and perl binaries are mismatched (got > handshake key 0xdb00080, needed 0xdb80080) > > This is v5.24 on a Linux system, and it flawless afaik. Are you sure that you don't have perl modules that you installed separately with an earlier perl version? You may need to update those. Either way, this is not an OpenSSL issue, it's a perl one. Closing this ticket. -- Richard Levitte levi...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4556 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4555] Enhancement request: allow installation without manuals, but anyway without HTML manuals
On Thu Jun 02 15:50:31 2016, stef...@sdaoden.eu wrote: > Oh yes, please! The 'install' target calls three other targets: install_sw install_ssldirs install_docs So if you simple do 'make install_sw' or 'nmake install_sw', I think you'll get what you want. Closing this ticket. -- Richard Levitte levi...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4555 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4557] Nit: temporary files left over after [master:8d054a5] installation process
Yep: -rw--- 1 steffen steffen 1848 Jun 2 14:46 VhXl383LiQ -rw--- 1 steffen steffen 1612 Jun 2 14:46 F1RkvxEZi0 -rw--- 1 steffen steffen 1848 Jun 2 14:46 qg_wML0XIF -rw--- 1 steffen steffen 1848 Jun 2 14:46 4MUN7KIs69 -rw--- 1 steffen steffen 1840 Jun 2 14:46 fU_zMQI7Wb -rw--- 1 steffen steffen 1848 Jun 2 14:46 gbNE7UjUAJ -rw--- 1 steffen steffen 1848 Jun 2 14:46 P2Vff7Duiz -rw--- 1 steffen steffen 1840 Jun 2 14:46 3E_oztoePh ;do head -n 1 $i; done: -BEGIN SSL SESSION PARAMETERS- -BEGIN SSL SESSION PARAMETERS- -BEGIN SSL SESSION PARAMETERS- -BEGIN SSL SESSION PARAMETERS- -BEGIN SSL SESSION PARAMETERS- -BEGIN SSL SESSION PARAMETERS- -BEGIN SSL SESSION PARAMETERS- -BEGIN SSL SESSION PARAMETERS- --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4557 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4555] Enhancement request: allow installation without manuals, but anyway without HTML manuals
Oh yes, please! --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4555 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4556] Unknown: mysterious perl(1) error during [master:8d054a5] installation process
Hello. I have never seen something like this: Parser.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080) This is v5.24 on a Linux system, and it flawless afaik. Thanks. --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4556 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] DTLS retransmission api
On 02/06/16 14:33, Alfred E. Heggestad wrote:
>
>
> On 01/06/16 13:58, Matt Caswell wrote:
>>
>>
>> On 01/06/16 11:15, Alfred E. Heggestad wrote:
>>> hi,
>>>
>>> we are using DTLS from OpenSSL to implement DTLS-SRTP in our
>>> product (Wire.com) .. The code and implementation works really well
>>> and is very robust. We are using OpenSSL version 1.0.2g
>>>
>>>
>>> since our product is deployed globally on mobile data networks,
>>> we have quite variable latency and packetloss. The patch below
>>> shows my working code, it has an initial retransmit timeout
>>> of 400 ms which is incrementing by 10% for every re-trans.
>>>
>>>
>>> obviously this patch cannot make it into the official tree.
>>>
>>>
>>> but I would like to discuss with you guys the option to
>>> add some kind of API for:
>>>
>>> - Setting the initial RTO for DTLS (in milliseconds).
>>> - Setting the retransmit policy for DTLS, i.e. should it
>>>double or increment by X for every re-trans.
>>
>> I think an API for that would be a great idea. Perhaps a callback could
>> be used so that you can set exactly the policy you want?
>>
>
> Thank you, Matt
>
>
> I can work on a patch for this, if you guys can help me to define
> the API.
>
>
> I think we only need one CTRL api to set the next re-transmit
> interval. then in the application code that calls this:
>
> - DTLSv1_handle_timeout
> - DTLSv1_get_timeout
>
>
> can also call DTLS_set_retrans_interval(400)
>
I'm not sure I follow you. I was thinking something like:
int DTLS_set_timer_cb(SSL *s, int (*cb)(SSL *s, int timer));
Then where in the current code we have:
dtls1_double_timeout(s);
We might instead do
if(s->d1->timer_cb != NULL)
s->d1->timeout_duration = timer_cb(s, s->d1->timeout_duration);
else
dtls1_double_timeout(s);
And in dtls1_start_timer() where we have:
/* If timer is not set, initialize duration with 1 second */
if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec
== 0) {
s->d1->timeout_duration = 1;
}
Instead have:
/* If timer is not set, initialize duration with 1 second */
if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec
== 0) {
if (s->d1->timer_cb != NULL)
s->d1->timeout_duration = s->d1_timeout_cb(s, 0);
else
s->d1->timeout_duration = 1;
}
...or something like that.
Matt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] DTLS retransmission api
On 01/06/16 13:58, Matt Caswell wrote:
On 01/06/16 11:15, Alfred E. Heggestad wrote:
hi,
we are using DTLS from OpenSSL to implement DTLS-SRTP in our
product (Wire.com) .. The code and implementation works really well
and is very robust. We are using OpenSSL version 1.0.2g
since our product is deployed globally on mobile data networks,
we have quite variable latency and packetloss. The patch below
shows my working code, it has an initial retransmit timeout
of 400 ms which is incrementing by 10% for every re-trans.
obviously this patch cannot make it into the official tree.
but I would like to discuss with you guys the option to
add some kind of API for:
- Setting the initial RTO for DTLS (in milliseconds).
- Setting the retransmit policy for DTLS, i.e. should it
double or increment by X for every re-trans.
I think an API for that would be a great idea. Perhaps a callback could
be used so that you can set exactly the policy you want?
Thank you, Matt
I can work on a patch for this, if you guys can help me to define
the API.
I think we only need one CTRL api to set the next re-transmit
interval. then in the application code that calls this:
- DTLSv1_handle_timeout
- DTLSv1_get_timeout
can also call DTLS_set_retrans_interval(400)
in addition we have seen the code hit this assert
in production:
/*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever get here */
so I would say it should be safe to remove it.
Hmthe question is why does it get there? It shouldn't.
I can try to reproduce this. We have seen that this assert was
executed, when the code was under quite heavy load and lots of traffic.
/alfred
Matt
Best Regards,
Alfred E. Heggestad
Berlin
--
diff -Naur openssl-1.0.2g/ssl/d1_lib.c openssl/ssl/d1_lib.c
--- openssl-1.0.2g/ssl/d1_lib.c2016-03-01 14:35:53.0 +0100
+++ openssl/ssl/d1_lib.c2016-06-01 10:45:27.0 +0200
@@ -359,6 +359,8 @@
void dtls1_start_timer(SSL *s)
{
+struct timeval diff;
+
#ifndef OPENSSL_NO_SCTP
/* Disable timer for SCTP */
if (BIO_dgram_is_sctp(SSL_get_wbio(s))) {
@@ -369,14 +371,17 @@
/* If timer is not set, initialize duration with 1 second */
if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec
== 0) {
-s->d1->timeout_duration = 1;
+s->d1->timeout_duration = 0.400;
}
/* Set timeout to current time */
get_current_time(&(s->d1->next_timeout));
/* Add duration to current time */
-s->d1->next_timeout.tv_sec += s->d1->timeout_duration;
+diff.tv_sec = 0;
+diff.tv_usec = 100*s->d1->timeout_duration;
+timeradd(>d1->next_timeout, , >d1->next_timeout);
+
BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0,
&(s->d1->next_timeout));
}
@@ -441,7 +446,7 @@
void dtls1_double_timeout(SSL *s)
{
-s->d1->timeout_duration *= 2;
+s->d1->timeout_duration *= 1.10;
if (s->d1->timeout_duration > 60)
s->d1->timeout_duration = 60;
dtls1_start_timer(s);
diff -Naur openssl-1.0.2g/ssl/d1_pkt.c openssl/ssl/d1_pkt.c
--- openssl-1.0.2g/ssl/d1_pkt.c2016-03-01 14:35:53.0 +0100
+++ openssl/ssl/d1_pkt.c2016-03-08 14:39:44.0 +0100
@@ -1502,7 +1502,7 @@
* will happen with non blocking IO
*/
if (s->s3->wbuf.left != 0) {
-OPENSSL_assert(0); /* XDTLS: want to see if we ever get
here */
+/*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever
get here */
return (ssl3_write_pending(s, type, buf, len));
}
diff -Naur openssl-1.0.2g/ssl/dtls1.h openssl/ssl/dtls1.h
--- openssl-1.0.2g/ssl/dtls1.h2016-03-01 14:35:53.0 +0100
+++ openssl/ssl/dtls1.h2016-03-08 14:39:44.0 +0100
@@ -225,8 +225,8 @@
* Indicates when the last handshake msg or heartbeat sent will
timeout
*/
struct timeval next_timeout;
-/* Timeout duration */
-unsigned short timeout_duration;
+/* Timeout duration in Seconds */
+double timeout_duration;
/*
* storage for Alert/Handshake protocol data received but not yet
* processed by ssl3_read_bytes:
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4474] Overflow optimizations being taken by GCC
It looks like a lot of these warnings are bogus. For example ct_validation is only ever set to 0 or 1 yet it throws out a warning with if(ct_vlidation) in one place while not warning about a similar expression just above it. I tidied up ocsp_prn.c which avoided the warning in that file: though again it didn't seem to be genuine. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4474 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 #4548] s390x build problem
>>> I'm getting:
>>> crypto/chacha/chacha-s390x.S: Assembler messages:
>>> crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'
>>>
>>>
>>> A full build log is available on:
>>> https://buildd.debian.org/status/fetch.php?pkg=openssl=s390x=1.1.0~pre5-1=1464594754
>>
>> It's overly easy to get carried away if you have access to single
>> system. Double-check attached.
>
> I made this while I did not notice this earlier:
> https://github.com/openssl/openssl/pull/1146
>
> It fixes the chacha thing + memcpy.
Thanks!!! There is couple of problems with suggested modifications
though. First general comment. While 31-bit is arguably not very
fashionable, bugs are still reported at occasions. Important to keep in
mind that 31-bit build still requires z/Arch processor *and* highgprs
kernel feature, i.e. target is not s390 systems (note lack of x), but
64-bit processor running 64-bit OS, just running legacy *process*. Goal
also is to minimize deviations and "parametrize", so that most of the
code is constantly "exposed" to assembler. That's what are those ${g}
things are and that's why #if clauses are limited to clearing most
significant 32 bits of registers. This means that suggestion to
introduce big #if in CRYPTO_memcmp is not considered favourable.
Adhering to non-extension instructions is. Another problem is with
suggested ltgr in chacha-s390x. It has to be "parametrized", i.e. look
as lt${g}r. Because in 31-bit build there is no guarantee that most
significant 32-bit of $len register are actually zero-ed. In other words
could you double-check attached patch instead?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548
Please log in as guest with password guest if prompted
commit d11ca41a907ce6465e688cbfe548e21c0db94311
Author: Andy Polyakov
Date: Mon May 30 22:16:31 2016 +0200
s390x assembly pack: improve portability.
Some of the instructions used in latest additions are extension
ones. There is no real reason to limit ourselves to specific
processors, so [re-]adhere to base ISA set.
diff --git a/crypto/chacha/asm/chacha-s390x.pl b/crypto/chacha/asm/chacha-s390x.pl
index c7a2692..c315264 100755
--- a/crypto/chacha/asm/chacha-s390x.pl
+++ b/crypto/chacha/asm/chacha-s390x.pl
@@ -147,7 +147,8 @@ $code.=<<___;
.type ChaCha20_ctr32,\@function
.align 32
ChaCha20_ctr32:
- cl${g}ije $len,0,.Lno_data # $len==0?
+ lt${g}r $len,$len # $len==0?
+ bzr %r14
a${g}hi $len,-64
l${g}hi %r1,-$frame
stm${g} %r6,%r15,`6*$SIZE_T`($sp)
@@ -279,7 +280,6 @@ $code.=<<___;
stmg %r0,%r3,$stdframe+4*12($sp)
lm${g} %r6,%r15,`$frame+6*$SIZE_T`($sp)
-.Lno_data:
br %r14
.align 16
diff --git a/crypto/s390xcpuid.S b/crypto/s390xcpuid.S
index df7b35a..a292d10 100644
--- a/crypto/s390xcpuid.S
+++ b/crypto/s390xcpuid.S
@@ -137,9 +137,9 @@ CRYPTO_memcmp:
je .Lno_data
.Loop_cmp:
- llc %r0,0(%r2)
+ llgc %r0,0(%r2)
la %r2,1(%r2)
- llc %r1,0(%r3)
+ llgc %r1,0(%r3)
la %r3,1(%r3)
xr %r1,%r0
or %r5,%r1
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4554] Bug: psk argument of the s_client/s_server command strips leading zero bytes.
In s_client.c (function psk_client_db), the "-psk" value is converted
from hexadecimal to binary by converting to a BN using BN_hex2bn() [line
285] and then from BN to binary using BN_bn2bin [line 301].
This means that it is not possible to input a key where the first byte
is zero.
e.g.
If the user specifies "-psk 00010203". BN_hex2bin converted this to
0x10203. BN_bn2Bin converted this to { 0x01, 0x02, 0x03 } where
on the specified { 0x00, 0x01, 0x02, 0x03 }.
The same problem seems to exist in s_server.c. This has probably not be
detected in testing as given the same "-psk" values s_server and
s_client produce the same key.
I found this in 1.1.0-pre5. It is at least as old as 1.0.1e, and seems
to date from the addition of the PSK code.
--
Ian Miller
Senior Software Engineer
ADDER Technology
Saxon Way
Bar Hill
Cambridge
CB23 8SL
United Kingdom
Europe Head Office
Tel: +44 (0)1954 780044
Fax: +44 (0)1954 780081
Web: www.adder.com
-
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify your system
manager. Any views expressed in this message are those of
the individual sender and not necessarily those of Adder Technology Limited.
Adder Technology Limited is a company registered in England and Wales with
company number 1823478 and VAT number GB 388 8704 87 and
registered office address 110 Regent Road, Leicester LE1 7LT, UK. Adder
Corporation is a company registered in Delaware, United States of
America with a trading address of 350R Merrimac Street, Newburyport, MA 01950.
-
This footnote confirms that this email message has been swept for the presence
of computer viruses, however, you should make no reliance
upon this when opening this message or any attachments.
-
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4554
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] Null Ciphers in FIPS mode
On Wed, Jun 01, 2016, Mody, Darshan (Darshan) wrote: > > Does Openssl allows NULL ciphers when we put openssl in FIPS mode? > If you mean NULL ciphersuites then yes though they're not enabled by default just like non-FIPS mode. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] 1.1 release being delayed
When it is expected to release now? Regards Nikhil -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Salz, Rich Sent: Monday, May 23, 2016 6:46 PM To: openssl-dev@openssl.org; openssl-us...@openssl.org Subject: [openssl-dev] 1.1 release being delayed ... in case you haven't noticed :) Our announced release date for 1.1 has come and gone. We want to close many more bugs before we release it. In the meantime, please test against master or a daily snapshot or the last beta release. Thanks for your patience! -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz -- 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
