Re: [TLS] Passive TLS Clients - Reverse Connections

Marsh Ray <maray@microsoft.com> Tue, 17 December 2013 05:39 UTC

Return-Path: <maray@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF191ADF44 for <tls@ietfa.amsl.com>; Mon, 16 Dec 2013 21:39:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib0ELRNhz0He for <tls@ietfa.amsl.com>; Mon, 16 Dec 2013 21:39:43 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAD51ADF99 for <tls@ietf.org>; Mon, 16 Dec 2013 21:39:43 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) with Microsoft SMTP Server (TLS) id 15.0.842.7; Tue, 17 Dec 2013 05:39:34 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.137]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.137]) with mapi id 15.00.0842.003; Tue, 17 Dec 2013 05:39:34 +0000
From: Marsh Ray <maray@microsoft.com>
To: Mohamad Badra <mbadra@gmail.com>, Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [TLS] Passive TLS Clients - Reverse Connections
Thread-Index: AQHO+S5uUTwOSitRtUqUmvRBcpH27ppUbDWAgACS4wCAAuFhwA==
Date: Tue, 17 Dec 2013 05:39:33 +0000
Message-ID: <9b71054038a54d40b1f686497b3eb162@BY2PR03MB074.namprd03.prod.outlook.com>
References: <CAOhHAXwwrJJuVKou68yz8zJ1gHZk6xqjuKN40XzxTS0uYxQyUw@mail.gmail.com> <CACsn0ck4=cdAhVB_mKdWuOrULF1+sY-xptAsNWrLGayPCwC8Ew@mail.gmail.com> <CAOhHAXyes7DiAxqNs6Zpv7JYFg1FZage+ty2YV2pf84tzJyJyg@mail.gmail.com>
In-Reply-To: <CAOhHAXyes7DiAxqNs6Zpv7JYFg1FZage+ty2YV2pf84tzJyJyg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::2]
x-forefront-prvs: 006339698F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(51704005)(377454003)(189002)(199002)(24454002)(80022001)(59766001)(74502001)(15202345003)(47446002)(19300405004)(85852003)(31966008)(77982001)(54316002)(56776001)(90146001)(79102001)(33646001)(74876001)(65816001)(76576001)(77096001)(49866001)(83072002)(76482001)(83322001)(19580395003)(63696002)(56816005)(51856001)(74662001)(69226001)(85306002)(53806001)(54356001)(16236675002)(15975445006)(81686001)(81816001)(19609705001)(74366001)(50986001)(2656002)(81542001)(80976001)(74316001)(74706001)(87266001)(19580405001)(47736001)(4396001)(76796001)(87936001)(81342001)(46102001)(47976001)(76786001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB074; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_9b71054038a54d40b1f686497b3eb162BY2PR03MB074namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Passive TLS Clients - Reverse Connections
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 05:39:46 -0000

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Mohamad Badra
> 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.

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:tls-bounces@ietf.org] On Behalf Of Mohamad Badra
Sent: Sunday, December 15, 2013 1:34 AM
To: Watson Ladd
Cc: tls@ietf.org
Subject: Re: [TLS] Passive TLS Clients - Reverse Connections

On Sun, Dec 15, 2013 at 4:47 AM, Watson Ladd <watsonbladd@gmail.com<mailto:watsonbladd@gmail.com>> wrote:
On Sat, Dec 14, 2013 at 4:41 PM, Mohamad Badra <mbadra@gmail.com<mailto:mbadra@gmail.com>> wrote:
> 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.
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

​​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