On 28 Aug 2015, at 22:52, Ken Ballou via RT r...@openssl.org wrote:
I originally found this in version 1.0.1e, but this also appears to be
present in the latest master branch of the git repository.
If a DTLS server has been configured to require a cookie exchange, it
appears the server
Dear all,
the attached patch solves the reported issue. With the attached patch all tests
in
the test directory pass using openssl configured with sctp support.
Tested on Ubuntu 14.04 and Mac OS X.
Best regards
Michael
BIO_dgram_is_sctp.patch
Description: Binary data
Dear all,
the attached patch solves the reported issue. With the attached patch all tests
in
the test directory pass using openssl configured with sctp support.
Tested on Ubuntu 14.04 and Mac OS X.
Best regards
Michael
BIO_dgram_is_sctp.patch
Description: Binary data
On 15 Jun 2015, at 10:35, Matt Caswell m...@openssl.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/06/15 14:43, Hanno Böck wrote:
Serious question: Is there any valid use case for heartbeats in TLS
or DTLS? (With valid use case I mean something like I use it for
this
-Original Message-
From: Michael Tüxen via RT [mailto:r...@openssl.org]
Sent: Wednesday, August 27, 2014 3:33 PM
To: Brian Hassink
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #3470] [BUG] DTLS abort
On 18 Aug 2014, at 21:47, Michael Tuexen michael.tue...@lurchi.franken.de
wrote
On 18 Aug 2014, at 21:47, Michael Tuexen michael.tue...@lurchi.franken.de
wrote:
On 18 Aug 2014, at 16:31, Brian Hassink brian.hass...@oracle.com wrote:
Yes, this was observed for DTLS/SCTP.
OK. The problem is an incorrect usage of OPENSSL_assert()... Let me see if I
can
come-up
On 08 Aug 2014, at 15:54, Martin Brejcha via RT r...@openssl.org wrote:
Hello,
When I run our application in valgrind it shows memory leak in
dgram_sctp_write:1262.
Our application using openssl-1.0.1 for DTLS over sctp.
The issue seems to be in sending of shutdown alarm. When shutdown
On 18 Aug 2014, at 16:31, Brian Hassink brian.hass...@oracle.com wrote:
Yes, this was observed for DTLS/SCTP.
OK. The problem is an incorrect usage of OPENSSL_assert()... Let me see if I can
come-up with a patch...
Best regards
Michael
-Brian
-Original Message-
From: Michael
On 14 Aug 2014, at 20:27, Tobias Herre 7...@mail.ru wrote:
Hello,
maybe I miss something ...
But there seems to be no way to change the initial timeout
duration for DTLSv1. It's value is set to one second, and it's
hard-coded in d1_lib.c in function dtls1_start_timer.
The problem is I
On 22 Jul 2014, at 23:32, Brian Hassink via RT r...@openssl.org wrote:
OpenSSL: 1.0.1e
OS: Red Hat Enterprise Linux Server release 6.5
(Santiago)
Hello,
We recently did some negative testing against OpenSSL 1.0.1e, with a focus on
DTLS,
On 05 Aug 2014, at 09:18, Jan Hykel via RT r...@openssl.org wrote:
Hello,
OpenSSL (1.0.1h and older) contains following problematic part of code in
/crypto/bio/bss_dgram.c, dgram_sctp_read():
---
static int dgram_sctp_read(BIO *b, char *out, int outl)
{
int ret = 0, n = 0, i,
On 25 May 2014, at 23:29, Kurt Roeckx k...@roeckx.be wrote:
On Sun, May 25, 2014 at 10:20:03PM +0200, Michael Tuexen wrote:
I'm just a bit hesitating to invest more time given that
the patch wasn't accepted the last four years... If there is interest,
I would be happy to update it to include
On 27 May 2014, at 10:01, Krzysztof Kwiatkowski krzys...@leeds.pl wrote:
On Tue, 2014-05-27 at 09:18 +0200, Michael Tuexen wrote:
Please do update it.
I guess that patch should be against the master branch, right?
(the current patch doesn't apply there...)
That what I was thinking about
On 25 May 2014, at 23:29, Kurt Roeckx k...@roeckx.be wrote:
On Sun, May 25, 2014 at 10:20:03PM +0200, Michael Tuexen wrote:
I'm just a bit hesitating to invest more time given that
the patch wasn't accepted the last four years... If there is interest,
I would be happy to update it to include
On 25 May 2014, at 19:30, Kurt Roeckx k...@roeckx.be wrote:
On Sun, May 25, 2014 at 02:40:08PM +0200, Krzysztof Kwiatkowski wrote:
Hi,
In general yes, but it seems s_client (https://lwn.net/Articles/486369/)
doesn't support IPv6 (or I'm wrong?)
There is a patch for it at:
On 25 May 2014, at 22:02, Viktor Dukhovni openssl-us...@dukhovni.org wrote:
On Sun, May 25, 2014 at 09:24:32PM +0200, Michael Tuexen wrote:
On 25 May 2014, at 19:30, Kurt Roeckx k...@roeckx.be wrote:
On Sun, May 25, 2014 at 02:40:08PM +0200, Krzysztof Kwiatkowski wrote:
Hi,
In general
On 15 Apr 2014, at 14:26, Fedor Indutny fe...@indutny.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Hanno!
Despite not a being an active community member, I'd like to share my thoughts
on it, if you don't mind.
I certainly agree that this extension has a quite faulty
On 15 Apr 2014, at 16:43, Hanno Böck ha...@hboeck.de wrote:
On Tue, 15 Apr 2014 14:35:36 +0200
Michael Tuexen michael.tue...@lurchi.franken.de wrote:
On 15 Apr 2014, at 14:26, Fedor Indutny fe...@indutny.com wrote:
I certainly agree that this extension has a quite faulty
specification
On 15 Apr 2014, at 18:23, Richard Könning richard.koenn...@ts.fujitsu.com
wrote:
Am 15.04.2014 14:35, schrieb Michael Tuexen:
On 15 Apr 2014, at 14:26, Fedor Indutny fe...@indutny.com wrote:
Hello Hanno!
Despite not a being an active community member, I'd like to share my
thoughts
On 13 Apr 2014, at 17:48, David Jacobson dmjacob...@sbcglobal.net wrote:
On 4/13/14 3:54 AM, Michael Tuexen wrote:
On 13 Apr 2014, at 01:54, tolga ceylan tolga.cey...@gmail.com wrote:
The RFC has a lot of statements about silently dropping packets in case of
various anomalies
On 13 Apr 2014, at 01:54, tolga ceylan tolga.cey...@gmail.com wrote:
The RFC has a lot of statements about silently dropping packets in case of
various anomalies. But the correct action should be to drop the connection.
This would uncover faulty implementations and other bugs that may
This patch ensures that
* A HelloRequest is retransmitted if not responded by a ClientHello
* The HelloRequest consumes the sequence number 0. The subsequent
ServerHello uses the sequence number 1.
* The client also expects the sequence number of the ServerHello to
be 1 if a HelloRequest was
This patch ensures that
* A HelloRequest is retransmitted if not responded by a ClientHello
* The HelloRequest consumes the sequence number 0. The subsequent
ServerHello uses the sequence number 1.
* The client also expects the sequence number of the ServerHello to
be 1 if a HelloRequest was
On Aug 11, 2013, at 3:33 PM, The default queue via RT r...@openssl.org wrote:
Greetings,
This message has been automatically generated in response to the
creation of a trouble ticket regarding:
[openssl.org #3041[PATCH] DTLS message_sequence number wrong in
rehandshake ServerHello
On Apr 10, 2013, at 1:19 PM, Balakumaran Kannan wrote:
On Tue, Apr 9, 2013 at 10:13 PM, Mike Frysinger via RT r...@openssl.org
wrote:
i've improved the original patch to make the -4/-6 behavior consistent across
the tools. i also tweaked the behavior slightly to make it run correctly
On Mar 28, 2013, at 12:22 AM, Daniel Caiafa wrote:
tl;dr: I've been looking into an issue in my product (uses DTLS) for the last
couple of days. Tracked it down to a CHANGE_CIPHER_SPEC being processed too
early causing the handshake to never complete.
Details:
- OpenSSL version 1.0.1c
On Mar 6, 2013, at 11:11 PM, Prashant Jaikumar wrote:
Hello,
I am seeing an issue where my DTLS server spins in a tight loop when
it receives an application data packet before the DTLS handshake.
I am using the sample code provided at
http://sctp.fh-muenster.de/dtls-samples.html. The
On Mar 6, 2013, at 11:58 PM, igenyar wrote:
Hi,
Has anyone tried this combination? Or, is DTLS compatible with epoll?
My test, after replacing select() with epoll in dtls_udp_echo.c, shows that it
may work properly. Is there anything particular about select() that DTLS
relies
on? I
On Mar 6, 2013, at 1:19 PM, Gary Grebus via RT wrote:
I have an application which needs to protect datagram traffic, and
also directly control the socket I/O. Using DTLS over a BIO pair
appears to work for my purposes except for one problem when handling timeouts.
In
On Mar 6, 2013, at 4:27 PM, Gary Grebus wrote:
On 03/06/2013 09:54 AM, Michael Tuexen wrote:
On Mar 6, 2013, at 1:19 PM, Gary Grebus via RT wrote:
I have an application which needs to protect datagram traffic, and
also directly control the socket I/O. Using DTLS over a BIO pair
appears
On Feb 22, 2013, at 6:24 AM, saurav barik wrote:
Hello,
I am trying to implement TLS security (in the client side) over a UDP
connection. I have a parallel TCP connection(to the same server) over
which TLS is already done and it works fine. In the same session of my
application I am
On Nov 1, 2012, at 2:14 PM, Bojan Pisler wrote:
Hello,
I’m doing interop testing with our DTLS server and OpenSSL. I’m using OpenSSL
version “OpenSSL 1.0.1c 10 May 2012” with the following command line.
openssl s_client -msg -debug -connect 127.0.0.1:9683 -dtls1 -cert client.pem
On Jun 12, 2012, at 5:13 PM, Andy Polyakov wrote:
This patch adds the BIO_CTRL_DGRAM_SET_DONT_FRAG option for
BIO_ctrl() to activate the Don't Fragment bit for the current socket,
if possible on the platform.
This a necessary feature to realize a Path MTU Discovery with
Heatbeats and to
On Jun 11, 2012, at 8:21 AM, Tomas Mraz via RT wrote:
On Sun, 2012-06-10 at 18:04 +0200, Michael Tuexen wrote:
On Jun 10, 2012, at 4:03 PM, Andy Polyakov wrote:
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so
On Jun 11, 2012, at 10:47 AM, Andy Polyakov wrote:
At least this is what I normally use. The type of *option_value
might be platform dependent, but then we need some #ifdefs for
platforms.
But the choice is still between 32- and 64-bit integers. And if so,
you can distinguish among them at
On Jun 11, 2012, at 4:36 PM, Andy Polyakov wrote:
On side note. Looking at first getsockopt in bss_dgram.c. In non-Windows
case it passes pointer to timeval and says it's sizeof(int) large... How
would non-Windows BIO_CTRL_DGRAM_GET_RECV_TIMEOUT work when ret is
initialized to 1?
Consider
On Jun 11, 2012, at 4:59 PM, Andy Polyakov via RT wrote:
This patch adds the BIO_CTRL_DGRAM_SET_DONT_FRAG option for
BIO_ctrl() to activate the Don't Fragment bit for the current socket,
if possible on the platform.
This a necessary feature to realize a Path MTU Discovery with
Heatbeats
On Jun 10, 2012, at 2:09 PM, Andy Polyakov wrote:
Hi Thomas,
we'll have a look at the issue. We are looking into MTU stuff anyway...
Best regards
Michael
On Jun 9, 2012, at 4:10 AM, Tomas Mraz via RT wrote:
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of
On Jun 10, 2012, at 4:03 PM, Andy Polyakov wrote:
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so critical
problem however on big endian 64 bit systems it means the interpretation
of the returned value by the code
On Jun 10, 2012, at 4:03 PM, Andy Polyakov wrote:
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so critical
problem however on big endian 64 bit systems it means the interpretation
of the returned value by the code
Hi Thomas,
we'll have a look at the issue. We are looking into MTU stuff anyway...
Best regards
Michael
On Jun 9, 2012, at 4:10 AM, Tomas Mraz via RT wrote:
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so critical
thanks,
manish
On Thu, Mar 15, 2012 at 6:16 PM, Michael Tuexen
michael.tue...@lurchi.franken.de wrote:
On Mar 15, 2012, at 1:08 PM, Manish Yadav wrote:
Hi Michael, Robin,
i had a basic doubt, suppose i have dtls client (ip address:cip, source
port: cport) and dtls server (ip address
with this?
The attacker also needs to know the master secret to get the server to accept
the packet...
Best regards
Michael
thanks,
manish
On Sun, Feb 5, 2012 at 5:01 PM, Michael Tuexen
michael.tue...@lurchi.franken.de wrote:
On Feb 5, 2012, at 10:25 AM, Manish Yadav wrote:
Hi Michael
sure that a fix like yours makes it into 1.0.1.
Best regards
Michael
Regards,
Z
From: Michael Tuexen [michael.tue...@lurchi.franken.de]
Sent: Friday, February 24, 2012 7:49 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl.org #2730] [PATCH
On Feb 24, 2012, at 5:47 PM, Arpadffy Zoltan via RT wrote:
Hello,
Please find the included patch that solves [openssl.org #2670] [BUG] OpenSSL
1.0.1 beta 1 released (on VMS FAILED)
TITAN2_ZAY $ diff USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;1
On Feb 24, 2012, at 5:47 PM, Arpadffy Zoltan via RT wrote:
Hello,
Please find the included patch that solves [openssl.org #2670] [BUG] OpenSSL
1.0.1 beta 1 released (on VMS FAILED)
TITAN2_ZAY $ diff USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;1
, Michael Tuexen wrote:
On Jan 25, 2012, at 2:21 PM, Manish Yadav wrote:
Hi Michael,
thanks for quick response. i had one more question, is it possible to do
decoupling of ssl object and socket fd to avoid rehandshake? (i am
thinking to create socketfd only for active clients
On Jan 25, 2012, at 7:08 AM, Manish Yadav wrote:
Hi all,
could you please confirm if dtls timers are implemented at client side only
and not on server side (only client retries/attempts to establish connection)
or why they should be implemented on server side also.
You need timers on the
? is it possible based on error value from
DTLSv1_listen to tell if i received hello message or invalid message or
invalid hello message/wrong cookie.
I don't think so. Robin?
thanks,
manish
On Wed, Jan 25, 2012 at 3:24 PM, Michael Tuexen
michael.tue...@lurchi.franken.de wrote:
On Jan 25
On Jan 1, 2012, at 12:39 AM, Florian Weimer wrote:
* Michael Tuexen:
I don't know. But you need a socket per peer and might use select()
for multiplexing which might also introduce some limits.
Do you really need one socket per peer? Why?
The implementation of DTLS is derived from
AM, Michael Tuexen
michael.tue...@lurchi.franken.de wrote:
On Dec 26, 2011, at 7:09 PM, Manish Yadav wrote:
Hi all,
i am building dtls server using OpenSSL v0.9.8r. i see following crash in
openssl code:
Whenever you are using DTLS: Upgrade to the latest version OpenSSL 1.0.0
On Dec 26, 2011, at 7:09 PM, Manish Yadav wrote:
Hi all,
i am building dtls server using OpenSSL v0.9.8r. i see following crash in
openssl code:
Whenever you are using DTLS: Upgrade to the latest version OpenSSL 1.0.0.
Please report if your problem persists with the latest version of
On Dec 26, 2011, at 8:25 PM, Stephen Henson via RT wrote:
[seggelm...@fh-muenster.de - Fri Dec 23 09:04:52 2011]:
Updated version with less defines and without breaking binary
compatibility.
Thank you. We've only got one SSL_OP flag left. Would it be possible to
use an alternative to
On Sep 16, 2011, at 12:51 PM, Paul Witty wrote:
On 15/09/11 18:12, Michael Tuexen wrote:
Hi Paul,
I think this is what Robin found. Could you give the patch provided by Robin
in
http://rt.openssl.org/Ticket/Display.html?id=2602
a try? It should fix your issue.
It does indeed; the code
On Sep 15, 2011, at 6:57 PM, Paul Witty wrote:
The code which reproduces the crash (not necessarily minimal):
SSL_CTX * dtls_context = SSL_CTX_new(DTLSv1_method());
SSL_CTX_set_read_ahead(dtls_context, 1);
SSL_CTX_set_cipher_list(dtls_context, DEFAULT:!LOW:!EXP:!MD5);
On Jul 23, 2011, at 3:14 AM, Yogesh Chopra wrote:
Hi,
While testing DTLS on windows ran into the following problem with scenario
described as below:
Does the same happen when running the server on Linux?
Robin will look into this on Monday.
Best regards
Michael
There are 2 problems:
The attached patch fixes 1.0.0-stable and 1.0.1-stable such that
BIO_new_accept(8080)
will bind an IPv4 or IPv6 socket, which depends on the system.
stable-0.9.8 would use an IPv4 socket.
BIO_new_accept(::8080)
will bind an IPv6 socket.
BIO_new_accept(*:8080)
will bind an IPv4 socket.
Best
On Apr 28, 2011, at 6:18 PM, N. J. wrote:
Hi Michael,
Just tried it with my 1.0.0a code and Robin's patch. It is the same behaviour
when using -reconnect:
1. The client connects to the server and completes the first DTLS handshake
successfully.
2. The client sends and encrypted alert
Looks good to me.
Thanks for fixing it.
Best regards
Michael
On Oct 15, 2009, at 8:50 PM, Stephen Henson via RT wrote:
[steve - Thu Oct 15 20:37:17 2009]:
Erk, this breaks Win32 builds. The type in_port_t is not defined,
that
may be true of other platforms too.
I've committed a fix
Here is an updated patch which compiles without warnings on gcc 4.4.
It only patches the applications and requires the updated patch
for #2069.
Best regards
Michael
appsv6.patch
Description: Binary data
On Sep 23, 2009, at 8:39 AM, The default queue via RT wrote:
Greetings,
This
Here is an updated patch. It uses the union pattern to deal with
sockaddr_storage. It compiles without warnings on gcc 4.4.
Best regards
Michael
dtlsv6.patch
Description: Binary data
On Oct 3, 2009, at 10:44 AM, The default queue via RT wrote:
Greetings,
This message has been
This patch fixes an warning on platforms not defining OPENSSL_USE_IPV6.
Best regards
Michael
appsv6.patch
Description: Binary data
On Sep 23, 2009, at 8:39 AM, The default queue via RT wrote:
Greetings,
This message has been automatically generated in response to the
creation of a
Dear all,
this patch fixes the address handling in the DTLS code to support
IPv6.
Best regards
Michael
dtlsv6.patch
Description: Binary data
Hi Arkadiusz,
by looking at the OpenSSL code I think it supports some
legacy platforms which have very limited support. So I
prefer not to break them and this is done most easily by
by not touching the code for platforms not defining
OPENSSL_USE_IPV6.
For OpenSSH thinks might be different, I do
This patch adds support for IPv6 for s_client and s_server and
fixes the IPv6 handling for DTLS.
s_server will listen on IPv4 and IPv6 as default. When using -4
as an argument, it will listen only on IPv4, when using -6 as
an argument, it will listen only on IPv6.
The client will use IPv4 as
Dear all,
the attached patch fixes the handling of error cases:
* For dgram bios use always BIO_dgram_should_retry() instead
of BIO_scok_should_retry().
* ENOTCONN is a fatal error.
* EMSGSIZE is a fatal error, not related to path MTU.
Thanks to Daniel Mentz, who pointed out the incorrect
I'm also working on IPv6 support (also for the openssl s_client and
s_server apps). I use code like
#if OPENSSL_USE_IPV6
struct sockaddr_storage server, client;
#else
struct sockaddr_in server, client;
#endif
This should be portable.
Best regards
Michael
On Sep 18, 2009, at
Hi Robin,
the problem is that the variable LIBDIR is not set. The
attached patch fixes the problem.
Best regards
Michael
Makefile.org.patch
Description: Binary data
On Aug 23, 2009, at 3:22 PM, Robin Seggelmann via RT wrote:
When configuring OpenSSL with ./config shared
errors from that code path to the user.
So I changed that check to an assertion. An updated patch is
attached.
Thanks for testing the patch.
Best regards
Michael
fragmentation1.patch
Description: Binary data
On Aug 13, 2009, at 12:34 PM, Daniel Mentz wrote:
Michael Tuexen via RT wrote
Dear all,
the attached patch fixes a bug where a single user message
was distributed over multiple DTLS records.
Best regards
Michael
fragmentation.patch
Description: Binary data
When using s_client and s_server with DTLS and the -msg arg,
the message types are not printed.
This fixes adds support in the corresponding callback for
printing DTLS message types.
s_cb.c.patch
Description: Binary data
Dear all,
I agree with Daniel that reading a record from multiple UDP packets
is a bug. I need some time to figure out if the proposed fix is the
right one.
Robin is on holiday for two weeks.
Best regards
Michael
On Jul 8, 2009, at 10:15 PM, Daniel Mentz wrote:
ssl3_read_n() was conceived to
Dear all,
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.
2. If additional data is behind a valid DTLS record in the UDP packet,
it is
Dear all,
please find attached a patch which adds support for ECDHE and PSK
support for DTLS as requested by Stephen.
The diff is against openssl-1.0.0-beta2.
Stephen: Please let me know if you have any issues with the patch.
Best regards
Michael
dtls.patch
Description: Binary data
On
Dear all,
please find attached in in-lined an updated version of the patch
for the path MTU detection.
The library stores the maximum DTLS packet size and converts to
that when using the example programs which run only over IPv4
and UDP.
On Linux the path MTU infrastructure is used, which is
75 matches
Mail list logo
