Tom Ritter | 19 Jan 18:55 2015

Requiring OCSP Stapling as a directive in HSTS

Hi all.  I'd like to propose an idea: add an optional directive to the
HSTS header that, when included, mandates any certificate received for
a domain require OCSP Stapling. It would respect includeSubdomains and
max-age.

The threat model I'm trying to address is an attacker who can get a
valid certificate misissued for a domain.  Because of the revocation
situation, the attacker can then MITM users with impunity, blocking
revocation lookups if they occur.  While UAs would receive a crlset or
other push of revoked certificates, I believe that the UA will still
work if that connection is blocked, and it's not clear how long that
connection must be blocked before the UA stops working entirely.  (If
that happens at all.)

Counting from the detection of the attack (which efforts like CT and
Pinning help detect), requiring OCSP stapling changes the window of
attack from {forever?, 30 days?, an unknown value?} to the OCSP
staple's lifetime.  (Assuming the attacker gets a OCSP signature right
before revocation.)

Why OCSP stapling and not require the UA to instead use 'hard-fail'
revocation checking?  Well, CRLs have all sorts of drawbacks: longer
expiry times, large sizes, and they're pretty much being phased out
everywhere.  (I know about Delta-CRLs - developing a specification for
them, implementing, and deploying them will take years, if ever, due
to IPR stuff. This does not.)   What about requiring OCSP querying?
Browsers don't much care for that - it's slow, can timeout for
non-security reasons, it's out of the control of the web site owner.
That leaves us with OCSP Stapling - it's fast, implemented, deployed.

(Continue reading)

=JeffH | 13 Jan 19:36 2015

test pls ignore

test

Chris Hartmann | 12 Jan 20:18 2015
Picon

Authentic inter-domain relationships. Is this a security problem? Appropriate for websec?

1) Bob trusts and does personal business with a.com.

2) a.com forms a business relationship with b.com to perform a
business function on its behalf (payment processor, blog, whatever).
The landing page is b.com/a

3) Bob visits b.com/a and notices that the page claims to be
affiliated and owned by a.com

4) How can Bob, in absolute terms, trust that b.com/a is affiliated
and a delegated service by a.com? (say, prior to submitting sensitive
information)

Is this a security problem? I think so.

We’ve all had to make this decision one time or another on weak
inferences and correlations. I’d imagine Phishers don’t mind at all
that there is an inability for the common internet user (looking at
you grandma) to make the judgement call on web service affiliations.
They’ve been conditioned with the best practice of looking at the
address bar (and perhaps the DNS namespace) along with the lock icon
to indicate trustworthiness, which may actually help the attacker in
their act of misdirection. Inter-domain relationships model business
relationships and trust. If web users could be armed with a new
“sense” which proves these legitimate relationships (say
cryptographically) then perhaps they would have more reason to be
skeptical of those who cannot prove their affiliation. I’m not saying
we can take human judgement completely out of the equation, but why
not have a tool to help anchor this commonly needed and risky
correlation.
(Continue reading)

Jeffrey Walton | 2 Jan 06:21 2015
Picon

Comments on draft-ietf-websec-key-pinning

I'd like to share some comments on
https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21.

Pubic key pinning is an effective security control and I'm glad to see
the IETF moving forward with it. And I'm especially thankful to Palmer
and Sleevi for taking the time to put it together and shepherd it
through the process.

***** (1) *****

The title "Public Key Pinning Extension for HTTP" seems overly broad
and misses the mark a bit. The Abstract states its for User Agents,
but the title does not narrow focus.

There are different problem domains where public key pinning can be
utilized. Painting with a broad brush, I categorize them as "the
general problem" where no 'a priori' knowledge exists, and various
specific "instance problems", where 'a priori' does exits and can be
leveraged. An example of the general problem is browsers, and an
example of the instance problem is any custom software deployed by an
organization.

Suggestion: change the title to "Trust on First Use Pinsets and
Overrides for HTTP" or "Pinsets and Overrides for HTTP in User
Agents".

There are a few reasons for the suggestion. First, the abstract
effectively states its. Second, the proposed standard is a TOFU scheme
used for the general problem. Third, the Introduction recognizes the
two classes of problems when it discusses the pre-shared keys. Fourth,
(Continue reading)

