Re: [openssl-dev] [openssl.org #4025] Bug? DTLS server does not respond if HelloVerifyRequest message lost
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 never retransmits the HelloVerifyRequest message if the client sends another ClientHello with sequence number zero and no cookie. But, this means that if the HelloVerifyRequest message from the server is lost (it's UDP, so anything can happen), the client will never be able to connect. Is this intentional behavior? I can imagine this may be an attempt to thwart a DoS attack, but it seems the attacker has to do as much work as the system under attack by resending the ClientHello again. The server isn't retransmitting the HelloVerifyRequest message, the client should retransmit the ClientHello. See https://tools.ietf.org/html/rfc6347#section-3.2.1 Best regards Michael I am attaching source code (in C) for a small (single source file) test program to reproduce this. The test program uses separate read and write datagram BIOs to simulate a lost UDP datagram. After the program sends the initial ClientHello and fails to read the HelloVerifyRequest, the user is prompted to press enter. When the user does so, the program replaces the read BIO in the SSL object with the correct BIO and retries SSL_connect. In a wireshark trace, one can see that the server never resends the HelloVerifyRequest in reply. (Pass the server IP address and port as command line parameters.) I have tested this with openssl s_server running on localhost: % ./apps/openssl version OpenSSL 1.1.0-dev xx XXX % ./apps/openssl s_server -cert keycert.pem -accept -dtls1 Then: % test-lost-helloverifyrequest 127.0.0.1 - Ken test-lost-helloverifyrequest.c___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ 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
[openssl-dev] [openssl.org #4004] Patch resolving the issue
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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4004] Patch resolving the issue
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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3908] Patch fixing some heartbeat issues (vs latest git master)
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 system, not answers like you could use it for xy) I had always understood the argument in favour of heartbeat for DTLS to be: 1) PMTU discovery 2) Keep-alive functionality I've never heard a good argument for TLS (PMTU is irrelevant for TLS, and TCP provides keep-alive). TCP provides keep-alives, but at a timescale which is not acceptable for all applications. The default to start sending them is an idle time of 2 hours. So applications will need to send their own in some cases, but they can be application messages. Best regards Michael Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVfo5IAAoJENnE0m0OYESRqHEIAJnLGo1qzx+k+qtodZpzQ8M9 fhmsTsZJy6zbVK0lIEcK4Rn/0BEMM0i/0GTYiqHpIduIjR5utNDSfyl3ViYsPP0W e3zjzWAy4L2CjdNLcwbOMAjvTAIxKUJIYtkisT3BN0Pv8zMN19Imqso8CnaWtgG7 0n5QHE9Wx4wSgUI8Wt29q7LoPxnFNf7NOOi++fO8RjE4K+evP2OE7i4oAFk/nlZs m5J+XJ2CVYHkg7uQ4btHLINVt9PBU7GpK58fOQ+3A8VXcXMYLKEwNoB3r7hsB2Uj zvNECHXQFn9sVaj7u2PLNZITn3O1diw88oTe6O9PrSVQKh6+1QCZwU1cW7C9AWg= =zepT -END PGP SIGNATURE- ___ 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
Re: [openssl.org #3470] [BUG] DTLS abort
On 28 Aug 2014, at 17:25, Brian Hassink via RT r...@openssl.org wrote: Hello Michael, We can confirm that the patch resolves the disconnect abort. Great, thanks a lot for the feedback. Let me know if you have further issues with DTLS/SCTP. Best regards Michael Thanks, Brian -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 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... Hi Brian, please find attached a patch which fixes several usages of OPENSSL_assert() and let me know if this resolves your issue. Please note that you want also to apply the patch from http://rt.openssl.org/Ticket/Display.html?id=3483user=guestpass=guest Best regards Michael __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
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 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... Hi Brian, please find attached a patch which fixes several usages of OPENSSL_assert() and let me know if this resolves your issue. Please note that you want also to apply the patch from http://rt.openssl.org/Ticket/Display.html?id=3483user=guestpass=guest Best regards Michael OPENSSL_assert.patch Description: Binary data Best regards Michael -Brian -Original Message- From: Michael Tüxen via RT [mailto:r...@openssl.org] Sent: Thursday, August 14, 2014 6:17 PM To: Brian Hassink Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #3470] [BUG] DTLS abort 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, and observed that the library, running on the peer, could be made to abort by simply disconnecting during the handshake process. The abort is due to a getsockopt() or setsockopt() call failing from within dgram_sctp_read() because the socket descriptor has been rendered invalid by the disconnect. Did you test DTLS/UDP or DTLS/SCTP? Do you really mean dgram_sctp_read()? Best regards Michael We ran the same scenario against TLS, but it is not affected. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3489] [PATCH] DTLS/sctp stored shutdown memory leak
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 alert
is not sent because the socket is not dry, it is stored in bio object,
but when the bio object is freed before this stored alarm can be sent,
the shutdown alarm is not freed.
Possible patch is attached.
The patch looks good to me.
Best regards
Michael
Best regards,
Martin Brejcha
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any attachment
and all copies and inform the sender. Thank you for understanding.
diff -u -u -r openssl-1.0.1i_old/crypto/bio/bss_dgram.c
openssl-1.0.1i_new/crypto/bio/bss_dgram.c
--- openssl-1.0.1i_old/crypto/bio/bss_dgram.c 2014-08-06 23:10:56.0
+0200
+++ openssl-1.0.1i_new/crypto/bio/bss_dgram.c 2014-08-08 13:26:00.307001406
+0200
@@ -982,7 +982,13 @@
return 0;
data = (bio_dgram_sctp_data *)a-ptr;
- if(data != NULL) OPENSSL_free(data);
+ if(data != NULL)
+ {
+ if(data-saved_message.data != NULL)
+ OPENSSL_free(data-saved_message.data);
+
+ OPENSSL_free(data);
+ }
return(1);
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3470] [BUG] DTLS abort
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 Tüxen via RT [mailto:r...@openssl.org] Sent: Thursday, August 14, 2014 6:17 PM To: Brian Hassink Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #3470] [BUG] DTLS abort 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, and observed that the library, running on the peer, could be made to abort by simply disconnecting during the handshake process. The abort is due to a getsockopt() or setsockopt() call failing from within dgram_sctp_read() because the socket descriptor has been rendered invalid by the disconnect. Did you test DTLS/UDP or DTLS/SCTP? Do you really mean dgram_sctp_read()? Best regards Michael We ran the same scenario against TLS, but it is not affected. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS initial timeout duration
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 need to set a higher value, because in a project, I am working on, I am implementing a DTLS server, that has to serve a client, which needs more than one second to send it's own certificate after receiving the server's certficate in DTLS handshake process. When the timeout occurs, the ssl library re-transmist the server's certificate, which confuses the client. Isn't this a problem of the client which has to be fixed anyway? Best regards Michael It would be nice to have that configurable. Regards T. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3470] [BUG] DTLS abort
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, and observed that the library, running on the peer, could be made to abort by simply disconnecting during the handshake process. The abort is due to a getsockopt() or setsockopt() call failing from within dgram_sctp_read() because the socket descriptor has been rendered invalid by the disconnect. Did you test DTLS/UDP or DTLS/SCTP? Do you really mean dgram_sctp_read()? Best regards Michael We ran the same scenario against TLS, but it is not affected. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3483] [BUG] DTLS/sctp crashes sporadically when remote endpoint closes connection
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, optval;
socklen_t optlen;
bio_dgram_sctp_data *data = (bio_dgram_sctp_data *)b-ptr;
union sctp_notification *snp;
struct msghdr msg;
struct iovec iov;
struct cmsghdr *cmsg;
char cmsgbuf[512];
if (out != NULL)
{
clear_socket_error();
do
{
memset(data-rcvinfo, 0x00, sizeof(struct
bio_dgram_sctp_rcvinfo));
iov.iov_base = out;
iov.iov_len = outl;
msg.msg_name = NULL;
msg.msg_namelen = 0;
msg.msg_iov = iov;
msg.msg_iovlen = 1;
msg.msg_control = cmsgbuf;
msg.msg_controllen = 512;
msg.msg_flags = 0;
n = recvmsg(b-num, msg, 0);
if (msg.msg_controllen 0)
{
for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg =
CMSG_NXTHDR(msg, cmsg))
...
...
---
msg structure is accessed even if recvmsg() called previously returned -1
(some error) or 0 (remote endpoint has closed the connection). This can cause
process crash with SIGSEGV, or infinite loop (for (cmsg =
CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)).
We have encountered with this problem during development of proprietary
communication software using OpenSSL/DTLS on RHEL6. But other systems using
OpenSSL DTLS are also affected.
Please have a look at the patch attached, it could solve this issue.
The patch look good to me.
Best regards
Michael
Thank you.
Best Regards,
Jan Hykel
Acision
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any attachment
and all copies and inform the sender. Thank you for understanding.
--- a/openssl-1.0.1h/crypto/bio/bss_dgram.c 2014-06-05 11:44:33.0
+0200
+++ b/openssl-1.0.1h/crypto/bio/bss_dgram.c 2014-07-23 16:48:53.659651003
+0200
@@ -1034,6 +1034,13 @@
msg.msg_flags = 0;
n = recvmsg(b-num, msg, 0);
+ if (n = 0)
+ {
+ if (n 0)
+ ret = n;
+ break;
+ }
+
if (msg.msg_controllen 0)
{
for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg =
CMSG_NXTHDR(msg, cmsg))
@@ -1073,13 +1080,6 @@
}
}
- if (n = 0)
- {
- if (n 0)
- ret = n;
- break;
- }
-
if (msg.msg_flags MSG_NOTIFICATION)
{
snp = (union sctp_notification*) out;
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2578] s_client bind ip
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 documentation changes. Please do update it. I guess that patch should be against the master branch, right? (the current patch doesn't apply there...) Best regards Michael Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2578] s_client bind ip
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. Wouldn't it be less work to apply my patch to master and then apply patch for IPv6 (as it cleanly applies right now)? In such case I won't need to change my patch later. Makes sense. Apply your patch... Let me know once it is in. Looking at your patch: Wouldn't it make sense to allow setting the local port number as well? You could use -bind host:port similar to -connect host:port instead of -localip arg You could also call bind() in any case. Just initialise the address and port number to 0. Best regards Michael __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2578] s_client bind ip
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 documentation changes. Please do update it. Will do. Thanks for the feedback. Best regards Michael Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2578] s_client bind ip
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: https://bugs.debian.org/589520 You could also consider http://rt.openssl.org/Ticket/Display.html?id=2051 Best regards Michael Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2578] s_client bind ip
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 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: https://bugs.debian.org/589520 You could also consider http://rt.openssl.org/Ticket/Display.html?id=2051 I don't see any associated documentation updates with that patch. I would like to see OpenSSL not accept any further patches that increase the gap between features and documentation. Changes to s_client, s_server, ... that add support for IPv6 need to update the documentation for s_client, s_server, ... I agree. 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 documentation changes. Best regards Michael -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL should disable or remove heartbeat
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 specification and very questionable use. But perhaps, instead of just removing it from OpenSSL, we should try to make IETF deprecate it in a spec as well? I don't think there is a problem with the spec. The spec tells you how to deal with packets having a faulty length field. The problem was with the implementation. I think OpenSSL has already a switch to disable the extension at compile time. This is available for a lot of extensions/features. Having also a runtime switch for features (with the default being off) is a possibility. Might be something for other extensions as well. So someone needing a feature needs to write code to enable it. Best regards Michael Cheers, Fedor. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJTTSVtAAoJEPsOEJWxeXmZfDoP/25Eqt9Ec3SCnqOrUaSg9D01 JtNWZ8s8xq0BDdcjSCzeYh3yHPhWK2JbIhxm3t0Dq1vUK+TZtxvBHl6Vr141JioD fM6WBGqr1eA8Htk5RkEC5xcIgDiEMs3xpGmeg0JYWaisPcdF9ChvPL51FII+FPXj V26RJKHQhu+3XBKi3z4pmlJOvQNHaQ4B8EFw66mAfgyAVBXbi/EyHOpuJ0vZ/Z0p WgPBnPSuhe8eu9Gmac440jvx/YHd+feYfjELw/vQiU5mZOCtgIKChu0hgSHQkke+ jTFGTTzBca/3wULAC3VtTFMwHif3bCHuN8GauuvW0NLemB3DslnbEYFCnYXp+vJl Dv6YJOyc2XUOw576La3ZdAgyAvSnFhnGjWodkVZRYZJsXheblJcWhXOoH5TDK5Zq mqIfTtFuPE5J2JplYs+Rgpjpss8F5hJgc1GbsfPqb4qU+VEN3DB0w2BdYBcSWt4B PiANM0OcuaTwWS15KECR+yoItUJwbZyHmqCIsFzHlWNzymD5wr8xdcUtq0HFo8oV B1G6vZXhoHxsB04xusK9kJZPwxbZXFL8hWwyvJprsPVEBD7v7taFHN01cItFXxGR pSWVa0PdJc7JzvAOpJhXKKAqiQtr/cNcAUSl+BGXBkhzFMs5sPYVCXaD0a+01piw jEjk3196JpBMEJOUBDbF =Z4D3 -END PGP SIGNATURE- On Tue, Apr 15, 2014 at 4:17 PM, Hanno Böck ha...@hboeck.de wrote: Hi, I think this question needs to be asked. We have a TLS extension here that - as far as I can see - nobody uses. I have asked in different contexts recently if anyone is aware of real software that makes use of the heartbeat extension. I got often answerts like it could be used for X, but not a single one of them saying there is software Y that does X with it. Also, a search on ohloh turned up nothing. I think there is no justification to have an extension that gets enabled by default around if it is not used. So I propose that openssl either disables it in the default build or removes it completely. I'd suggest the first one if there are reasonable chances that anyone might use it in the future. And: I'd like to see a discussion on what further unused features there are in OpenSSL that could be disabled just to reduce attack surface. E.g. I could think of removing DSA key support, because nobody uses that anyway and DSA is a bad algorithm. cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL should disable or remove heartbeat
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 and very questionable use. But perhaps, instead of just removing it from OpenSSL, we should try to make IETF deprecate it in a spec as well? I don't think there is a problem with the spec. The spec tells you how to deal with packets having a faulty length field. The problem was with the implementation. I disagree. Too many features and too much complexity is a problem in the spec. Unused features is a problem in the spec, because nobody will care to look after them. I don't think the spec is complex... I think it is simple, the problematic case is explicitly mentioned. However, this does not avoid that someone makes a mistake. I think OpenSSL has already a switch to disable the extension at compile time. This is available for a lot of extensions/features. Yes, and it should have sane defaults. Enabling an extension that nobody uses shouldn't happen. So the default of that switch should be off, unless someone has a convincing argument otherwise. Adding features because we can is not helpful and adds attack surface. I guess the default could be always off. This would mean if an application wants a new feature, it has to enable it. So if there is no new code in the application, there is no new behaviour in the (D)TLS stack. Best regards Michael -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL should disable or remove heartbeat
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 it, if you don't mind. I certainly agree that this extension has a quite faulty specification and very questionable use. But perhaps, instead of just removing it from OpenSSL, we should try to make IETF deprecate it in a spec as well? I don't think there is a problem with the spec. The spec tells you how to deal with packets having a faulty length field. The problem was with the implementation. When the spec leads to an unnecessary large implementation then there is a problem with the spec because more source code means in general more errors (there may be deviations from this rule when a more general spec allows to use common source parts). I think OpenSSL has already a switch to disable the extension at compile time. This is available for a lot of extensions/features. At least in this case it would have been better to have a compile time option for *enabling* the extension. Or perhaps two options differentiating between DTLS and TLS would have been even better. Having explicit compile time options for enabling is a possibility, however, I think this is not how it is done in OpenSSL in general. I think there are a lot of OPENSSL_NO_* defines. That is why OPENSSL_NO_HEARTBEATS was used and not the opposite. Having also a runtime switch for features (with the default being off) is a possibility. Might be something for other extensions as well. So someone needing a feature needs to write code to enable it. For people who provide OpenSSL libs for a broad audience with unknown needs a compile time option helps not much, here a runtime option (being off per default) helps to provide a functionality without imposing it on the user. With such an option the Heartbleed bug wouldn't have it made into the major news. Best regards, Richard __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: heartbeat RFC 6520 and silently drop behaviour
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. But the correct action should be to drop the connection. This would uncover faulty implementations and other bugs that may slide due to 'silently drop' behavior. It'll also make malicious activity a bit more difficult and exposed due to the necessity to reestablish connections for any brute force attempts. What is your opinion on this? There are two MUST discards. One is the the payload being reflected doesn't match, the other is the the payload_length is too large. The second one is the critical one for the heartbleed attack. Let us consider this case. It is clear that you don't respond. You could keep the connection or drop it. When dropping it, you give the attacker an immediate indication that you are not vulnerable. So the attacker can move on. If you don't drop the connection, the attacker has to wait until he decides that the stack is not vulnerable. So it takes more resources on his side. However, the crucial point is to follow the MUST and not send the heartbeat response... Best regards Michael Cheers, Tolga Ceylan First, dropping the connect does not comply with the RFC, which says that the heartbeat request MUST be silently discarded. I know (I'm a co-author)... Second, it is debatable as to whether dropping the connection is a good idea. First is contrary to Postel's Law: an implementation should be conservative in its sending behavior, and liberal in its That is what I wanted to say... The crucial point is not to respond with an Heartbeat response. There are arguments for dropping the connections, the are arguments against it. The consensus was for silently discard. I just wanted to make the options clear. receiving behavior. There may be a coding error in some client and the length is 1 byte too large. Now that client can't communicate with the server. The client user can't do whatever he wants to do. The server user may be losing business. Neither of these are responsible for the problem nor can they do anything about it. Second, yes, it makes the attacker do a bit more work. But it is very little, and the attacker can run attacks in parallel, so it doesn't make much difference in this throughput. The difference is not big, agree. Best regards Michael --David Jacobson __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: heartbeat RFC 6520 and silently drop behaviour
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 slide due to 'silently drop' behavior. It'll also make malicious activity a bit more difficult and exposed due to the necessity to reestablish connections for any brute force attempts. What is your opinion on this? There are two MUST discards. One is the the payload being reflected doesn't match, the other is the the payload_length is too large. The second one is the critical one for the heartbleed attack. Let us consider this case. It is clear that you don't respond. You could keep the connection or drop it. When dropping it, you give the attacker an immediate indication that you are not vulnerable. So the attacker can move on. If you don't drop the connection, the attacker has to wait until he decides that the stack is not vulnerable. So it takes more resources on his side. However, the crucial point is to follow the MUST and not send the heartbeat response... Best regards Michael Cheers, Tolga Ceylan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3109] [openssl.org #3041[PATCH] DTLS message_sequence number wrong in rehandshake ServerHello
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 received earlier. This patch fixes the RFC violation. This patch should be applied to 1.0.1, 1.0.0 and 0.9.8. renegotiate.patch Description: Binary data
[openssl.org #3041][PATCH] DTLS message_sequence number wrong in rehandshake ServerHello
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 received earlier. This patch fixes the RFC violation. This patch should be applied to 1.0.1, 1.0.0 and 0.9.8. renegotiate.patch Description: Binary data
Re: [openssl.org #3109] AutoReply: [openssl.org #3041[PATCH] DTLS message_sequence number wrong in rehandshake ServerHello
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 , a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #3109]. Please include the string: [openssl.org #3109] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. It is a response to [openssl.org #304], so I'll resend the message correctly. You can close this ticket. Sorry for the inconvenience. Best regards Michael Thank you, r...@openssl.org - 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 received earlier. This patch fixes the RFC violation. This patch should be applied to 1.0.1, 1.0.0 and 0.9.8. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2051] [PATCH] IPv6 support for s_client and s_server
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
(imo).
-mike
I tried your patch it works well. Thank you very much for this work.
I thought of doing some changes in the patch.
1. Leaving openssl binary as it is.
Run openssl in IPv4 mode if not specified explicitly.
If IPv6 support is needed, user should use '-6' option.
2. Use IPv6 hosts inside square brackets ( [] )
As IPv6 addresses use ':' as a separator for its segments we could not
use it as separator for host and port. So if user forgets to enter port with
'-connect' option, the last segment of IPv6 address will be taken as port.
This is not desired.
So it will be better to use square brackets( [] ) to surround IPv6 hosts.
I made an incremental patch after applying your patch to openssl-1.0.1e.
Please let me know your idea over this.
And still I'm working on this patch to verify its functionality. So please
let me know if you modify anything regards this.
Thank you.
The main point is whether the OpenSSL maintainers are interested in IPv6
support or not.
If they are, the patch can be optimized in whatever way they want. I they are
not, the
patch goes nowhere, so optimizing it doesn't make much sense...
Best regards
Michael
Regards,
Bala
---
diff -x '*.out' -x '*tags' -x '*.pem' -x '*.0' -ur
openssl-1.0.1e.mike/apps/s_apps.h openssl-1.0.1e/apps/s_apps.h
--- openssl-1.0.1e.mike/apps/s_apps.h2013-04-10 14:17:59.0 +0530
+++ openssl-1.0.1e/apps/s_apps.h2013-04-10 14:59:57.0 +0530
@@ -159,7 +159,8 @@
int init_client(int *sock, char *server, int port, int type, int use_ipv4,
int use_ipv6);
int should_retry(int i);
int extract_port(char *str, short *port_ptr);
-int extract_host_port(char *str,char **host_ptr,unsigned char *ip,short *p);
+int extract_host_port(char *str,char **host_ptr,unsigned char *ip,short *p,
+int use_ipv4, int use_ipv6);
long MS_CALLBACK bio_dump_callback(BIO *bio, int cmd, const char *argp,
int argi, long argl, long ret);
diff -x '*.out' -x '*tags' -x '*.pem' -x '*.0' -ur
openssl-1.0.1e.mike/apps/s_client.c openssl-1.0.1e/apps/s_client.c
--- openssl-1.0.1e.mike/apps/s_client.c2013-04-10 14:17:59.0 +0530
+++ openssl-1.0.1e/apps/s_client.c2013-04-10 16:35:13.0 +0530
@@ -637,12 +637,10 @@
meth=SSLv23_client_method();
+/* By default use IPv4 */
use_ipv4 = 1;
-#if OPENSSL_USE_IPV6
-use_ipv6 = 1;
-#else
use_ipv6 = 0;
-#endif
+
apps_startup();
c_Pause=0;
c_quiet=0;
@@ -673,6 +671,17 @@
argc--;
argv++;
+
+/* Determine what to be used? IPv4 or IPv6 */
+#if OPENSSL_USE_IPV6
+for (i = 0; i argc; i++) {
+if (!strcmp(argv[i], -6)) {
+use_ipv4 = 0;
+use_ipv6 = 1;
+}
+}
+#endif /* OPENSSL_USE_IPV6 */
+
while (argc = 1)
{
if(strcmp(*argv,-host) == 0)
@@ -689,7 +698,8 @@
else if (strcmp(*argv,-connect) == 0)
{
if (--argc 1) goto bad;
-if (!extract_host_port(*(++argv),host,NULL,port))
+if (!extract_host_port(*(++argv),host,NULL,port, use_ipv4,
+ use_ipv6))
goto bad;
}
else if(strcmp(*argv,-verify) == 0)
diff -x '*.out' -x '*tags' -x '*.pem' -x '*.0' -ur
openssl-1.0.1e.mike/apps/s_server.c openssl-1.0.1e/apps/s_server.c
--- openssl-1.0.1e.mike/apps/s_server.c2013-04-10 14:17:59.0 +0530
+++ openssl-1.0.1e/apps/s_server.c2013-04-10 15:06:32.0 +0530
@@ -980,12 +980,9 @@
#endif
meth=SSLv23_server_method();
+/* By default use IPv4 */
use_ipv4 = 1;
-#if OPENSSL_USE_IPV6
-use_ipv6 = 1;
-#else
use_ipv6 = 0;
-#endif
local_argc=argc;
local_argv=argv;
diff -x '*.out' -x '*tags' -x '*.pem' -x '*.0' -ur
openssl-1.0.1e.mike/apps/s_socket.c openssl-1.0.1e/apps/s_socket.c
--- openssl-1.0.1e.mike/apps/s_socket.c2013-04-10 14:17:59.0 +0530
+++ openssl-1.0.1e/apps/s_socket.c2013-04-10 16:38:11.0 +0530
@@ -572,12 +572,31 @@
}
int extract_host_port(char *str, char **host_ptr, unsigned char *ip,
- short *port_ptr)
+ short *port_ptr, int use_ipv4, int use_ipv6)
{
char *h,*p;
+int domain;
h=str;
-p=strrchr(str,':');
+if (use_ipv4) {
+domain = AF_INET;
+p=strrchr(str,':');
+}
+#if OPENSSL_USE_IPV6
+else if (use_ipv6) {
+domain = AF_INET6;
+str++;
+h = strchr(str, ']');
+if (h) {
+p = strchr(h, ':');
+*h =
Re: DTLS fails handshake due to early CHANGE_CIPHER_SPEC
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 - Brackets indicate a single datagram packet. (1) Client: send [SSL3_MT_CLIENT_HELLO] (2) Server: send [SSL3_MT_SERVER_HELLO, SSL3_MT_CERTIFICATE, SSL3_MT_CERTIFICATE_REQUEST, SSL3_MT_SERVER_DONE] (3) Client: send [SSL3_MT_CERTIFICATE, SSL3_MT_CLIENT_KEY_EXCHANGE, SSL3_MT_CERTIFICATE_VERIFY, *CHANGE_CIPHER*, SSL3_MT_FINISHED] Client packet (3) is lost. Oh noes! Other stuff happens, but Client eventually resends each message in its own datagram this time: (4) Client: send [SSL3_MT_CERTIFICATE] (5) Client: send [SSL3_MT_CLIENT_KEY_EXCHANGE] (6) Client: send [SSL3_MT_CERTIFICATE_VERIFY] (7) Client: send [*CHANGE_CIPHER*] (8) Client: send [SSL3_MT_FINISHED] Now, one of the following thing happens: a) packet (6) is lost or, in my case, packet (7) arrives before (6). Unfortunately, when Server processes packet (7) it changes the cypher spec before the handshake is over. When (6) finally arrives, it's dropped by dtls1_read_bytes. Subsequent re-sends from Client are also ignored. Without having read any spec, and with my limited knowledge of the OpenSSL codebase, my naive interpretation is that the problem is caused by dtls1_accept setting change_cipher_spec_ok on SSL3_ST_SR_CERT_VRFY_* states. Commenting out that line definitely seems to fix the problem for me. Is this really the bug, or does that line plays a role in a different scenario? Hi Daniel, this really sounds like a bug. Can you file one using the request tracker at http://www.openssl.org/support/rt.html This way it doesn't get lost and a fix can be tied to it. Thanks a lot. Best regards Michael Cheers, -dan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS server get stuck when application data i sreceived before handshake
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 server keeps spinning on DTLSv1_listen(), and fails to processing incoming ClientHellos. I am using openssl-1.0.1c. Hi Prashant, I can confirm that this is a bug. Can you file one using the request tracker at http://www.openssl.org/support/rt.html This way it doesn't get lost and a fix can be tied to it. Thanks a lot. Best regards Michael Start the DTLS server: [muranant@muranant ssl_bm]$ ./dtls_udp_discard Client: Send Application Data pkt: p Ether dst=00:50:56:BD:76:6B src=00:50:56:BD:17:5D type=IPv4 |IP version=4L ihl=5L tos=0x0 len=51 id=0 flags=DF frag=0L ttl=63 proto=udp src=10.193.78.127 dst=10.193.78.239 options='' |UDP sport=42973 dport=23232 len=31 |Raw load='\x17\xfe\xfd\x00\x00\x00\x00\x00\x00\x00\x18\x00\n!\x00\x01\x00\x00\x00\x00\x17\x00\x01' | str(p) '\x00PV\xbdvk\x00PV\xbd\x17]\x08\x00E\x00\x003\x00\x00@\x00?\x11\x88\xca\n\xc1N\x7f\n\xc1N\xef\xa7\xddZ\xc0\x00\x1f\xfb\x00\x17\xfe\xfd\x00\x00\x00\x00\x00\x00\x00\x18\x00\n!\x00\x01\x00\x00\x00\x00\x17\x00\x01' sendp(p) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS with epoll?
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 suspect that because when I check it, at least DTLSv1_get_timeout() returns very big number. What does returns a very big number mean? The second argument is a struct timeval *. Best regards Michael Thank you very much for the help, Igenyar __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3008] Possible bug when using DTLS with a BIO pair
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 dtls1_check_timeout_num(), after 2 unsuccessful retransmission
attempts, the code calls BIO_ctrl() with the BIO_CTRL_DGRAM_GET_FALLBACK_MTU
option to adjust the MTU. This operation is not defined for a BIO
pair, and results in the MTU being set to zero. That eventually
causes an OpenSSL_assert() to fail in dtls1_do_write().
So the question is: When using a BIO pair, why does sending fail? Are the
packets later on sent over UDP? If yes, how to you handle the case that
the path MTU needs to be adjusted?
Best regards
Michael
It would make sense to recognize that zero can't be a valid fallback MTU
value, and avoid resetting the MTU. A patch with a possible fix is attached.
--- Gary
diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index db180f2..371199d 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -401,12 +401,17 @@ void dtls1_stop_timer(SSL *s)
int dtls1_check_timeout_num(SSL *s)
{
+ unsigned int mtu;
s-d1-timeout.num_alerts++;
/* Reduce MTU after 2 unsuccessful retransmissions */
if (s-d1-timeout.num_alerts 2)
{
- s-d1-mtu = BIO_ctrl(SSL_get_wbio(s),
BIO_CTRL_DGRAM_GET_FALLBACK_MTU, 0, NULL);
+ mtu = BIO_ctrl(SSL_get_wbio(s),
BIO_CTRL_DGRAM_GET_FALLBACK_MTU, 0, NULL);
+ if (mtu 0)
+ {
+ s-d1-mtu = mtu;
+ }
}
if (s-d1-timeout.num_alerts DTLS1_TMO_ALERT_COUNT)
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3008] Possible bug when using DTLS with a BIO pair
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 to work for my purposes except for one problem when handling
timeouts.
In dtls1_check_timeout_num(), after 2 unsuccessful retransmission
attempts, the code calls BIO_ctrl() with the BIO_CTRL_DGRAM_GET_FALLBACK_MTU
option to adjust the MTU. This operation is not defined for a BIO
pair, and results in the MTU being set to zero. That eventually
causes an OpenSSL_assert() to fail in dtls1_do_write().
So the question is: When using a BIO pair, why does sending fail? Are the
packets later on sent over UDP? If yes, how to you handle the case that
the path MTU needs to be adjusted?
It fails because dtls1_do_write() contains the following check:
OPENSSL_assert(s-d1-mtu = dtls1_min_mtu()); /* should have
something reasonable now */
which fails if s-d1-mtu is set to zero.
Isn't this after the sending failed two times?
In our particular case, we do eventually send the packets over UDP. We
use SSL_set_mtu() and fix the MTU to a suitable minimum.
OK.
Best regards
Michael
-- Gary
It would make sense to recognize that zero can't be a valid fallback MTU
value, and avoid resetting the MTU. A patch with a possible fix is
attached.
--- Gary
diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index db180f2..371199d 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -401,12 +401,17 @@ void dtls1_stop_timer(SSL *s)
int dtls1_check_timeout_num(SSL *s)
{
+ unsigned int mtu;
s-d1-timeout.num_alerts++;
/* Reduce MTU after 2 unsuccessful retransmissions */
if (s-d1-timeout.num_alerts 2)
{
- s-d1-mtu = BIO_ctrl(SSL_get_wbio(s),
BIO_CTRL_DGRAM_GET_FALLBACK_MTU, 0, NULL);
+ mtu = BIO_ctrl(SSL_get_wbio(s),
BIO_CTRL_DGRAM_GET_FALLBACK_MTU, 0, NULL);
+ if (mtu 0)
+ {
+ s-d1-mtu = mtu;
+ }
}
if (s-d1-timeout.num_alerts DTLS1_TMO_ALERT_COUNT)
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Use TLS over UDP connection
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 creating a UDP connection to the same server (UDP socket) and am trying to do a TLS handshake. When I call SSL_connect() over UDP connection, it fails with SSL_ERROR_SYSCALL error. When I checked the error with ERR_get_error() I get a value of 0. Can I use TLS over a UDP connection(I understand DTLS can be used but my project needs TLS)? Please share some pointers. Thanks for your time. TLS doesn't work over UDP, use DTLS instead. Best regards Michael Regards, Saurav __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS finished MAC calculation and handshake message fragmentation
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 -certform PEM -key client.key -keyform PEM -CAfile root.crt –state Our server and OpenSSL handshake successfully when I run our server without client authentication turned on. In this test there are no fragmented handshake messages. The Finished signatures are calculated in the same way in both ends since the handshake is successful. But when I turn on client authentication the handshake fails. Both the CertificateVerify and Finished signatures are different which makes the handshake fail. I suspect that the reason for this is that OpenSSL sends its certificate to the server split into 3 fragments. The server reassembles the Certificate handshake message successfully. But it seems like the signatures are calculated differently. I have read this mailing list and tried several suggestions for handling fragmentation but with no success. Also both RFC 4347 and 6347 are unclear on how the signatures should be computed with regard to handshake fragmentation. So I would like to ask for a description of how this is done in OpenSSL so I can adapt our implementation and make it interoperable with OpenSSL? If you think RFC 6347 is unclear how the computation should be done, please send a message to t...@ietf.org to discuss this. I think just doing something because OpenSSL does it, is not the right way. If the issue can be resolved on t...@ietf.org, the implementations can be fixed if needed. Best regards Michael Best regards, /Bojan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2830] [PATCH] Allow setting the Don't Fragment bit for DTLS
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 use SCTP over DTLS for RTCWeb (Real-time Browser to Browser Communication). Please double-check http://cvs.openssl.org/chngview?cn=22628 along with http://cvs.openssl.org/chngview?cn=22627. Once confirmed bss_dgram.c will propagate down to 1.0.2. It's hardly appropriate to go lower, because binaries compiled with pre-1.0.2 won't call it anyway. Not sure I understand this... We need this to for implementing SCTP over DTLS. Why can't we require a version of, let's say 1.0.1d at least. But it is up to you. When you say require what do you mean? That you require it from your target users, right? But most users run pre-packaged software and are reluctant to compile themselves. So that effectively you're more likely to require yours users to ask their favorite vendor? But vendors have their own policies for maintaining their packages and don't want *any* functional changes within same package. So that your target audience is unlikely to see new functionality on their systems, not through 1.0.1 package update from their vendors. Starting with 1.0.0 we favor this and add *no* functional changes in letter updates. Instead we aim to ensure that 1.0.x releases are binary compatible, so that vendors can maintain different versions of packages for same distribution, so that it's possible stage *in* version with extra functionality, without having to recompile applications that don't rely on new functionality. OK, your choice. What I meant: Adding a functionality like in 2830 doesn't break binary compatibility, right? Only someone depending on such a feature, needs to make sure that a specific letter release is used when linking (dynamic or static). But if you have changed the policy you use for adding features, it is OK. We just refer people to the patch or to the upcoming 1.0.2 release. Best regards Michael __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use
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 critical problem however on big endian 64 bit systems it means the interpretation of the returned value by the code in dgram_ctrl() is completely wrong - Actually similar argument applies even to sockopt_len. Modulo fact that you get into trouble in cases when *expected* sizeof(sockopt_len) is 8, while the value is declared int. The situation is intensified by fact that in some cases expected sizeof(sockopt_len) depends on compiler flags. And I'm not talking about -m32 vs. -m64 compiler flags, I'm talking about flags in 64-bit case [Tru64 for one if you have to know]. One way to attack the problem is depicted in crypto/bio/b_sock.c:975. I mean union between unsigned int and size_t, explicit zeroing of size_t member and heuristic that detects big-endian trouble. Then one can declare even sockopt_val as similar union and pick int or long depending on calculated sockopt_len being 4 or 8. General comment: Can't you use socklen_t as the type of the last argument? As it says in crypto/bio/b_sock.c:975, there *are* platforms that don't have socklen_t. Of course one can question if these platforms are modern enough/worth to care about, but why not, if it's feasible and enriching? Or course one can go for #ifdef, but does one have to? 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 run time as accurately. Or should one say even more accurately, because it's actual value, not assumed one from compile time. Of course, absolute majority of compiled code heavily relies on assumed values being equal to actual, but it's not prohibited to assume that there are not, is it? #ifdefs have to be maintained in sense that you have to follow their changes on multiple platforms, while #ifdef-free alternative simply adapts to whichever situation with *no* maintenance. Regarding the IP_MTU/IPV6_MTU socket option on Linux: The Linux man page says, that the type of the option_value is int. So I guess the bug is simply, that the code uses long sockopt_val instead of int sockopt_val. All this is specific to Linux. Can you guarantee that the code in question won't ever become interesting to reuse even in non-Linux context? I mean do you really have to assume Linux that categorically? In other words in context of multi-platform code such as OpenSSL there is value in *not* assuming things. I think http://rt.openssl.org/Ticket/Display.html?id=2830user=guestpass=guest already fixes the bug, since it changes sockopt_val from long to int. It fixes the first problem (although non-portably). But there are still ... the problem is specific to a platform... the signed/unsigned int comparisons of the mtu values later in the code in d1_both.c. Of course fixing the first problem will probably mask the Ahh, right. We'll look at it and update the patch. Thanks a lot. Best regards Michael second problem. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use
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 run time as accurately. Or should one say even I'm not sure I understand what you are requesting. The implementation of the IP_MTU defines the opt_value as an int. Apparently I've carried away in the heat of discussion. You said option_value might be platform dependent and I assumed that some might want 32- and some might want 64-bit value. While this [some want 32, some 64] is true for option_len, all platforms seem to expect 32-bit for option_value is different for different socket options. And if the socket option is not part of the common set of socket options, the type might be platform specific simple options. So that int declaration for option_val is sufficient [for now]. The comment therefore falls to what *if* category. I mean if you had ioctl that reports that it has written 4 or 8 bytes, then you could use that value to determine if it was 32- or 64-bit value returned and act accordingly. But never mind, once again, int declaration for option_val appears sufficient. Yes, for know, as you say. That code is platform specific. It is surrounded by #ifdef OPENSSL_SYS_LINUX #endif We are looking in several platform specific issues, like setting the TOS (for ECN) byte, setting the DF bit, querying the interface MTU, receiving the ECN bits for DTLS. We will provide one API, but the implementation is platform specific. It's hypothetical, but what if tomorrow it will become possible to reuse the code on another platform? All I'm saying is that it *might* prove to be useful to think outside Linux even within #idef LINUX. It's not a requirement, just wishful thinking... Well, that socket option is currently only available on Linux. If it becomes available on other platforms, we have to re-consider the code in OpenSSL. Maybe the other platform really duplicates the function provided by Linux or does it differently. Then the #ifdefs can be adopted... So I guess, we can fix this bug easily. However, according to initial comment, all getsockopt() call are broken, right? This is a trick question. Does initial refer to Tomas's report about Sorry for not being clear. I was referring to your comment regarding the final argument of getsockopt(), which *socklen_t, but you use specific code to deal with platforms which don't have that type in the accept() call. So I was asking if the same mechanism should also be used for all getsockopt() calls. option_val or my comment about option_len? If former, see above, if latter, then yes, admittedly they are all effectively broken *in cases* when expected option_len is 64-bit value. There is a number of getsockopt calls in bss_dgram.c and there is one in b_sock.c. Most of them work out and don't break at run time, because 64-bit compilers usually allocate 64-bit slot even for 32-bit values on stack. It's *not* an excuse for not fixing them, merely an explanation for how it could have worked so far without causing trouble. 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 That seems to be a bug. Robin: Can you submit a patch? would non-Windows BIO_CTRL_DGRAM_GET_RECV_TIMEOUT work when ret is initialized to 1? 'perror's are just wrong in context... That seems to be another bug. Robin: Can you fix that, too? Best regards Michael __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use
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 http://cvs.openssl.org/chngview?cn=22627. Note that it doesn't use heuristic union approach on systems with IP_MTU and SCTP, assuming that they are modern enough to provide even socklen_t. OK. Robin: Can you please double check? As for Linux-specific code reuse. What prevents us from removing all occurrences of defined(OPENSSL_SYS_LINUX) except for first one? What if other platforms implement IP_MTU, but it has a different semantic or requires a different option_value? I would keep it Linux specific... Best regards Michael __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2830] [PATCH] Allow setting the Don't Fragment bit for DTLS
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 and to use SCTP over DTLS for RTCWeb (Real-time Browser to Browser Communication). Please double-check http://cvs.openssl.org/chngview?cn=22628 along with http://cvs.openssl.org/chngview?cn=22627. Once confirmed bss_dgram.c will propagate down to 1.0.2. It's hardly appropriate to go lower, because binaries compiled with pre-1.0.2 won't call it anyway. Not sure I understand this... We need this to for implementing SCTP over DTLS. Why can't we require a version of, let's say 1.0.1d at least. But it is up to you. Best regards Michael __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use
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 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 in dgram_ctrl() is completely wrong - Actually similar argument applies even to sockopt_len. Modulo fact that you get into trouble in cases when *expected* sizeof(sockopt_len) is 8, while the value is declared int. The situation is intensified by fact that in some cases expected sizeof(sockopt_len) depends on compiler flags. And I'm not talking about -m32 vs. -m64 compiler flags, I'm talking about flags in 64-bit case [Tru64 for one if you have to know]. One way to attack the problem is depicted in crypto/bio/b_sock.c:975. I mean union between unsigned int and size_t, explicit zeroing of size_t member and heuristic that detects big-endian trouble. Then one can declare even sockopt_val as similar union and pick int or long depending on calculated sockopt_len being 4 or 8. General comment: Can't you use socklen_t as the type of the last argument? 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. Regarding the IP_MTU/IPV6_MTU socket option on Linux: The Linux man page says, that the type of the option_value is int. So I guess the bug is simply, that the code uses long sockopt_val instead of int sockopt_val. All this is specific to Linux. Robin will test, if this fixes the issue and provide a patch. Best regards Michael you will get a bogus huge value of MTU which leads even to a segfault (fortunately without security impact) later in the DTLS code. The simplest fix would be to use int instead of long for the sockopt_val although I am not sure about the portability to other non-linux kernels. Another problem is when s-d1-mtu is compared to dtls1_min_mtu() value in dtls1_do_write() - as signed integer value is compared to unsigned value an implicit conversion of the signed integer to unsigned value is performed and negative value (which came out of the bogus call in dgram_ctrl()) is converted to some large value and thus the comparison fails and the fallback code for choosing some safe MTU value is not invoked. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use
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 in dgram_ctrl() is completely wrong - Actually similar argument applies even to sockopt_len. Modulo fact that you get into trouble in cases when *expected* sizeof(sockopt_len) is 8, while the value is declared int. The situation is intensified by fact that in some cases expected sizeof(sockopt_len) depends on compiler flags. And I'm not talking about -m32 vs. -m64 compiler flags, I'm talking about flags in 64-bit case [Tru64 for one if you have to know]. One way to attack the problem is depicted in crypto/bio/b_sock.c:975. I mean union between unsigned int and size_t, explicit zeroing of size_t member and heuristic that detects big-endian trouble. Then one can declare even sockopt_val as similar union and pick int or long depending on calculated sockopt_len being 4 or 8. General comment: Can't you use socklen_t as the type of the last argument? As it says in crypto/bio/b_sock.c:975, there *are* platforms that don't have socklen_t. Of course one can question if these platforms are modern enough/worth to care about, but why not, if it's feasible and enriching? Or course one can go for #ifdef, but does one have to? OK, I see... Personally, I would define socklen_t on platforms which don't have them to the right type (int of size_t according to you comment), but that is just personal preference... 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 run time as accurately. Or should one say even I'm not sure I understand what you are requesting. The implementation of the IP_MTU defines the opt_value as an int. It doesn't matter what sizeof(int) is. Only if I compile on one platform and run it on a different platform and both don't agree on sizeof(int). more accurately, because it's actual value, not assumed one from compile time. Of course, absolute majority of compiled code heavily relies on assumed values being equal to actual, but it's not prohibited to assume that there are not, is it? #ifdefs have to be maintained in sense that you have to follow their changes on multiple platforms, while #ifdef-free alternative simply adapts to whichever situation with *no* maintenance. Regarding the IP_MTU/IPV6_MTU socket option on Linux: The Linux man page says, that the type of the option_value is int. So I guess the bug is simply, that the code uses long sockopt_val instead of int sockopt_val. All this is specific to Linux. Can you guarantee that the code in question won't ever become interesting to reuse even in non-Linux context? I mean do you really have to assume Linux that categorically? In other words in context of multi-platform code such as OpenSSL there is value in *not* assuming things. That code is platform specific. It is surrounded by #ifdef OPENSSL_SYS_LINUX #endif We are looking in several platform specific issues, like setting the TOS (for ECN) byte, setting the DF bit, querying the interface MTU, receiving the ECN bits for DTLS. We will provide one API, but the implementation is platform specific. So I guess, we can fix this bug easily. However, according to initial comment, all getsockopt() call are broken, right? Best regards Michael __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use
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 in dgram_ctrl() is completely wrong - Actually similar argument applies even to sockopt_len. Modulo fact that you get into trouble in cases when *expected* sizeof(sockopt_len) is 8, while the value is declared int. The situation is intensified by fact that in some cases expected sizeof(sockopt_len) depends on compiler flags. And I'm not talking about -m32 vs. -m64 compiler flags, I'm talking about flags in 64-bit case [Tru64 for one if you have to know]. One way to attack the problem is depicted in crypto/bio/b_sock.c:975. I mean union between unsigned int and size_t, explicit zeroing of size_t member and heuristic that detects big-endian trouble. Then one can declare even sockopt_val as similar union and pick int or long depending on calculated sockopt_len being 4 or 8. General comment: Can't you use socklen_t as the type of the last argument? As it says in crypto/bio/b_sock.c:975, there *are* platforms that don't have socklen_t. Of course one can question if these platforms are modern enough/worth to care about, but why not, if it's feasible and enriching? Or course one can go for #ifdef, but does one have to? 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 run time as accurately. Or should one say even more accurately, because it's actual value, not assumed one from compile time. Of course, absolute majority of compiled code heavily relies on assumed values being equal to actual, but it's not prohibited to assume that there are not, is it? #ifdefs have to be maintained in sense that you have to follow their changes on multiple platforms, while #ifdef-free alternative simply adapts to whichever situation with *no* maintenance. Regarding the IP_MTU/IPV6_MTU socket option on Linux: The Linux man page says, that the type of the option_value is int. So I guess the bug is simply, that the code uses long sockopt_val instead of int sockopt_val. All this is specific to Linux. Can you guarantee that the code in question won't ever become interesting to reuse even in non-Linux context? I mean do you really have to assume Linux that categorically? In other words in context of multi-platform code such as OpenSSL there is value in *not* assuming things. I think http://rt.openssl.org/Ticket/Display.html?id=2830user=guestpass=guest already fixes the bug, since it changes sockopt_val from long to int. Do you want that patch to be split up in a bug fixing patch and a feature patch? Best regards Michael __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use
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 problem however on big endian 64 bit systems it means the interpretation of the returned value by the code in dgram_ctrl() is completely wrong - you will get a bogus huge value of MTU which leads even to a segfault (fortunately without security impact) later in the DTLS code. The simplest fix would be to use int instead of long for the sockopt_val although I am not sure about the portability to other non-linux kernels. Another problem is when s-d1-mtu is compared to dtls1_min_mtu() value in dtls1_do_write() - as signed integer value is compared to unsigned value an implicit conversion of the signed integer to unsigned value is performed and negative value (which came out of the bogus call in dgram_ctrl()) is converted to some large value and thus the comparison fails and the fallback code for choosing some safe MTU value is not invoked. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: DTLSv1_get_timeout/DTLSv1_handle_timeout on server for each connection
On Mar 16, 2012, at 8:31 AM, Manish Yadav wrote: Michael, i am curious, how would we detect DOS attack on server if someone sends too many such packets? dtls server would keep silently dropping them, will it report any error/status? Just dropping, no report. Best regards Michael 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: dip, destination port: dport). both are connected. then client goes down/crashes without calling ssl_shutdown, so server still has the client context information. again client comes up and uses same ip (cip) and port (cport) to establish ssl connection, since server has already ssl context created (it thinks ssl is initialized) but receives client hello? what is expected behavior in such scenario, does server starts negotiation again or ignores client hello. Assuming that the client crashes and looses its state, the client will send an unencrypted client hello. Since it uses the same IP/port number, it will be processed by the server. But the server expects the client hello to be sent using the key material it has, it will be dropped. The server will keep its state. i was thinking what would happen if someone spoofs the client ip (cip) and uses same port (cport) to establish connection with server (dip and dport), could you please help me to understand how dtls deals 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, Robin, thanks for input. i was thinking if i am not implementing dtls heartbeat in that scenario, how could client detect if server is still getting the messages (assuming the server deleted inactive session after sometime or server got reloaded), is there any mechanism that could help here? i see http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-02#section-3.1, which talks about similar problem (section3) and possible solution. You need a mechanism in the application protocol. If you don't have that, using the heartbeats is (from my perspective) the next option. Please note that it is part of OpenSSL 1.0.1 (currently in beta2) and the corresponding RFC will be out soon (matter of days, I guess). If you don't want to use the heartbeats, you can only renegotiate the DTLS session to see if the peer is still there. Please note that uses more resources than the heartbeat stuff and it might affect the transfer of user messages. Best regards Michael thanks, manish On Mon, Jan 30, 2012 at 1:10 PM, Robin Seggelmann seggelm...@fh-muenster.de wrote: On Jan 25, 2012, at 5:16 PM, 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, if it is inactive for sometime then close the connection/socket and for inactive clients keep the ssl object cached, whenever inactive clients send data create new fd and associate with old ssl object, similar to http://net-snmp.sourceforge.net/dev/agent/snmpDTLSUDPDomain_8c_source.html). is it possible? If you make sure that you don't send anything locally... Why not close the DTLS connection after some time and let the client do a new connect. You can cache the session and the client can use session resumption. if i look at DTLSv1_listen, i am thinking i can not distinguish between active/inactive client? 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? ClientHello messages are processed, so when the message or its attached cookie is invalid, an error will be returned. All other messages will be silently discarded and DTLSv1_listen() will not return, but simply wait for the next message. I'd also recommend session resumption for inactive clients. Best regards Robin thanks, manish On Wed, Jan 25, 2012 at 3:24 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: 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
Re: DTLSv1_get_timeout/DTLSv1_handle_timeout on server for each connection
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: dip, destination port: dport). both are connected. then client goes down/crashes without calling ssl_shutdown, so server still has the client context information. again client comes up and uses same ip (cip) and port (cport) to establish ssl connection, since server has already ssl context created (it thinks ssl is initialized) but receives client hello? what is expected behavior in such scenario, does server starts negotiation again or ignores client hello. Assuming that the client crashes and looses its state, the client will send an unencrypted client hello. Since it uses the same IP/port number, it will be processed by the server. But the server expects the client hello to be sent using the key material it has, it will be dropped. The server will keep its state. i was thinking what would happen if someone spoofs the client ip (cip) and uses same port (cport) to establish connection with server (dip and dport), could you please help me to understand how dtls deals 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, Robin, thanks for input. i was thinking if i am not implementing dtls heartbeat in that scenario, how could client detect if server is still getting the messages (assuming the server deleted inactive session after sometime or server got reloaded), is there any mechanism that could help here? i see http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-02#section-3.1, which talks about similar problem (section3) and possible solution. You need a mechanism in the application protocol. If you don't have that, using the heartbeats is (from my perspective) the next option. Please note that it is part of OpenSSL 1.0.1 (currently in beta2) and the corresponding RFC will be out soon (matter of days, I guess). If you don't want to use the heartbeats, you can only renegotiate the DTLS session to see if the peer is still there. Please note that uses more resources than the heartbeat stuff and it might affect the transfer of user messages. Best regards Michael thanks, manish On Mon, Jan 30, 2012 at 1:10 PM, Robin Seggelmann seggelm...@fh-muenster.de wrote: On Jan 25, 2012, at 5:16 PM, 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, if it is inactive for sometime then close the connection/socket and for inactive clients keep the ssl object cached, whenever inactive clients send data create new fd and associate with old ssl object, similar to http://net-snmp.sourceforge.net/dev/agent/snmpDTLSUDPDomain_8c_source.html). is it possible? If you make sure that you don't send anything locally... Why not close the DTLS connection after some time and let the client do a new connect. You can cache the session and the client can use session resumption. if i look at DTLSv1_listen, i am thinking i can not distinguish between active/inactive client? 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? ClientHello messages are processed, so when the message or its attached cookie is invalid, an error will be returned. All other messages will be silently discarded and DTLSv1_listen() will not return, but simply wait for the next message. I'd also recommend session resumption for inactive clients. Best regards Robin thanks, manish On Wed, Jan 25, 2012 at 3:24 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: 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 server side also. However, DTLSv1_get_timeout/DTLSv1_handle_timeout is only necessary if you use select. after looking at : http://crypto.stanford.edu/~nagendra/papers/dtls.pdf i understood that i need to call DTLSv1_get_timeout/DTLSv1_handle_timeout incase of non-blocking socket. but after looking at example available on net dtls_udp_echo2.c, i see only client side take care
Re: [openssl.org #2730] [PATCH] solving #2670 BUG
On Feb 25, 2012, at 12:01 AM, Arpadffy Zoltan wrote: Hello, BTW: Isn't SCTP support off by default (at least this is what is intended)? No, it is unfortunately not off by default. ... but applying the following patch OPENSSL_NO_SCTP is easily made default. File DKA400:[ZOLI.OPENSSL-101-BETA3]MAKEVMS.COM;2 506 $ WRITE H_FILE /* STCP support comes with TCPIP 5.7 ECO 2 507 $ WRITE H_FILE * enable on newer systems / 2012-02-24 arpadffy */ 508 $ WRITE H_FILE #define OPENSSL_NO_SCTP 509 $ WRITE H_FILE ** File DKA400:[ZOLI.OPENSSL-101-BETA3]MAKEVMS.COM;1 506 $ WRITE H_FILE OK, I must admit that we have never touched the makevms.com file (we also don't have a VMS system for testing). You are right, OPENSSL_NO_SCTP has to be defined in that file. Not sure if it is better to file a bug report through the RT tracker to make 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] solving #2670 BUG 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 USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRY PTO.BIOBIO.H;4 File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;1 72 #include stdint.h 73 #endif ** File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;4 72 # ifndef VMS 73 # include stdint.h 74 # else 75 # include inttypes.h 76 # endif 77 #endif Also, OpenSSL version 1.0.1 Beta 3 is tested and it works very well, except that I have been forced to set #define OPENSSL_NO_SCTP BTW: Isn't SCTP support off by default (at least this is what is intended)? Best regards Michael ...because SCTP comes with TCPIP 5.7 ECO 2 and I do not have access to those systems. Regards, Z -Original Message- From: OpenSSL [mailto:open...@master.openssl.org] Sent: den 24 februari 2012 00:27 To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; openssl-us...@master.openssl.org Subject: OpenSSL 1.0.1 beta 3 released -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1 Beta 3 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The third beta is now released. This is expected to be the final beta depending on the number of bugs reported. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-1.0.1-beta3.tar.gz Size: 4451351 MD5 checksum: dc141587e0d374bdb0c7b97f770fff5e SHA1 checksum: 32105cbcc1bc6bc959102b2d70eb16ed1da732ce The checksums were calculated using the following command: openssl md5 openssl-1.0.1-beta3.tar.gz openssl sha1 openssl-1.0.1-beta3.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 55 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Also check the latest snapshots at ftp://ftp.openssl.org/snapshot/ or CVS (see http://www.openssl.org/source/repos.html) to avoid reporting previously fixed bugs. Since the second beta the following has happened: - Improved TLS v1.2 client authentication interop. - MDC2 signature format compatibility fix. - ABI compatibility fixes. - Other fixes. Reports and patches should be sent to openssl-b...@openssl.org. Discussions around the development of OpenSSL should be sent to openssl-dev@openssl.org. Anything else should go to openssl-us...@openssl.org. The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBT0bJ2qLSm3vylcdZAQJv1Qf9G5Vf7BgbdhHW+psSd3s6Z8zeijxSkZl1 cue84LkJEDRr7Tkbyk2eGuLR5cNiuH5u9waPlf31zCWsoh2cOl2fMDm+3LTB6Wqk 9zU8gkaarUFZxYxbRJa2VVDTOEzbW/qO/Gabjt/dkh/0xb2iKZvTVGr8G8xK0PVN aYhehHEHl6yxJv2V8uPZgxOC0KIMRXIj3zy/Db/Aeu9FRH1vFCHg4o+HjvaMfXRd
Re: [openssl.org #2730] [PATCH] solving #2670 BUG
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 USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRY PTO.BIOBIO.H;4 File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;1 72 #include stdint.h 73 #endif ** File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;4 72 # ifndef VMS 73 # include stdint.h 74 # else 75 # include inttypes.h 76 # endif 77 #endif Also, OpenSSL version 1.0.1 Beta 3 is tested and it works very well, except that I have been forced to set #define OPENSSL_NO_SCTP ...because SCTP comes with TCPIP 5.7 ECO 2 and I do not have access to those systems. I'm pretty sure the DTLS/SCTP works currently only on recent Linux stacks, FreeBSD 9, FreeBSD 8.3 (when released) and Mac OS X with an additional NKE. I really doubt, that VMS supports that required SCTP features, even if it supports SCTP. So OPENSSL_NO_SCTP should be defined on VMS. Best regards Michael Regards, Z -Original Message- From: OpenSSL [mailto:open...@master.openssl.org] Sent: den 24 februari 2012 00:27 To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; openssl-us...@master.openssl.org Subject: OpenSSL 1.0.1 beta 3 released -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1 Beta 3 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The third beta is now released. This is expected to be the final beta depending on the number of bugs reported. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-1.0.1-beta3.tar.gz Size: 4451351 MD5 checksum: dc141587e0d374bdb0c7b97f770fff5e SHA1 checksum: 32105cbcc1bc6bc959102b2d70eb16ed1da732ce The checksums were calculated using the following command: openssl md5 openssl-1.0.1-beta3.tar.gz openssl sha1 openssl-1.0.1-beta3.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 55 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Also check the latest snapshots at ftp://ftp.openssl.org/snapshot/ or CVS (see http://www.openssl.org/source/repos.html) to avoid reporting previously fixed bugs. Since the second beta the following has happened: - Improved TLS v1.2 client authentication interop. - MDC2 signature format compatibility fix. - ABI compatibility fixes. - Other fixes. Reports and patches should be sent to openssl-b...@openssl.org. Discussions around the development of OpenSSL should be sent to openssl-dev@openssl.org. Anything else should go to openssl-us...@openssl.org. The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBT0bJ2qLSm3vylcdZAQJv1Qf9G5Vf7BgbdhHW+psSd3s6Z8zeijxSkZl1 cue84LkJEDRr7Tkbyk2eGuLR5cNiuH5u9waPlf31zCWsoh2cOl2fMDm+3LTB6Wqk 9zU8gkaarUFZxYxbRJa2VVDTOEzbW/qO/Gabjt/dkh/0xb2iKZvTVGr8G8xK0PVN aYhehHEHl6yxJv2V8uPZgxOC0KIMRXIj3zy/Db/Aeu9FRH1vFCHg4o+HjvaMfXRd Ahhwsh4HLaKQ3GZZKHGBlIzFANd6QJM0Q96tf2rVdINq9CZ3iw7KnbHUXNH26H3P VSfxF0sZcbl2PvQ0EnTKuKLt3QXkea9Ihtf7h7srTP4VikKbkAeh8Q== =27QW -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager
Re: [openssl.org #2730] [PATCH] solving #2670 BUG
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 USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRY PTO.BIOBIO.H;4 File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;1 72 #include stdint.h 73 #endif ** File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;4 72 # ifndef VMS 73 # include stdint.h 74 # else 75 # include inttypes.h 76 # endif 77 #endif Also, OpenSSL version 1.0.1 Beta 3 is tested and it works very well, except that I have been forced to set #define OPENSSL_NO_SCTP BTW: Isn't SCTP support off by default (at least this is what is intended)? Best regards Michael ...because SCTP comes with TCPIP 5.7 ECO 2 and I do not have access to those systems. Regards, Z -Original Message- From: OpenSSL [mailto:open...@master.openssl.org] Sent: den 24 februari 2012 00:27 To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; openssl-us...@master.openssl.org Subject: OpenSSL 1.0.1 beta 3 released -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1 Beta 3 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The third beta is now released. This is expected to be the final beta depending on the number of bugs reported. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-1.0.1-beta3.tar.gz Size: 4451351 MD5 checksum: dc141587e0d374bdb0c7b97f770fff5e SHA1 checksum: 32105cbcc1bc6bc959102b2d70eb16ed1da732ce The checksums were calculated using the following command: openssl md5 openssl-1.0.1-beta3.tar.gz openssl sha1 openssl-1.0.1-beta3.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 55 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Also check the latest snapshots at ftp://ftp.openssl.org/snapshot/ or CVS (see http://www.openssl.org/source/repos.html) to avoid reporting previously fixed bugs. Since the second beta the following has happened: - Improved TLS v1.2 client authentication interop. - MDC2 signature format compatibility fix. - ABI compatibility fixes. - Other fixes. Reports and patches should be sent to openssl-b...@openssl.org. Discussions around the development of OpenSSL should be sent to openssl-dev@openssl.org. Anything else should go to openssl-us...@openssl.org. The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBT0bJ2qLSm3vylcdZAQJv1Qf9G5Vf7BgbdhHW+psSd3s6Z8zeijxSkZl1 cue84LkJEDRr7Tkbyk2eGuLR5cNiuH5u9waPlf31zCWsoh2cOl2fMDm+3LTB6Wqk 9zU8gkaarUFZxYxbRJa2VVDTOEzbW/qO/Gabjt/dkh/0xb2iKZvTVGr8G8xK0PVN aYhehHEHl6yxJv2V8uPZgxOC0KIMRXIj3zy/Db/Aeu9FRH1vFCHg4o+HjvaMfXRd Ahhwsh4HLaKQ3GZZKHGBlIzFANd6QJM0Q96tf2rVdINq9CZ3iw7KnbHUXNH26H3P VSfxF0sZcbl2PvQ0EnTKuKLt3QXkea9Ihtf7h7srTP4VikKbkAeh8Q== =27QW -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: DTLSv1_get_timeout/DTLSv1_handle_timeout on server for each connection
On Feb 5, 2012, at 10:25 AM, Manish Yadav wrote: Hi Michael, Robin, thanks for input. i was thinking if i am not implementing dtls heartbeat in that scenario, how could client detect if server is still getting the messages (assuming the server deleted inactive session after sometime or server got reloaded), is there any mechanism that could help here? i see http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-02#section-3.1, which talks about similar problem (section3) and possible solution. You need a mechanism in the application protocol. If you don't have that, using the heartbeats is (from my perspective) the next option. Please note that it is part of OpenSSL 1.0.1 (currently in beta2) and the corresponding RFC will be out soon (matter of days, I guess). If you don't want to use the heartbeats, you can only renegotiate the DTLS session to see if the peer is still there. Please note that uses more resources than the heartbeat stuff and it might affect the transfer of user messages. Best regards Michael thanks, manish On Mon, Jan 30, 2012 at 1:10 PM, Robin Seggelmann seggelm...@fh-muenster.de wrote: On Jan 25, 2012, at 5:16 PM, 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, if it is inactive for sometime then close the connection/socket and for inactive clients keep the ssl object cached, whenever inactive clients send data create new fd and associate with old ssl object, similar to http://net-snmp.sourceforge.net/dev/agent/snmpDTLSUDPDomain_8c_source.html). is it possible? If you make sure that you don't send anything locally... Why not close the DTLS connection after some time and let the client do a new connect. You can cache the session and the client can use session resumption. if i look at DTLSv1_listen, i am thinking i can not distinguish between active/inactive client? 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? ClientHello messages are processed, so when the message or its attached cookie is invalid, an error will be returned. All other messages will be silently discarded and DTLSv1_listen() will not return, but simply wait for the next message. I'd also recommend session resumption for inactive clients. Best regards Robin thanks, manish On Wed, Jan 25, 2012 at 3:24 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: 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 server side also. However, DTLSv1_get_timeout/DTLSv1_handle_timeout is only necessary if you use select. after looking at : http://crypto.stanford.edu/~nagendra/papers/dtls.pdf i understood that i need to call DTLSv1_get_timeout/DTLSv1_handle_timeout incase of non-blocking socket. but after looking at example available on net dtls_udp_echo2.c, i see only client side take care of this. i feel only client side should try to reconnect, why server should try to resend message to client. Not sure about dtls_udp_echo2.c. You might want to take a look at the examples available at http://sctp.fh-muenster.de/dtls-samples.html please share if you know any example on this. Maybe Robin has more examples... Best regards Michael thanks, manish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager
Re: DTLSv1_get_timeout/DTLSv1_handle_timeout on server for each connection
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 server side also. However, DTLSv1_get_timeout/DTLSv1_handle_timeout is only necessary if you use select. after looking at : http://crypto.stanford.edu/~nagendra/papers/dtls.pdf i understood that i need to call DTLSv1_get_timeout/DTLSv1_handle_timeout incase of non-blocking socket. but after looking at example available on net dtls_udp_echo2.c, i see only client side take care of this. i feel only client side should try to reconnect, why server should try to resend message to client. Not sure about dtls_udp_echo2.c. You might want to take a look at the examples available at http://sctp.fh-muenster.de/dtls-samples.html please share if you know any example on this. Maybe Robin has more examples... Best regards Michael thanks, manish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: DTLSv1_get_timeout/DTLSv1_handle_timeout on server for each connection
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, if it is inactive for sometime then close the connection/socket and for inactive clients keep the ssl object cached, whenever inactive clients send data create new fd and associate with old ssl object, similar to http://net-snmp.sourceforge.net/dev/agent/snmpDTLSUDPDomain_8c_source.html). is it possible? If you make sure that you don't send anything locally... Why not close the DTLS connection after some time and let the client do a new connect. You can cache the session and the client can use session resumption. if i look at DTLSv1_listen, i am thinking i can not distinguish between active/inactive client? 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, 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 server side also. However, DTLSv1_get_timeout/DTLSv1_handle_timeout is only necessary if you use select. after looking at : http://crypto.stanford.edu/~nagendra/papers/dtls.pdf i understood that i need to call DTLSv1_get_timeout/DTLSv1_handle_timeout incase of non-blocking socket. but after looking at example available on net dtls_udp_echo2.c, i see only client side take care of this. i feel only client side should try to reconnect, why server should try to resend message to client. Not sure about dtls_udp_echo2.c. You might want to take a look at the examples available at http://sctp.fh-muenster.de/dtls-samples.html please share if you know any example on this. Maybe Robin has more examples... Best regards Michael thanks, manish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: maximum dtls connections
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 the TLS implementation. There you have a TCP socket per peer. For UDP, connected UDP socket are used. Have a look at the examples at http://sctp.fh-muenster.de/dtls-samples.html So the demultiplexing of incoming UDP packets is done by the kernel. If you want a single socket, you need either: * Change the implementation to have a 1-to-many relation between SSL objects and a BIO. * Do the demultiplexing with BIOs and copy the messages around. Best regards Michael __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: maximum dtls connections
On Dec 27, 2011, at 5:00 PM, Manish Yadav wrote: Hi Michael, thanks for info, could you please do let me know in case of dtls how much memory is allocated per connection? or any clue how do i Hi Manish, I don't know. But you need a socket per peer and might use select() for multiplexing which might also introduce some limits. For the memory overhead I suggest that you do some measurements... Best regards Michael calculate this? i want to define maximum number of concurrent connections could be supported for any dtls server. thanks, manish On Tue, Dec 27, 2011 at 12:31 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. Please report if your problem persists with the latest version of OpenSSL. See http://sctp.fh-muenster.de/dtls-patches.html for the patches which will be included in the next revision. Best regards Michael (gdb) bt #0 0x485b0297 in kill () from /lib/libc.so.7 #1 0x485b01f6 in raise () from /lib/libc.so.7 #2 0x485aedca in abort 28) from /lib/libc.so.7 #3 0x4852f9d5 in malloc () from /lib/libc.so.7 #4 0x4821ce1e in BN_clear_free () from /lib/libcrypto.so.6 #5 0x4821d4af in CRYPTO_malloc () from /lib/libcrypto.so.6 #6 0x4828f495 in ssl3_setup_buffers () from /usr/lib/libssl.so.6 #7 0x4828d5c5 in dtls1_read_bytes () from /usr/lib/libssl.so.6 #8 0x4828db82 in ssl3_renegotiate_check () from /usr/lib/libssl.so.6 #9 0x48282e28 in SSL_read () from /usr/lib/libssl.so.6 could you please let me know what could be reason for this? i am curious to understand how much memory ssl library allocates per connection/session, so that i could calculate maximum number of connection i could support using my server. thanks, manish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: maximum dtls connections
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 OpenSSL. See http://sctp.fh-muenster.de/dtls-patches.html for the patches which will be included in the next revision. Best regards Michael (gdb) bt #0 0x485b0297 in kill () from /lib/libc.so.7 #1 0x485b01f6 in raise () from /lib/libc.so.7 #2 0x485aedca in abort 28) from /lib/libc.so.7 #3 0x4852f9d5 in malloc () from /lib/libc.so.7 #4 0x4821ce1e in BN_clear_free () from /lib/libcrypto.so.6 #5 0x4821d4af in CRYPTO_malloc () from /lib/libcrypto.so.6 #6 0x4828f495 in ssl3_setup_buffers () from /usr/lib/libssl.so.6 #7 0x4828d5c5 in dtls1_read_bytes () from /usr/lib/libssl.so.6 #8 0x4828db82 in ssl3_renegotiate_check () from /usr/lib/libssl.so.6 #9 0x48282e28 in SSL_read () from /usr/lib/libssl.so.6 could you please let me know what could be reason for this? i am curious to understand how much memory ssl library allocates per connection/session, so that i could calculate maximum number of connection i could support using my server. thanks, manish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2658] [PATCH] Add TLS/DTLS Heartbeats
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 SSL_OP_NO_HB_REQUEST? For example a ctrl and using a bit in s-tlsext_heartbeat? In ssl_parse_serverhello_tlsext() and the heartbeat extension is absent should s-tlsext_heartbeat be set to an appropriate value? Reading through the draft specification it isn't clear to me how the heartbeat extension interacts with sessions. Section 2 does say This decision can be changed with every renegotiation. but it isn't clear how resumed sessions are treated. You always base the decision on the values provided in the client/server hellos. That is what is meant by the spec. In other words for a resumed session should the heartbeat extension in the client hello be recognised or should the value from the initial session be used? If the latter then the heartbeat value from the original session needs to be stored in the SSL_SESSION structure. It is not stored, but used for the client hello. Minor code nitpick. There are several unnecessary 0xff operations in the patch for fields which can never exceed 0xff or which are always less than 0xff (e.g. data[0], 0x02) The points related to the code will be addressed by Robin. Thanks for the code review! Best regards Michael PS: Thank you very for integrating the DTLS/SCTP code! Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Issue with dtls1_clear changes from issue #2506
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 to reproduce is for informational purposes only, as you did ask :) Great. And thanks for providing the code. Let us know if you find more issues with the DTLS code. Best regards Michael -- Paul __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Issue with dtls1_clear changes from issue #2506
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); SSL_CTX_set_options(dtls_context, SSL_OP_NO_TICKET); SSL * client_ssl = SSL_new(dtls_context); SSL_set_options(client_ssl_context, SSL_OP_NO_QUERY_MTU); BIO * client_ip_bio = BIO_new(BIO_s_mem()); BIO * client_op_bio = BIO_new(BIO_s_mem()); BIO_set_callback(client_op_bio, bio_callback); BIO_set_callback_arg(client_op_bio, NULL); SSL_set_bio(client_ssl, client_ip_bio, client_op_bio); SSL_set_verify(client_ssl, SSL_VERIFY_PEER, dtls_verify_callback); SSL_set_connect_state(client_ssl); SSL_set_mtu (client_ssl, 1400); SSL_do_handshake(client_ssl); 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. Best regards Michael -- Paul On 12/09/11 14:45, Robin Seggelmann wrote: Hi Paul, On Sep 9, 2011, at 4:56 PM, Paul Witty wrote: Since updating to OpenSSL 1.0.0e from 1.0.0d, I've been suffering a crash when connecting with DTLS. I've tracked this down to trying to perform a memcpy of (unsigned int)-13 in do_dtls1_write (where a length of -13 is passed all the way down from dtls1_do_Write, which seems to be because the MTU on the DTLS context is 0, despite having manually set it to a non-zero value. Further investigation shows that the change to dtls1_clear is clearing everything in the DTLS1_STATE, which includes my previously configured MTU. Preserving the value of the MTU across the memset in dtls1_clear fixes the issue. I just looked into this and I guess you're right. Currently, DTLS1_STATE is always cleared and thus the MTU set to 0 before starting the initial handshake. By default, the MTU will be retrieved from the socket of the BIO object, if possible, or the default value is used later on. If SSL_OP_NO_QUERY_MTU is set to prevent the retrieval from the BIO object to provide the MTU manually, it will use the MTU stored in DTLS1_STATE as it is, that is 0, which makes no sense whatsoever. So the MTU stored in DTLS1_STATE must not be cleared if SSL_OP_NO_QUERY_MTU is set, otherwise there is no proper way to set the MTU manually. I'll provide a patch shortly. Thanks for the report! Best regards Robin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS server on windows issues a sslv3 alert bad record mac for a client re-negotiating a connection
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: 1. Server issuing a SSLv3 ALERT BAD RECORD MAC 2. Server unable to detect an error when this happens as SSL_accept returns SSL_WANTS_READ/SSL_WANTS_WRITE where as Client it returns SSL error. (Using OpenSSL-1.0.0d + all DTLS patches + Heart beat feature) Server (Windows) Client (Linux or Windows) 1. Start server Start client (Once a DTLS connection is established and heart beats getting exchanged, Quickly restart the DTLS server.) 2. Restart server (The DTLS client enters into re-tries and continues retrying until the 12 connection attempts are exhausted) 3. Server runningClient attempting to revive the connection and continues sending heart beat messages Server does not send any responses for these messages (as it has not seen any new CLIENT HELLO messages yet) 4. Client closes this connection and starts a new connection with a new source port, sends a CLIENT HELLO Server responds with HELLO+VERIFY CLIENTHELLO + COOKIE SERVERHELL+SERV CERT+ SERVER KEY EXCHANGE CLIENT CERT + CLIENT KEY EXCHANGE+ CERT VERIFY SSLV3 ALERT BAD RECORD MAC SSL_Connect returns an error on client The DTLS server issues a SSLV3 ALERT BAD RECORD MAC when the client attempts a new connection after it has seen some heart beats for a client that is re-negotiating. Server issues the SSLv3 ALERT BAD RECORD MAC as part of SSL_accept which on server side returns SSL_WANT_READ or SSL_WANT_WRITE and does not return any ERROR where as the Client side on SSL_connect gets a SSL_ERROR So on the Server side there is no way to know that this connection is actually in error as SSL_accept does not issue any errors. Thanks, -Yogi __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2512] [PATCH] Fix for BIO_new_accept()
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 regards Michael bio.patch Description: Binary data
Re: s_client -reconnect with DTLS
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 followed by a client hello 3. No response is received from the server and the client begins re-transimitting the client hellos. Hi Nadhem, hmmm. Could you provide a capture file in .pcap format? You can send it privately to me. I'm interested in the epoch of the second client hello? Best regards Michael Regards, Nadhem From: Michael Tüxen michael.tue...@lurchi.franken.de To: N. J. nadh...@yahoo.com Cc: openssl-dev@openssl.org Sent: Thu, April 28, 2011 2:04:42 PM Subject: Re: s_client -reconnect with DTLS On Apr 22, 2011, at 11:40 PM, N. J. wrote: Thanks Michael and Robin, I will be waiting for your response. Hi Nadhem, could you try the patches Robin has posted yesterday to the list and report if they fix the problem you are experiencing? At least for us it fixed it. Thanks for reporting the problem. Best regards Michael Meanwhile, enjoy your Easter holiday. Cheers, Nadhem From: Michael Tüxen michael.tue...@lurchi.franken.de To: openssl-dev@openssl.org Cc: Andrey Kulikov amde...@gmail.com Sent: Sat, April 23, 2011 12:08:12 AM Subject: Re: s_client -reconnect with DTLS On Apr 22, 2011, at 2:56 PM, N. J. wrote: Thanks for the reply Andy, Please find hereafter the full description. I hope it is more clear. 1. What are you doing exactly: N I am testing the session resumption feature available with OpenSSL using s_client. My setup has a machine running s_client and another one running s_server. I am using OpenSSL 1.0.0a. I am testing with both, TLS and DTLS, and I uses the -reconnect handler to test the session resumption feature. For example: openssl s_client -connect 10.1.1.1:4443 -dtls1 -reconnect -reconnect- Drop and re-make the connection with the same Session-ID 3. What do you expect to see. N I expect to see the following in accordance to the documentation of OpenSSL: The client reconnects to the same server 5 times using the same session ID 2. What do you see. N With TLS all good, I can see the session getting resumed as per the OpenSSL's documentaton. I can see the client sending the session resumption hellos and the server replying back and both finishing the session resumption cycle multiple times. When I use DTLS instead, with the -dtls1 handler, I can see the client and server getting initially connected. However, when the client tries to reconnect by sending a session resumption client hello, the server never respond. Dear all, Robin Seggelmann and myself have verified that there is some issue using DTLS. He will look into this as soon as time permits... Best regards Michael Thanks, Nadhem From: Andrey Kulikov amde...@gmail.com To: openssl-dev@openssl.org Sent: Fri, April 22, 2011 3:26:56 PM Subject: Re: s_client -reconnect with DTLS Hello, I'm sure you'll get help faster, if you describe: 1. What are you doing exactly. 2. What do you see. 3. What do you expect to see. This is absolutelly necessary steps, as all telepathist is on vacation now. On 22 April 2011 15:50, N. J. nadh...@yahoo.com wrote: Hi again, I am not sure if someone can help confirming that the -reconnect option is broken with the dtls implementation? Please refer to my email below. Looking forward for your support. Regards, Nadhem Hi there, I have been trying to get the s_client -reconnect option working with my s_server but had no luck when using DTLS, -dtls1. I could not find any information why it is not working so I wonder if this is broken in openssl 1.0.0a. If so, is there any fix? Thanks in advance, Nadhem __ OpenSSL Projecthttp://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2069] [PATCH] IPv6 support for DTLS
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 for this here: http://cvs.openssl.org/chngview?cn=18709 Check this is OK. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2051] AutoReply: [PATCH] IPv6 support for s_client, s_server and DTLS
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 message has been automatically generated in response to the creation of a trouble ticket regarding: [PATCH] IPv6 support for s_client, s_server and DTLS, a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #2051]. Please include the string: [openssl.org #2051] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, r...@openssl.org - 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 default. When -6 is used as a command line argument, it will use IPv6. The code is #ifdefed with OPENSSL_USE_IPV6. It is assumed that a platform which defines OPENSSL_USE_IPV6 to non zero, supports * AF_INET6 * struct sockaddr_storage * gehostbyname2() * inet_pton() Best regards Michael
Re: [openssl.org #2069] AutoReply: [PATCH] IPv6 support for DTLS
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 automatically generated in response to the creation of a trouble ticket regarding: [PATCH] IPv6 support for DTLS, a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #2069]. Please include the string: [openssl.org #2069] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, r...@openssl.org - Dear all, this patch fixes the address handling in the DTLS code to support IPv6. Best regards Michael
Re: [openssl.org #2051] AutoReply: [PATCH] IPv6 support for s_client, s_server and DTLS
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 trouble ticket regarding: [PATCH] IPv6 support for s_client, s_server and DTLS, a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #2051]. Please include the string: [openssl.org #2051] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, r...@openssl.org - 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 default. When -6 is used as a command line argument, it will use IPv6. The code is #ifdefed with OPENSSL_USE_IPV6. It is assumed that a platform which defines OPENSSL_USE_IPV6 to non zero, supports * AF_INET6 * struct sockaddr_storage * gehostbyname2() * inet_pton() Best regards Michael
[openssl.org #2069] [PATCH] IPv6 support for DTLS
Dear all, this patch fixes the address handling in the DTLS code to support IPv6. Best regards Michael dtlsv6.patch Description: Binary data
Re: [openssl.org #2047] [PATCH][Beta3] Fix IPv6 handling in BIO_get_accept_socket()
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 not know. I have submitted an initial patch as #2051 which does what you call the ifdef mess, but it should be simple to verify that nothing breaks on legacy platforms. I really only care about the changes affecting the DTLS layer. The changes to s_client and s_server are for testing the stuff for DTLS and TLS. The OpenSSL devteam can use the patch or not, depending on the code style they want. I'll leave the decision up to them. Let's see... Best regards Michael On Sep 24, 2009, at 10:36 AM, Arkadiusz Miskiewicz wrote: 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. It's portable but it makes huge mess in the code. Take a look at openssh to see how to make ipv6 support in a clean way. They always use sockaddr_storage and getaddrinfo. configure tests for existence of these in system and if not found then compat headers/ library is included. This makes code clean, readable and avoids ugly #if mess. Please follow that way. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2051] [PATCH] IPv6 support for s_client, s_server and DTLS
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 default. When -6 is used as a command line argument, it will use IPv6. The code is #ifdefed with OPENSSL_USE_IPV6. It is assumed that a platform which defines OPENSSL_USE_IPV6 to non zero, supports * AF_INET6 * struct sockaddr_storage * gehostbyname2() * inet_pton() Best regards Michael ipv6.patch Description: Binary data
[openssl.org #2050] [PATCH] Fix handling of ENOTCONN and EMSGSIZE for dgram bios
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 error handling when testing with the DTLS/SCTP implementation. Best regards Michael errno.patch Description: Binary data
Re: [openssl.org #2047] [PATCH][Beta3] Fix IPv6 handling in BIO_get_accept_socket()
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 5:02 AM, live4t...@gmail.com via RT wrote:
On Fri, Sep 18, 2009 at 4:40 AM, Stephen Henson via RT
r...@openssl.org wrote:
[openssl-...@openssl.org - Thu Sep 17 16:32:23 2009]:
Hi, list
I downloaded OpenSSL 1.0 beta3 and found a bug in the function
BIO_get_accept_socket(), when dealing with an IPv6 address.
The line below copies the content of `res-ai_addr' to `server', but
sizeof(server) = 16, while for IPv6 address, res-ai_addrlen is 28.
i.e, sizeof(struct sockadr_in6). The missing 12 bytes will cause
the later bind() always fail.
struct sockaddr server,client;
server = *res-ai_addr;
To fix it, I use the type `struct sockaddr_storage' to hold the
address information so that its storage can satisfy any type of
socket
address, for example:
struct sockaddr_storage server,client;
memcpy(server, res-ai_addr, res-ai_addrlen);
Pls see the patch in attachment for details.
How portable is this code? Would it work on all systems not
supporting
IPv6 or should it all be surrounded by #if OPENSSL_USE_IPV6?
The patch basically did only one thing - use `struct sockaddr_storage'
instead of `struct sockaddr', so this patch should work on all
systems
that have `sockaddr_storage' defined - including various Linux
distributions
Windows series and FreeBSD etc.
`sockaddr_storage' is introduced back to year 1999, in RFC2553:
Basic Socket Interface Extensions for IPv6,
http://www.ietf.org/rfc/rfc2553.txt
This data structure can simplify writing code portable across
multiple address
families and platforms.
It seems that 'OPENSSL_USE_IPV6' is not in beta3? I found your patch
which introduced this macro at Aug, 26.
http://groups.google.com/group/mailing.openssl.cvs/browse_thread/thread/9c801a7da9d62f04?pli=1
It's a pity that I can't find a non-IPv6 system around which I can
test my
patch against. (BeOS/Netware?)To be really careful, I modified
my patch
to take care of 'OPENSSL_USE_IPV6', as shown below:
--begin--
--- a/crypto/bio/b_sock.c Fri Sep 18 09:59:57 2009 +0800
+++ b/crypto/bio/b_sock.c Fri Sep 18 10:59:08 2009 +0800
@@ -590,10 +590,19 @@
return(1);
}
+/* Use macro `openssl_sockaddr' to hide the difference between
+ * struct `sockaddr_storage' and `sockaddr'.
+ */
+#ifdef OPENSSL_USE_IPV6
+# define openssl_sockaddr sockaddr_storage
+# define sa_family ss_family
+#else
+# define openssl_sockaddr sockaddr
+#endif
int BIO_get_accept_socket(char *host, int bind_mode)
{
int ret=0;
- struct sockaddr server,client;
+ struct openssl_sockaddr server,client;
struct sockaddr_in *sa_in;
int s=INVALID_SOCKET,cs;
unsigned char ip[4];
@@ -665,7 +674,7 @@
}
if ((*p_getaddrinfo.f)(h,p,hint,res)) break;
- server = *res-ai_addr;
+ memcpy(server, res-ai_addr, res-ai_addrlen);
(*p_freeaddrinfo.f)(res);
goto again;
} while (0);
@@ -778,6 +787,11 @@
}
return(s);
}
+/* undefine the macro to avoid pollution. */
+#undef openssl_sockaddr
+#ifdef OPENSSL_USE_IPV6
+#undef sa_family
+#endif
int BIO_accept(int sock, char **addr)
---end---
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
Thanks,
Li Qun
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #2015] Patch
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 --prefix=$HOME/install on Mac OS X 10.5.8, it compiles cleanly but doesn't install. Apparently some Makefiles seem to be messed up: making install in crypto... ... making install in ssl... making install in engines... installing 4758cca cp: /Users/robinseggelmann/install//engines/lib4758cca.so.new: No such file or directory installing aep cp: /Users/robinseggelmann/install//engines/libaep.so.new: No such file or directory installing atalla cp: /Users/robinseggelmann/install//engines/libatalla.so.new: No such file or directory installing cswift cp: /Users/robinseggelmann/install//engines/libcswift.so.new: No such file or directory installing gmp cp: /Users/robinseggelmann/install//engines/libgmp.so.new: No such file or directory installing chil cp: /Users/robinseggelmann/install//engines/libchil.so.new: No such file or directory installing nuron cp: /Users/robinseggelmann/install//engines/libnuron.so.new: No such file or directory installing sureware cp: /Users/robinseggelmann/install//engines/libsureware.so.new: No such file or directory installing ubsec cp: /Users/robinseggelmann/install//engines/libubsec.so.new: No such file or directory installing padlock cp: /Users/robinseggelmann/install//engines/libpadlock.so.new: No such file or directory installing capi cp: /Users/robinseggelmann/install//engines/libcapi.so.new: No such file or directory make[1]: *** [install] Error 1 make: *** [install_sw] Error 1 The problem occurs since request #2003, check-in #18488. When I return engines/Makefile to a version before that patch (1.25), it installs cleanly. However, then the binaries in apps can't find the libraries because they got the wrong directory for the shared libs: openssl: /Users/robinseggelmann/install//libssl.1.1.0.dylib (compatibility version 1.1.0, current version 1.1.0) /Users/robinseggelmann/install//libcrypto.1.1.0.dylib (compatibility version 1.1.0, current version 1.1.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) The lib is missing there. It doesn't matter whether the new libdir parameter is used or not. Unfortunatley I'm not familiar with the Makefiles, so I can't provide a patch. I'd appreciate if this is fixed soon because I have to use links now, so the binaries can find the libs. That in turn has the disadvantage, that the binaries don't notice changes and I have to rebuild everything every time, which is very annoying. - Robin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2006] [PATCH]: Do not use multiple DTLS records for a single user message
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 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: 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_PLAIN_LENGTH) . dtls1_write_app_data_bytes and dtls1_write_bytes both perform this check whereas dtls1_write_app_data_bytes calls dtls1_write_bytes. Let's remove this sanity check from dtls1_write_app_data_bytes because it'll get checked anyway further down the call stack. What do you think? -Daniel __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2006] [PATCH]: Do not use multiple DTLS records for a single user message
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
[openssl.org #1991] [Patch] DTLS fix for -msg arg of s_client and s_server
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
Re: [openssl.org #1984][PATCH]: DTLS: ssl3_read_n() concatenates UDP datagrams in DTLS case
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 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 bytes of data and not
less. ssl3_read_n() calls read() - or I should say BIO_read() -
multiple times if that is necessary to get this amount of data.
Compare this with the read() function provided by the OS. If you
want to read 50 bytes then read() *might* return a chunk of data
that is shorter than 50 bytes. On the other hand ssl3_read_n() calls
read() multiple times if necessary to make sure you really get the
number of bytes you requested.
The key point is that ssl3_read_n() *concatenates* data from
successive read() calls which is fine for a byte oriented stream
like in the TCP case. But in the UDP case this is very bad because
each read() call returns one datagram and each datagram needs to be
treated i.e. parsed separately.
This patch aims to make sure that ssl3_read_n() *never* concatenates
two different datagrams. Also, dtls1_get_record() had to be changed
slightly to make it cope with datagrams that are shorter than the
minimum length required by the DTLS Record Header.
I'm asking the OpenSSL developers to double check this patch because
ssl3_read_n() is also used by the TLS code and not only by the DTLS
part.
The bug that this patch tries to fix can be used by an off path
attacker to hamper the ongoing connection. He could use for example
hping3 --udp --baseport 49468 --destport 4433 -d 1 -c 1 localhost
to send an UDP datagram of size 1 to one DTLS peer. This peer
buffers this packet and concatenates it with the next packet it
receives. The peer then tries to parse this concatenated piece of
data which fails.
An alternative to this patch would be IMHO to come up with a
replacement for ssl3_read_n() that is used in the DTLS case only.
-Daniel
--- s3_pkt.c 20 Apr 2009 11:33:11 - 1.74
+++ s3_pkt.c 8 Jul 2009 18:24:59 -
@@ -172,18 +172,21 @@
}
}
s-packet = rb-buf + rb-offset;
s-packet_length = 0;
/* ... now we can act as if 'extend' was set */
}
/* extend reads should not span multiple packets for DTLS */
- if ( (SSL_version(s) == DTLS1_VERSION || SSL_version(s) ==
DTLS1_BAD_VER)
- extend)
+
+ /* reads should *never* span multiple packets for DTLS because
+ * the underlying transport protocol is message oriented as opposed
+ * to byte oriented as in the TLS case. */
+ if ( (SSL_version(s) == DTLS1_VERSION || SSL_version(s) ==
DTLS1_BAD_VER))
{
if ( left 0 n left)
n = left;
}
/* if there is enough in the buffer from a previous read, take some
*/
if (left = n)
{
@@ -239,16 +242,24 @@
{
rb-left = left;
if (s-mode SSL_MODE_RELEASE_BUFFERS)
if (len+left == 0)
ssl3_release_read_buffer(s);
return(i);
}
left+=i;
+ /* reads should *never* span multiple packets for DTLS because
+ * the underlying transport protocol is message oriented as
opposed
+ * to byte oriented as in the TLS case. */
+ if ( (SSL_version(s) == DTLS1_VERSION || SSL_version(s) ==
DTLS1_BAD_VER))
+ {
+ if (n left)
+ n = left; /* makes the while condition false */
+ }
}
/* done reading, now the book-keeping */
rb-offset += n;
rb-left = left - n;
s-packet_length += n;
s-rwstate=SSL_NOTHING;
return(n);
--- d1_pkt.c 4 Jul 2009 12:04:06 - 1.36
+++ d1_pkt.c 8 Jul 2009 18:25:13 -
@@ -556,17 +556,19 @@
/* check if we have the header */
if ((s-rstate != SSL_ST_READ_BODY) ||
(s-packet_length DTLS1_RT_HEADER_LENGTH))
{
n=ssl3_read_n(s, DTLS1_RT_HEADER_LENGTH, s-s3-rbuf.len, 0);
/* read timeout is handled by dtls1_read_bytes */
if (n = 0) return(n); /* error or non-blocking */
- OPENSSL_assert(s-packet_length == DTLS1_RT_HEADER_LENGTH);
+ /* this packet contained a partial record, dump it
[openssl.org #1984] [PATCH]: DTLS: ssl3_read_n() concatenates UDP datagrams in DTLS case
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 read as an additional record instead of being discarded. I have added fixes for the above problems to Daniel's patch (and cleaned up some parentheses/whitespaces) and I'm attaching that patch. It should be included in 1.0.0 and 0.9.8. Best regards Michael dtls.patch Description: Binary data
Re: [openssl.org #1921] DTLS: openssl s_client broken in 1.0.0-beta2 due to lack of ECDHE support
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 May 13, 2009, at 6:27 PM, Stephen Henson via RT wrote: [steve - Wed May 13 14:29:35 2009]: [danie...@sent.com - Thu May 07 12:40:28 2009]: I hope that somebody can fix that problem or at least print out a log message saying No DTLS support for ECDHE This looks like this bit of DTLS code hasn't been updated for 1.0.0 . The code in question looks like it is similar (identical?) to that in s3_clnt.c . Maybe copying the ECDHE portion to d1_clnt.c et would fix this? Turns out that et al is rather large. For now I've added some code that doesn't include ECDHE ciphersuites in client hello. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1929] DTLS MTU bug
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 limited to
UDP/IPv4 and UDP/IPv6 without any options. Automatic path MTU
discovery does not work in any other case.
On other platforms this infrastructure is not supported and
therefore not used anymore. A general path MTU discovery needs
to be implemented in the future, but this patch should fix
what is right now available in OpenSSL.
Thanks to Daniel Mentz for reporting this bug and doing
some testing of the patch.
Best regards
Michael
diff -u -r openssl-1.0.0-beta2-orig/apps/s_client.c openssl-1.0.0-
beta2/apps/s_client.c
--- openssl-1.0.0-beta2-orig/apps/s_client.c2009-02-15
16:29:59.0 +0100
+++ openssl-1.0.0-beta2/apps/s_client.c 2009-05-16 22:51:04.0
+0200
@@ -320,7 +320,7 @@
BIO_printf(bio_err, -ssl3 - just use SSLv3\n);
BIO_printf(bio_err, -tls1 - just use TLSv1\n);
BIO_printf(bio_err, -dtls1- just use DTLSv1\n);
- BIO_printf(bio_err, -mtu - set the MTU\n);
+ BIO_printf(bio_err, -mtu - set the link layer MTU\n);
BIO_printf(bio_err, -no_tls1/-no_ssl3/-no_ssl2 - turn off that
protocol\n);
BIO_printf(bio_err, -bugs - Switch on all SSL
implementation bug workarounds\n);
BIO_printf(bio_err, -serverpref - Use server's cipher
preferences (only SSLv2)\n);
@@ -999,10 +999,10 @@
BIO_ctrl(sbio, BIO_CTRL_DGRAM_SET_SEND_TIMEOUT, 0,
timeout);
}
- if (socket_mtu 0)
+ if (socket_mtu 28)
{
SSL_set_options(con, SSL_OP_NO_QUERY_MTU);
- SSL_set_mtu(con, socket_mtu);
+ SSL_set_mtu(con, socket_mtu - 28);
}
else
/* want to do MTU discovery */
diff -u -r openssl-1.0.0-beta2-orig/apps/s_server.c openssl-1.0.0-
beta2/apps/s_server.c
--- openssl-1.0.0-beta2-orig/apps/s_server.c2009-04-16
19:22:47.0 +0200
+++ openssl-1.0.0-beta2/apps/s_server.c 2009-05-16 22:52:16.0
+0200
@@ -459,7 +459,7 @@
BIO_printf(bio_err, -tls1 - Just talk TLSv1\n);
BIO_printf(bio_err, -dtls1- Just talk DTLSv1\n);
BIO_printf(bio_err, -timeout - Enable timeouts\n);
- BIO_printf(bio_err, -mtu - Set MTU\n);
+ BIO_printf(bio_err, -mtu - Set link layer MTU\n);
BIO_printf(bio_err, -chain- Read a certificate chain\n);
BIO_printf(bio_err, -no_ssl2 - Just disable SSLv2\n);
BIO_printf(bio_err, -no_ssl3 - Just disable SSLv3\n);
@@ -1823,10 +1823,10 @@
BIO_ctrl(sbio, BIO_CTRL_DGRAM_SET_SEND_TIMEOUT, 0,
timeout);
}
- if (socket_mtu 0)
+ if (socket_mtu 28)
{
SSL_set_options(con, SSL_OP_NO_QUERY_MTU);
- SSL_set_mtu(con, socket_mtu);
+ SSL_set_mtu(con, socket_mtu - 28);
}
else
/* want to do MTU discovery */
diff -u -r openssl-1.0.0-beta2-orig/crypto/bio/bss_dgram.c
openssl-1.0.0-beta2/crypto/bio/bss_dgram.c
--- openssl-1.0.0-beta2-orig/crypto/bio/bss_dgram.c 2009-04-14
17:13:35.0 +0200
+++ openssl-1.0.0-beta2/crypto/bio/bss_dgram.c 2009-05-16
23:10:11.0 +0200
@@ -70,7 +70,9 @@
#include sys/timeb.h
#endif
+#ifdef OPENSSL_SYS_LINUX
#define IP_MTU 14 /* linux is lame */
+#endif
#ifdef WATT32
#define sock_write SockWrite /* Watt-32 uses same names */
@@ -272,6 +274,10 @@
bio_dgram_data *data = NULL;
long sockopt_val = 0;
unsigned int sockopt_len = 0;
+#ifdef OPENSSL_SYS_LINUX
+ socklen_t addr_len;
+ struct sockaddr_storage addr;
+#endif
data = (bio_dgram_data *)b-ptr;
@@ -330,24 +336,87 @@
#endif
break;
/* (Linux)kernel sets DF bit on outgoing IP packets */
-#ifdef IP_MTU_DISCOVER
case BIO_CTRL_DGRAM_MTU_DISCOVER:
- sockopt_val = IP_PMTUDISC_DO;
- if ((ret = setsockopt(b-num, IPPROTO_IP, IP_MTU_DISCOVER,
- sockopt_val, sizeof(sockopt_val))) 0)
- perror(setsockopt);
+#ifdef OPENSSL_SYS_LINUX
+ addr_len = (socklen_t)sizeof(struct sockaddr_storage);
+ memset((void *)addr, 0, sizeof(struct sockaddr_storage));
+ if (getsockname(b-num, (void *)addr, addr_len) 0)
+ {
+ ret = 0;
+ break;
+ }
+
