Hodges, Jeff | 14 Jan 00:31 2016
Picon

www.w3.org servers

see below for an interesting announcement re deploying HTTPS/HSTS support
on www.w3.org servers, but first, some quick background..

deploying HSTS [RFC6797] can be tricky for sites having non-trivial
existing deployments of insecure resources (e.g., accessed via
"http://..."), e.g.: www.w3.org.  A large reason this is tricky is "mixed
content blocking" [1], and in which order in user agents' overall
"fetch()" algorithm [2] HSTS and mixed content blocking are integrated.

the W3C WebAppSec WG is developing a means, known as "Upgrade Insecure
Requests" [3], to address this conundrum. Upgrade Insecure Requests
provides a means for webapp deployers (aka "authors") to finess their
migration to a fully secure site, and this along with HSTS is what the W3C
has deployed (see the forwarded announcement below)

[1] https://www.w3.org/TR/mixed-content/
[2] https://fetch.spec.whatwg.org/
[3] https://w3c.github.io/webappsec-upgrade-insecure-requests/

-------- Forwarded Message --------
From:  Wendy Seltzer <wseltzer <at> w3.org>
Organization:  W3C
Date:  Monday, January 11, 2016 at 11:42 AM
To:  "public-webappsec <at> w3.org" <public-webappsec <at> w3.org>
Subject:  Fwd: HTTPS/HSTS support on www.w3.org servers

Thanks to WebAppSec for the specs that helped to make W3C's HTTPS update
possible (and for the prodding to get there even sooner).

Please don't hesitate to share configuration suggestions or bug reports.
(Continue reading)

Yoav Nir | 2 Nov 13:09 2015
Picon

Sniffly

https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf (presentation)


This tool manages to track which sites a user has visited before by finding out if they have HSTS set for that site.  Pretty cool demonstration of how information can leak.

Yoav

<div>
<a href="https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf" class="">https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf</a>&nbsp;(presentation)<div class="">
<a href="https://zyan.scripts.mit.edu/blog/sniffly/" class="">https://zyan.scripts.mit.edu/blog/sniffly/</a>&nbsp; (blog)</div>
<div class="">
<br class=""><div class=""><br class=""></div>
<div class="">This tool manages to track which sites a user has visited before by finding out if they have HSTS set for that site. &nbsp;Pretty cool demonstration of how information can leak.</div>
</div>
<div class=""><br class=""></div>
<div class="">Yoav</div>
<div class=""><br class=""></div>
</div>
jxtps435 | 22 Sep 01:18 2015
Picon

HPKP: Cross-signing with a self-signed certificate and pinning that cert?

I'm interested in implementing HPKP on my sites, but it is a bit tricky to do: 

- We add / remove websites from a single SAN certificate on a semi-regular basis. 

- Our CA recently switched out at least their intermediate, if not their root cert in response to the SHA1 -> SHA256 transition. 

- We'd like to be able to switch root CA for business reasons. 

So pinning any of these certs seems like a recipe for disaster (maybe things won't change in the future, but when they have demonstrably changed in the past I would / should get fired if I don't take that into account).

So basically, I need to be able to switch out our certificates at any time, for any reason, to any CA, without bricking our sites, to be able to use HPKP. 

Sounds impossible, right? 

But wait. What if I could cross-sign my certificates with a self-signed certificate and pin that certificate? 

So the browser would trust the regular root CA's authority, but it would do the pinning to my not-at-all-trusted self-signed certificate, enabling me to update my certs whenever I want, and as long as I can keep my self-signed cert safe no-one else can tamper with our sites. 

Would that work in theory? Would that work with current implementations? Thoughts? 


