Why: Setup DTLS failed; using SSL instead

[Ahmed Kamal]

Hello folks,

I'm trying to connect to ocserv. DTLS is always failing to connect.
You can find a dump of the connection attempt here
http://paste.ubuntu.com/p/fPP9X59yFH/

PS: I'm not subscribed to the list.

[Daniel Lenski]

Post by Ahmed Kamal
Hello folks,
I'm trying to connect to ocserv. DTLS is always failing to connect.
You can find a dump of the connection attempt here
http://paste.ubuntu.com/p/fPP9X59yFH/
PS: I'm not subscribed to the list.

In your connection log, the response returned from the server after
the CONNECT contain no X-DTLS headers (except, for some reason, for
X-DTLS-Content-Encoding).

Is the *server* not configured to offer a DTLS connection?

Dan

[Ahmed Kamal]

Thanks for helping. My config file is mostly defaults. Here it is:
https://transfer.sh/tXIM0/ocserv.conf.txt
Let me know if anything else is needed to debug this. Thanks

Post by Daniel Lenski

Post by Ahmed Kamal
Hello folks,
I'm trying to connect to ocserv. DTLS is always failing to connect.
You can find a dump of the connection attempt here
http://paste.ubuntu.com/p/fPP9X59yFH/
PS: I'm not subscribed to the list.

In your connection log, the response returned from the server after
the CONNECT contain no X-DTLS headers (except, for some reason, for
X-DTLS-Content-Encoding).
Is the *server* not configured to offer a DTLS connection?
Dan

[Daniel Lenski]

Post by Ahmed Kamal
https://transfer.sh/tXIM0/ocserv.conf.txt
Let me know if anything else is needed to debug this. Thanks

In your configuration file, you've explicitly *disabled* the settings
which allow DTLS connections from (a) Cisco clients and (b)
openconnect < v7.08. Since you're connecting with openconnect v7.06,
that explains the problem. (It's not offering the PSK-NEGOTIATE cipher
which newer openconnect versions send to trigger the new-style DTLS
negotiation.)

# This option will enable the pre-draft-DTLS version of DTLS, and
# will not require clients to present their certificate on every TLS
# connection. It must be set to true to support legacy CISCO clients
# and openconnect clients < 7.08. When set to true, it implies
dtls-legacy = true.
cisco-client-compat = false

