DTLS Client retry ClientHello

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

DTLS Client retry ClientHello

Tim Panton new
Hi, I now need to have BouncyCastle DTLS act as a DTLS client (after years of just being a server).

I’m at a loss to know how to deal with the case where the ClientHello gets dropped.

this code snippet illustrates the issue:

import org.bouncycastle.crypto.tls.DTLSClientProtocol;
import org.bouncycastle.crypto.tls.DTLSTransport;
….

                SecureRandom sec = new SecureRandom();
                DTLSClientProtocol protocol = new DTLSClientProtocol(sec);
                Log.debug("DTLS client protocol created " + _verified);
                TimerTask kill = new TimerTask() {
                    @Override
                    public void run() {
                        Log.error("would resend DTLS hello -  If we knew how.");
                    }
                };
                this.deadmanwalking.schedule(kill, 100 * n);
                DTLSTransport dtls = protocol.connect(this, _dt);

In essence I have 2 problems:
1) protocol.connect never times out
2) I can’t see an external method to prod protocol into resending.

I could hack something up with the Transport I pass in, but that seems ugly.

Thanks in advance for any hints.


T.

(P.S. keep up the great work!)


Reply | Threaded
Open this post in threaded view
|

Re: DTLS Client retry ClientHello

Peter Dettman-3
Hi,

First can I recommend that you update your code to use the newer API in
the bctls jar (and the org.bouncycastle.tls package). The code that you
are using is considered legacy code and is not being developed further.
Apart from the package change, there should only be small differences
for client code.

Regarding 1), no we don't have a global timeout for the handshake yet.
Perhaps we could support a timeout parameter to the connect method that
would fail if the handshake hasn't completed in that time. "Hacking" the
underlying transport is presumably how others have coped.

As to 2), there is already an internal retry mechanism for resending
packets after a delay (during the handshake only). You can see it e.g.
by running this test case:

https://github.com/bcgit/bc-java/blob/master/tls/src/test/java/org/bouncycastle/tls/test/DTLSClientTest.java

If you have nothing running on port 5556, you will see in the console
that it is resending with 1 second, 2s, 4s, etc. delays.

After the handshake, packets can simply be lost; it is of course an
unreliable transport by design.

Regards,
Pete Dettman


On 29/5/18 5:14 pm, westhawk wrote:

> Hi, I now need to have BouncyCastle DTLS act as a DTLS client (after years of just being a server).
>
> I’m at a loss to know how to deal with the case where the ClientHello gets dropped.
>
> this code snippet illustrates the issue:
>
> import org.bouncycastle.crypto.tls.DTLSClientProtocol;
> import org.bouncycastle.crypto.tls.DTLSTransport;
> ….
>
>                 SecureRandom sec = new SecureRandom();
>                 DTLSClientProtocol protocol = new DTLSClientProtocol(sec);
>                 Log.debug("DTLS client protocol created " + _verified);
>                 TimerTask kill = new TimerTask() {
>                     @Override
>                     public void run() {
>                         Log.error("would resend DTLS hello -  If we knew how.");
>                     }
>                 };
>                 this.deadmanwalking.schedule(kill, 100 * n);
>                 DTLSTransport dtls = protocol.connect(this, _dt);
>
> In essence I have 2 problems:
> 1) protocol.connect never times out
> 2) I can’t see an external method to prod protocol into resending.
>
> I could hack something up with the Transport I pass in, but that seems ugly.
>
> Thanks in advance for any hints.
>
>
> T.
>
> (P.S. keep up the great work!)
>
>