[websec] #7: clarify and add examples/justification wrt connection termination due to tls warnings/errors

"websec issue tracker" <trac+websec@trac.tools.ietf.org> Fri, 08 July 2011 22:57 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: websec issue tracker <trac+websec@trac.tools.ietf.org>
Precedence: bulk
Auto-Submitted: auto-generated
To: jeff.hodges@kingsmountain.com
Date: Fri, 08 Jul 2011 22:57:48 -0000
Message-ID: <070.70d4f97ece5def5d52ae93f9d858bdc2@trac.tools.ietf.org>
Cc: websec@ietf.org
Subject: [websec] #7: clarify and add examples/justification wrt connection termination due to tls warnings/errors

#7: clarify and add examples/justification wrt connection termination due to
tls warnings/errors

 http://www.ietf.org/mail-archive/web/websec/current/msg00045.html

 Subject: Re: [websec] Some questions about HSTS
 From: "Steingruebl, Andy" <asteingruebl@paypal-inc.com>
 Date: Mon, 22 Nov 2010 09:57:21 -0700 (08:57 PST)
 To: Yoav Nir <ynir@checkpoint.com>, "'websec@ietf.org'" <websec@ietf.org>

 > In sections 2.4.1.1, point #9 says:
 >    9.  UAs need to prevent users from clicking-through security
 >        warnings.  Halting connection attempts in the face of secure
 >        transport exceptions is acceptable.
 > What exactly are these secure transport exceptions?  Expired
 certificates?
 > Mismatched FQDN? Revoked certificates? Unreachable CRL? Untrusted CA?
 > Self-signed?

 Anything that would currently pop a browser warning for a user currently.
 Browsers differ slightly in how they handle OCSP, etc.  In any case where
 a browser has already made the policy decision it should show a
 certificate "error", it must now abort.

 > Also, I don't understand why this change is needed. HSTS is supposed to
 stop
 > a very specific attack vector - a user duped into using insecure HTTP
 over the
 > (presumably secure) HTTPS.
 >
 > As it is, HSTS cannot be used by servers with self-signed or corporate
 > certificates, for fear that user agents may not allow the user to
 browse.

 That is correct.  I personally believe, as do several of the contributors
 on this (and I hope I'm not speaking too much out of turn) that self-
 signed certificate warnings are just a punt, and an easy way for a user to
 make a bad security decision.  If  you want to support HTTPS, do it with a
 cert that your browser already trusts.  Anything else is just a recipe for
 a MiTM attack.  If a host advertises HSTS, it is specifically opting into
 this scheme, whereby all certificate warnings will cause abort, with no
 chance to "fool" the user into making the wrong decision.

-- 
-------------------------------------------+--------------------------------
 Reporter:  jeff.hodges@…                  |       Owner:  =JeffH
     Type:  defect                         |      Status:  new   
 Priority:  major                          |   Milestone:        
Component:  strict-transport-sec           |     Version:        
 Severity:  Active WG Document             |    Keywords:        
-------------------------------------------+--------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/7>
websec <http://tools.ietf.org/websec/>

[websec] #7: clarify and add examples/justificati… websec issue tracker
Re: [websec] #7: clarify and add examples/justifi… websec issue tracker
Re: [websec] #7: clarify and add examples/justifi… websec issue tracker