IETF Logo Mail Archive

Re: [HASMAT] wrt handling TLS establishment - comment 41 bug 495115 (bugzilla.mozilla.org)

Adam Barth <ietf@adambarth.com> Sat, 17 July 2010 02:31 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: hasmat@core3.amsl.com
Delivered-To: hasmat@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA503A6407 for <hasmat@core3.amsl.com>; Fri, 16 Jul 2010 19:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.674
X-Spam-Level:
X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 iXMNKGUFUXB9 for <hasmat@core3.amsl.com>; Fri, 16 Jul 2010 19:31:49 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 44F5F3A6847 for <hasmat@ietf.org>; Fri, 16 Jul 2010 19:31:48 -0700 (PDT)
Received: by iwn38 with SMTP id 38so2947970iwn.31 for <hasmat@ietf.org>; Fri, 16 Jul 2010 19:32:00 -0700 (PDT)
Received: by 10.231.147.18 with SMTP id j18mr1858501ibv.19.1279333919946; Fri, 16 Jul 2010 19:31:59 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id g31sm12455422ibh.4.2010.07.16.19.31.58 (version=SSLv3 cipher=RC4-MD5); Fri, 16 Jul 2010 19:31:59 -0700 (PDT)
Received: by iwn38 with SMTP id 38so2947950iwn.31 for <hasmat@ietf.org>; Fri, 16 Jul 2010 19:31:58 -0700 (PDT)
Received: by 10.231.171.18 with SMTP id f18mr1920994ibz.9.1279333918301; Fri, 16 Jul 2010 19:31:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.143.145 with HTTP; Fri, 16 Jul 2010 19:31:38 -0700 (PDT)
In-Reply-To: <4C41100D.3050204@extendedsubset.com>
References: <4C40B043.2070707@KingsMountain.com> <AANLkTik2wzgwoMLnUwan6hMUvqL0YIujy_-rP-ZHo9em@mail.gmail.com> <4C41100D.3050204@extendedsubset.com>
From: Adam Barth <ietf@adambarth.com>
Date: Fri, 16 Jul 2010 19:31:38 -0700
Message-ID: <AANLkTincOn8GpUlA4ckAXSS8NHEoy2YGOynEuYT849rP@mail.gmail.com>
To: Marsh Ray <marsh@extendedsubset.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: IETF HASMAT list <hasmat@ietf.org>
Subject: Re: [HASMAT] wrt handling TLS establishment - comment 41 bug 495115 (bugzilla.mozilla.org)
X-BeenThere: hasmat@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HTTP Application Security Minus Authentication and Transport <hasmat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hasmat>
List-Post: <mailto:hasmat@ietf.org>
List-Help: <mailto:hasmat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Jul 2010 02:31:50 -0000

On Fri, Jul 16, 2010 at 7:06 PM, Marsh Ray <marsh@extendedsubset.com> wrote:
> On 07/16/2010 07:39 PM, Adam Barth wrote:
>> I'm not sure exactly what that means, but a server opting into STS
>> should trump user configuration to ignore certificate errors.  That's
>> the whole point of the protocol.  :)
>
> Just a pragmatic question here.
>
> If browsers are consistently strict about this, how is the admin going to
> troubleshoot his port 80 service or even notice if it has gone down (or out
> of STS mode)? Is there effectively a requirement to maintain some
> non-STS-respecting clients around for development and testing?
>
> Does anyone have operational experience with this kind of scenario?

Presumably sites that care about their uptime are already using
monitoring services like browsermob.com which solve this problem.

Adam

v2.23.0 | Report a Bug | By Email