# This option allows to disable the legacy DTLS negotiation
(enabled by default,
# but that may change in the future).
# The legacy DTLS uses a pre-draft version of the DTLS protocol and was
# from AnyConnect protocol. It has several limitations, that are addressed
# by the dtls-psk protocol supported by openconnect 7.08+.
dtls-legacy = false

-Dan

On Thu, Jul 26, 2018 at 4:28 AM, Ahmed Kamal

Post by Ahmed Kamal
https://transfer.sh/tXIM0/ocserv.conf.txt
Let me know if anything else is needed to debug this. Thanks

Post by Daniel Lenski

Post by Ahmed Kamal
Hello folks,
I'm trying to connect to ocserv. DTLS is always failing to connect.
You can find a dump of the connection attempt here
http://paste.ubuntu.com/p/fPP9X59yFH/
PS: I'm not subscribed to the list.

In your connection log, the response returned from the server after
the CONNECT contain no X-DTLS headers (except, for some reason, for
X-DTLS-Content-Encoding).
Is the *server* not configured to offer a DTLS connection?
Dan

[Ahmed Kamal]

Thanks a lot Daniel! This seems to have resolved the issue. There is a
remaining tangential issue, which you might be able to help with. So
here I go. Unfortunately Egypt is performing DPI and seems to be
killing the DTLS stream, so I cannot connect over DTLS even though I'm
using v7.08 (from brew on OSX). The client emits the error message:
DTLS handshake failed: Resource temporarily unavailable, try again.

and on the server side "# tcpdump -ni eth0 udp and port 443" is
showing zero packets reaching the server! Unfortunately it seems the
DPI is effective here. My question is, is there any extra
encryption/obfuscation that can be done on the DTLS stream? Would
using newer ciphers like TLS_1.3 perhaps help? I know it's a long
shot, but worth trying. Thanks again!

Post by Ahmed Kamal
https://transfer.sh/tXIM0/ocserv.conf.txt
Let me know if anything else is needed to debug this. Thanks

In your configuration file, you've explicitly *disabled* the settings which allow DTLS connections from (a) Cisco clients and (b) openconnect < v7.08. Since you're connecting with openconnect v7.06, that explains the problem. (It's not offering the PSK-NEGOTIATE cipher which newer openconnect versions send to trigger the new-style DTLS negotiation.)
# This option will enable the pre-draft-DTLS version of DTLS, and
# will not require clients to present their certificate on every TLS
# connection. It must be set to true to support legacy CISCO clients
# and openconnect clients < 7.08. When set to true, it implies dtls-legacy = true.
cisco-client-compat = false
# This option allows to disable the legacy DTLS negotiation (enabled by default,
# but that may change in the future).
# The legacy DTLS uses a pre-draft version of the DTLS protocol and was
# from AnyConnect protocol. It has several limitations, that are addressed
# by the dtls-psk protocol supported by openconnect 7.08+.
dtls-legacy = false
-Dan

[Daniel Lenski]

This post might be inappropriate. Click to display it.

[Ahmed Kamal]

Thanks for the info. Really appreciating your help! I wish more and
more privacy software, would focus a bit more on censorship
resistance. Without it, users who most deeply need the privacy
features, are not getting it. Although I understand the technical
difficulties and appreciate all the hard-work the OC team is doing.

Regards!

Post by Daniel Lenski

Post by Ahmed Kamal
Thanks a lot Daniel! This seems to have resolved the issue. There is a
remaining tangential issue, which you might be able to help with. So
here I go. Unfortunately Egypt is performing DPI and seems to be
killing the DTLS stream, so I cannot connect over DTLS even though I'm
DTLS handshake failed: Resource temporarily unavailable, try again.
and on the server side "# tcpdump -ni eth0 udp and port 443" is
showing zero packets reaching the server! Unfortunately it seems the
DPI is effective here. My question is, is there any extra
encryption/obfuscation that can be done on the DTLS stream? Would
using newer ciphers like TLS_1.3 perhaps help? I know it's a long
shot, but worth trying. Thanks again!

AFAIK, Egypt's censorship blocks *all* DTLS and IPSEC (IKE+ESP)
traffic, plus *some* TLS traffic by blacklisted domains, detected via
DNS and SNI (e.g. Signal and WhatsApp encrypted chat). VPN TLS traffic
can't be distinguished from ordinary TLS traffic (e.g. HTTPS) so it
can't be banned entirely without enormous collateral damage, though of
course the censors could block your VPN's domain or IP if they notice
it and decide it's a VPN.
From what I've heard from Israelis traveling to the Sinai, VoIP and
video chat don't work reliably either, which probably means other UDP
traffic is being blocked or interfered with.
Given this situation… you're stuck with connecting to your ocserv VPN
via TLS only. It's perfectly secure, but can be slow if the
client-server connection has a lot of congestion or packet loss.
Setting compression=true in your ocserv config might offset this,
slightly, for some kinds of traffic.
Dan

[Daniel Lenski]

On Fri, Jul 27, 2018 at 11:20 AM, Ahmed Kamal

Post by Ahmed Kamal
Thanks for the info. Really appreciating your help! I wish more and
more privacy software, would focus a bit more on censorship
resistance. Without it, users who most deeply need the privacy
features, are not getting it. Although I understand the technical
difficulties and appreciate all the hard-work the OC team is doing.

Glad to help.

Keep in mind that anti-circumvention is a tricky problem that can't be
solved in the application layer alone. We're talking about an
application (VPN) that really needs a datagram-based transport (UDP)
to work correctly, but we have a censor which is willing and able to:

- Inspect and modify packets at the network level (blocking by subnets and IPs)
- Inspect and modify datagrams and streams at the transport level (TCP
resets, UDP black holes)
- Use MITM attacks to downgrade crypto (various TLS attacks)

Unless/until encrypted datagram-based traffic becomes a large and
economically crucial part of Internet traffic (perhaps via WebRTC
calling?) national censors can and will just shut it down entirely.

Dan