DTLS reconnect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux