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

From: =JeffH <[email-masked]>
Date: Fri, 16 Jul 2010 12:17:23 -0700

Comment 41    Kai Engert <[email-masked]>      2010-07-12 17:06:43 PDT
https://bugzilla.mozilla.org/show_bug.cgi?id=495115#c41

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.

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. 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.

---
end

---

From: Adam Barth <[email-masked]>
Date: Fri, 16 Jul 2010 17:39:30 -0700

> 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.  :)

> 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.

> I propose to be more

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, but either proceeding with the connection or erroring out is
probably fine.  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.

Adam

---

From: Marsh Ray <[email-masked]>
Date: Fri, 16 Jul 2010 21:06:05 -0500

> 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

---

From: Adam Barth <[email-masked]>
Date: Fri, 16 Jul 2010 19:31:38 -0700

On Fri, Jul 16, 2010 at 7:06 PM, Marsh Ray <[email-masked]> wrote:
> 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?
>

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

Adam