12:13 PM, Daniel Mentz wrote:
I can't get DTLS working with the current CVS version. When I run
./openssl s_client -dtls1
against
./openssl s_server -dtls1
I get
14710408:error:1408C06F:SSL routines:SSL3_GET_FINISHED:bad digest
length:s3_both.c:264:
on the server side.
Is somebody worki
I can't get DTLS working with the current CVS version. When I run
./openssl s_client -dtls1
against
./openssl s_server -dtls1
I get
14710408:error:1408C06F:SSL routines:SSL3_GET_FINISHED:bad digest
length:s3_both.c:264:
on the server side.
Is somebody working on that? I should point out th
Robin Seggelmann via RT wrote:
> #define RSMBLY_BITMASK_IS_COMPLETE(bitmask, msg_len, is_complete) { \
> + if (is_complete) for (ii = (((msg_len) - 1) >> 3) - 1;
> ii > 0 ; ii--) \
I'm wondering if there are two issues with this for loop:
1. It fails to check if bitmask[0]
Robin Seggelmann via RT wrote:
> + for (ii = (((start) >> 3) + 1); ii < (((end -
> 1)) >> 3); ii++) bitmask[ii] = 0xff; \
I guess there's a minor mistake:
I recommend to replace
(((end - 1)) >> 3)
with
(((end) - 1) >> 3)
-Daniel
_
Robin Seggelmann via RT wrote:
To handle handshake message timeouts properly, DTLS sets the socket timeouts
according to the currently remaining time until the next timeout occurs.
However, in some cases this doesn't work because the operating system returns
the socket call a few milliseconds
dtls1_process_out_of_seq_message() has two bugs:
- Only one handshake message fragment per sequence number is saved.
However, there may be multiple fragments with identical sequence
numbers. All of them should be buffered.
- Fragments with zero length are not saved. This is incorrect behavior
d1_pkt.c:dtls1_get_record() processes DTLS records which it gets from
the wire. At the same time, this function performs replay protection: It
memorizes the (explicit) sequence numbers of the records and drops
records that have already been processed.
The sequence numbers of the processed recor
I believe there's an error in man page BIO_should_retry(3).
BIO_get_retry_reason() IMHO does NOT return a mask of the cause of a
retry condition, but BIO_retry_type() does.
Index: BIO_should_retry.pod
===
RCS file: /v/openssl/cvs/op
I read Eric Rescorla's
An Introduction to OpenSSL Programming (Part II)
and learned about the i/o discipline you have to implement if you are
using OpenSSL with non-blocking i/o. The paper talks about which file
descriptors you have to include in your select() calls.
Check out section "6 Mul
to the user.
> So I changed that check to an assertion. An updated patch is
> attached.
>
> Thanks for testing the patch.
>
> Best regards
> Michael
>
>
>
>
> On Aug 13, 2009, at 12:34 PM, Daniel Mentz wrote:
>
>> Michael Tuexen via RT wrote:
>
Michael Tuexen via RT wrote:
the attached patch fixes a bug where a single user message
was distributed over multiple DTLS records.
Dear Michael,
thanks for the patch. My app runs smoothly now.
I'm wondering if we can get rid of the redundant if statement that checks
if (len > SSL3_RT_MAX_PL
ysctl variable.
More comments in-line.
Best regards
Michael
On Aug 10, 2009, at 10:21 AM, Daniel Mentz wrote:
In my understanding DTLS should provide UDP semantics when run over
the later. That is if a user message is too large in terms of the PMTU
it should either be silently discarded or the s
In my understanding DTLS should provide UDP semantics when run over the
later. That is if a user message is too large in terms of the PMTU it
should either be silently discarded or the sender should be notified by
an error message similar to "Message too big".
In no event should the message be
Dear Michael,
I've got some concerns regarding your patch:
Michael Tuexen via RT wrote:
I have looked at the patch provided by Daniel. All suggested changes are
OK, but there are two additional things which should be fixed:
1. In ssl3_read_n() the argument max is overwritten before used.
I d
Dear Michael,
I've got some concerns regarding your patch:
Michael Tuexen via RT wrote:
> I have looked at the patch provided by Daniel. All suggested changes are
> OK, but there are two additional things which should be fixed:
>
> 1. In ssl3_read_n() the argument max is overwritten before used.
ssl3_read_n() was conceived to read blocks of data from a byte oriented
stream. This can be easily explained by an example: You call
ssl3_read_n() with the a parameter like "Read 50 bytes of data". As
opposed to the read() function provided by the OS, ssl3_read_n() makes
sure you really get 50
dtls1_read_bytes() uses dtls1_get_record() to get a record from the
wire. There's an agreement between those two functions that says that
ssl->s3->rrec.length contains the length of the record just read. If
ssl->s3->rrec.length equals 0 then there's no record in the buffer.
dtls1_get_record() f
This is a bug report.
Version: openssl-1.0.0-beta2
OS: Ubuntu 9.04, Linux 2.6.28-11-generic #42-Ubuntu SMP
When I run
./openssl s_server -dtls1 -no_ecdhe -timeout -cert large.pem
against
./openssl s_client -dtls1
I'll get a Segmentation fault on the client side. I attached the
certificate (in
r at least print out a log
message saying "No DTLS support for ECDHE"
Thanks
Daniel Mentz
__
OpenSSL Project http://www.openssl.org
Development Mailing List ope
19 matches
Mail list logo
