Subject: [TLS] Passive TLS Clients - Reverse Connections

From: Mohamad Badra <[email-masked]>
Date: Sun, 15 Dec 2013 04:41:12 +0400

Dear All,

I've submitted the following document to enable a TLS connection from a
server to a client after the initial handshake is complete.

Comments are welcome!
Best regards,
Badra

Filename:        draft-badra-tls-passive-client
Revision:        00
Title:           Passive Transport Layer Security (TLS) Clients
Creation date:   2013-12-15
Group:           Individual Submission
Number of pages: 3
URL:
http://www.ietf.org/internet-drafts/draft-badra-tls-passive-client-00.txt
Status:
http://datatracker.ietf.org/doc/draft-badra-tls-passive-client
Htmlized:
http://tools.ietf.org/html/draft-badra-tls-passive-client-00

Abstract:
   This document describes a technique for a Transport Layer Security
   (TLS) server to initiate a TLS connection to a TLS client.  This is
   accomplished by the TLS client listening on a port number sent from
   the client to the server during the initial TLS Handshake.  This
   document defines a TLS extension for conveying a port number from the
   client to the server.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 14 Dec 2013 16:47:53 -0800

> server to a client after the initial handshake is complete.
Do you have a use case for this? Because once the handshake finishes
you have a perfectly good connection.
If an application protocol requires this, it can do it at the application level.
Sincerely,
Watson Ladd

---

From: Mohamad Badra <[email-masked]>
Date: Sun, 15 Dec 2013 13:33:36 +0400

> If an application protocol requires this, it can do it at the application

​​I don't have an exhaustive list of scenarios where this extension could
be useful:

​- Some of the applicative resources may be hosted behind a proxy or a
firewall that implements NAT for the internal network IP addresses. They
may be hosted on devices in stealth mode or with dynamic IP addresses so
mapping between the resources and IP is not efficient.

- It is suitable for network management protocols such as NETCONF(*). It
will be easier to extend TLS than revising every application to enable
reverse connection over TLS And assign a new port number.

- In the case of reverse connections, it would be more secure to
configure your server (it may be easier to secure one open port than to
having an open port on each server in the network).

(*) Other benefits related to device management may be found at
http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-02#section-3.

Best regards,
Badra

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Dec 2013 05:39:33 +0000

From: TLS [mailto:[email-masked]] On Behalf Of Mohamad Badra
> Some of the applicative resources may be hosted behind a proxy or a

http://tools.ietf.org/html/draft-badra-tls-passive-client-00 says:
> Once the initial handshaking is complete, the server MAY actively
> open a TCP or UDP connection to the client using the port number
> received in the ClientHello.  Once the TCP or UDP connection has been
> established, the client takes initiative and sends the TLS
> ClientHello message to begin the TLS abbreviated handshake.

So if an attacker were to intercept this TCP connection coming from
the legitimate server, couldn’t he just send a ClientHello, establish
his own session, and thus learn whatever the legitimate server had
intended to say to the applicative resource server and possibly even
forge a response?

-          Marsh

From: TLS [mailto:[email-masked]] On Behalf Of Mohamad Badra
Sent: Sunday, December 15, 2013 1:34 AM
To: Watson Ladd
Cc: [email-masked]
Subject: Re: [TLS] Passive TLS Clients - Reverse Connections

On Sun, Dec 15, 2013 at 4:47 AM, Watson Ladd <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,
Badra

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 17 Dec 2013 18:10:09 +0400

On Tue, Dec 17, 2013 at 9:39 AM, Marsh Ray <[email-masked]> wrote:

>  *From:* TLS [mailto:[email-masked]] *On Behalf Of *Mohamad Badra
​​

As indicated in the document, the client takes the initiative to begin an
"abbreviated" handshake, so he must include the session identifier
generated during the initial Handshake in the ClientHello. The server
shall reject that handshake in case the Finished message is not valid.

Best regards,
Badra