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

From: =JeffH <[email-masked]>
Date: Fri, 16 Jul 2010 22:19:21 -0700

Adam replied:
 >
 > Kai proposed:
 >
 >> I propose to clarify section 7.3 of the STS document.
 >>
 >> It currently says:
 >>
 >>  "When connecting to a Known STS Server, the UA must terminate the
 >>  connection with no user recourse if there are any errors (e.g. certificate
 >>  errors), whether "warning" or "fatal" or any other error level, with the
 >>  underlying secure transport."
 >>
 >> I propose to add another section:
 >>
 >>  During the initial https connection to a STS server,
 >>  the server certificate verification performed by a UA happens prior to
 >>  receiving the http headers.
 >>  If a user has configured the UA to continue the connection
 >>  despite certificate errors, the UA must ignore any such configuration
 >>  as soon as the server identifies itself as a STS server.
 >>
 >> Based on comment 23 in this bug I conclude we agree on this, but I'm worried
 >> that some readers of the spec might overlook this detail.
 >
 > 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.  :)

agreed.

 >> Also, I'm worried that someone might be able to construct an attack based on
 >> the fact that the initial connection is not yet strict.
 >
 > That's correct.  The protocol requires a secure initialization step.
 > If an active network attacker is present during the first connection
 > to the site, there's nothing the protocol does to help the user.

Yes, and that's also why the spec mentions, and Chrome implements, a "preloaded 
STS list" <http://dev.chromium.org/sts>

 >> I propose to be more
 >> restrictive for the initial connection if it involved errors and error
 >> overrides, and propose to add this:
 >>
 >>  If an https connection to a not-yet-known-as-STS-server involves
 >>  certificate errors and a user's decision to ignore certificate errors,
 >>  and the server identifies itself as being a STS server,
 >>  then the UA MUST show an error message and
 >>  MUST NOT display the information received from the server.
 >
 > This situation is most likely to be a configuration error on the
 > server where it both has a bogus certificate and is sending the STS
 > header.  It's essential that we don't anoint the server as an STS
 > server,

The spec as currently written (-02) has this base covered in the first para of 
section "7.1. Strict-Transport-Security Response Header Field Processing"

 > but either proceeding with the connection or erroring out is
 > probably fine.

However, it is silent on this -- it presently specifies neither option in this 
particular situation.

 > I don't think there's a security reason to prefer one
 > over the other.  It's a question of what you think its a better
 > experience for users and/or developers.

I think leaving it silent in the protocol portion of the spec is fine, and that 
it's another item to add to section "10. UA Implementation Advice".

=JeffH