Re: [TLS] TLS browser bugs

Martin Rex <mrex@sap.com> Thu, 30 September 2010 18:59 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593693A6E6D for <tls@core3.amsl.com>; Thu, 30 Sep 2010 11:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.827
X-Spam-Level:
X-Spam-Status: No, score=-9.827 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clVIuwf3knEe for <tls@core3.amsl.com>; Thu, 30 Sep 2010 11:59:05 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 2F7983A6E6A for <tls@ietf.org>; Thu, 30 Sep 2010 11:58:17 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8UIx0Qn000954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Sep 2010 20:59:00 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201009301858.o8UIwxUk005976@fs4113.wdf.sap.corp>
To: henry.story@bblfish.net (Henry Story)
Date: Thu, 30 Sep 2010 20:58:59 +0200 (MEST)
In-Reply-To: <41DDF4DF-7BB3-44E0-A3DB-989DAAACC174@bblfish.net> from "Henry Story" at Sep 6, 10 03:48:36 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLS browser bugs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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/listinfo/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: Thu, 30 Sep 2010 18:59:06 -0000

Henry Story wrote:
> 
> Problem: you don't yet know which site you have arrived on!
> And it is asking you for a certificate. So really what you want
> to do is click "Cancel" to first check out the site. But then
> without this patch that @snej is working on, you won't be able
> to login to the site later to see the classified content
> - well not without restarting your browser!

That looks like a normal bug in the browser.  Restarting the
browser should never be necessary, just open a new network
connection and perform a new TLS handshake without proposing
session resumption.

Many years ago, MSIE would always try to access https:// resources
without sending a client cert on initial connect, and only when
the server terminated the handshake with a fatal error, MSIE
would repeat the SSL handshake, Prompt the User interactively
when receiving a CertificateRequest handshake message and close
the network communication channel while prompting the user
and then re-connect and perform the full handshake with the
memorized users decision whether and which client cert to
send to the server.  The problem with the old MSIE behaviour
was, that a server that allowed anonymous plus client-cert
access and sent a CertificateRequest in the initial handhshake
would never result in a ClientCert selection popup.

The old MSIE behaviour with the bug of not offering client-cert
selection for servers that allowed no-cert acces might have been
the reason why Microsoft started implementing the
"request client certificate through renegotiation" approach.


> 
> 2. Logout on the Server
> =======================
> 
> While waiting for the above fix to be implemented correctly,
> I have been investigation how one could get server side logout
> to work.

I don't know what this is supposed to mean.  To delete/destroy
application-level backend state, you would need application
level functionality.

There is not necessarily a link between a cached TLS session
and backend session state.  Potentially, there could be
a backend reverse proxy in between that terminates and
reencrypts the application data, in which case the application
state may be completely detached from the TLS session state.

For servers, where the backend-state is tied to the TLS session,
purging the TLS session from the server side TLS session cache
should do (most of) the trick.  Terminating active network
connections that are currently using a resumed copy of the TLS session
will usually continue to exist.



-Martin