DTLS reconnect
Detlef Vollmann
dv at vollmann.ch
Thu Jul 30 15:30:49 UTC 2020
Hello,
section 4.2.8 "Establishing New Associations with Existing Parameters"
of RFC 6347 (<https://tools.ietf.org/html/rfc6347#section-4.2.8>)
recommends ("SHOULD") that a new ClientHello from a client IP/port
pair for which a session already exists initiates a new handshake.
I tried to test such a scenario using s_server and s_client:
As server:
openssl s_server -accept 127.0.0.1:18001 -4 -cert demoCA/srv.crt -key
demoCA/testdev.key -CAfile demoCA/testca.crt -dtls1_2
As client:
openssl s_client -bind 127.0.0.1:19933 -connect 127.0.0.1:18001 -4
-noservername -cert demoCA/clnt.crt -key demoCA/testdev.key -CAfile
demoCA/testca.crt -dtls1_2
Then stop the client using CTRL-C and start it again.
tcpdump/wireshark shows the first (successful) handshake and then
ClientHellos from the same IP/port pair which are never replied to.
I tested the official Debian unstable package 1.1.1g-1 and
today's master (a3f15e237c).
So here are my questions:
- Is this part of RFC 6347 implemented in OpenSSL?
- If yes, how can it be used?
Note: this is not the same as what the "-reconnect' option of
s_client does. This reconnect sends a ClientHello with a
previously established session ID for cached connections.
Section 4.2.8 of DTLS 1.2 is about a client that has no
existing session context but tries to connect from an IP address
and UDP port it has used previously. This happens e.g. for many
embedded devices after a reset.
Thanks,
Detlef
More information about the openssl-users
mailing list