You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → wolfSSL → DTLS timeouts
Hi,
I am looking into porting an app from OpenSSL to wolfSSL embedded SSL.
OpenSSL has a function 'DTLSv1_handle_timeout' that can be used
to re-transmit packets when sockets in non-blocking
mode are used. Is there similar mechanism in wolfSSL?
I realize that data packets are not re-transmitted and could
be lost and that's the consequence of using DTLS,
but some method of re-transmissions is needed for DTLS'
own protocol packets...
We don't have that functionality, yet. I'm currently working on it. I'll let you know when I get it checked into our GitHub repository.
Do you have an expected timeline for that feature?
Is it a matter of days, weeks or longer?
Even without the 'timeouts' feature, is there a way to force
wolfSSL embedded SSL to resend last handshake packet(s)? Because without
that loosing even a single handshake packet will block
the whole handshake procedure...
I also had some other issues:
- WOLFSSL_USER_IO doesn't really work with DTLS, because there is no
way to provide alternative to EmbedGenerateCookie function.
- The '-b' option of the 'server' example doesn't work with DTLS
These issues are minor and easy to change - do you accept patches?
Finally, OpenSSL provides an additional 'DTLS listen' function,
which is supposed to respond to 'client hello' messages that don't contain a cookie.
For these requests there is no need to generate a new SSL object
and allocate memory - this is supposed to help with DOS attacks.
Is there anything similar in wolfSSL? It looks like the first cookie-less
'hello' message changes the internal state of the SSL object,
so it cannot be used for responding to another cookie-less hello message.
This most likely will have to be changed anyway to support the 'timeout' feature,
but I am wondering if that feature is considered?
Thanks!
Do you have an expected timeline for that feature?
Is it a matter of days, weeks or longer?
Days.
Even without the 'timeouts' feature, is there a way to force
wolfSSL to resend last handshake packet(s)? Because without
that loosing even a single handshake packet will block
the whole handshake procedure...
Not at the moment. But, the retry should be there soon.
I also had some other issues:
- WOLFSSL_USER_IO doesn't really work with DTLS, because there is no
way to provide alternative to EmbedGenerateCookie function.
- The '-b' option of the 'server' example doesn't work with DTLSThese issues are minor and easy to change - do you accept patches?
Handling an alternative EmbedGenerateCookie function is something we're going to add at a later date, mostly when someone asks about it. It should take too long to add. Patches are welcome.
Finally, OpenSSL provides an additional 'DTLS listen' function,
which is supposed to respond to 'client hello' messages that don't contain a cookie.
For these requests there is no need to generate a new SSL object
and allocate memory - this is supposed to help with DOS attacks.Is there anything similar in wolfSSL? It looks like the first cookie-less
'hello' message changes the internal state of the SSL object,
so it cannot be used for responding to another cookie-less hello message.This most likely will have to be changed anyway to support the 'timeout' feature,
but I am wondering if that feature is considered?Thanks!
It hasn't been considered, yet. But, that's something I'll look at adding.
Thanks for the answer!
Patches are welcome.
Is there a specific way to do that, or can I use github?
I have update our DTLS code on GitHub. I am a little new to GitHub, but I think you can send us some pull requests, we can take a look at the patches, and incorporate them into our code upon review.
Hey,
I finally got everything working on my stm32f4 evaluation board, where I use FreeRTOS 7.4.0 and wolfSSL embedded SSL 2.6.1 for DTLSv1.2.
Because I'm using the USART Interface for communication, I have now the problem with the missing cookie callback.
Would you provide me some infos, what is needed. Since I'm not affected to DoS attacks, I just need something trivial to walk through.
KR Thomas
For the cookie callback, I'd still put in something, even if it just copies zeroes in as the cookie.
The read and write callbacks should be replaced. The read callback moves data from the network device into a buffer that wolfSSL provides for processing. (The network device can be a buffer, or a socket, or whatever. The callback context is data you provide to facilitate your function's work. It will have the socket or pointer to the buffer, etc.) The send callback does the same for writes to the network device.
What are you looking for specifically? How to get DTLS working? The RECVFROM and SENDTO callbacks in src/io.c are the model to follow.
Hey,
I already got the cookie callback to work.
/*
*Creates a simple pseudo Cookie, easy to find in hexdump
*/
int MyEmbedGenerateCookie(WOLFSSL* ssl, byte *buf, int sz, void *ctx) {
int i;
for (i=0; i<sz; i++)
buf[i]= 0xDADA;
return sz;
}I was interested in the arguments and the expected return value. What is delivered in buf? I don't use it, but I'm intrested.
It's also interesting now, that everything works fine with DTLS1.2 but I receive an error when I use DTLS1.0, somewhere at the ChangeCipferSpec message. But that's another story which I won't follow up.
KR
Hey,
I already got the cookie callback to work./* *Creates a simple pseudo Cookie, easy to find in hexdump */ int MyEmbedGenerateCookie(WOLFSSL* ssl, byte *buf, int sz, void *ctx) { int i; for (i=0; i<sz; i++) buf[i]= 0xDADA; return sz; }I was interested in the arguments and the expected return value. What is delivered in buf? I don't use it, but I'm intrested.
buf is the buffer for the cookie value. sz is the size of that buffer. The return value should be the number of bytes written into buf, which should be less than or equal to sz. Note, in the example you provided, 0xDADA is a 16-bit value, but buf(i) is a byte.
It's also interesting now, that everything works fine with DTLS1.2 but I receive an error when I use DTLS1.0, somewhere at the ChangeCipferSpec message. But that's another story which I won't follow up.
KR
Which error are you getting?
Thank you for the hint, with the hint with the 16-bit to byte assignment.
Here is the the error throughing code of DTLS 1.0 and the correct output of DTLS 1.2 for comparison:
DTLS 1.0
received record layer msg
wolfSSL Entering DoDtlsHandShakeMsg()
wolfSSL Entering DoHandShakeMsgType
processing client key exchange
wolfSSL Leaving DoHandShakeMsgType(), return 0
wolfSSL Leaving DoDtlsHandShakeMsg(), return 0
More records in input
received record layer msg
got CHANGE CIPHER SPEC
More records in input
received record layer msg
wolfSSL Entering DoDtlsHandShakeMsg()
wolfSSL error occured, error = -210
ERROR
wolfSSL Entering SSL_accept()
received record layer msg
wolfSSL Entering DoDtlsHandShakeMsg()
wolfSSL error occured, error = -210
ERROR
****************
DTLS 1.2
received record layer msg
wolfSSL Entering DoDtlsHandShakeMsg()
wolfSSL Entering DoHandShakeMsgType
processing client key exchange
wolfSSL Leaving DoHandShakeMsgType(), return 0
wolfSSL Leaving DoDtlsHandShakeMsg(), return 0
More records in input
received record layer msg
got CHANGE CIPHER SPEC
More records in input
received record layer msg
wolfSSL Entering DoDtlsHandShakeMsg()
wolfSSL Entering DoHandShakeMsgType
processing finished
wolfSSL Leaving DoHandShakeMsgType(), return 0
wolfSSL Leaving DoDtlsHandShakeMsg(), return 0
accept state ACCEPT_SECOND_REPLY_DONE
growing output buffer
accept state CHANGE_CIPHER_SENT
growing output bufferThe line with text ERROR is given on application layer.
wolfSSL - Embedded SSL Library → wolfSSL → DTLS timeouts
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.022 seconds (91% PHP - 9% DB) with 10 queries