Stephane Bortzmeyer | 17 Dec 14:56 2014
Picon

[HSTS] Contradiction between sections 8.1 and 11.3 of RFC 6797?


[I'm not subscribed to the websec working group so please copy me when
replying.]

I don't know how to read section 11.3 of RFC 6797. It says "If all
four of the following conditions are true... [self-signed
certificates...]  ...then secure connections to that site will fail,
per the HSTS design." It seems to imply that adding a
Strict-Transport-Security: header to a site which has a self-signed
certificate is an error.

But section 8.1 says that the Strict-Transport-Security: will be
ignored if the HTTPS session is not secured (for instance because the
client uses a self-signed cert, section 8.1 says the header will be
accepted only "if there are no underlying secure transport errors or
warnings"). So, it seems that adding Strict-Transport-Security: is
useless (they will be ignored, per section 8.1) but not an error.

I checked with the Chromium browser "Version 20.0.1132.47 Ubuntu 12.04
(144678)" and a HTTPS site signed by CAcert.org (unknown CA for most
browsers) and, indeed, Chromium ignores the HSTS header and accepts to
use HTTP. Once CAcert.org cert is added, Chromium accepts the HSTS
header and uses only HTTPS. So, it seems the Chromium programmers
decided to ignore section 11.3?

Xiaoyin Liu | 7 Nov 07:56 2014

HSTS: Infinite max-age to address NTP spoofing attack?

 I recently read the slides "Bypassing HTTP Strict Transport Security" by
Jose Selvi.[1] It seems to me that one way to address NTP spoofing attack
on HSTS is to allow sites to specify HSTS policies that never expire (i.e.
infinite max-age), so that the enforcement of HSTS does not depend on the
system time.
 
So I want to propose a update to RFC 6797 to define a new directive called
"infinite" (or something else). When a UA sees this directive, max-age
should be ignored and HSTS should always be enforced until users clear the
cache or the server sends a valid STS header without "infinite" directive.
 
The new header field will look like:
  Strict-Transport-Security: max-age=31536000; infinite
 
Of course, many websites will be unwilling to set infinite max-age, so this
attack is not completely addressed. However, I think this new directive
should help a lot, because some websites, especially those that need to
send and receive sensitive information, such as online banking, are very
unlikely to revert to HTTP in the future. Also, a very long max-age, such
as 20 years used by Twitter, is effectively infinite, but long max-age is
subject to the NTP attack, while an explicit "infinite" is not.
 
Any comments on this? Thanks!
 