(I don't know the details of cross-signing, but apparently Google does it: http://googleonlinesecurity.blogspot.com/2015/09/disabling-sslv3-and-rc4.html )


<div><div dir="ltr">I'm interested in implementing HPKP on my sites, but it is a bit tricky to do:&nbsp;<div><br></div>
<div>- We add / remove websites from a single SAN certificate on a semi-regular basis.&nbsp;<br>
</div>
<div><br></div>
<div>- Our CA recently switched out at least their intermediate, if not their root cert in response to the SHA1 -&gt; SHA256 transition.&nbsp;</div>
<div><br></div>
<div>- We'd like to be able to switch root CA for business reasons.&nbsp;</div>
<div><br></div>
<div>So pinning any of these certs seems like a recipe for disaster (maybe things won't change in the future, but when they have demonstrably changed in the past I would / should get fired if I don't take that into account).</div>
<div><br></div>
<div>So basically, I need to be able to switch out our certificates at any time, for any reason, to any CA, without bricking our sites, to be able to use HPKP.&nbsp;</div>
<div><br></div>
<div>Sounds impossible, right?&nbsp;</div>
<div><br></div>
<div>But wait. What if I could cross-sign my certificates with a self-signed certificate and pin that certificate?&nbsp;</div>
<div><br></div>
<div>So the browser would trust the regular root CA's authority, but it would do the pinning to my not-at-all-trusted self-signed certificate, enabling me to update my certs whenever I want, and as long as I can keep my self-signed cert safe no-one else can tamper with our sites.&nbsp;</div>
<div><br></div>
<div>Would that work in theory? Would that work with current implementations? Thoughts?&nbsp;<br>
</div>
<div><br></div>
<div><br></div>
<div>(I don't know the details of cross-signing, but apparently Google does it:&nbsp;<a href="http://googleonlinesecurity.blogspot.com/2015/09/disabling-sslv3-and-rc4.html">http://googleonlinesecurity.blogspot.com/2015/09/disabling-sslv3-and-rc4.html</a> )</div>
<div><br></div>
<div><br></div>
</div></div>
RFC Errata System | 18 Aug 16:34 2015

[Editorial Errata Reported] RFC6797 (4449)

The following errata report has been submitted for RFC6797,
"HTTP Strict Transport Security (HSTS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6797&eid=4449

--------------------------------------
Type: Editorial
Reported by: deo luyimbaazi <luyimbaazi28 <at> gmail.com>

Section: facebook

Original Text
-------------
i cant access Facebook wall through Mozilla Firefox, thank

Corrected Text
--------------
i cant access Facebook wall through Mozilla Firefox, thank

Notes
-----

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6797 (draft-ietf-websec-strict-transport-sec-14)
--------------------------------------
Title               : HTTP Strict Transport Security (HSTS)
Publication Date    : November 2012
Author(s)           : J. Hodges, C. Jackson, A. Barth
Category            : PROPOSED STANDARD
Source              : Web Security
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

Tobias Gondrom | 13 Jun 15:40 2015

FYI: Wikimedia Foundation Turns On HTTPS and HSTS, Including Wikipedia

Hi all,

I thought this might be nice to read for some of us:
Good news, Wikipedia is turning on HSTS. :-)

http://techcrunch.com/2015/06/12/the-wikimedia-foundation-turns-on-https-by-default-across-all-sites-including-wikipedia/

Have a nice weekend, Tobias

Brad Hill | 6 May 18:43 2015

Call for review: Subresource Integrity

WebSec members and interested parties,

The WebAppSec WG at the W3C plans to advance Subresource Integrity to Candidate Recommendation soon and is
asking for wide review of the specification.

This specification defines a mechanism by which user agents may verify that a fetched resource has been
delivered without unexpected manipulation.

http://w3c.github.io/webappsec/specs/subresourceintegrity/

If you wish to make comments regarding this document, please send them to public-webappsec <at> w3.org with
[SRI] at the start of your email's subject. All comments are welcome.

Further sharing of this call for wide review among other interested communities is encouraged.

Thank you,

Brad Hill

RFC Errata System | 5 May 13:28 2015

[Errata Verified] RFC7469 (4354)

The following errata report has been verified for RFC7469,
"Public Key Pinning Extension for HTTP". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7469&eid=4354

--------------------------------------
Status: Verified
Type: Technical

Reported by: Kirit Saelensminde <kirit <at> felspar.com>
Date Reported: 2015-05-04
Verified by: Barry Leiba (IESG)

Section: 3

Original Text
-------------
   As in Section 2.4, the token refers to the algorithm name, and the
   quoted-string refers to the base64 encoding of the SPKI Fingerprint.
   When formulating the JSON POST body, the UA MUST either use single-
   quoted JSON strings or use double-quoted JSON strings and backslash-
   escape the embedded double quotes in the quoted-string part of the
   known-pin.

....

      'pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="',

Corrected Text
--------------
   As in Section 2.4, the token refers to the algorithm name, and the
   quoted-string refers to the base64 encoding of the SPKI Fingerprint.
   When formulating the JSON POST body, the UA MUST use double-quoted
   JSON strings and backslash-escape the embedded double quotes in the
   quoted-string part of the known-pin.

....

      "pin-sha256=\"d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=\"",

Notes
-----
This RFC seems to think that single quotes are permissible in JSON. This is not the case. See http://tools.ietf.org/html/rfc7159#section-7

--------------------------------------
RFC7469 (draft-ietf-websec-key-pinning-21)
--------------------------------------
Title               : Public Key Pinning Extension for HTTP
Publication Date    : April 2015
Author(s)           : C. Evans, C. Palmer, R. Sleevi
Category            : PROPOSED STANDARD
Source              : Web Security
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

RFC Errata System | 5 May 08:01 2015

[Technical Errata Reported] RFC7469 (4354)

The following errata report has been submitted for RFC7469,
"Public Key Pinning Extension for HTTP".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7469&eid=4354

--------------------------------------
Type: Technical
Reported by: Kirit Saelensminde <kirit <at> felspar.com>

Section: 3

Original Text
-------------
   As in Section 2.4, the token refers to the algorithm name, and the
   quoted-string refers to the base64 encoding of the SPKI Fingerprint.
   When formulating the JSON POST body, the UA MUST either use single-
   quoted JSON strings or use double-quoted JSON strings and backslash-
   escape the embedded double quotes in the quoted-string part of the
   known-pin.

....

      'pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="',

Corrected Text
--------------
   As in Section 2.4, the token refers to the algorithm name, and the
   quoted-string refers to the base64 encoding of the SPKI Fingerprint.
   When formulating the JSON POST body, the UA MUST use double-quoted
   JSON strings and backslash-escape the embedded double quotes in the
   quoted-string part of the known-pin.

....

      "pin-sha256=\"d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=\"",

Notes
-----
This RFC seems to think that single quotes are permissible in JSON. This is not the case. See http://tools.ietf.org/html/rfc7159#section-7

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7469 (draft-ietf-websec-key-pinning-21)
--------------------------------------
Title               : Public Key Pinning Extension for HTTP
Publication Date    : April 2015
Author(s)           : C. Evans, C. Palmer, R. Sleevi
Category            : PROPOSED STANDARD
Source              : Web Security
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

Alice Wonder | 20 Apr 19:02 2015
Picon

Suggestions for Fixing PKI

Dear List,

This is just for thought, I have neither the resources nor energy to 
push it through.

I would use the existing DNS system to do the equivalent of OCSP stapling.

ICANN creates a new TLD, we can call it pki.

Only certificate authorities can register names in pki.

The registry `Example Certificates, LTD.' would register example.pki

Even though the system uses the DNS system, only a limited subset of RR 
types would be allowed in the pki. TLD.

For example, MX and A and AAAA records etc. should not be allowed, it is 
a utility TLD intended to serve as infrastructure.

For the serial number in the SOA record, seconds since UNIX epoch would 
be what I would suggest. As serial is 32-bit that will eventually wrap 
but DNS allows for serial to wrap. Whether it is seconds since UNIX 
epoch or something else doesn't matter but I do suggest the serial be 
standardized, and YYYYMMDDnn does not allow enough updates in a 24 hour 
period.

BIND etc. probably shouldn't be used for the master, the master should 
probably be a custom server that talks to the CA's database and probably 
shouldn't have a public facing IP address, but bind / NSD / whatever 
could serve as slaves, there is no need for non-standard RR types to be 
used and they shouldn't be used.

Each signed certificate will have a serial number assigned by the 
certificate authority. That may actually already exist. I would suggest 
they be ASCII characters <= 63 with existing DNS label limitations, but 
no need for hostname restrictions. For example d3we74ldqw1190 could be a 
valid serial number. The serial number should be included in the signed 
TLS certificate.

For each valid certificate, the DNS server will respond as an 
authoritative DNS to a request for a TXT record of the serial number. 
For example:

     dig TXT d3we74ldqw1190.example.pki. +short

would then get the rdata for that certificate, with a record that can be 
DNSSEC validated, if the certificate is valid.

If the certificate is revoked, I *might* get a DNSSEC signed response. 
If the certificate was never issued then I would get a DNSSEC signed 
response stating is does not exist. NSEC is probably good enough for 
that, doesn't need the complexity of NSEC3 IMHO.

For the rdata - it should include the OCSP uri, timestamp, and whether 
or not the certificate was valid at the time of the timestamp.

TLS clients could then validate a certificate by doing a simple DNS 
query. If they don't get a DNSSEC validating response, they fall back to 
using the OCSP URI provided in the certificate.
If they get a validating response stating the record does not exist, 
they reject the certificate.
If they get a validating response stating the record does exist but the 
certificate has been revoked, they reject the certificate.
If they get a validating response stating the record does exist and the 
certificate was not revoked, the client can then look at the timestamp 
and if it is recent enough - accept the certificate, otherwise do the 
OCSP lookup itself.

This would solve the problem of certificate authorities having the 
ability to track users, because the client would be using their local 
recursive resolver to query for the information. It would also solve the 
problem of a sudden spike at a web site radically increasing traffic at 
the certificate OCSP server, because the local resolvers would cache the 
requests until the TTL expires.

Obviously this solution needs more details and someone to take the idea 
to the appropriate powers, but that is how I would solve the revoked 
certificate problem if I was emperor of the Internet.

I would personally limit the RR types to SOA, TXT, RP, and the DNSSEC RR 
types, and DNSSEC should be required. But there may be valid reasons for 
some other RR types. I would suggest that CAs push updates to the slaves 
every 5 to 10 minutes. For the TTL on TXT records, 1800 would be what I 
would use but it seems to me like a lot of resolvers ignore that and 
make up their own TTL. For the negative TTL I would suggest 120 seconds. 
But really until this is implemented those are just numbers, real usage 
will help refine them.

Thank you for your time,

Alice Wonder

Tobias Gondrom | 15 Apr 17:22 2015

FYI: presentation about HSTS and key pinning adoption at last IETF 92 SAAG meeting

Hi guys,

just fyi: there was 2 weeks ago an interesting presentation at the IETF 
92 SAAG about HSTS and key pinning adoption. If you are interested you 
can watch it here:

http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_SAAG&chapter=chapter_0 
(you can jump to minute 24 and play).

Best regards, Tobias

Phillip Hallam-Baker | 9 Apr 00:00 2015

DNS publication of HSTS and PKP header data using CAA

http://tools.ietf.org/html/draft-hallambaker-webseccaa-00

It is a pretty straightforward proposal:

* Use the CAA record with either the hsts or hpkp tag
* Put the same text you would have put into the CAA record value field

There are a few differences in interpretation. All we are trying to do
here is to help people to close the 'secure after first use' hole, not
replace.

Given that we have quite a bit of use of HSTS headers, providing a
mechanism for publishing this in the DNS looks like being the obvious
approach.


Gmane