Hi Daniel,
the check in dtls1_write_app_data_bytes() protects against users
sending messages which are too long. An appropriate error is
signaled.
dtls1_write_bytes() is also call from DTLS internal routines
and I want to catch also error from that code path. But it might
be better not to signal
Hi
Can anone please clarify this data with OPENSSL 0.9.8i:
RSA uses key ranges from 768-2048 and can operate only in CBC mode
DSA uses key length of 1024 and operates only in CBC
Thanks and Regards,
Sudarshan
__
OpenSSL Project
Alright. Sounds good. Thanks. I checked the new version of the patch and
I do endorse it.
Just in case anybody is wondering why the patch removes the following
code segment:
/* next chunk of data should get another prepended empty fragment
* in ciphersuites with known-IV weakness: */
s->s3->e
Hi list,
this is my first post. My name is Alfredo and I'm a PhD student at
Cambridge University, UK. In my research project we automatically
generate monitor implementations for standard protocols. In particular
we are focussing on the session initialization of SSLv3. We believe
our monitor coul
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
On Aug 12, 2009, at 3:23 PM, Stephen Henson via RT wrote:
>> [seggelm...@fh-muenster.de - Wed Aug 12 08:34:27 2009]:
>>
>>
>> Ok, here's an updated version. Internally is dtls1_get_timeout() and
>> dtls1_handle_timeout() used. They can be called externally using
>> SSL_ctrl() with DTLS_CTRL_GET_TI
