IETF Logo Mail Archive

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

Marsh Ray <marsh@extendedsubset.com> Sat, 17 July 2010 02:05 UTC

Return-Path: <marsh@extendedsubset.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 4D5CF3A6783 for <hasmat@core3.amsl.com>; Fri, 16 Jul 2010 19:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.783
X-Spam-Level:
X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599]
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 jJYuQCNfyMpr for <hasmat@core3.amsl.com>; Fri, 16 Jul 2010 19:05:56 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 93BA23A6407 for <hasmat@ietf.org>; Fri, 16 Jul 2010 19:05:56 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OZwn2-000Ml7-J6; Sat, 17 Jul 2010 02:06:08 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 3473D633B; Sat, 17 Jul 2010 02:06:06 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18TJoVT01jNt9JPQ2LXJg5ANmCb6d9G0WU=
Message-ID: <4C41100D.3050204@extendedsubset.com>
Date: Fri, 16 Jul 2010 21:06:05 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5
MIME-Version: 1.0
To: Adam Barth <ietf@adambarth.com>
References: <4C40B043.2070707@KingsMountain.com> <AANLkTik2wzgwoMLnUwan6hMUvqL0YIujy_-rP-ZHo9em@mail.gmail.com>
In-Reply-To: <AANLkTik2wzgwoMLnUwan6hMUvqL0YIujy_-rP-ZHo9em@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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:05:58 -0000

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?

- Marsh

v2.23.0 | Report a Bug | By Email