Subject: [keyassure] client behavior in context of host policy (was: HTTPS -> HTTP downgrade)

From: =JeffH <[email-masked]>
Date: Thu, 23 Dec 2010 14:34:54 -0800

Paul Hoffman replied..
 >
 >> eg something like:
 >>
 >> "If a service is offered on both insecure and secure ports, and the client
 >>  supports the secure port, it SHOULD|MUST connect to the secure port only"
 >>
 >
 > And, again, that is you telling someone else what they MUST do, regardless
 > of what they want.

Yes, because what they "want", or are just blindly trying to do (eg in order to 
accomplish some task) -- i.e. e.g. connect to the host via http/80 -- may not 
be what they ought to be doing in order to make use of the webapp/site they are 
attempting to connect to.

E.g. for a site that has a deployment history on http/80 (or a mixture of 
http/80 & https/443) and wishes to move to being a TLS-only https/443 site, it 
will need to at a minimum listen on http/80 and http-redirect to https/443 if 
it wishes to maximize continued use as well as minimize breakage due to "http:" 
links (and equivalents) embedded in itself and/or in other webapps/sites.

Thus, this stipulation in draft-hoffman-server-has-tls-01 (aka HASTLS)..

     Given this, a host that wants clients to only use the secure form of
     a protocol MUST only be configured to be SSO [server secure only];
     a client that wants to only communicate with a server securely MUST
     only be configured to be CSO [client secure only].

..isn't realistically deployable today in the HTTP-based world for a large 
number of sites, due to the behavior of the installed base of both servers and 
clients.

Also, presently web browsers, and possibly other HTTP clients (i don't know for
sure), when given a URI fragment containing the host and perhaps a path,
attempt http/80 first by default (modulo those that understand HSTS and have
the site cached). So this behavior would have to continue as-is for quite some
time, because there's going to be a transition period of years as sites start
emitting HSTS (HTTP Strict Transport Security) policy and/or adopting something 
else that might emerge, eg HASTLS (ie the consumer browser vendors aren't going 
to want to alter their default behavior for a long time if ever), and deployed 
browsers start to understand HSTS, HASTLS, and whatever else we come up with.

 >> To me, this falls in the same category as "MUST NOT use a nonce twice".
 >> It's inheritant in the security protocol to counter an attack vector.
 >
 > They are completely unrelated. To repeat my example from a day or two ago:
 > assume that the client does not have the trust anchor you require for TLS in
 > their trust anchor store. "SHOULD|MUST connect to the secure port only"
 > means "you're going to fail to connect, tough luck".

Yes, in that particular example, that is what would, and correctly should 
happen, if the client supports, for example, HSTS 
(draft-hodges-strict-transport-sec), and/or I would argue, whatever else we 
come up with for the longer term, eg whatever HASTLS becomes.

Note that in the above example the webapp/site would have to have both 
advertised a policy of "TLS only" _and_ not ensured that it is using a cert 
that properly chains up to a trust anchor that's loaded in its users clients. 
So it's sorta shooting itself in the foot, unfortunately (and we're betting 
this is a uncommon occurrence and is an edge case).

The sort of use case we're more concerned with is where the webapp/site _is_ 
properly configured both policy- and cert-wise, and there's a MITM or an 
impersonator, and here we want the connection attempt to hard fail by default.

 > More likely it will
 > mean "you will tell your client to let you through anyway, ignoring what
 > HASTLS told you securely".

Well, that's typical behavior today because clients have made it inordinately 
easy for any user to simply "click-through" the warnings and proceed 
insecurely. We _really_ want to prevent that by default going forward.

The rationale being that there are formal user studies (see below) plus tons of 
anecdotal evidence illustrating that most person-off-the-street users have no 
context to understand what is going on when given a choice whether to proceed 
insecurely or to just stop and are inclined to continue getting their task done 
if it is made easy for them to do so (i.e. their task workflow isn't 
unavoidably interrupted).

Note that this _does not_ for example obviate the client being configurable
such that HSTS policy adherence could be turned off for any or all sites. We
note this and other "suggested" UA features in "UA Implementation Advice" in
draft-hodges-strict-transport-sec.

Now, that all said, it seems that HASTLS, as presently imagined, advertises
host capabilities in terms of on which ports it speaks TLS, and then a client,
depending upon what client policy is in effect (the {CIO,CSO,CFB} as outlined
in the draft-hoffman-server-has-tls) behaves according to the combination of 
what the host is advertising and what the client policy is.

What HSTS does, essentially, is instruct the client that for a given host,
implement the CSO (client security only) policy, which is presently stated in 
draft-hoffman-server-has-tls as..

     o  A client whose policy is that it is a CSO MUST only try to
        communicate securely with a server that has the secure-port set to
        a non-zero number; it MUST NOT try to communicate with the server
        on the insecure-port value given.

Which is essentially the HSTS behavior for a client when connecting to a "known
HSTS host".

And also for consumer general-purpose browsers, it seems to me that they will
need to behave as whichever of {CIO,CSO,CFB} on a per-host (ie per webapp)
basis.

hope this helps,

=JeffH
------

[quickly selected bibliography, nominally ordered reverse-chrono; all papers 
should be available on web, discoverable by google scholar and/or citeseer]

You’ve Been Warned: An Empirical Study of the
Effectiveness of Web Browser Phishing Warnings
Serge Egelman, Lorrie Faith Cranor, Jason Hong; 2010

Crying Wolf: An Empirical Study of SSL Warning Effectiveness
Joshua Sunshine, Serge Egelman, Hazim Almuhimedi, Neha Atri, and Lorrie Faith 
Cranor; 2009

Browser Interfaces and Extended Validation
SSL Certificates: An Empirical Study
Sobey, Whalen, Biddle, van Oorschot, Patrick; 2009

Browser Interfaces and EV-SSL Certificates:
Confusion, Inconsistencies and HCI Challenges
Jennifer Sobey, P.C. van Oorschot, and Andrew S. Patrick; 2009

Exploring User Reactions to New Browser Cues
for Extended Validation Certificates
Jennifer Sobey, Robert Biddle, P.C. van Oorschot, and Andrew S. Patrick; 2008

The Emperor’s New Security Indicators
An evaluation of website authentication
and the effect of role playing on usability studies
Stuart E. Schechter Rachna Dhamija Andy Ozment Ian Fischer; 2007

An Evaluation of Extended Validation and
Picture-in-Picture Phishing Attacks
Collin Jackson, Daniel R. Simon, Desney S. Tan, and Adam Barth; 2007

Deceit and Deception: A Large User Study of Phishing
Alex Tsow and Markus Jakobsson; 2007

Do Security Toolbars Actually Prevent Phishing Attacks?
Min Wu, Robert C. Miller, Simson L. Garfinkel; 2006

Gathering Evidence: Use of Visual Security Cues in Web Browsers
Tara Whalen Kori M. Inkpen; 2005

User Perceptions of Privacy and Security on the Web
Scott Flinn and Joanna Lumsden; 2005

---
end