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

[Adam Barth <[e-mail]>]

On Fri, Jul 16, 2010 at 12:17 PM, =JeffH <[e-mail]> wrote:
>
> Comment 41    Kai Engert <[e-mail]>      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.

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

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

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