IETF Logo Mail Archive

Re: [TLS] Passive TLS Clients - Reverse Connections

Mohamad Badra <mbadra@gmail.com> Tue, 17 December 2013 14:10 UTC

Return-Path: <mbadra@gmail.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 67C5E1AE25D for <tls@ietfa.amsl.com>; Tue, 17 Dec 2013 06:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 9rByRIEd3JzT for <tls@ietfa.amsl.com>; Tue, 17 Dec 2013 06:10:11 -0800 (PST)
Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 40BCD1AE234 for <tls@ietf.org>; Tue, 17 Dec 2013 06:10:11 -0800 (PST)
Received: by mail-ve0-f181.google.com with SMTP id oy12so4394674veb.12 for <tls@ietf.org>; Tue, 17 Dec 2013 06:10:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=00T32sKA2+kWslg59GvUJmn0Yk0Hm+6UAhuVTGODbwQ=; b=hfoxcjJMlOHgkqM+VDVh0M8VOh8JkVJP33+74xJEmiv3w5FOz50UO1FDdShHT+we2u DQuBuvFYI9jDt0JnrSVRSJbNgkYsvPNoPnuz9FK/7YTrFjex2JwKO6sDpQGcr7W6mGoe cwtlE1EHTUjnhF5HmtlWAQgT8crKcrwkWS/l6ma+dbJpAkxe8K31Wr2JCXxSArepRxAy cC7kqt3w8bbfx2B81nMgy+u+CCw5cuZ32C3hhtv2f1PpUK/cNXFbo4JGSUX/RSgW1rzx uKunK1Z5QQV9VtqD15t/742w9zQ9uyUAUIq0MOdtMsXKN076P3DIA2UDyuf3B8d9eocy Gzhw==
MIME-Version: 1.0
X-Received: by 10.221.19.196 with SMTP id ql4mr437480vcb.54.1387289410017; Tue, 17 Dec 2013 06:10:10 -0800 (PST)
Received: by 10.220.165.132 with HTTP; Tue, 17 Dec 2013 06:10:09 -0800 (PST)
In-Reply-To: <9b71054038a54d40b1f686497b3eb162@BY2PR03MB074.namprd03.prod.outlook.com>
References: <CAOhHAXwwrJJuVKou68yz8zJ1gHZk6xqjuKN40XzxTS0uYxQyUw@mail.gmail.com> <CACsn0ck4=cdAhVB_mKdWuOrULF1+sY-xptAsNWrLGayPCwC8Ew@mail.gmail.com> <CAOhHAXyes7DiAxqNs6Zpv7JYFg1FZage+ty2YV2pf84tzJyJyg@mail.gmail.com> <9b71054038a54d40b1f686497b3eb162@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Tue, 17 Dec 2013 18:10:09 +0400
Message-ID: <CAOhHAXw5opwAAEK2rJvddnRTUc-zZGArHTeLRuKoRpHPZ9f7bQ@mail.gmail.com>
From: Mohamad Badra <mbadra@gmail.com>
To: Marsh Ray <maray@microsoft.com>
Content-Type: multipart/alternative; boundary="001a11339b207c20b704edbb7c92"
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 14:10:13 -0000

On Tue, Dec 17, 2013 at 9:39 AM, Marsh Ray <maray@microsoft.com> wrote:

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

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

v2.23.0 | Report a Bug | By Email