Best,
Xiaoyin
[1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf
<div><div dir="ltr">&nbsp;I recently read the slides "Bypassing HTTP Strict Transport Security" by <br>Jose Selvi.[1] It seems to me that one way to address NTP spoofing attack <br>on HSTS is to allow sites to specify HSTS policies that never expire (i.e. <br>infinite max-age), so that the enforcement of HSTS does not depend on the <br>system time.<br>&nbsp;<br>So I want to propose a update to RFC 6797 to define a new directive called <br>"infinite" (or something else). When a UA sees this directive, max-age <br>should be ignored and HSTS should always be enforced until users clear the <br>cache or the server sends a valid STS header without "infinite" directive.<br>&nbsp;<br>The new header field will look like:<br>&nbsp; Strict-Transport-Security: max-age=31536000; infinite<br>&nbsp;<br>Of course, many websites will be unwilling to set infinite max-age, so this <br>attack is not completely addressed. However, I think this new directive <br>should help a lot, because some websites, especially those that need to <br>send and receive sensitive information, such as online banking, are very <br>unlikely to revert to HTTP in the future. Also, a very long max-age, such <br>as 20 years used by Twitter, is effectively infinite, but long max-age is <br>subject to the NTP attack, while an explicit "infinite" is not.<br>&nbsp;<br>Any comments on this? Thanks!<br>&nbsp;<br>Best,<br>Xiaoyin<br>[1] <a href="https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf">https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf</a><br>
</div></div>
Anne van Kesteren | 29 Oct 19:55 2014
Picon

HSTS at DNS level

Is there some way we could add an annotation to DNS that makes it
clear a given domain for the purposes of HTTP is only available over
port 443 using TLS? DNS can be easily spoofed of course so you also
want HSTS, but perhaps it would be sufficient to be able to disable
port 80 entirely.

--

-- 
https://annevankesteren.nl/

Hodges, Jeff | 17 Oct 02:22 2014
Picon

wrt closing the websec WG (was: DISCUSS positions on draft-ietf-websec-key-pinning

On 10/11/14, 1:03 PM, "Barry Leiba" <barryleiba <at> computer.org> wrote:

>  The working group will officially remain open until the RFC is
>published, after which I'll close it, but will leave the mailing list
>open for any continued discussion.

Yes, please do leave the mailing list open, the Web is a percolating pot
and there may well be more protocol-level security stuff boiling over into
IETF territory (I don’t have a firm example right now, but something along
the lines of defining more generic policy-expression format(s) is not hard
to imagine), and so perhaps similar to what we did with HTTP-State, who
knows, we might have a need to re-spin it up.

Thanks,

=JeffH

_______________________________________________
websec mailing list
websec <at> ietf.org
https://www.ietf.org/mailman/listinfo/websec
IETF Secretariat | 13 Oct 17:13 2014
Picon

ID Tracker State Update Notice: <draft-ietf-websec-key-pinning-21.txt>

IESG has approved the document and state has been changed to Approved-announcement sent
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

Jeffrey Walton | 14 Oct 18:33 2014
Picon

Question on Pinning Overrides

Section 2.7 states:

   UAs MAY choose to implement additional sources of pinning
   information, such as through built-in lists of pinning information.
   Such UAs should allow users to override such additional sources,
   including disabling them from consideration.

>From section 2.7, I understand a _user_ can provide an override to a
_preloaded_ pinset. But I don't see where a user is provided the
authority to override a non-preloaded pinset. And I don't see where an
external entity is provided authority to override a preloaded or
non-preloaded pinset.

Is this correct?

If correct, shouldn't the user be allowed to override both preloaded
and non-preloaded pinsets?

If correct, won't that break Chrome with respect to
http://www.imperialviolet.org/2011/05/04/pinning.html (see section
"What about MITM proxies, Fiddler etc?")?

The IESG | 13 Oct 17:13 2014
Picon

Protocol Action: 'Public Key Pinning Extension for HTTP' to Proposed Standard (draft-ietf-websec-key-pinning-21.txt)

The IESG has approved the following document:
- 'Public Key Pinning Extension for HTTP'
  (draft-ietf-websec-key-pinning-21.txt) as Proposed Standard

This document is the product of the Web Security Working Group.

The IESG contact persons are Barry Leiba and Pete Resnick.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

Technical Summary

This spec describes an extension to the HTTP protocol allowing web
host operators to instruct user agents to remember ("pin") the hosts'
cryptographic identities for a given period of time.  During that
time, UAs will require that the host present a certificate chain
including at least one Subject Public Key Info structure whose
fingerprint matches one of the pinned fingerprints for that host.  By
effectively reducing the number of authorities who can authenticate
the domain during the lifetime of the pin, pinning may reduce the
incidence of man-in-the-middle attacks due to compromised
Certification Authorities.

Review and Consensus

Previous versions of this document received useful reviews on the 
mailing list. Many changes were introduced due to working group 
consensus, including to pin format, an includeSubdomains directive,
and interaction with private trust anchors. 

Some changes were proposed and rejected by the working group,
most notably named pins, a "strict" directive, and hard limits on the 
max-age directive. The consensus on these involved a long and hard 
discussion, but as chairs, Tobias and I believe that it is a regular
rather than rough consensus.

Two issues that were left for last were the interaction of pre-loaded
pins with noted pins, and the processing of report-only pins. There 
was a lot of controversy and a lot of back-and-forth about these 
issues. We believe that the current drafts represents the working
group's consensus, although at least one participant would have 
preferred a different outcome.

Personnel

Yoav Nir is the document shepherd. Barry Leiba is the responsible
Area Director.


Gmane