Re: opensssl 1.1.1g test failure(s)
> On 22. Apr 2020, at 10:38, Matt Caswell wrote:
>
>
>
> On 21/04/2020 23:45, Michael Tuexen wrote:
>>> Looks like the failing call is here:
>>>
>>> if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
>>> (const void *)&on, sizeof(on)) != 0) {
>> Can you provide a pointer to the code?
>
> Yes, its here:
>
> https://github.com/openssl/openssl/blob/fa555aa8970260c3e198d91709b2d4b3e40f8fa8/crypto/bio/b_sock2.c#L267-L282
OK. Thanks.
Could it be that on == 0, when you do the setsockopt() call? Disabling
IPV6_V6ONLY seems not to be supported
on OpenBSD:
From sys/netinet6/ip6_output.c:
case IPV6_V6ONLY:
/*
* make setsockopt(IPV6_V6ONLY)
* available only prior to bind(2).
* see ipng mailing list, Jun 22 2001.
*/
if (inp->inp_lport ||
!IN6_IS_ADDR_UNSPECIFIED(&inp->inp_laddr6))
{
error = EINVAL;
break;
}
/* No support for IPv4-mapped addresses. */
if (!optval)
error = EINVAL;
else
error = 0;
break;
I don't see a bug in OpenBSD here, or a strange behaviour. OpenBSD just does
not support mapped addresses.
Best regards
Michael
>
> Matt
Re: opensssl 1.1.1g test failure(s)
> On 21. Apr 2020, at 23:49, Matt Caswell wrote:
>
>
>
> On 21/04/2020 18:34, Claus Assmann wrote:
>> Thanks for the reply, below is the output, It seems it only fails
>> because the host doesn't support IPv6?
>
> Yes - it does seem to be an IPv6 problem. I don't recall any recent
> changes in this area. Were you successfully able to run the tests with
> previous versions of OpenSSL?
>
> Looks like the failing call is here:
>
>if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
> (const void *)&on, sizeof(on)) != 0) {
Can you provide a pointer to the code?
Best regards
Michael
>
> To which we get an errno indicating "Invalid argument". So it looks like
> your host has the relevant IPV6 macros defined (otherwise we would have
> got a compilation failure) - but doesn't understand them when used.
>
> If you're not using IPv6 on that host and this is the only test failure
> then it can probably be safely ignored.
>
> Matt
Re: [openssl-users] Query regarding the SCTP events for DTLS connections
> On 28. Sep 2017, at 20:36, mahesh gs wrote:
>
> Hi,
>
> We have an application which has SCTP connections we have secured the SCTP
> connections using the openssl DTLS. DTLS is working as expected other than
> the SCTP events.
>
> We use the API "BIO_new_dgram_sctp" to create a BIO objects and we register a
> callback function to openssl using API "BIO_dgram_sctp_notification_cb" to
> populate the SCTP events. I observe that openssl enables only authentication
> related events, do not enable any other events like association, shutdown etc.
>
> Code snippet from the API "BIO_new_dgram_sctp":
>
> event.sctp_authentication_event = 1;
>
> ret =
> setsockopt(fd, IPPROTO_SCTP, SCTP_EVENTS, &event,
>sizeof(struct sctp_event_subscribe));
> if (ret < 0) {
> BIO_vfree(bio);
> return (NULL);
> }
>
> Is there any specific reason for just enabling the authentication events ?
The authentication events are needed by the DTLS implementation and are
therefore
enabled by it. Other events have to be subscribed by the application. See
https://github.com/nplab/DTLS-Examples/blob/master/src/dtls_sctp_echo.c
for an example.
Best regards
Michael
>
> If yes, is there any way applications register for other events like
> shutdown, association etc. We have a requirement where based on the SCTP
> events application executes certain business logic.
>
> Thanks,
> Mahesh G S
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Query regarding DTLS handshake
> On 2. May 2017, at 08:03, mahesh gs wrote: > > > > On Sun, Apr 30, 2017 at 11:11 PM, Michael Tuexen > wrote: > > On 20. Apr 2017, at 20:01, mahesh gs wrote: > > > > Hi, > > > > This issue occur purely based on the time (sequence of events) at which SSL > > read_state_machine enter the post processing of certificate verify which is > > received from client. > > > > Handshake works fine if the certificate verify post processing is done > > before the next message arrives at SCTP socket layer (In your case may be > > there is a delay in receiving the next message at SCTP layer). Handshake > > works fine even in my environment some times. > Can you try the attached patch and report if it fixes the issue for you? > > I have tried with the patch provided by Matt. Our test results are > successful. Issue is fixed with the patch. OK, I see. It isn't fixed in our case. That is why I sent the patch. Thanks for the feedback. Best regards Michael > > Best regards > Michael > > > > > > > > > I added some debug statements, below is the debug statements. > > > > > > Debug statements when the handshake does not work > > > > > > > > Length of the next packet (Cipher spec change) is exactly 14 as i mentioned > > in - https://github.com/openssl/openssl/issues/3251 > > > > Debug logs when the handshake is successful > > > > > > > > If no message is waiting to be received at socket layer then handshake is > > successful. If message is waiting to be received at socket layer then the > > handshake will never be completed. > > > > > > Thanks, > > Mahesh G S > > > > On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha > > wrote: > > > > > > Matt Caswell wrote on 04/20/2017 03:23 PM: > > > > > > > > > On 20/04/17 14:19, Martin Brejcha wrote: > > >> > > >> > > >> Matt Caswell wrote on 04/20/2017 01:29 PM: > > >>> > > >>> > > >>> On 20/04/17 12:26, mahesh gs wrote: > > >>>> Hi Matt, > > >>>> > > >>>> Yes I raised github case for the same issue. I also tried running this > > >>>> call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and > > >>>> handshake is successful with the latest SNAPSHOT code which is not an > > >>>> official release. > > >>>> > > >>>> I checked the github repo history and observer that during commits on > > >>>> (11 th Jan) as a part of "Move state machine knowledge out of the > > >>>> record > > >>>> layer". "renegotiate" bit that is set to "2" in function > > >>>> "tls_post_process_client_hello" has been removed. May be that is > > >>>> causing > > >>>> the call flow to be successful in the latest SNAPSHOT release. > > >>>> > > >>>> I am assuming commits that are done on 11th Jan or later are not part > > >>>> of > > >>>> release openssl 01.01.00e > > >>> > > >>> Ah. No. That commit is in the dev branch only (scheduled for version > > >>> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why that > > >>> commit might help things, but probably a different solution is more > > >>> appropriate for 1.1.0. > > >>> > > >>> I'm looking at this issue at the moment. > > >>> > > >>> Matt > > >>> > > >> > > >> hi, > > >> > > >> btw: I've tested similar scenario and handshake works fine. > > >> test env: client and server on different VMs (rhel7.2, openssl 1.1.0e, > > >> non-blocking sockets and segmented certificate) > > >> So, it should work also with 1.1.0e version. > > > > > > Thanks. Did your handshake include client auth? I think this issue only > > > arises in that case. > > > > > > Matt > > > > > > > > > > yes, client auth with segmented certificate has been included. > > > > Martin > > > > > > > > > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Query regarding DTLS handshake
> On 20. Apr 2017, at 20:01, mahesh gs wrote: > > Hi, > > This issue occur purely based on the time (sequence of events) at which SSL > read_state_machine enter the post processing of certificate verify which is > received from client. > > Handshake works fine if the certificate verify post processing is done before > the next message arrives at SCTP socket layer (In your case may be there is a > delay in receiving the next message at SCTP layer). Handshake works fine even > in my environment some times. Can you try the attached patch and report if it fixes the issue for you? Best regards Michael dtls.patch Description: Binary data > > > I added some debug statements, below is the debug statements. > > > Debug statements when the handshake does not work > > > > Length of the next packet (Cipher spec change) is exactly 14 as i mentioned > in - https://github.com/openssl/openssl/issues/3251 > > Debug logs when the handshake is successful > > > > If no message is waiting to be received at socket layer then handshake is > successful. If message is waiting to be received at socket layer then the > handshake will never be completed. > > > Thanks, > Mahesh G S > > On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha > wrote: > > > Matt Caswell wrote on 04/20/2017 03:23 PM: > > > > > > On 20/04/17 14:19, Martin Brejcha wrote: > >> > >> > >> Matt Caswell wrote on 04/20/2017 01:29 PM: > >>> > >>> > >>> On 20/04/17 12:26, mahesh gs wrote: > Hi Matt, > > Yes I raised github case for the same issue. I also tried running this > call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and > handshake is successful with the latest SNAPSHOT code which is not an > official release. > > I checked the github repo history and observer that during commits on > (11 th Jan) as a part of "Move state machine knowledge out of the record > layer". "renegotiate" bit that is set to "2" in function > "tls_post_process_client_hello" has been removed. May be that is causing > the call flow to be successful in the latest SNAPSHOT release. > > I am assuming commits that are done on 11th Jan or later are not part of > release openssl 01.01.00e > >>> > >>> Ah. No. That commit is in the dev branch only (scheduled for version > >>> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why that > >>> commit might help things, but probably a different solution is more > >>> appropriate for 1.1.0. > >>> > >>> I'm looking at this issue at the moment. > >>> > >>> Matt > >>> > >> > >> hi, > >> > >> btw: I've tested similar scenario and handshake works fine. > >> test env: client and server on different VMs (rhel7.2, openssl 1.1.0e, > >> non-blocking sockets and segmented certificate) > >> So, it should work also with 1.1.0e version. > > > > Thanks. Did your handshake include client auth? I think this issue only > > arises in that case. > > > > Matt > > > > > > yes, client auth with segmented certificate has been included. > > Martin > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Query regarding DTLS handshake
> On 13. Apr 2017, at 11:11, mahesh gs wrote: > > Hi, > > We are running SCTP connections with DTLS enabled in our application. We have > adapted openssl version (openssl-1.1.0e) to achieve the same. > > We have generated the self signed root and node certificates for testing. We > have a strange problem with the incomplete DTLS handshake if we run the DTLS > client and DTLS server is different systems.If we run the DTLS client and > server in same system handshake is successful, handshake is not successful if > run client and server in different VM's. > > This strange problem happens only for SCTP/DTLS connection. With the same set > of certificates TCP/TLS connection is successful and we are able to exchange > the application data. > > I am attaching the code bits for SSL_accept and SSL_connect and also the > wireshark trace of unsuccessful handshake. Please assist me to debug this > problem. > > SSL_accept returns SSL_ERROR_WANT_READ(2) infinite times but SSL_connect is > called 4 or 5 times and select system call timeout. Which OS are you using? With a test program I could reproduce SSL_accept() returning SSL_ERROR_WANT_READ under FreeBSD, but not under Linux. Haven't figured out what the problem is. So if you are using FreeBSD we might experience the same problem... Best regards Michael > > Thanks, > Mahesh G S > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Query regarding DTLS handshake
> On 13. Apr 2017, at 19:26, Martin Brejcha wrote: > > > > Matt Caswell wrote on 04/13/2017 03:45 PM: >> >> >> On 13/04/17 10:11, mahesh gs wrote: >>> Hi, >>> >>> We are running SCTP connections with DTLS enabled in our application. We >>> have adapted openssl version (openssl-1.1.0e) to achieve the same. >>> >>> We have generated the self signed root and node certificates for >>> testing. We have a strange problem with the incomplete DTLS handshake if >>> we run the DTLS client and DTLS server is different systems.If we run >>> the DTLS client and server in same system handshake is successful, >>> handshake is not successful if run client and server in different VM's. >>> >>> This strange problem happens only for SCTP/DTLS connection. With the >>> same set of certificates TCP/TLS connection is successful and we are >>> able to exchange the application data. >>> >>> I am attaching the code bits for SSL_accept and SSL_connect and also the >>> wireshark trace of unsuccessful handshake. Please assist me to debug >>> this problem. >>> >>> SSL_accept returns SSL_ERROR_WANT_READ(2) infinite times but >>> SSL_connect is called 4 or 5 times and select system call timeout. >> >> Your trace shows the following interactions occurring: >> >> Client Server >> -- -- >> >> ClientHello > >> < ServerHello >> < Certificate >> < CertificateRequest >> < ServerDone >> Certificate -> >> ClientKeyExchange-> >> CertificateVerify-> >> CCS -> >> [Encrypted Finished] >> >> We would expect the server to continue with its own CCS and Encrypted >> Finished to complete the handshake. It seems that, for some reason, the >> server is not receiving (or acting upon) the client's second flight of >> messages. >> >> Normally in DTLS this sort of thing can happen due to lost messages etc >> but, obviously, with SCTP, this is not the case. Something else must be >> happening. >> > > There are some SCTP segmented messages during handshake. > May be some issue in reassembling could lead to strange behavior. > Can be observed these segmented messages also when the handshake is > successful? Which OS are you using? The OpenSSL code expects the kernel to reassemble the messages. Can you check if this is true using truss on FreeBSD or a similar tool on Linux? Best regards Michael > > M. > > >> In your description you say SSL_accept() gets called repeatedly and >> always gives SSL_ERROR_WANT_READ. Looking at your code it looks like you >> are calling pollSocketForEvents() after each accept. I am assuming that >> this is returning true each time (otherwise you would break out of the >> loop). This suggests that the "select" call thinks there is something to >> read from the underlying socket. Am I correct? The question is why >> doesn't OpenSSL then read that data out of the socket? >> >> Are you able to build a debug version of OpenSSL (run "config" with -d), >> and step through to figure out where it gets stuck. Is it attempting to >> read the data and failing, or does it not get as far attempting to read it? >> >> Another question: does this fail every time or does it sometimes work >> and sometimes not (which might suggest some race condition)? >> >> Matt >> > <0xB42AB632.asc>-- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Query regarding DTLS handshake
> On 13. Apr 2017, at 11:11, mahesh gs wrote: > > Hi, > > We are running SCTP connections with DTLS enabled in our application. We have > adapted openssl version (openssl-1.1.0e) to achieve the same. > > We have generated the self signed root and node certificates for testing. We > have a strange problem with the incomplete DTLS handshake if we run the DTLS > client and DTLS server is different systems.If we run the DTLS client and > server in same system handshake is successful, handshake is not successful if > run client and server in different VM's. > > This strange problem happens only for SCTP/DTLS connection. With the same set > of certificates TCP/TLS connection is successful and we are able to exchange > the application data. > > I am attaching the code bits for SSL_accept and SSL_connect and also the > wireshark trace of unsuccessful handshake. Please assist me to debug this > problem. > > SSL_accept returns SSL_ERROR_WANT_READ(2) infinite times but SSL_connect is > called 4 or 5 times and select system call timeout. We are currently implementing DTLS/SCTP support in a project and seem to experience a similar problem. Haven't hunted it down... Are you using blocking or unblocking I/O? Best regards Michael > > Thanks, > Mahesh G S > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Reg, TLS over SCTP (SOCK_SEQPACKET)
> On 1 Mar 2017, at 06:34, Sanjaya Joshi wrote: > > Hi, > Thank you Salz Rich for the confirmation. > So, whether application can perform manual TLS handshakes when SOCK_SEQPACKET > is used ? I this the SOCK_SEQPACKET model doesn't fit well to the way the openssl code is layed out. They basically want a one-to-one relation between a bio (for example a socket bio) and a TLS connection. So there is no muxing/demuxing ongoing. I'm wondering why you are sticking to the 1-to-many style sockets and why you are not considering DTLS over SCTP instead of TLS over SCTP. DTLS over SCTP using one-to-one style sockets (SOCK_STREAM) is supported by OpenSSL on Linux and FreeBSD. Best regards Michael > > Regards, > Sanjaya > > On Tue, Feb 28, 2017 at 7:03 PM, Salz, Rich wrote: > > But these calls don't work when SOCK_SEQPACKET (one-to-many connections) is > > used. Does openssl provide any alternatives for these calls ? Or an > > application need to perform the TLS handshakes manually ? > > This is not supported, and there are no demo's available. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] DTLS for SCTP connections
> On 24 Feb 2017, at 10:31, mahesh gs wrote: > > Hi, > > I did some more search regarding this problem and found that its a defect in > kernel SCTP. OS was built with linux kernel version 2.6 which is quite old. > > Defect Link : https://sourceforge.net/p/lksctp/mailman/message/27729264/ > > I upgraded to RHEL 7.1 and the problem resolved. > Great. Thanks for letting us know. Best regards Michael > Thanks for your support. > > On Thu, Feb 23, 2017 at 10:43 AM, mahesh gs wrote: > Hi Michael, > > I am using "Red Hat Enterprise Linux Server release 6.4 (Santiago)" and > openssl version is 1.1.0. > > SCTP version : > > [root@localhost DIAMETER]# rpm -qa | grep -i "sctp" > lksctp-tools-1.0.10-5.el6.x86_64 > [root@localhost DIAMETER]# rpm -qi lksctp-tools-1.0.10-5.el6.x86_64 > Name: lksctp-tools Relocations: (not relocatable) > Version : 1.0.10Vendor: Red Hat, Inc. > Release : 5.el6 Build Date: Mon 22 Feb 2010 > 12:24:33 PM CET > Install Date: Wed 08 Feb 2017 10:08:12 AM CET Build Host: > hs20-bc1-2.build.redhat.com > Group : System Environment/Libraries Source RPM: > lksctp-tools-1.0.10-5.el6.src.rpm > Size: 203688 License: GPLv2 and GPLv2+ and > LGPLv2 and BSD > Signature : RSA/8, Mon 16 Aug 2010 08:17:01 PM CEST, Key ID 199e2f91fd431d51 > Packager: Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> > URL : http://lksctp.sourceforge.net > Summary : User-space access to Linux Kernel SCTP > Description : > This is the lksctp-tools package for Linux Kernel SCTP (Stream Control > Transmission Protocol) Reference Implementation. > > > > Thanks, > Mahesh G S > > On Wed, Feb 22, 2017 at 8:33 PM, Michael Tuexen > wrote: > > On 22 Feb 2017, at 07:47, mahesh gs wrote: > > > > Hi, > > > > Thank you for sharing the sample code. > > > > I tried running SCTP DTLS Echo server and client. I am facing strange > > problem "ssl_connect" hangs on the client side, even the "ssl_accept" hangs > > on the server side. > > > > Client side back trace > > > > (gdb) bt > > #0 0x003db4c0ea10 in __recvmsg_nocancel () from /lib64/libpthread.so.0 > > #1 0x77a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073 > > "\026\376\377", outl=17741) at bss_dgram.c:1178 > > #2 0x77a597a9 in BIO_read (b=0x6223f0, out=0x629073, outl=17741) > > at bio_lib.c:210 > > #3 0x77db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741, > > extend=) at s3_pkt.c:258 > > #4 0x77dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676 > > #5 0x77dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22, > > buf=0x7ffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938 > > #6 0x77dcdda5 in dtls1_get_message_fragment (s=0x622c70, > > st1=, stn=4449, max=30, ok=0x7ffee09c) > > at d1_both.c:908 > > #7 0x77dce414 in dtls1_get_message (s=0x622c70, st1=4448, > > stn=4449, mt=14, max=30, ok=0x7ffee09c) at d1_both.c:512 > > #8 0x77dacaf9 in ssl3_get_server_done (s=0x622c70) at > > s3_clnt.c:2458 > > #9 0x77dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466 > > #10 0x00402f75 in start_client(char*, char*, int, int, int) () > > #11 0x00403573 in main () > > > > > > Server side back trace > > > > (gdb) info threads > > 2 Thread 0x7793c700 (LWP 20161) 0x003db4c0ea2d in recvmsg () > > from /lib64/libpthread.so.0 > > * 1 Thread 0x7793e720 (LWP 20155) 0x003db4c0e84d in accept () from > > /lib64/libpthread.so.0 > > (gdb) t 2 > > [Switching to thread 2 (Thread 0x7793c700 (LWP 20161))]#0 > > 0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > > (gdb) bt > > #0 0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > > #1 0x77a633a6 in BIO_dgram_sctp_wait_for_dry (b=0x70001930) at > > bss_dgram.c:1803 > > #2 0x77dc7830 in dtls1_accept (s=0x78c0) at d1_srvr.c:403 > > #3 0x004021ee in connection_handle(void*) () > > #4 0x003db4c07851 in start_thread () from /lib64/libpthread.so.0 > > #5 0x003db48e890d in clone () from /lib64/libc.so.6 > > (gdb) > > > > > > I am also attaching the wireshark trace (port 4443) and a server key for > > decoding wireshark. > > > > Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443 > > > > Comm
Re: [openssl-users] DTLS for SCTP connections
> On 22 Feb 2017, at 07:47, mahesh gs wrote: > > Hi, > > Thank you for sharing the sample code. > > I tried running SCTP DTLS Echo server and client. I am facing strange problem > "ssl_connect" hangs on the client side, even the "ssl_accept" hangs on the > server side. > > Client side back trace > > (gdb) bt > #0 0x003db4c0ea10 in __recvmsg_nocancel () from /lib64/libpthread.so.0 > #1 0x77a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073 > "\026\376\377", outl=17741) at bss_dgram.c:1178 > #2 0x77a597a9 in BIO_read (b=0x6223f0, out=0x629073, outl=17741) at > bio_lib.c:210 > #3 0x77db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741, > extend=) at s3_pkt.c:258 > #4 0x77dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676 > #5 0x77dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22, > buf=0x7ffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938 > #6 0x77dcdda5 in dtls1_get_message_fragment (s=0x622c70, st1= optimized out>, stn=4449, max=30, ok=0x7ffee09c) > at d1_both.c:908 > #7 0x77dce414 in dtls1_get_message (s=0x622c70, st1=4448, stn=4449, > mt=14, max=30, ok=0x7ffee09c) at d1_both.c:512 > #8 0x77dacaf9 in ssl3_get_server_done (s=0x622c70) at s3_clnt.c:2458 > #9 0x77dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466 > #10 0x00402f75 in start_client(char*, char*, int, int, int) () > #11 0x00403573 in main () > > > Server side back trace > > (gdb) info threads > 2 Thread 0x7793c700 (LWP 20161) 0x003db4c0ea2d in recvmsg () from > /lib64/libpthread.so.0 > * 1 Thread 0x7793e720 (LWP 20155) 0x003db4c0e84d in accept () from > /lib64/libpthread.so.0 > (gdb) t 2 > [Switching to thread 2 (Thread 0x7793c700 (LWP 20161))]#0 > 0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > (gdb) bt > #0 0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > #1 0x77a633a6 in BIO_dgram_sctp_wait_for_dry (b=0x70001930) at > bss_dgram.c:1803 > #2 0x77dc7830 in dtls1_accept (s=0x78c0) at d1_srvr.c:403 > #3 0x004021ee in connection_handle(void*) () > #4 0x003db4c07851 in start_thread () from /lib64/libpthread.so.0 > #5 0x003db48e890d in clone () from /lib64/libc.so.6 > (gdb) > > > I am also attaching the wireshark trace (port 4443) and a server key for > decoding wireshark. > > Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443 > > Command used on client side : ./dtls_sctp_echo -L 16.181.38.161 -p 4443 -l 50 > -n 5 16.181.38.161 > > Thanks in advance for your valuable input I've CCed Irene, who did some testing recently on FreeBSD, where the implementation works. The server is waiting for a sender dry event which it should get. Which version of OpenSSL are you using and which OS are you using? Best regards Michael > > Regards, > Mahesh G S > > > > On Tue, Feb 21, 2017 at 2:28 PM, Michael Tuexen > wrote: > > On 21 Feb 2017, at 09:53, mahesh gs wrote: > > > > Hi, > > > > We have a client, server applications that is using SCTP as a transport > > protocol. We have to secure the connections using DTLS. I am using openssl > > version 1.0.2 which supports DTLS. But the problem i am facing is usage of > > DTLS SCTP related API's. Openssl documentation does not clearly explain all > > the SCTP related API's and usage sequence. > > > > I have tried going though internet and found most of the sites redirect to > > one link for SCTP DTLS sample code. But this link is not working. > > > > http://sctp.fh-muenster.de/dtls-samples.html > Try > http://web.archive.org/web/20150617012520/http://sctp.fh-muenster.de/dtls-samples.html > and yes, we need to bring the machine up again. > > Best regards > Michael > > > > If any of you has an sample code of DTLS adaptation for SCTP. It would > > immensely help me for my work. > > > > Looking forward to your valuable inputs. > > > > Thanks, > > Mahesh G S > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] DTLS for SCTP connections
> On 21 Feb 2017, at 09:53, mahesh gs wrote: > > Hi, > > We have a client, server applications that is using SCTP as a transport > protocol. We have to secure the connections using DTLS. I am using openssl > version 1.0.2 which supports DTLS. But the problem i am facing is usage of > DTLS SCTP related API's. Openssl documentation does not clearly explain all > the SCTP related API's and usage sequence. > > I have tried going though internet and found most of the sites redirect to > one link for SCTP DTLS sample code. But this link is not working. > > http://sctp.fh-muenster.de/dtls-samples.html Try http://web.archive.org/web/20150617012520/http://sctp.fh-muenster.de/dtls-samples.html and yes, we need to bring the machine up again. Best regards Michael > > If any of you has an sample code of DTLS adaptation for SCTP. It would > immensely help me for my work. > > Looking forward to your valuable inputs. > > Thanks, > Mahesh G S > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: SSL_MODE_ENABLE_PARTIAL_WRITE does not work in DTLS
On 31 Aug 2014, at 14:34, Iñaki Baz Castillo wrote: > It is sad to know that this question will never be replied by the > OpenSSL developers. May I know what I should do? I am not sure whether > this is a bug or not, should I report it as a bug? If so, how? The > OpenSSL homepage provides NO WAY to report a bug. > > This project really annoys me. > > 2014-08-21 19:34 GMT+02:00 Iñaki Baz Castillo : >> Hi, >> >> I've a SSL in DTLS mode. Previously in its SSL_CTX I set the >> SSL_MODE_ENABLE_PARTIAL_WRITE option to enable SSL_write() to return >> less than the given data length. >> >> It does not work. I call SSL_write() by passing a very long data >> (65536) and it still returns -1. So, in case I want to write a big >> data over a DTLS UDP connection, how can I do that? I expected that I don't think you can do that. A user message is mapped into a DTLS message. This is limited by the protocol (I think there is a limit in the 16 KB range) and by the MTU of the path, which is normally about 1500 bytes. Sending larger frames would require IP level fragmentation, which normally has to be avoided. >> SSL_MODE_ENABLE_PARTIAL_WRITE would work in a way that SSL_write() >> returns a value suitable for a UDP datagram so I send it and then call >> SS_write() again by passing the following chuck in my data buffer. >> >> Is it a bug? or am I missing something? Not sure... I think allowing this in the API doesn't make much sense. Best regards Michael >> >> Thanks a lot. >> >> -- >> Iñaki Baz Castillo >> > > > > -- > Iñaki Baz Castillo > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Possible Issue
On 14 Apr 2014, at 08:33, Me wrote: > possible vulnerable file: openssl-1.0.1g/ssl/d1_clnt.c > Line: 155 unsigned char sctpauthkey[64]; > > fixed sized arrays can be overflowed. To fix the problem, use functions that > limit length, or ensure that the size is larger than the maximum possible > length. It's avoid us attack like buffer overflow! Hi, as far as I read the code, the variable sctpauthkey is filled via SSL_export_keying_material(s, sctpauthkey, sizeof(sctpauthkey), labelbuffer, sizeof(labelbuffer), NULL, 0, 0); which only fills in sizeof(sctpauthkey) bytes. It is then used in BIO_ctrl(SSL_get_wbio(s), BIO_CTRL_DGRAM_SCTP_ADD_AUTH_KEY, sizeof(sctpauthkey), sctpauthkey); which is also fine, I think. The constant 64 comes from the second sentence in https://tools.ietf.org/html/rfc6083#section-4.8 Please let me know how an overflow can happen. Best regards Michael > > Best Regards! > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On 12 Apr 2014, at 21:43, Michael Smith wrote: > > On Apr 12, 2014, at 3:08 PM, Michael Tuexen > wrote: >>> >> I have read the rumor. It is wrong. > > "Introduced with intent" vs. "known to the NSA" -- two > different things, right? My statement was referring to the "Introduced with intend". I personally don't know anything about "known to the NSA". Best regards Michael > > I don't have any direct knowledge of what goes on in the > NSA, but if they don't have a whole cubicle farm full > of people looking for vulnerabilities, I'd be surprised. > OpenSSL would be an obvious high-value target for scrutiny > just because of its ubiquity. > > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On 12 Apr 2014, at 21:30, Matthias Apitz wrote: > El día Saturday, April 12, 2014 a las 09:08:15PM +0200, Michael Tuexen > escribió: > >>> What is the exact bug, can someone show a svn/git diff of the first >>> source version having the bug? >> http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 >>> > > Hi, > > Thanks for the git diff (and the other statements). Could you please be > so kind and point to the exact place of the offending statement (or > missing boundary check) in the 19 *.[ch] files? I only want (as a C > programmer) to get my own impression of the nature of the issue. Thanks Here is the commit of the fix: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=731f431497f463f3a2a97236fe0187b11c44aead Best regards Michael > > matthias > > -- > Sent from my FreeBSD netbook > > Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 > UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) > UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On 12 Apr 2014, at 17:43, Matthias Apitz wrote: > El dÃa Wednesday, April 09, 2014 a las 01:05:22AM -0700, monloi perez > escribió: > >> True. Thanks for the quick reply. >> >> >> On Wednesday, April 9, 2014 3:33 PM, Alan Buxey >> wrote: >> >> https://www.openssl.org/news/changelog.html >> >> 1.0.1 introduced the heartbeat support. >> >> 1.0.0 and earlier are fortunate in that they didnt have it.but then they >> didnt have things to stop you from being BEASTed so some you win, some you >> lose. ;) >> >> alan > > Hello, > > As you can read in the above change log, heartbeat support was > introduced in version 1.0.1 of openssl. Does this mean that also the bug > was introduced with this version in March 2012, or was it later? As the security advisory states, the bug showed up in version 1.0.1 released in March 2012. > > What is the exact bug, can someone show a svn/git diff of the first > source version having the bug? http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 > > Is it possible that the bug was introduced with intention (to make > use of it later)? > > Here in Germany in the news we have rumor, that the bug was used by NSA, > of course the American Goverment says no. I have read the rumor. It is wrong. I was Robins boss at the time he did the work, he worked in my lab. Neither me personally nor my lab at the university had any cooperations with any security agency (from any country). Robin worked on the OpenSSL code for multiple years. During his work with the DTLS code, he fixed a lot of bugs in that code and implemented some features, like the support of RFC 6520. He worked in the public, all his patches were submitted with his name. The intention was to improve OpenSSL, not to introduce bugs. Unfortunately, the patch above contained a bug which wasn't catched, neither by Robin, nor by the reviewers, nor by the people using the stack. It is a bug. A bug with a huge impact. Nothing more. Nothing less. Best regards Michael Tüxen > > Thanks > > matthias > > -- > Matthias Apitz | /"\ ASCII Ribbon Campaign: > E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail > WWW: http://www.unixarea.de/ | X- No proprietary attachments > phone: +49-170-4527211 | / \ - Respect for open standards > | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CVE 2014-0160 -- disabling the heartbeat
On 08 Apr 2014, at 19:19, mclellan, dave wrote: > Hi all. There are two mitigations possible for the recently discovered > Heartbleed attack. > > Ø Upgrade to 1.0.1g, released yesterday with a fix > Ø Recompile a vulnerable release with –DOPENSSL_NO_HEARTBEATS > > Suppose we choose the latter. We might be installed into a server host in a > shop with an earlier release of our software on the clients. Is it an issue > if the server refuses to do heartbeats but the client expects to use them? > or is there a negotiation element that determines their shared capability WRT > heartbeats? Support is negotiated as part of the TLS handshake. So the client has always to deal with the case that the server doesn't support it or does not allow the client to send Heartbeats. Best regards Michael > > Thanks. > > +-+-+-+-+-+-+-+-+- > Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. > Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 > Office:508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com > +-+-+-+-+-+-+-+-+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS heartbeats
On Apr 22, 2013, at 7:11 PM, Tamer Refaei wrote: > I guess my confusion was that I expected heartbeats to be > automatically/frequently sent by DTLS but it seems they have to be > triggered by your application by an SSL_heartbeat function call. Am I > right? Correct. Best regards Michael > > On Fri, Apr 19, 2013 at 3:58 PM, Dr. Stephen Henson wrote: >> On Fri, Apr 19, 2013, Tamer Refaei wrote: >> >>> I am using openssl 1.1.0-dev. How exactly do I turn on heartbeats for >>> DTLSv1.2? They seem to not be on by default. >>> >> >> What makes you think that? >> >> Just tested them with s_server/s_client and they seem 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 >> User Support Mailing Listopenssl-users@openssl.org >> Automated List Manager majord...@openssl.org > > > > -- > > -- > Tamer Refaei > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Crash in DTLS (version 1.0.1c)
On Sep 17, 2012, at 3:25 PM, Fredrik Jansson wrote: > Hi! > > I have found a crash in the DTLS code (OpenSSL 1.0.1c), unfortunately I don't > have a way of reproducing it. This has happened to one client (of many) in a > production environment, so it's not a common problem. > > The code that crashes is a DTLS client calling SSL_heartbeat. > > What is odd is the code at d1_pkt.c: 1460: > OPENSSL_assert(0); /* XDTLS: want to see if we ever get here */ > > I guess the answer is yes, sometimes you get here :) I really would like to understand why... I see two possibilities: 1. There is a code path which results in hitting this. 2. Memory corruption. > > The callstack is: > > OpenSSLDie openssl-1.0.1c/crypto/cryptlib.c:918 > do_dtls1_write openssl-1.0.1c/ssl/d1_pkt.c:1460 > dtls1_write_bytes openssl-1.0.1c/ssl/d1_pkt.c:1442 > dtls1_heartbeat openssl-1.0.1c/ssl/d1_both.c:1575 > ssl3_ctrl openssl-1.0.1c/ssl/s3_lib.c:3334 > dtls1_ctrl openssl-1.0.1c/ssl/d1_lib.c:267 > SSL_ctrl openssl-1.0.1c/ssl/ssl_lib.c:1104 This only show how we run into the condition, not what is causing it. Unfortunately. > > I will try my best to get more information about this. It would be great to have a way to reproduce it. > > Best regards, > Fredrik __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL port in FreeBSD: DTLS networking problem (DF bit not set)
On Jun 3, 2012, at 11:35 PM, Oleg Moskalenko wrote: > Hi Michael > > You are right, this is SHOULD, not MUST, but still it is strongly > recommended. Hi Oleg, my point was that the application SHOULD be able to control the sending of the DF bit, not that the DF bit always has to be set... > > My point was that, probably, OpenSSL should make the things as universally > and portable as possible... it allows setting this bit to DF for Linux, and > if FreeBSD provides the same facility, then why not use it, to make the > application code as portable as possible ? I agree, that is why we were looking into the it... > > And you are right, setting DF bit is not enough for PMTU discovery. But it > would still be nice to have. > > You mentioned a patch, where can I find it ? I guess Robin can polish it a bit and submit it to the OpenSSL maintainers for inclusion... Once it has been submitted we can also put it on our web page with the OpenSLL patches. I can drop you a note... Best regards Michael > > Thanks ! > Oleg > >> -Original Message- >> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- >> us...@openssl.org] On Behalf Of Michael Tuexen >> Sent: Sunday, June 03, 2012 1:31 PM >> To: openssl-users@openssl.org >> Cc: Robin Seggelmann >> Subject: Re: OpenSSL port in FreeBSD: DTLS networking problem (DF bit >> not set) >> >> On Jun 3, 2012, at 7:56 PM, Oleg Moskalenko wrote: >> >>> Hi >>> >>> I am using the OpenSSL library with FreeBSD, primarily the DTLS >> functionality. Unfortunately, what I discovered, is that the DTLS >> networking requirements are implemented for Linux only in OpenSSL code. >> That code is protected by #ifdef OPENSSL_SYS_LINUX and nothing is done >> for other OSes (see the file bss_dgram.c, line 534 in OpenSSL 1.0.1c). >>> >>> For FreeBSD, that would be an easy fix - just use the socket option >> IP_DONTFRAG on IPPROTO_IP level. >>> >>> Of course, a developer can always "manually" set the DF flag on the >> UDP socket, but then the application code would not be portable. >>> >>> It can be fixed in either original OpenSSL code, or in FreeBSD "port" >> patch for OpenSSL. >>> >>> Thanks ! >>> Oleg Moskalenko >>> >>> Formal bug description: >>> >>> OpenSSL version: all versions with DTLS support. >>> OS name: FreeBSD 7.x, 8.x, 9.x >>> Compiler: any >>> Application: any DTLS application >>> Problem description: The DTLS packets do not have "Don't fragment" >> IP flag set (DF bit). According to DTLS specs, it must always be set. >> In OpenSSL code, DF bit is supported only for Linux. >> Where is it specified, that the DF bit must always be set. In >> http://tools.ietf.org/html/rfc6347 >> I only see: >> - Where allowed by the underlying transport protocol, the upper >> layer protocol SHOULD be allowed to set the state of the DF bit >> (in IPv4) or prohibit local fragmentation (in IPv6). >> The problem is that not all OSes support controlling the DF bit. >> FreeBSD >> allows it. We do have a patch, which allows controlling it on platforms >> which support it. >> >> However, providing a way to do PMTU discovery in a portable way is more >> complex... >> >> Best regards >> Michael >>> >> >> __ >> OpenSSL Project http://www.openssl.org >> User Support Mailing Listopenssl-users@openssl.org >> Automated List Manager majord...@openssl.org > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL port in FreeBSD: DTLS networking problem (DF bit not set)
On Jun 3, 2012, at 7:56 PM, Oleg Moskalenko wrote: > Hi > > I am using the OpenSSL library with FreeBSD, primarily the DTLS > functionality. Unfortunately, what I discovered, is that the DTLS networking > requirements are implemented for Linux only in OpenSSL code. That code is > protected by #ifdef OPENSSL_SYS_LINUX and nothing is done for other OSes (see > the file bss_dgram.c, line 534 in OpenSSL 1.0.1c). > > For FreeBSD, that would be an easy fix – just use the socket option > IP_DONTFRAG on IPPROTO_IP level. > > Of course, a developer can always “manually” set the DF flag on the UDP > socket, but then the application code would not be portable. > > It can be fixed in either original OpenSSL code, or in FreeBSD “port” patch > for OpenSSL. > > Thanks ! > Oleg Moskalenko > > Formal bug description: > > OpenSSL version: all versions with DTLS support. > OS name: FreeBSD 7.x, 8.x, 9.x > Compiler: any > Application: any DTLS application > Problem description: The DTLS packets do not have “Don’t fragment” IP flag > set (DF bit). According to DTLS specs, it must always be set. In OpenSSL > code, DF bit is supported only for Linux. Where is it specified, that the DF bit must always be set. In http://tools.ietf.org/html/rfc6347 I only see: - Where allowed by the underlying transport protocol, the upper layer protocol SHOULD be allowed to set the state of the DF bit (in IPv4) or prohibit local fragmentation (in IPv6). The problem is that not all OSes support controlling the DF bit. FreeBSD allows it. We do have a patch, which allows controlling it on platforms which support it. However, providing a way to do PMTU discovery in a portable way is more complex... Best regards Michael > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS Handshake TImer
On Mar 15, 2012, at 7:39 PM, Erwin Himawan wrote: > Hi Folks, > > Can anybody shed some light where to adjust DTLS flight timer? I think they are hardcoded. An initial value of 1 second and doubling on timeout as specified in http://tools.ietf.org/html/rfc6347#section-4.2.4.1 Best regards Michael > > Thks, > Erwin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS - cannot make client detect restarted server
On Jan 3, 2012, at 11:17 AM, Fredrik Jansson wrote: > Hi all, > > I am having some trouble with DTLS. > > I can easily get into a situation where my server is restarted (or the > client's SSL object is removed for other reasons) and the client may not know. > > Now when the client sends data to the server, a new SSL object is created but > the server is stuck in: > > Info Tue Jan 3 09:55:59 2012 > All.DTLS ssl_info_cb: SSL_accept: error in SSLv3 read client hello B > Info Tue Jan 3 09:55:59 2012 > All.DTLS SSL_read: rc: -1, err: 2 > > i.e. it returns SSL_WANT_READ and of course expects a handshake, but no alert > or similar is sent to the client to indicate the client needs to take some > measure. The client happily keeps sending data. The message should go to the listener and discarded there. If not, it is a problem. > > Any help on how to resolve this would be greatly appreciated. As indicated in my private answer: Your application must detect that the peer is dead. It can do that with its own messages or use DTLS heartbeats for that. Best regards Michael > > Best regards, > Fredrik Jansson > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_OP_NO_QUERY_MTU problem in openssl 1.0.0.e
On Oct 19, 2011, at 11:45 PM, Oleg Moskalenko wrote: > Hi > > I installed the new OpenSSL version and I immediately ran into a problem with > DTLS: when the option SSL_OP_NO_QUERY_MTU is set, then the SSL_connect > command produces a segmentation fault. Have you tried the first bug fix available at http://sctp.fh-muenster.de/dtls-patches.html It should address the problem. It will be included in the next release. > > I am using Linux Ubuntu 11.04. > > If I want to use my own discovered MTU, then I have to use that option. > Otherwise, the system would ignore my MTU and use whatever the IP_MTU > getsockopt on UDP socket returns. > > Unfortunately, I am using different platforms, and MTU discovery is supported > in OpenSSL only on Linux platform. I need it working on FreeBSD, too, and I > have to discover MTU myself. > > Is this a known bug ? Yes... > > By the way, are there any plans to support FreeBSD MTU discovery ? We have a patch which adds PMTU discovery and used DTLS heartbeats for that. Once the heartbeats are approved as an RFC we will contribute code for that and the PMTU stuff. Best regards Michael > > Thanks ! > Oleg Moskalenko > > > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS cookies rendered useless by SSL_accept behavior
On Jul 24, 2011, at 12:40 AM, com...@gmx.ch wrote: > Hi, > > > I got some code which uses nonblocking dtls via self fed bios. > If a unknown session comes up, I create a new session, feed/drain the > sessions bios from/to the wire until SSL_accept returns success. > > Now, I added DTLS cookies. > I expected SSL_accept to return an error if a ClientHello packet is received > without the cookie, so I could free the resources for the session and wait > for the remote to resent its ClientHello with the cookie, so I can allocate > the resources for a new session again and finally complete the handshake. > > Turns out SSL_accept silently accepts a ClientHello without cookie, for > packets without a cookie, the cookie verify callback is not called too, so I > can't free any resources. You are supposed to call DTLSv1_listen() to handle the front state... > The timers do not help me either, as I'd have to keep state for the timers. > This basically renders the whole idea of DTLS cookies useless. > > ssl3_get_client_hello returns 1 for packets without cookie - if a cookie is > requested, but dtls1_accept does not propagate this in any way I could use. > > Therefore my question, what is the proposed way to free resources until a > ClientHello packet with valid cookie arrives? You don't need to free anything. Use the listen for front state handling. > > I think it might be best to change SSL_accept to return SSL_ERROR_SSL for > ClientHello packets without cookie - if a cookie is requested. > This would allow to free up resources of sessions created by received > ClientHello packets without cookie. > > > I mainly use openssl 0.9.8o, but verified the problem exists in 1.x too. Robin is always suggesting to use 1.0.0 ... Best regards Michael > > > MfG > Markus > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Mac OS X DR 4
Dear opensslers, has someone compiled openssl compiled on MacOS X DR 4? Best regards Michael -- e-mail: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
