W3C home > Mailing lists > Public > public-wsc-wg@w3.org > July 2007

Re: ACTION-240 :TLS errors...

From: Serge Egelman <egelman@cs.cmu.edu>
Date: Thu, 19 Jul 2007 11:39:00 -0400
Message-ID: <469F8594.6010007@cs.cmu.edu>
To: Dan Schutzer <dan.schutzer@fstc.org>
CC: "'Johnathan Nightingale'" <johnath@mozilla.com>, "'W3C WSC Public'" <public-wsc-wg@w3.org>

I haven't done any work on it.  But this might help:


Read the references as well, if you're not familiar with them.  I'm sure
you can download the paper elsewhere if you google for it.


Dan Schutzer wrote:
> Can you send me some references to your work in Key continuity management?
> Thanks
> Dan
> -----Original Message-----
> From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
> Behalf Of Serge Egelman
> Sent: Wednesday, July 18, 2007 10:11 AM
> To: Johnathan Nightingale
> Cc: W3C WSC Public
> Subject: Re: ACTION-240 :TLS errors...
> Righto, I now see what he meant and am in complete agreement.  This is
> delving into not just keeping track of root certificates (which I think
> you all know my opinion on), to keeping track of every certificate.
> Peter Gutmann and Simson Garfinkel have done some work on this-- "key
> continuity management", and I think this would be a good recommendation
> for us to make.  It's trivial to keep track of every host/certificate
> tuple, just as browsers already keep track of form information.
> serge
> Johnathan Nightingale wrote:
>> On 18-Jul-07, at 9:48 AM, Serge Egelman wrote:
>>> Well, you said that this "is the poster child for exploiting browser
>>> state."  For it to be a serious threat that warrants consideration, you
>>> must assume that most users read certificate data (regardless of whether
>>> the browser is actually throwing a warning).  If we can assume that most
>>> users do *not* read this information, then there's a plethora of much
>>> easier/likelier attacks.
>>> That is, it's a waste of time worrying about how a burglar might pick
>>> your fancy new lock when you regularly leave all the windows open.
>> Serge,
>> I might be wrong here, but I think you are talking past each other
>> because I think you are misunderstanding Thomas' use of the word
>> "exploiting".  His original quote, in response to the discussion about
>> using a self-signed cert to facilitate a man in the middle attack, was:
>>> Isn't this a poster child use case for exploiting browser state?
>>> E.g., exploiting the knowledge that a certain domain in connection
>>> with HTTPS used to have a CA-based cert, and warning when that
>>> changes?
>> By which I believe he meant:  "This nicely illustrates why it would be
>> useful for browsers to maintain state about prior SSL connections so
>> that, in the event - however unlikely - that you visit a site which used
>> to have a CA-signed cert, but which now instead presents a self-signed
>> one, the browser can make all manner of noise/aggressive blockage, since
>> that scenario is magnificently unlikely for any legitimate bank,
>> webstore, etc."
>> I think he meant "exploiting browser state" as "leveraging browser state
>> to do good things for users" not "attacking browser state, here's a new
>> threat for us to consider."
>> As I say, maybe I'm wrong, and you're reacting to the idea as I
>> (re-)expressed it, but one of us is being tripped up by email-fail,
>> because I'm having trouble following your arguments against (what I
>> understand to be) his point.
>> Cheers,
>> Johnathan
>> ---
>> Johnathan Nightingale
>> Human Shield
>> johnath@mozilla.com

Serge Egelman

PhD Candidate
Vice President for External Affairs, Graduate Student Assembly
Carnegie Mellon University

Legislative Concerns Chair
National Association of Graduate-Professional Students
Received on Thursday, 19 July 2007 15:41:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:17 UTC